ChatGPT 服務超過 10 億人，資料怎麼存？OpenAI Habitat 架構、Python 瓶頸與 Rust 遷移解析

當你登入 ChatGPT、查看 Codex 設定，或開始一段新對話，畫面背後可能已經進行數十甚至數百次資料查詢。模型回覆得再快，只要其中一筆關鍵資料卡住，使用者感受到的仍然是「ChatGPT 很慢」。

OpenAI 在 2026 年 9 月 11 日首度完整介紹自建的線上儲存平台 Habitat。官方公布，這套系統目前每秒處理超過 7,000 萬次請求，支援每週超過 10 億人使用的產品，橫跨近 40 個地理區域，管理超過 500 PB 資料。

Habitat 不是新的 AI 模型，也不是 ChatGPT 的長期記憶功能。它比較像 OpenAI 產品共用的資料交通中心：產品只要提出需求，Habitat 就負責判斷資料在哪裡、能不能存取、該走哪條路，以及如何避免一個服務拖垮整套系統。

這段工程故事最值得看的，不只是 7,000 萬次請求的規模，而是 OpenAI 如何在高速成長時接受一段「明知不是終點」的 Python 技術債，先把產品穩住，再用 Codex 與 GPT-5.5 協助遷移至 Rust。對正在打造 AI 產品的團隊來說，這比單純比較哪種程式語言最快更有參考價值。

Habitat 是什麼？它不是模型記憶，而是產品的資料交通中心

Habitat 是 OpenAI 自建的 online storage platform，也就是讓線上產品快速讀寫應用資料的平台。它在 2023 年 DevDay 推出 GPTs 時首次上線，最初只是一個連接 ChatGPT 主伺服器與 Azure Cosmos DB 的 Python 程式庫。

產品工程師不必直接處理資料庫的每個細節。當服務送出一筆請求，Habitat 會負責 schema lookup、routing、authorization、encryption、serialization、request shaping 與 connection pooling。

白話來說，它會回答幾個問題：這筆資料是什麼、放在哪個儲存系統、誰有權限讀取、如何加密傳輸，以及一次能送多少請求。底層資源可能是 Azure Cosmos DB、快取、Blob storage，或其他資料服務，但產品端使用的是同一套介面。

這種抽象層的價值，是讓 ChatGPT、Codex、API 與內部服務不必各自重做資料存取能力。不過，OpenAI 這篇文章說明的是系統架構，並沒有公開每一類使用者資料的保存期限、完整欄位或加密實作。因此，不能只靠這篇工程文章推論 ChatGPT 的隱私政策或資料保留方式。

每秒 7,000 萬次請求、500 PB 資料，規模到底有多大？

OpenAI 公布的三組數字，分別代表流量、使用規模與資料量。

如果把每秒 7,000 萬次請求假設為全天維持同一速度，換算後一天會超過 6 兆次。OpenAI 並未公布實際每日總量，這裡只是協助理解量級的試算。除了買更多伺服器，團隊還得確保每次擴容、更新與故障都不會讓前台產品停擺。

OpenAI 表示，一般系統工程師可能先設計能承受 10 倍成長的架構，再用幾年準備下一次擴充。但 Habitat 過去 3 年每年都成長超過 10 倍，團隊沒有等待「一次到位」的空間，只能一面榨出既有系統的容量，一面替下一代架構爭取時間。

為什麼 Habitat 從 Python 程式庫變成獨立服務？

最初把 Habitat 做成共用程式庫，優點是開發快。產品團隊只要更新套件，就能加入快取、壓縮或加密能力。當使用 Habitat 的服務變多後，這個做法卻產生新的營運風險。

OpenAI 曾想把重要資料分散到多個區域的 Azure Cosmos DB 帳戶，降低單一區域故障的影響。團隊必須先把新的路由邏輯放進每個服務，再逐一部署、進行 shadowing，最後開啟 feature flag。

Shadowing 是把正式請求複製一份給新邏輯測試，但不讓測試結果影響使用者。Feature flag 則是用開關控制新功能何時生效。兩者原本都用來降低風險，問題是幾十個服務的版本很難永遠同步。OpenAI 花了數天協調更新，最後仍有團隊因其他原因回滾到含有舊錯誤的版本，反而造成原本想避免的中斷。

因此，OpenAI 在 2025 年中把 Habitat 從程式庫拆成獨立服務。產品端保留輕量 client SDK，路由、部署、監控與平台功能則集中到 Habitat service。此後只要中央服務更新，所有產品就能一起受益，不必等待每個團隊重新部署。

這項集中化也讓存取控制、稽核紀錄與底層資料庫權限有單一執行點。它能降低版本分裂與權限散落的風險，但也讓 Habitat 成為必須特別保護的關鍵層。中央服務若設計不當，影響範圍同樣會更大，所以集中控制必須搭配隔離、限流與可觀測性，而不是把所有責任塞進同一支程式。

