OpenAI 揭露 Habitat 儲存架構：每週逾十億人使用背後的規模與極限

2026 年 9 月 11 日，OpenAI 在官方工程部落格發布文章《Rapidly scaling online storage to serve over 1 billion ChatGPT users》，說明內部儲存平台 Habitat 這幾年怎麼從一個 Python 用戶端函式庫，演變成一套獨立運作的服務。文章掛在 Engineering 分類下，作者具名為三位技術人員 Jon Lee、Chaomin Yu 與 Ben Ries，文末附上一個工程職缺連結，是一篇技術部落格，不是新產品或新方案的公告。

本文於 2026 年 9 月 18 日查核 OpenAI 官方文章原文、OpenAI 官方新聞 RSS feed，以及官方網站地圖 Engineering 分類頁。openai.com 的文章頁在先前幾天一度只回應存取限制頁面，本文查核當天已能直接讀取正文。以下數字全部是 OpenAI 自己的說法，本站沒有做任何測試，也不提供任何購買或使用建議；本文沒有使用虛構的生活情境。

這篇文章是什麼：一篇工程部落格，不是新產品公告

OpenAI 把這篇文章歸類在 Engineering（工程）分類下，說明 Habitat 是自己打造的線上儲存平台，讓旗下產品能快速、可靠地取得需要的資料：使用者登入、查看 Codex 設定或在 ChatGPT 開新對話，背後都可能牽涉多次資料查詢。OpenAI 寫道，這些查詢一慢，產品就會讓人覺得慢；查詢失敗，產品就直接無法運作。

文章開頭的統計方塊並列三個數字：每秒超過 7000 萬次請求、每週超過 10 億人，以及超過 500 PB 的資料量；OpenAI 說明 Habitat 最早是 2023 年 DevDay 為了支援 GPTs 而推出，一開始只是一個連到單一資料庫的 Python 用戶端函式庫，如今已成長為一套複雜的分散式系統。

文章末尾附上一個工程職缺連結（網址裡帶著西雅圖的地名）；這是儲存主題兩篇系列文章的第一篇，第二篇預定說明多租戶可靠性、讀取效能分層策略，以及和 Azure Cosmos DB 的合作方式如何擴大。以官方網站地圖與新聞 feed 查核到 2026 年 9 月 18 日，都還沒有看到第二篇的項目，也沒有公布日期。

OpenAI 說的規模：幾個數字要放在一起看

OpenAI 在文章正文寫道，Habitat 現在每秒處理超過 7000 萬次請求，支撐旗下產品每週被超過 10 億人使用，服務範圍涵蓋近 40 個地區；文章沒有列出地區的國家或城市名稱，只在一張自陳為「簡化」的示意圖上，出現 us0、us1、eu0 三個範例資料庫代號，那是圖上的標籤，不是一份公布的地區清單。

值得留意的是，OpenAI 官方 RSS feed 與網頁的中繼資料另外寫著「22M requests per second」，但本文查核當天重新讀過正文全文，這個數字只出現在摘要與中繼資料裡，正文從頭到尾沒有再提過，也沒有交代它和 7000 萬、2000 萬有什麼關係。

OpenAI 也說明，過去 3 年他們每年成長幅度超過 10 倍；文中原句提到，系統工程師通常抓 10 倍規模做設計，希望撐個幾年，同時準備下一個 10 倍。

為什麼一次變慢的查詢，使用者會感覺得到

OpenAI 解釋，當一般使用者的一次請求會帶出幾百次資料庫呼叫時，使用者感覺到的就是最慢的那一次。文章把管理這種「尾端延遲」（少數特別慢的查詢）稱為在這個規模下跑 Python 服務的主要挑戰。

文章舉了一個案例：Habitat 用 Statsig 這套功能開關工具，預設每分鐘輪詢一次更新後的設定、沒有錯開時間差，而那份設定包含每個服務的每一條正式環境規則；疊上「一個 Pod 最多跑 8 個 Python 處理程序」的架構決定後，變成每分鐘每個 Pod 都會有某個瞬間，所有工作處理程序同時停下手上的請求，改去解析那份龐大的設定檔。OpenAI 說一旦用 CPU 剖析定位到根因，修法就很單純：改用範圍更小的設定、拉長輪詢間隔，並替這類背景工作加上隨機時間差。

