摘要： 就這篇由 OpenAI 親自發布的說明來看，Habitat 現在每秒要消化超過 7,000 萬次請求，它所支撐的產品每週有超過 10 億人使用，部署版圖橫跨近 40 個地理區域，管理的資料量超過 500 PB。 此刻要解決的並不是成本最佳化，而是讓產品開發者不再被卡住、讓平台先穩定下來。 如果平均每個使用者請求會觸發數百次資料庫呼叫，那麼使用者實際感受到的，就是最慢的那一次。
使用者按一次送出，背後可能就散成上百次資料庫查詢；而使用者唯一感受到的，是其中跑得最慢的那一次。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 把它包起來、確認每個客戶端都收到推送，然後才能把開關扳開。光是跨數十個服務協調部署就耗掉數天；為了驗證 sharding 邏輯是否正確而補上 shadowing，又是數天；中途發現 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 找出來的，不是靠猜。