OpenAI Habitat 擴展以支援超過 10 億名 ChatGPT 用戶
TL;DR
OpenAI 宣布其 Habitat 存儲平台目前每秒處理 >7000 萬個請求，儲存 >500 PB，並支援超過 10 億名每周 ChatGPT 用戶，該平台從一開始的簡單 Python 客戶端程式庫，演變為現今的分散式服務，並正以 Rust 重寫以提升效率。
Habitat 成長概覽
Habitat 目前每秒處理超過 7000 萬個請求，服務遍及約 40 個區域的超過 10 億名用戶，並儲存超過 500 PB 的資料。 此系統於 2024 年中從 Azure Cosmos DB 上的輕量級 Python 客戶端程式庫起家，如今已發展為一個複雜且全球分散的儲存服務。
服務取代程式庫的原因
在數十個服務之間協調協定變更變得脆弱，促使轉向集中式服務。 客戶端程式庫需要功能旗標發佈、影子測試與多區域路由邏輯，協調需耗時數日，仍會導致中斷。將儲存邏輯集中化，讓 OpenAI 擁有一個統一的部署、監控、安全與政策執行點。
架構選擇與權衡
Python 服務作為戰略性切入
- 以 Python 服務運行 Habitat 帶來更高的延遲與 CPU/記憶體成本，但能快速交付核心 API 與平台穩定性。
- OpenAI 接受效能損失，預期未來的 Codex/GPT 基於工具將簡化後續遷移。
管理 Python 中的尾部延遲
- Asyncio 排程延遲 主導了 p99+ 延遲，因為 CPU 負載高的任務（路由、壓縮、加密、健康檢查）會阻塞事件迴圈。
- 監控事件迴圈延遲並限制每個程序的併發請求數，迫使工作程序進行巨量的水平擴展。
功能旗標設定瓶頸
- 每分鐘定期解析大型 Statsig 設定檔的 JSON，導致同一 Pod 中所有工作程序每分鐘停頓一次。
- 解法：縮小設定大小、延長更新間隔、為背景任務加入隨機抖動（jitter）。
連接池負載平衡問題
- aiohttp 的
TCPConnector預設使用 LIFO 重用，造成一種不穩定的反饋迴圈：較慢的 Pod 回傳連接較晚，導致後續請求再次路由至它們，加劇負載。 - 改為 FIFO 重用後打破迴圈，並顯著降低每程序使用率的變異性。
- 現在由 Envoy/Istio 提供連接池、HTTP/2 多工與集中式速率限制，避免「雷鳴群羊效應」。
約束式 NoSQL API 作為可擴展性槓桿
Habitat 故意提供簡單的 NoSQL API，而非任意 SQL，以保持請求成本可預測。 客戶端定義物件與邊（受 TAO 啟發），但無法執行無界查詢，防止昂貴的表格掃描，並保護服務免於濫用。複雜的分析查詢則透過 CDC 流轉至 Rockset 處理。
從 Python 迁移到 Rust
2026 年第二季，OpenAI 將 Habitat 重寫為 Rust，目前處理 95% 的生產流量。 據報告，Rust 服務的 CPU 效率提升 6 倍、記憶體效率提升 15 倍，平均與尾部延遲顯著降低。Python 實作（曾達到 >2000 萬請求/秒）將在接下來幾週內停用。
未來方向（第二部分）
- 第二部分將詳述多租戶可靠性、讀取效能分層，以及支援 500 PB 儲存層的 Azure Cosmos DB 合作關係。
- 持續進行的工作包括進一步優化連接聚合、電路斷路，以及擴展 Rust 服務以應對持續成長的用戶，超越目前每年 10 倍的成長軌跡。
關鍵要點
- Habitat 的演進展示了快速發展的產品團隊如何在優先考量開發者速度（Python 服務）的同時，規劃長期效率（Rust 重寫）。
- 在擴展高吞吐量儲存服務時，對 API 表面的嚴格控制、事件迴圈的仔細監控，以及正確的連接池策略至關重要。
- 將儲存邏輯集中化，可讓 OpenAI 在龐大的全球分佈用戶群中，實現統一的安全性、監控與快速功能發佈。