明知 Python 不夠省，OpenAI 為什麼仍先用它？

把 Habitat 變成網路服務後，Python 的成本變得更明顯。原本在應用程式內呼叫函式，現在每筆資料都要經過網路、序列化與獨立服務，CPU、記憶體與延遲都會增加。OpenAI 也知道，Python 的效率無法支撐再成長 100 倍後的需求，日後幾乎一定要重寫。

團隊仍選擇先用 Python，因為當時的優先事項是讓產品團隊能持續開發，並把共用 API、監控與營運方式穩定下來，降低單位成本可以稍後處理。OpenAI 將這稱為策略性承擔技術債。

這個判斷對 MVP 團隊很實際。過早改用效能更高、但團隊不熟悉的語言，可能同時面臨需求還在變、介面尚未穩定與遷移成本過高。先用熟悉工具驗證服務邊界，再在瓶頸有數據時重寫，通常更容易控制風險。

但這個策略成立有前提：團隊必須知道技術債在哪裡、持續量測，並保留替換路徑。若只是以「先做 MVP」為理由，不設定容量門檻與遷移條件，暫時方案很容易變成無限期方案。

Python 真正的瓶頸，不是平均速度，而是最慢的那 1％

一次使用者操作可能引發數百筆資料查詢。即使大部分查詢很快，只要其中一筆特別慢，整個畫面仍得等待。因此，Habitat 最在意的是 tail latency，也就是延遲分布尾端那些最慢的請求。

例如 p99 latency 代表 99％ 的請求都比這個時間快，剩下約 1％ 更慢。對小型服務來說，1％ 似乎不多；但當一個操作串起數百筆查詢，使用者碰到慢請求的機率會被放大。

OpenAI 使用 Python 的 asyncio 同時等待大量網路 I/O。asyncio 是事件迴圈：一個工作等待資料時，CPU 可以先處理另一個工作，但同一執行緒無法同時執行多個 CPU 密集任務。Python 官方文件也提醒，只要某段 CPU 工作阻塞 1 秒，同一事件迴圈上的其他任務與 I/O 都會一起延遲。

Habitat 除了轉送資料，還要處理路由、壓縮、加密、checksum、健康檢查與請求複製。當 CPU 忙碌時，資料庫可能早已回傳結果，負責解析回應的 coroutine 卻還在排隊。OpenAI 量到的排程抖動可達數百毫秒，極端情況甚至達數秒。

團隊限制每個 Python process 的同時請求數，再水平增加大量 process，避免把更多請求塞進單一 process。這提高了資源成本，卻能換取比較穩定的尾端延遲。對使用者而言，穩定地快通常比平均值漂亮、偶爾卡住更重要。

一個每分鐘更新的設定，為什麼會拖慢整個服務？

Habitat 初期曾出現規律的高尾端延遲。CPU profiling 最後找到一個不起眼的原因：feature flag 工具 Statsig 預設每分鐘更新一次設定，而且所有 worker 在相近時間解析包含全公司規則的大型 JSON 檔案。

當時一個 pod 最多執行 8 個 Python process。每逢設定更新，這些 worker 會同時把 CPU 用在解析 JSON，正在處理的使用者請求只能等待。單次工作並不複雜，大量背景任務同時啟動才是問題來源。

OpenAI 的修正很直接：只下發 Habitat 需要的設定、延長更新間隔，並替背景工作加入 jitter。Jitter 是刻意加入少量隨機時間差，避免所有節點同時啟動相同工作。

這個案例提醒產品團隊，排程設成「每分鐘一次」不代表成本平均分散。當數百個服務副本使用相同時鐘，普通背景工作也可能變成週期性的流量尖峰。

連線池的 LIFO，如何讓慢伺服器愈來愈慢？

另一個問題來自 connection pool，也就是重複利用既有網路連線，省去每次重新建立連線的成本。Habitat 使用的 aiohttp 連線池原本採 LIFO，會優先拿回最後放回池中的連線。

在突發流量後，較慢的 server process 會比較晚完成工作，也比較晚歸還連線。LIFO 隨即優先選中這些剛歸還的連線，把新工作再次送到已經較慢的 process。結果形成回饋循環：慢節點收到更多請求，因而變得更慢，即使原始尖峰已經結束也難以恢復。

OpenAI 把連線重用順序改成 FIFO，優先使用較早回到池中的連線，才打破這個循環。部分 process 在修正前承受的同時請求量，曾是平均值的 5 至 10 倍。

