當一個使用者按下送出，背後可能是上百次資料庫查詢。任何一次慢，使用者就覺得產品慢；任何一次失敗，產品就直接不能用。這是 OpenAI 在 2026 年 9 月 11 日發布的技術文章開頭所描述的處境，也是他們打造線上儲存平台 Habitat 的原因。
根據該篇由 OpenAI 發布的說明，Habitat 目前每秒處理超過 7,000 萬次請求，服務每週超過 10 億人使用的產品，橫跨近 40 個地理區域，承載超過 500 PB 資料。更關鍵的是成長曲線：過去三年，這個系統每年成長超過 10 倍。
從函式庫變成服務，是為了收斂協調成本
Habitat 在 2024 年中誕生時，只是一個連到 Azure Cosmos DB 的 Python 客戶端函式庫。它的價值在於讓產品工程師不必理解 schema 查詢、路由、授權、加密、序列化、請求塑形與連線池。
到了 2025 年中，這個模式撞到牆。OpenAI 舉了一個具體例子：他們想把最關鍵的資料集搬到一組區域分散的 Cosmos DB 帳號，以縮小單一區域故障的影響範圍。這件事需要在客戶端加入額外路由邏輯、用 feature flag 包住、確認推送到所有客戶端，再開啟開關。跨數十個服務協調部署花了數天；想加 shadowing 驗證 sharding 邏輯正確，又是數天；發現 bug 要修，再數天。最後準備開 flag 時，某個團隊因為無關原因回滾到有 bug 的舊客戶端，把他們努力想避免的故障真的引發了。
把儲存邏輯抽成獨立服務，換來的是部署、可觀測性與平台改進的單一控制點。OpenAI 也把這視為安全上的收斂點：存取控制政策、稽核日誌、對底層儲存資源的存取限制，都集中在這一層執行。
明知 Python 不划算，還是先選它
Habitat 服務用 Python 寫。OpenAI 自己說得很直白：相較於本地函式庫執行，Python 服務會增加網路延遲，也帶來可觀的 CPU 與記憶體擴充成本，而且這些低效在 100 倍規模下不會被接受，未來幾乎確定要重寫。
他們把這筆帳稱為策略性的技術債。當下的目標不是成本最佳化，而是解開產品開發者的阻塞、取得平台穩定性。他們同時押注自家 coding model 的進步速度，認為等到非遷移不可時，Codex 與 GPT 能讓遷移變得可行，而這個賭注後來證明是對的。
這種「先買時間、再補地基」的順序安排，和我們在前綴感知路由：讓 KV cache 不再被隨機打散裡看到的取捨是同一類問題：延遲預算有限時，先決定哪一段可以暫時不完美。
尾延遲的敵人不是資料庫，是 event loop
當平均每個使用者請求會產生數百次資料庫呼叫，使用者感受到的是最慢的那一次。OpenAI 指出，在這種規模下跑 Python 服務，主要挑戰就是管理尾延遲。
他們的觀察很具體：asyncio 能讓 I/O 密集工作併發執行，但繞不開 GIL，也提供不了 CPU 平行。Habitat 除了代理請求，還要做路由、壓縮、加密、checksum、下游健康檢查、請求 shadowing 與 hedging 等 CPU 密集工作。在 p99 以上的延遲軌跡裡，下游儲存其實回應得很快，請求卻卡在等待協程被重新排程去解析回應。
他們用一個實測方法量測 event loop 排程延遲：定期排入背景任務，記錄預期與實際執行時間的落差。高利用率下，即使每個 process 只有少量併發請求，也可能產生數百毫秒、極端情況達數秒的排程抖動。對策是讓每個 process 只服務少量併發請求，改為大量水平擴充 Python worker process。
兩個被 profiling 抓出來的具體 bug
第一個是 feature flag 設定。Statsig 預設每分鐘輪詢一次更新且沒有 jitter，而設定檔包含所有服務的所有 production 規則；同時架構上每個 pod 跑最多 8 個 Python process。結果是每分鐘每個 pod 都會有一刻，所有 worker 停下手上請求，把 CPU 花在解析一份巨大設定檔。修法很單純：部署更小的目標設定、拉長更新間隔、加上 jitter。
第二個是連線池與負載平衡的衝突。客戶端連線池可能讓一個發出大量併發請求的 client process 只建立少數幾條伺服器連線，把全部負載壓到少數 process 上。在調整負載平衡方式之前，他們的服務利用率變異很大，最尾端的 process 承受的併發請求數是中位數的 5 到 10 倍。
對產品開發者的實際意義
這篇是兩部曲的第一篇，OpenAI 表示後續才會細談大規模多租戶可靠性、讀取效能的分層最佳化策略，以及與 Azure Cosmos DB 的合作如何擴展。也就是說，這裡看到的只是前半段。
可帶走的判斷有兩點。第一，把儲存邏輯抽成服務的時機，往往不是效能問題，而是協調成本問題——當一次改動要跨數十個服務、花上數天還可能被別人的回滾抵銷，抽象層的價值就出現了。第二，當你選擇用一個不擅長高吞吐的語言先上線，就必須同時建立量測能力，否則你連自己欠了多少技術債都不知道。OpenAI 是靠 CPU profiling 才找到那兩個每分鐘發作一次的延遲來源，而不是靠猜。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。