TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
OpenAI 拆解 Habitat 儲存平台，兩人配 Codex 重寫成 Rust
OpenAI 以工程長文完整攤開 ChatGPT 背後的儲存平台 Habitat：每秒逾 7,000 萬次請求、管理 500 PB 資料，2025 年刻意背下的 Python 技術債，2026 年由兩名工程師配 Codex 與 GPT-5.5 重寫成 Rust，官方數字稱 CPU 效率 6 倍、記憶體 15 倍，95% 正式流量已完成搬移。
用 AI 摘要這篇文章：
OpenAI 在 9 月 11 日刊出一篇署名工程文章，完整攤開 ChatGPT 背後那套名為 Habitat 的自建儲存平台：官方數字寫著每秒處理超過 7,000 萬次請求、支撐每週超過 10 億人使用的產品、橫跨近 40 個地理區域、管理超過 500 PB 資料。三位工程師署名的這篇長文，把產品資料層的內部構造一次攤開。
不過這篇文章最值得記下的，並非規模奇觀。OpenAI 在文中承認，2025 年把 Habitat 從共用程式庫拆成獨立服務時，團隊明知 Python 撐不到下一個百倍成長，仍然選擇先把這筆技術債背下來，因為他們同時押了一注：等到真的必須遷移時，自家的 Codex 與 GPT 會讓整件事變得可行。官方的說法很直接：這一注，事後證明押對了。
兌現的帳面也出自官方：2026 年第二季，兩名工程師配上 Codex 與 GPT-5.5，把整個服務重寫成 Rust；新版本目前處理 95% 的正式環境流量，官方數字稱 CPU 效率是 Python 版的 6 倍、記憶體效率 15 倍，Python 版將在數週內完全除役。這篇拆解整場操作的時間軸，也把哪些部分能借鑑、哪些數字該保留幾分，一併說清楚。
登入到開對話，Habitat 是 ChatGPT 資料查詢的統一關卡
Habitat 是 OpenAI 自建的線上儲存平台，工作是把產品端的資料讀寫統一管理。你登入 ChatGPT、查看 Codex 設定、開一個新對話，每個動作背後可能拆成數十到數百筆資料查詢；任何一筆卡住，使用者感受到的就是「ChatGPT 很慢」。官方在文章開頭把這層關係講得很白：這些請求慢，產品就慢；這些請求失敗，產品就直接停擺。
它不是模型。產品端看到的是同一套介面，Habitat 負責判斷資料的型別、放在哪個儲存系統、有沒有權限讀取、怎麼加密傳輸、一次能送多少請求；schema 查找、路由、授權、序列化這些細節，都被擋在產品工程師的視線之外。底層實際落在哪，官方架構圖列出 Azure Cosmos DB、Nanobase、Valkey、快取與 Blob 儲存等資源，產品團隊不需要關心。
時間軸從 2023 年 DevDay 開始。Habitat 為了支援 GPTs 上線，最早只是連接 ChatGPT 主伺服器與單一資料庫的 Python 程式庫，之後在 OpenAI 內部快速擴散，官方特別註明這中間沒有中央推動。文章描述這三年每年成長都超過 10 倍；一般系統工程師習慣把架構設計到能乘載 10 倍流量、撐個幾年再說，Habitat 沒有這種餘裕，團隊能做的是榨出既有系統的容量，同時替下一代架構爭取時間。
一場回滾事故，把共用程式庫逼成獨立服務
2025 年中，OpenAI 判定程式庫形態已到極限，原因出在協調成本而非效能。文章給了一個具名案例：團隊想把最關鍵的資料搬到多個地理區域分散的 Azure Cosmos DB 帳號，降低單一區域故障的衝擊。這需要把新的路由邏輯塞進每個使用 Habitat 的服務，逐一部署，再開功能旗標。
災難藏在細節裡。協調數十個服務的部署花了數天；團隊接著想加上 shadowing（把正式請求複製一份給新邏輯測試、不影響使用者）驗證分片正確性，又花數天；中途發現錯誤要修，再花數天。好不容易要開旗標時，其中一個團隊因為無關的原因把服務回滾到含有舊錯誤的用戶端版本，造成了眾人極力避免的那場中斷。官方對這段經歷的總結是，程式庫時代的每次變更都得跨數十個服務協調，過程越來越脆、越來越貴。
拆成獨立服務後，部署、監控與平台功能集中到 Habitat service，中央更新一次，所有產品同時受益。這也讓存取控制、稽核紀錄與底層資料庫權限有了單一執行點；官方特別點名，這個關卡要擋的對象涵蓋外部、內部與 agent 三類行為者。集中化當然有代價，Habitat 從此成為必須優先保護的關鍵層，這是 OpenAI 用一次真實停機換來的架構決定。
策略性技術債：明知撐不到 100 倍，仍然選 Python
服務化讓 Python 的成本無所遁形。原本在應用程式內呼叫函式，現在每筆資料都要經過網路、序列化與獨立服務，CPU、記憶體與延遲全部增加。官方直言，Python 的效率到 100 倍規模時不可能被接受，重寫幾乎是確定的未來。
但 OpenAI 把這筆債稱為 strategic incursion of technical debt，策略性的技術債舉借。當時的首要目標是解鎖產品開發、把核心 API 與基礎建設穩下來，成本最佳化往後排。但這段自白裡最關鍵的是下一句：團隊同時押注自家 coding model 的進步速度，賭等到必須全面離開 Python 時，Codex 與 GPT 會讓遷移變得可行。官方自述，這注押對了。
這段自白對工程管理的意義，比任何語言戰爭的口水都具體。技術債什麼時候還，傳統上取決於人力與風險的評估；Habitat 的案例把「AI coding agent 能不能把重寫成本壓低一個量級」放進了還款方程式。對正在打造 AI 產品的團隊，這是整篇文章最該帶走的一句話，但它的適用條件比字面嚴格得多，後面會回到這裡。
Python 版真正的敵人：最慢的那 1% 請求
Python 版 Habitat 的問題從來不是平均速度，而是尾端延遲。官方用 asyncio 處理大量網路 I/O：一個工作等待資料時，CPU 可以先處理別的工作，但同一條執行緒做不了 CPU 並行。Habitat 除了轉送資料，還要處理路由、壓縮、加密、校驗和、健康檢查與請求複製；CPU 一忙，資料庫早就回傳的結果會卡在佇列裡等著被解析。官方量到的 asyncio 排程抖動，在高負載時可達數百毫秒，極端情況到數秒。
使用者感受到的放大效應很殘酷：一次操作串起數百筆查詢，只要其中一筆落在最慢的百分之一，畫面就得等它。OpenAI 的對策是讓每個 process 只服務少量併發請求，再把 process 數量水平放大；代價是更多資源，換到的是比較穩定的尾端表現。
文章裡最生動的故障現場，與程式語言無關。Habitat 初期出現規律的尾端延遲尖峰，用 CPU profiling 追到的元凶是功能旗標（feature flag）工具 Statsig：預設每分鐘、無抖動地更新設定，而且設定檔包含全公司所有服務的規則。當時每個 pod 最多跑 8 個 Python process，每到整分鐘，所有 worker 同時放下手上的請求，把 CPU 花在解析同一份巨型 JSON 上。修法是三件事：只下發 Habitat 需要的設定、拉長更新間隔、給背景工作加上隨機時間差。任何把排程設成「每分鐘一次」的系統，都值得對照這段自省。
連線池的 LIFO 陷阱，與大量 process 帶來的連線洪水
另一個案例被官方歸類為 metastable failure，亞穩態失效：系統被一次衝擊打進不健康狀態後，自身的回饋機制把它鎖在那裡。Python 的 aiohttp 連線池預設 LIFO（後進先出），優先重用剛歸還的連線；突發流量過後，較慢的伺服器 process 較晚歸還連線，於是被優先選中，接到更多新請求，變得更慢。修正前，部分 process 承載的同時請求數達平均值的 5 到 10 倍；把重用順序改成 FIFO（先進先出），回饋循環斷了，連穩態的變異都一起下降。
大量 process 還有另一個副作用：連線數。每個 process 都可能自建連線，部署時大量連線同時湧向資料庫與網路設備，形成教科書上的 thundering herd（驚群效應）；官方舉例，一次連線洩漏就可能把 NAT 閘道灌爆。解法是靠 Envoy 把 Python 的 HTTP/1 連線升級成 HTTP/2，用多工讓多筆請求共用少量連線，限流與斷路器也集中在這一層實作。官方補充，如今 OpenAI 基礎設施裡的連線池與負載感知平衡，主要由 Istio 與 Envoy 承擔。
刻意少做一點：把成本的可預測性做成產品
Habitat 能用 Python 撐到這個規模，官方把一部分功勞歸給刻意受限的 API。它不開放任意 SQL 查詢，只提供簡單的 NoSQL 介面，物件與邊的資料模型靈感來自 Facebook 的 TAO；複雜的 join 與圖遍歷，用戶端得自己拆解。原因很現實：SQL 讓「寫起來便宜、跑起來昂貴」的查詢太容易出現。OpenAI 的線上資料過去大多放在 Postgres，團隊還小的年代，人工審查每筆查詢與 schema 變更行得通；規模一大，一筆落在熱門路徑上的昂貴查詢就足以拖垮資料庫，曾是停機的固定來源。
需要複雜查詢的團隊有出口。Habitat 用變更資料擷取（CDC）把資料變更近即時串流到隔離的 Rockset 環境，分析與搜尋類的工作負載在另一側執行，每個團隊自管自己的 Rockset 實例。官方承認這對使用方是額外摩擦，但判斷是當下正確的取捨：簡單查詢當預設，複雜需求走逃生門。
兩名工程師、一季、Rust：下注兌現的帳面
遷移的時機由幾個數字推著走。Python 版 Habitat 峰值每秒處理超過 2,000 萬次請求，是 OpenAI 以 CPU 核心數計的第二大服務、Envoy 部署足跡第四大。2026 年第二季，這場重寫動工，主力是兩名工程師加 Codex 與 GPT-5.5。官方公布的結果整理如下。
| 指標 | 官方數字 |
|---|---|
| 正式環境流量占比 | Rust 版處理 95%，Python 版數週內完全除役 |
| CPU 效率 | 官方數字為 Python 版的 6 倍 |
| 記憶體效率 | 官方數字為 Python 版的 15 倍 |
| 延遲 | 平均與尾端均顯著下降，官方未附具體數字 |
| Python 版歷史峰值 | 每秒逾 2,000 萬次請求 |
表外的但書也要記住。這些數字全部出自 OpenAI 單方公布，文章沒有附測試方法；同篇文章在 Hacker News 有兩筆提交紀錄，分數都停在個位數、零則討論，目前沒有外部工程師的獨立檢視可以對照。6 倍與 15 倍也是官方選擇公布的維度，總工時、測試覆蓋率與缺陷數都沒有揭露，官方只預告會在後續文章分享更多心得。
「兩人重寫」的適用條件，比字面嚴格
把這段讀成「AI 讓兩個人取代一個重寫團隊」，會漏掉案例裡最關鍵的前提。Habitat 遷移時已經有穩定的 API、正式流量、監控資料與多年營運經驗，工程師知道新版本必須維持哪些行為，手上有足夠的對照基礎。Codex 加速的是「已有明確規格與驗證標準」的遷移，憑空決定系統長相的設計工作，並沒有被取代。
換句話說，AI coding agent 改寫的是技術債的還款時機與成本，前提是債務本身已經有清楚的面額：API 相容性、錯誤行為、延遲門檻、回滾路徑。少了這些，重寫只會更快地產生更多不確定性。OpenAI 把這篇定位成兩篇系列的上篇：多租戶隔離的可靠性、讀取效能的分層策略，以及與 Azure Cosmos DB 合作擴充的細節，都要等下篇才會揭曉。
把還款條件寫清楚，再讓 AI coding agent 上場
對技術決策者，這篇文章的用法是對照自己的處境。OpenAI 拆服務的觸媒是跨服務協調開始製造停機，而非效能不足；還債的時機跟著規模訊號走，平台成熟、成長持續加速、Habitat 已是核心數第二大服務，就動手換掉 Python；AI coding agent 則是在規格與驗證標準都能對照之後才上場，這也是Codex 同款代理框架走向代管化之後，各家團隊遲早要面對的課題。整條線索指向同一個原則：把「何時換下一個方案」寫成條件，而不是靠感覺。
至於一般使用者，Habitat 不會出現在任何設定頁；它的影響反映在登入是否成功、設定載入是否即時、對話能不能順利開始。AI 產品的體驗從來不只有模型：模型推論、資料層治理、權限、網路任何一環變慢，使用者一律把它統稱為「AI 很慢」。OpenAI 願意把這層內部工程攤開，對產業是難得的第一手材料；等系列下篇刊出、資料層的完整故事補齊，這套架構值不值得追蹤，會有更清楚的答案。
