OpenAI 揭秘 ChatGPT 儲存底座：靠定製 Azure 支撐 10 億使用者

支撐 10 億人每天跟 ChatGPT 對話，底層存資料的系統到底長什麼樣？

很多人以為大模型公司最燒腦的是顯示卡和算力，其實海量使用者湧進來時，後端的線上資料庫更先喊救命。10 月 23 日，OpenAI 工程團隊發文復盤了自研應用儲存平臺 Habitat 的演進史。

這套系統目前要在全球 40 個地區承接超過 10 億使用者，管理的資料量突破了 500 PB。為了扛住這個體量，OpenAI 聯手微軟 Azure 團隊，把底層的 Azure Cosmos DB 折騰了個底朝天。

從被「吵鬧鄰居」搞垮，到全員上線救火

最開始，OpenAI 偷了個懶，把所有業務的資料塞進 Cosmos DB 的同一個大容器裡。很快現實就上了一課：某個邊緣小功能要是突然冒出一個超高頻訪問的「熱鍵」，連帶把同一個物理分割槽上的登入、註冊流程全給擠癱瘓了。

更要命的是分割槽機制。隨著資料越存越多，底層物理分割槽自動分裂，但總吞吐預算沒變，結果每個分割槽分到的讀寫能力反而縮水。這意味著有些大容量業務就算請求量沒漲，光靠堆資料就能把自己活活憋死。

為了止血，架構師們轉頭要求各業務線「分家」，給關鍵新功能單開獨立容器。隔離效果確實立竿見影，卻換來了組織上的災難。

各個業務團隊水平參差不齊，沒人懂怎麼算容量。經常是某個功能今天上線，團隊忘了提前擴容，結果全員直接在故障警報室裡手忙腳亂地臨時拉配置。集中管會互相干擾，分散管大家又管不好。

找微軟開外掛，再用 Rust 重寫代理

折騰了一圈，OpenAI 決定殺回多租戶架構，拉著微軟 Azure 團隊定製了一套「協同管理容器」。

他們從底層改了排隊邏輯：誰訪問最燙就先限流誰，絕不讓單個大客戶拖垮整個物理分割槽；再給請求分級，離線大批次寫入必須給前臺使用者的互動式請求讓路。

除了底層改造，工程團隊還把資料儘量存到離使用者最近的機房，只對延遲敏感的資料做跨區複製，加上內建快取，並直接用 Rust 重寫了代理邏輯。這一套組合拳下來，在撐住 500 PB 資料的同時，把資料讀取速度直接拉高了 12 倍。

為什麼重要

這篇架構復盤之所以值得看，是因為它把生成式 AI 從實驗室推進到頂級國民級應用時，最真實的一道工程暗礁給攤開了。做模型是一回事，讓全球幾億人同時秒級載入對話記錄完全是另一回事。

對於大部分正在做 AI 應用的開發者和架構師來說，現在盲目去抄這套方案沒有意義。500 PB 和 10 億使用者是極端規模下的極端解法，你大機率不需要自己去改底層分割槽邏輯。但他們踩過的坑極具參考價值，特別是過早拆分獨立資源導致的容量規劃失控，在任何中大型團隊都屢見不鮮。

我們認為，OpenAI 這一步最聰明的地方在於沒有盲目自研全新的分散式資料庫，而是押注在雲巨頭的成熟元件上，反客為主逼著微軟針對自己的極端負載打磨 Cosmos DB。這種深度定製既省去了造輪子的巨大風險，也把自身沉澱的工程壁壘順手做進了微軟的基礎設施裡。當然，隱患也很現實：這種高度協同讓 OpenAI 與 Azure 綁得越來越深，日後想要跨雲遷移或者分散雲廠商依賴，成本只會高到難以想像。