OpenAI 的每一項產品，無論是使用者登入、調整設定，還是開啟 ChatGPT 的新對話，都極度依賴於快速且可靠的數據存取。如果底層數據查詢緩慢或失敗，使用者將直接感受到產品的延遲甚至完全無法運作。為了滿足這一需求，OpenAI 開發了名為 Habitat 的在線儲存平台。
Habitat 的成長速度極其驚人。兩年前，它僅是一個連接單一資料庫的簡單 Python 用戶端函式庫（Client-side Library）；而現在，它已演變成一個複雜的分散式系統，每秒處理超過 7,000 萬次請求，管理超過 500 PB（Petabytes，1 PB 等於 1,000 TB）的數據，支持全球 40 個地理區域、每週超過 10 億名用戶的訪問。
背景與演進：從函式庫轉型為獨立服務
Habitat 的設計初衷是讓產品工程師無需關注繁瑣的資料庫管理。在初期，它以 Python 函式庫的形式存在，將產品請求映射到後端的 Azure Cosmos DB（微軟提供的全球分佈式 NoSQL 資料庫）。工程師只需透過簡單的介面存取數據，而 Habitat 負責處理底層的 Schema 查找（Schema Lookup，定義數據結構的過程）、路由、授權、加密以及連線池管理。
然而，隨著 OpenAI 產品線的增加，函式庫模式面臨嚴重的維護挑戰。由於邏輯分散在數十個不同的服務中，任何底層協議的變更都必須在所有客戶端同步更新，這導致部署週期極長且極易出錯。例如，當團隊嘗試將數據遷移到區域分佈的資料庫以降低單一區域故障的影響（Blast Radius）時，必須在所有客戶端部署功能標記（Feature Flag）並協調更新，過程耗時且脆弱。為了消除這種運作上的低效，OpenAI 將 Habitat 從函式庫重構為獨立的服務（Standalone Service），建立單一的控制點來統一管理部署、可觀測性與安全策略。
技術挑戰：在 Python 服務中對抗尾端延遲
儘管將 Habitat 轉化為服務能提高管理效率，但使用 Python 作為高吞吐量服務的語言帶來了性能挑戰。Python 的全域解釋器鎖（GIL, Global Interpreter Lock）限制了其在單個進程中的 CPU 並行能力，這使得 Habitat 在處理加密、壓縮等 CPU 密集型任務時，容易產生嚴重的尾端延遲（Tail Latency，指極少數請求所經歷的極高延遲，會嚴重影響整體用戶體驗）。
為了優化性能，OpenAI 採取了幾項關鍵策略。首先，他們監控 asyncio 迴圈的調度延遲（Scheduling Delay），發現當 CPU 負荷過高時，即使後端資料庫回應迅速，請求仍會在 Python 的事件迴圈中等待調度。解決方案是限制每個進程處理的併發請求數，並透過大幅增加進程數量來水平擴展。
其次，團隊發現了由功能標記配置引起的性能抖動。由於所有進程每分鐘會同步解析一個巨大的 JSON 配置檔案，導致 CPU 瞬間飽和，造成請求停頓。透過縮小配置範圍、延長刷新間隔並加入隨機抖動（Jitter），成功消除了此問題。
此外，連線池的回收機制也曾導致「亞穩態故障」（Metastable Failure）。Python 的 aiohttp 預設使用後進先出（LIFO）的連線重用機制，這導致在流量高峰期，較慢的伺服器會更頻繁地被重新選中，形成惡性循環。將其修改為先進先出（FIFO）後，成功將負載更均勻地分佈到所有伺服器上。
系統設計：以限制 API 換取可擴展性
Habitat 能在 Python 階段撐到如此規模，核心在於其 API 的刻意限制。與傳統允許複雜 SQL 查詢的 Postgres 不同，Habitat 採用了受 TAO（Facebook 的圖形數據儲存系統）啟發的 NoSQL API。它禁止執行昂貴的全表掃描或複雜的跨表連接（Join），僅支持預定義的物件（Object）與邊（Edge）的簡單查詢。
這種設計將複雜度推向了客戶端，確保每個請求的運算成本是可預測且恆定的。對於需要複雜分析或搜尋的團隊，OpenAI 提供了「逃生路徑」：利用變更數據擷取（CDC, Change Data Capture）將數據近實時地流向 Rockset（一個專為分析設計的索引數據庫），由各團隊自行管理其分析實例，從而將高負荷的分析查詢與在線儲存完全隔離。
影響與轉型：向 Rust 遷移
隨著規模持續擴大，Python 的資源開銷（CPU 與記憶體）變得不可接受。在 2026 年第二季度，OpenAI 利用其自研的編碼模型（Codex 與 GPT-5.5）的輔助，僅用兩名工程師就將整個 Habitat 服務用 Rust 語言重寫。
Rust 的導入帶來了顯著的性能飛躍：新服務的 CPU 效率提升了 6 倍，記憶體效率提升了 15 倍，且平均延遲與尾端延遲大幅下降。目前 Rust 版本已處理 95% 的生產流量，並將全面取代 Python 版本。
這次演進展示了 OpenAI 在極速成長壓力下的工程策略：先用開發速度快的語言（Python）快速建立功能並驗證架構，在面對性能瓶頸時採取戰術性優化，最後在平台成熟後，利用 AI 工具高效地遷移至高性能語言（Rust），以支持全球規模的數據需求。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。