「OpenAI 用兩名工程師加 AI，把核心系統從 Python 改寫成 Rust，效能提升六倍」是個吸睛說法，但真正值得研究的，不只是程式語言之爭，而是 OpenAI 如何在產品高速成長時，先接受技術債、穩定介面，再於合適時機重寫執行層。這是一個關於架構時機、成本控制與 AI 輔助工程的案例。
事件背景：Habitat 並非 OpenAI 的全部核心系統
台灣媒體報導將 Habitat 描述為 OpenAI 的「核心線上儲存平台」，並指出 Rust 版本的 CPU 效率為 Python 版六倍、記憶體效率為十五倍。報導來源可見：https://www.techbang.com/posts/133128-openai-rewrites-python-core-in-rust-for-gpt-5-5。
OpenAI 第一方技術文章則提供了更精確的邊界：Habitat 是讓 ChatGPT、Codex、API 與內部服務存取線上資料的平台，負責路由、授權、加密、快取、請求整形與連線管理等工作；它不是模型訓練、推論或 OpenAI 所有後端系統的總稱。截至文章發布時，Habitat 每秒處理逾 7,000 萬次請求、管理逾 500 PB 資料，服務範圍接近 40 個地理區域。第一方資料：https://openai.com/index/scaling-storage-one-billion-users-part-one/。
真正的第一步不是 Rust，而是把函式庫變成服務
Habitat 最初於 2023 年推出，是嵌入 ChatGPT 主伺服器的 Python 函式庫，替產品團隊隱藏 Azure Cosmos DB、快取與其他儲存資源的複雜度。這種模式適合早期快速開發，卻會讓儲存邏輯跟著每個應用程式散布出去。
到了 2025 年中，修改路由或協定已經需要協調數十個服務重新部署；甚至有團隊因其他原因回復舊版本，重新帶回已修正的錯誤。OpenAI 因而先將 Habitat 抽離成集中式服務，使部署、監控、存取控制、稽核與資源限制可以在同一入口執行。
來源事實是 OpenAI 先完成服務化，之後才遷移 Rust。合理推論則是：先固定 API 與責任邊界，可降低重寫時必須同時改動產品端的範圍。換句話說，兩名工程師能推進改寫，未必只是 AI 寫程式變快，也與前一年已完成的架構解耦有關。
Python 為何撐得住，又為何最後不划算
Python 並沒有「無法做大型系統」。OpenAI 表示，Python 版 Habitat 高峰曾處理每秒逾 2,000 萬次請求。問題在於 Habitat 不只等待資料庫回應，也要做壓縮、加密、校驗、路由、健康檢查及流量複製；當 CPU 工作增加，asyncio 的協程即使具備 I/O 併發能力，也可能因事件迴圈排程延遲而拉高尾端延遲。
Python 官方文件也說明，一般 CPython 的 GIL 同一時間只允許一個執行緒執行 Python 位元組碼；I/O 或部分原生擴充套件可釋放 GIL，而 Python 3.13 起亦提供可停用 GIL 的自由執行緒版本，因此不能把所有問題簡化成「Python 一定不能平行」。官方說明：https://docs.python.org/3/glossary.html#term-global-interpreter-lock。
OpenAI 當時的解法是限制每個行程的併發量、增加大量工作行程，並監測事件迴圈延遲。但行程變多又會增加記憶體與下游連線數。團隊還發現 aiohttp 預設的 LIFO 連線重用，在尖峰後會把新請求重新送往較慢的伺服器，形成自我強化的過載；改成 FIFO 後才切斷這個回饋循環。這說明瓶頸來自語言執行模型、連線池、排程與流量形狀的組合，而非單一語法速度。
六倍效能代表什麼，又不代表什麼
OpenAI 表示，2026 年第二季由兩名工程師搭配 Codex 與 GPT-5.5 完成 Rust 重寫；發布技術文章時，Rust 版本已承接 95% 生產請求，CPU 效率為 Python 版六倍、記憶體效率為十五倍，平均與尾端延遲也顯著降低。因此「全面完成切換」仍稍嫌超前：第一方原文是計畫在接下來數週淘汰剩餘 Python 服務。
這些數字也是 OpenAI 的內部量測，不是公開可重現的獨立基準。原文尚未揭露硬體、請求組成、比較期間、編譯設定及效率計算公式，也未拆分效能究竟有多少來自 Rust、資料結構調整或重寫時順便完成的架構最佳化。六倍 CPU 效率更不等於總帳單降為六分之一，因為 Habitat 還依賴 Envoy、網路、Cosmos DB、快取及跨區基礎設施。
Rust 的所有權規則由編譯器檢查記憶體管理，且不需為此加入執行期垃圾回收；這有利於控制資源與延遲，但也提高型別、生命週期及非同步程式設計的學習成本。Rust 官方說明：https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html。
AI 在這次重寫中能證明到哪裡
可確認的事實只有 OpenAI 宣稱兩名工程師運用 Codex 與 GPT-5.5 完成重寫；原文沒有公布 AI 生成的程式碼比例、人工審查工時、缺陷率，也沒有說明測試、部署、資安與基礎設施團隊是否另有投入。因此不能直接推導出「任何兩人團隊都能靠 AI 重寫關鍵系統」。
作者觀點是，AI 最可能放大的不是憑空設計分散式系統的能力，而是既有介面下的搬遷效率：轉譯重複邏輯、補齊測試、處理型別錯誤及協助比對新舊實作。真正高風險的部分仍是定義相容性、驗證資料語意、安排漸進導流與決定何時回復。
對台灣團隊的意義
台灣的電商、金融、遊戲與 SaaS 團隊不應把此案解讀成「Python 都該換 Rust」。更實用的判斷順序是：
- 瓶頸是否已由量測確認在應用程式 CPU、記憶體或尾端延遲，而非資料庫與網路？
- 核心 API、資料語意與錯誤行為是否足夠穩定，可以讓新舊版本並行驗證？
- 長期節省的運算成本與容量風險，是否高於招募、培訓、維運及重寫成本？
- 是否能先以受限介面、查詢隔離與集中治理，解決比語言效能更根本的問題？
Habitat 最值得借鏡的設計，其實是刻意「少做」：只提供成本可預測的 NoSQL 操作，不讓線上路徑任意執行跨表關聯或無界限掃描；複雜搜尋與分析則透過 CDC 分流至 Rockset。這種把昂貴操作從交易路徑隔離的做法，往往比直接更換語言更早產生效益。
後續觀察指標
接下來應觀察 OpenAI 是否如期將剩餘 5% 流量遷出 Python、是否公開六倍與十五倍數字的測試方法，以及承諾中的 Habitat 第二篇技術文章能否說明跨區、多租戶與資料庫層的成本。若未來能看到故障率、p99／p999 延遲、每百萬次請求成本及 AI 產碼的驗證流程，這個案例才足以從亮眼成果，進一步成為其他團隊可以評估與複製的工程方法。