另一個案例和連線池有關：OpenAI 說 Python 的 aiohttp 函式庫預設優先重複使用最近釋出的連線，平常是合理的預設；但流量突增時，比較慢、已經過載的伺服器比較晚把連線還回池子，反而更常被後續請求選中，流量逐漸集中到本來就吃力的 Pod 上。OpenAI 稱這是一種「亞穩態故障」（metastable failure）：造成過載的用戶端停掉之後，仍有一部分處理程序持續惡化，要重開才恢復。改成優先使用最早釋出的連線後，不只解掉回饋循環，連穩態下的請求量落差也跟著變小；現在這類連線管理大多交給 Istio 與 Envoy 負責。

OpenAI 沒有在這篇文章說明的事

本文以英文原詞逐字比對，文章沒有出現 durability、backup、replica 這幾個字，也沒有寫出一份資料會保留幾個副本；OpenAI 只描述過一次想把最關鍵的資料集移到跨地區分散的 Azure Cosmos DB 帳戶、以縮小單一地區故障影響範圍的經過，沒有再說明保存或備援機制。文章也沒有任何可用性數字或服務水準協議，只描述了幾次自家系統出過的狀況，例如某個團隊因為不相干的原因把自己的服務回滾到帶有問題用戶端的舊版本，反而引發原本想避免的事故，但沒有標明日期、時長或對使用者的實際影響。

地區方面，文章只寫近 40 個地區，沒有把任何國家或城市寫成資料存放地點，也沒有提到台灣或亞洲；比較接近地區資訊的，是示意圖上那三個資料庫代號，以及職缺連結網址裡的城市名。文章同樣沒有交代 Habitat 實際存放哪些資料——登入、查看 Codex 設定、開新對話都可能需要查資料，但沒有明講對話內容是否存在 Habitat 裡，只說這裡是保護使用者資料、防止外部、內部與代理程式未經授權存取的關鍵位置。

改寫成 Rust 之後的數字也一樣：OpenAI 說自家數據顯示，新版本的 CPU 效率是原本的 6 倍、記憶體效率是 15 倍，平均與尾端延遲都顯著降低，目前處理 95% 的正式環境請求，並計畫在未來幾週內完全停用 Python 版本；OpenAI 也說之後會再發一篇分享更多心得，這個後續同樣沒有公布日期。文章沒有附上測試方法、測試情境或第三方查核，這些數字目前只能視為 OpenAI 自己公布的內部量測結果。

讀者可以怎麼看待這篇文章

這篇文章沒有公布任何新產品、新方案、新地區或新設定，ChatGPT 或 Codex 的使用者不需要因此做任何調整；OpenAI 自己在文章裡也沒有宣稱使用者會感覺到更快或更省，改寫的效益目前只停留在 OpenAI 自己內部的說法。

這篇文章比較適合當成一個提醒：服務背後都有自己的儲存與可用性設計，而營運方自己公布的規模數字，不管是請求量、使用者數或成長倍數，在有第三方查核之前都只能算廠商自己的說法；讀者可以留意文章有沒有提到耐久性、服務水準協議或事故細節，這通常比單一個亮眼數字更能反映服務的穩定程度。

想確認後續進度的讀者，可以自己查兩個免費的官方管道：OpenAI 的新聞 RSS feed，以及工程分類的網站地圖，本文就是用這兩個管道確認第二篇還沒出現。要注意網站地圖上標的時間和頁面印出的發布日期對不起來，不宜當成文章的發布日或更新日，這是本文查核當天的觀察。

2026 年 AI 新聞總整理：1 月至 9 月的重點與生活應用

OpenAI 與 Broadcom 發表 Jalapeño 晶片：官方說的階段、分工，與還沒公布的事

• AI 工具
• 軟體與 App
• AI 新聞與趨勢