核心觀點

OpenAI 將線上儲存平台 Habitat 從 DevDay 2023 時期、連接單一資料庫的 Python 用戶端函式庫，演進為服務 ChatGPT、API、Codex 與內部系統的全球分散式平台。官方稱其現已覆蓋近 40 個地區、每週支撐逾 10 億使用者、處理每秒逾 7,000 萬次請求並服務逾 500 PB 資料。這篇文章真正值得讀的不是規模數字，而是其順序：先解除產品團隊的協調瓶頸，再逐步解決尾端延遲、連線放大與成本效率。

從函式庫改成服務：把更新與治理收回中心

早期 Habitat 代替產品工程師處理 schema 查找、路由、授權、加密、序列化、連線池與請求塑形；但當它仍是各服務內嵌的函式庫，每次協議或路由調整都得等待數十個服務升版。官方以跨區 Cosmos DB 遷移為例：功能旗標、shadowing 與逐團隊部署都會拉長變更時間，任何服務回滾到舊客戶端又可能重現已修正的風險。

獨立成服務後，Habitat 成為部署、可觀測性、存取控制與稽核日誌的單一控制點，也能集中保護 Cosmos DB、快取等底層資源。這是 OpenAI 全棧智能：晶片、算力、模型與產品的複利 所說「產品層可靠交付」的具體版本：基礎設施價值不在藏掉資料庫，而在把安全與變更成本由每個產品團隊各自負擔，改為平台統一治理。

Python 的策略性技術債：先穩定，再重寫

OpenAI 沒有立刻重寫服務，而是暫時接受 Python 的網路、CPU 與記憶體開銷，優先確立服務邊界與平台穩定度。問題是 asyncio 雖能並行 I/O，卻無法跨越 GIL 提供 CPU 平行性；路由、壓縮、加密、checksum、健康檢查與 request shadowing 都會擠壓事件迴圈，讓已返回的下游回應延遲被排程卡住。

團隊把事件迴圈的預期與實際執行時間差納入監測，並以小量併發、多 worker process 控制尾端延遲。一次 CPU profiling 還發現，所有 worker 同時解析大型 feature-flag 設定檔會造成週期性卡頓；縮小設定範圍、延長更新間隔並加入 jitter 才解除尖峰。這說明高併發 Python 的關鍵不只是 CPU 使用率，而是「排程延遲是否正在偷走 p99」。

連線池也會製造事故

文章另一個實用細節是 aiohttp 預設 LIFO 重用連線的副作用：流量突增後，較慢的 server 最晚歸還連線，卻更容易被再次挑中，形成流量持續集中於過載節點的 metastable failure。改為 FIFO 重用可打破這個回授迴圈；後續 Habitat 改以 Istio 與 Envoy 提供較能感知負載的平衡、HTTP/2 多工、連線匯聚、rate limit 與 circuit breaker。

這與 MRC 超算網路協議：OpenAI 的多路徑可靠連接技術 的共同教訓一致：大規模系統的失效往往不是單一元件壞掉，而是局部變慢後的路由或重試規則，反過來把更多工作推向原本最脆弱的位置。觀測資料必須能揭示負載分布與回授，而非只看平均吞吐。

可預期成本比通用查詢更重要

Habitat 刻意只暴露可預測、近乎 constant-work 的 NoSQL API，避免任意 SQL scan 或 join 把線上儲存拖垮。客戶端定義物件與直接邊關係；複雜分析、搜尋需求則透過 CDC 串到隔離的 Rockset 次要視圖。這不是功能不足，而是將即時交易與分析型負載分離，讓各自的容量、隔離與成本責任可被管理。

Rust 重寫與導入判讀

Python 版本最高曾承擔每秒逾 2,000 萬請求；OpenAI 稱 2026 年第二季由兩位工程師搭配 Codex、GPT-5.5 完成 Rust 重寫，目前 95% 正式流量已轉移，並報告 CPU 效率提升 6 倍、記憶體效率提升 15 倍及更低延遲。這是供應商自行發布的數據，宜視為架構案例而非通用基準。

可複製的原則是：先把跨團隊變更、權限與可觀測性收斂到平台邊界；再以 p99、事件迴圈延遲、連線分布及下游飽和度定位瓶頸；最後才在介面與流量模型穩定後，決定是否付出重寫成本。先重寫，很帥；先不讓全公司一起等版本，通常更有用。

相關連結

反向連結

以下頁面引用了本頁：