這類故障稱為 metastable failure，意思是系統受到一次衝擊後，會被自身的回饋機制困在不健康狀態。問題不一定出在硬體不足，而可能是負載平衡策略把更多工作持續送往最糟的位置。

Process 變多後，OpenAI 又如何避免壓垮資料庫？

大量增加 Python process 解決了事件迴圈壅塞，卻帶來另一個副作用：每個 process 都可能建立自己的連線。部署或重新啟動時，成千上萬條連線一起湧向資料庫與網路設備，便可能形成 thundering herd，也就是「驚群效應」。

OpenAI 因此使用 Envoy 集中連線，將 Python 的 HTTP/1 請求升級為 HTTP/2。HTTP/2 multiplexing 可以讓多筆請求共用同一條連線上的不同 stream，減少底層連線數。Envoy 同時提供限流與 circuit breaker，在下游服務接近極限時阻止更多流量繼續灌入。

這段取捨很重要：水平擴充不是只加 process 或機器。上游每增加一個副本，都可能放大下游資料庫、NAT gateway 與連線池的壓力。若容量規劃只看每秒查詢數，不看連線數、重啟尖峰與失敗重試，系統仍可能在正常部署時出事。

Habitat 為什麼刻意「少做一點」？

Habitat 能持續擴充的另一個原因，是它沒有讓產品團隊任意執行複雜 SQL。平台提供受限制的 NoSQL API，鼓勵簡單、可預測、工作量接近固定的查詢。

過去 OpenAI 的許多線上資料放在 Postgres。團隊規模還小時，可以人工檢查查詢與 schema 變更，避免昂貴的全表掃描進入正式環境。產品與工程師數量增加後，這種審查方式無法跟上，一筆位於熱門路徑的昂貴查詢就可能拖垮資料庫。

Habitat 的限制把成本提前暴露給開發者。複雜 join 或跨圖關係查詢不再是一行看似方便、實際代價難估的指令，產品團隊必須主動拆解工作。這犧牲了開發彈性，換來更容易隔離、限流與水平擴充的線上流量。

需要搜尋或分析複雜關係時，OpenAI 透過 change data capture，簡稱 CDC，把資料變更近即時串流到獨立的 Rockset 環境。CDC 可以理解為持續複製「哪些資料剛剛改變」，讓分析查詢在另一套系統執行，不去搶正式產品讀寫所需的資源。

我的判斷是，這是 Habitat 最值得產品團隊借鏡的設計。平台不必替所有情境提供最強功能，核心路徑更應該優先保證成本可預測，再替少數複雜需求提供隔離的出口。

2 名工程師加上 Codex，如何把 Habitat 遷移到 Rust？

Python 版本最高曾支撐每秒超過 2,000 萬次請求，但 Habitat 後來成為 OpenAI 使用 CPU 核心數第二多的服務，也是 Envoy 使用規模第四大的服務。當 API 與營運模式逐漸成熟，繼續支付 Python 的資源成本已不划算。

OpenAI 表示，2 名工程師在 2026 年第 2 季使用 Codex 與 GPT-5.5，完成整個服務的 Rust 重寫。新版本已處理 95％ 正式環境流量，CPU 效率是 Python 版本的 6 倍，記憶體效率則是 15 倍，平均延遲與尾端延遲也明顯下降。

這組結果很亮眼，但不能簡化成「AI 讓 2 個人取代一個重寫團隊」。Habitat 已經有穩定的 API、正式流量、監控資料與多年營運經驗，工程師知道新版本必須維持哪些行為，也能逐步比較新舊系統。Codex 加速的是已有明確規格與驗證標準的遷移，不是憑空決定系統應該怎麼運作。

更值得關注的訊號是，AI Coding Agent 正在改變技術債的還款時機。過去團隊可能因重寫成本過高，被迫長期忍受效率較差的技術棧。當 AI 能協助轉譯、補測試與處理重複工作，團隊就能先用熟悉語言建立產品，再於介面成熟後更早遷移到合適的執行環境。

這個結論仍有失效條件。如果後續缺少可靠測試、行為不相容，或 AI 產生的程式碼增加維護與安全問題，短期重寫速度就不能等同長期成本下降。OpenAI 也尚未在這篇文章公開遷移的測試覆蓋率、總工時或缺陷數，其他團隊不應直接套用「2 人就夠」的人力估算。

對 AI 產品團隊的 4 個實際啟示

1. 先穩定服務邊界，再追求最終效能

Python 並非最佳終點，卻讓 OpenAI 先把 API、部署與監控方式建立起來。若團隊仍在摸索產品需求，先選開發速度快、人才容易取得的工具，通常比一開始追求理論最佳效能更實際。

2. 技術債必須有可觀察的還款條件

Habitat 從 Python 遷移的理由很具體：CPU、記憶體、尾端延遲與成長速度都已跨過團隊設定的成本門檻。MVP 也應先定義何時需要拆服務、換資料庫或重寫，避免用感覺決定大型工程。

3. 平台的好處，常來自限制而不是功能數量

Habitat 不支援任意複雜查詢，表面上較不方便，卻讓每次請求的成本更容易預測。對共用平台而言，防止少數錯誤用法拖垮所有產品，往往比滿足每個團隊的彈性更重要。

4. 導入 Coding Agent 前，先建立可驗證的規格

OpenAI 的 Rust 遷移有舊系統可對照，也有真實流量與效能指標。若團隊只有一句「把系統改快」，AI 只會加速產生更多不確定性。先鎖定 API 相容性、錯誤行為、延遲門檻與回滾方式，Coding Agent 才能把工程速度轉成商業速度。

Habitat 對 ChatGPT 使用者代表什麼？

一般使用者不會直接操作 Habitat，也不會在 ChatGPT 裡看到一個 Habitat 選項。它的影響反映在登入是否成功、設定能否快速載入、對話能不能順利開始，以及區域故障時服務是否仍可用。

這篇文章也說明，AI 產品的體驗不只由模型決定。模型推論、應用資料、權限、網路與下游服務任何一層變慢，最後都會被使用者統稱為「AI 很慢」。因此，OpenAI 的競爭力除了模型能力，也來自能否把龐大資料需求包裝成穩定、可控的基礎設施。

我對 Habitat 的工程方向偏正面。它用受限制的介面換取可預測性，先接受 Python 的短期成本換取產品速度，再於服務邊界成熟後遷移 Rust，整體順序符合高速成長公司的現實。不過，這篇只是兩篇系列的上篇，多租戶隔離、讀取效能與 Azure Cosmos DB 優化仍要等 OpenAI 後續公開，才能完整評估這套架構如何處理資料層的可靠性。

FAQ

Habitat 是 ChatGPT 的記憶功能嗎？

不是。Habitat 是 OpenAI 產品共用的線上資料存取平台，負責路由、權限、加密、快取與連線等工作。ChatGPT 的記憶功能是使用者層的產品能力，兩者不能畫上等號。

OpenAI 的 10 億人是付費用戶嗎？

不是。OpenAI 的原文是 Habitat 支援「每週超過 10 億人使用的產品」，沒有說這些人都是付費用戶，也沒有在這篇文章提供方案別或單一產品功能的拆分。

500 PB 大約是多少資料？

以十進位換算，500 PB 約等於 50 萬 TB。這個數字描述 Habitat 服務的整體資料規模，不代表每位使用者平均占用相同容量。

Python 不適合大型服務嗎？

不能這樣下結論。Python 版本的 Habitat 最高曾支撐每秒超過 2,000 萬次請求，證明它可以服務極大規模。OpenAI 最終改用 Rust，是因為在自身工作負載下，CPU、記憶體與尾端延遲的成本已值得重寫。

Codex 真的讓 2 名工程師完成整套 Rust 重寫嗎？

OpenAI 表示，2 名工程師配合 Codex 與 GPT-5.5，在 2026 年第 2 季完成服務重寫。但原文沒有公開總工時、測試覆蓋率與缺陷數，其他公司不能只拿人數當作專案估算依據。

Habitat 為什麼不用任意 SQL 查詢？

任意 SQL 很有彈性，但某些全表掃描或大型 join 可能耗用難以預測的資源。Habitat 用受限制的 NoSQL API 保持線上請求簡單，再把複雜搜尋與分析分流到獨立系統，降低單一查詢拖垮產品的風險。

結論：真正的規模化，在於知道何時換下一個方案

Habitat 的發展路線重點不在「Rust 勝過 Python」的語言競賽。OpenAI 先用 Python 快速建立共用能力，發現程式庫更新已成為風險後拆成獨立服務，再透過監控逐一處理事件迴圈、背景排程、連線池與下游連線問題。等 API 與營運方式穩定，才用 Codex、GPT-5.5 與 2 名工程師把服務遷移到 Rust。

對多數 AI 團隊來說，最實際的做法也是如此：MVP 階段先選能快速交付的方案，同時量測真正的瓶頸；當成本與可靠性跨過明確門檻，再進行有驗證標準的遷移。技術選擇可以暫時不完美，但演進順序不能只靠運氣。

資料來源

• OpenAI：Rapidly scaling online storage to serve over 1 billion ChatGPT users
• Python 官方文件：Developing with asyncio
• Envoy 官方文件：Connection pooling
• Microsoft Learn：Azure Cosmos DB global distribution
• Microsoft Learn：Partitioning and horizontal scaling in Azure Cosmos DB
• USENIX：TAO, Facebook's Distributed Data Store for the Social Graph