智譜 RSI 報告：GLM-5.3 調校自己的推論系統，吞吐達三倍

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

2026 年 9 月 17 日，智譜（Z.ai）在官方部落格發表技術報告〈Toward Recursive Self-Improvement: How GLM Built Its Own Inference Infrastructure〉，一次交代三件事。八月以匿名身分橫掃 OpenRouter 的模型 Ox Alpha，真身就是 GLM-5.3-Flash。這個模型的所有生產推論，跑在一座超過十萬張中國製 AI 加速卡組成的叢集上。而從系統第一次點亮到生產就緒的過程裡，大量底層優化工作由 GLM-5.3 驅動的 Infra Agent（基礎設施代理）執行，前後不到兩週，端到端吞吐達到初始基準的三倍。

文章發表當天就衝上 Hacker News 熱門榜，十幾個小時累積三百多分與兩百多則留言，有人辯論這算不算遞迴自我改進，更熱的話題其實是智譜過往的蒸餾指控與這座十萬卡叢集的來歷。有趣的是，智譜自己在文裡把話講得保守：我們還沒抵達 RSI。標題裡的 Toward（邁向）是精確用字。這篇報告值得細看的原因也在此：它一方面提出「模型調校自己的推論系統」這種聽來科幻的主張，另一方面又留下了兩個任何人都能打開核對的開源痕跡。哪些能查證、哪些只是廠商自述，這條分線本身就是看點。

八月懸案收尾：Ox Alpha 官方認領

先把時間軸撥回八月。OpenRouter 在 8 月 20 日出現一個匿名條目 stealth/ox-alpha，免費限期預覽、百萬 token 級的上下文視窗，瞬間湧入大量開發者。先前報導整理過這波匿名模型潮：動物代號的 stealth 模型一個接一個被認領，而 Ox Alpha 的答案在 8 月 26 日揭曉，OpenRouter 官方模型頁掛出橫幅，寫明它「revealed to be ZAI GLM-5.3-Flash」。同一天，z-ai/glm-5.3-flash 這個正式條目出現在 OpenRouter 的模型清單裡，與 8 月 20 日上架的匿名條目相差六天。

當時智譜對身分保持沉默，這次報告等於官方親口認領，並補上了當時沒有的數字：GLM-5.3-Flash 以 Ox Alpha 的匿名名稱在 OpenCode 與 OpenRouter 上接受真實流量的測試，上線一週之內成為兩個平台上使用量最高的模型，六天內處理超過 62 兆個 token。報告原文的用字是「tested through real-world usage」，它被直接丟進生產環境等級的全球流量。

回頭看，這場匿名測試本身就是報告主題的一部分。智譜在文裡描述的順序是：先在十萬卡叢集上把推論系統建起來，再讓模型匿名上線吃真實流量，最後把優化過程寫成這份報告。匿名上線既是行銷也是壓力測試，62 兆 token 的呼叫量直接驗證了這套系統撐得住生產環境。

十萬張中國製加速卡上的記憶體緊縮工程

這份文件對叢集的描述很節制：超過十萬張中國製 AI 加速卡，GLM-5.3-Flash 的所有生產推論都跑在上面。沒有點名晶片廠牌，也沒有型號。智譜自述的起手處境是，這類中國製加速晶片的記憶體容量與頻寬相對受限，而且過去從未有人在此規模的叢集上部署過推論服務；團隊還要同時支援新模型架構、百萬 token 上下文與多模態請求。軟體生態不成熟、核心支援不完整，許多本來該有文件的地方只能靠猜。

Pin

應對方式是一整套用算力換頻寬、用通訊換顯示記憶體的工程手段，文中列出的技術包括：針對線性注意力與詞表預測層做節點內張量並行；ReplaySSM 用重算換取記憶體空間；把權重與激活都壓到 8 位元的 W8A8 量化；INT8、FP8、BF16 混合精度的快取量化；以及層間切分。在此之上再把編碼、預填、解碼三個階段拆開部署，也就是 EPD 分離式架構。這些技術名詞不需要全部記住，重點是它們共同的思路：硬體條件不夠，就用架構設計把每一 byte 的記憶體和每一次通訊都擠出來。

結果的宣稱數字有三個：整套優化讓端到端服務效能提升約三倍；從初始模型適配到生產就緒不到兩週；硬體利用率與單一 token 成本達到與主流 NVIDIA GPU 相當的水準。這三個數字全部出自智譜自己，報告沒有附第三方驗證，也沒有公開可比對的量測原始紀錄。要強調的是官方用字的範圍：可比較的項目是利用率與單 token 成本，網路上流傳的「能效追平 NVIDIA」說法，超出了報告原文的保證範圍。

稠密回饋：這份文件的方法論核心

拋開三倍吞吐的標題數字，這份報告對工程圈最有參考價值的其實是方法論段落。智譜觀察到，Infra Agent 的工程效能不只取決於模型的程式生成與推理能力，更取決於系統能不能持續提供「能追溯到特定原因」的回饋。程式碼本身只是靜態脈絡，推論系統的數值偏差、效能衰退、優化失效，往往來自核心實作、並行策略、通訊行為、記憶體管理與服務編排多層之間的動態互動。

問題的具體形貌是這樣：就算 agent 看得懂整個程式碼庫，改完之後只收到「數值正確性測試失敗」「首 token 延遲增加三成」「輸出吞吐掉了兩成」這類端到端指標，它仍然不知道該懷疑哪一層、目前的假設錯在哪裡、下一步該測什麼。端到端指標能告訴它結果變糟，不能解釋為什麼變糟。把更多原始日誌塞給它也沒有用，雜訊只會把關鍵訊號淹掉。

智譜的解法是所謂的稠密回饋（dense feedback），把正確性測試、執行痕跡、微基準、端到端指標組織成 agent 可直接取用、可重複執行的驗證流程，讓每一次實驗都在回答一個具體問題。這裡的稠密與數量無關，官方明確定義了三個特性：回饋要夠局部，能定位到特定環節；取得要便宜且及時，不必等整套服務部署完跑完負載測試；要支援客觀驗證，對錯有明確判準。在這個框架裡，工程師的角色被重新畫定為三件事：定義優化目標與系統約束、搭建回饋環境、審查牽涉數值語意／並發／生產風險的關鍵變更。

這套分工的對照點在於，這套分工把人從「逐一排查」挪到「定義問題與把關」，人仍在流程裡。文中的三個實戰案例，正好示範了稠密回饋如何讓 agent 把模糊的效能異常，一步步收斂成可驗證的工程假設。其中兩個案例，留下了外人可以動手核對的痕跡。

合併進上游的精度修正 PR

先看數值正確性的案例。智譜建立了一套從推論引擎的並行策略對應到核心實作的映射，讓 agent 能逐一驗證每種並行配置下的核心行為。在比對切分與未切分執行路徑的過程中，agent 發現 KDA 核心的上下文並行路徑有精度問題：這條路徑需要合併來自不同上下文分片的狀態，原始實作裡的矩陣乘法預設用 TF32 精度換取效能，但輸入其實是 FP32，較低的計算精度讓誤差在狀態合併與更新過程中累積，長上下文時特別明顯。

修正是把相關運算明確設成 tf32x3，用三次 TF32 運算組合出更高精度的結果。這個改動沒有停留在智譜內部：它以 PR #1180 之姿合併進開源庫 flash-linear-attention 的上游，標題是「[CP] use tf32x3 affine chain in kcp」，2026 年 8 月 27 日合併，比報告發表早了三週。任何人現在打開這個 PR，都能看到與報告敘述一致的說明：避免長上下文的精度損失。時間順序也合理，先有工程事實，後有對外報告。

Pin

DeepEP 原始碼裡的 GIL 落差

另一個案例更能說明這份報告的可信度結構。工程師替 agent 定義了包括單獨預填、預填加快取傳輸、單獨解碼在內的測試情境，並設有驗收標準（例如：同負載下，預填加快取傳輸的效能差距不應超過 5%）。agent 實測發現部分情境差距超過 20%，順著執行痕跡往下追，鎖定一個跨層的重疊執行問題：Python 端負責 KV 傳輸的 Mooncake Transfer 執行緒，從來不曾與 DeepEP 的分發/合併呼叫區間重疊。

關鍵認知是，進入 C++ 不等於自動釋放 Python 的 GIL。文中指出，在他們使用的 DeepEP v1.2.1 裡，intranode_dispatch 與 intranode_combine 都沒有明確釋放 GIL；而同版本的 internode_dispatch 早就明確釋放，還附了一段註解解釋原因：分發時 CPU 會忙著等待 GPU 從其他節點收回張量尺寸資訊，這段時間可能相當長，如果使用者的其他 Python 執行緒（例如 KV 傳輸）需要執行程式碼，會被 GIL 卡住，除非在這裡釋放。修正是在相關的 C++ 執行區間釋放 GIL，讓 Mooncake Transfer 執行緒及時推進工作。修正後，同條件下的效能差距從超過 20% 降到低於 1%。

這段敘述可以完整核對。DeepEP 是 DeepSeek 開源的通訊庫，v1.2.1 標籤的原始碼公開在 GitHub 上：csrc/deep_ep.cpp 裡 internode_dispatch 函式內確實有 pybind11::gil_scoped_release，前兩行註解逐字提到 KV transfer 與 GIL；而 intranode_dispatch 與 intranode_combine 的函式體內找不到任何 GIL 釋放。文中描述的落差，與開源原始碼的現狀完全對得上。換句話說，就算不信任智譜的任何績效數字，這個案例的問題定性與修法本身，經得起外人檢驗。

Pin

最後一個案例是核心效能優化，同樣有清楚的因果鏈：agent 先從 SGLang、Flash Linear Attention、DeepGEMM 等開源專案的手寫核心裡萃取優化技巧與適用條件，整理成所謂的優化骨架，再套用到自己的核心上。文中用一個 KDA 解碼核心展示過程：引入 ReplaySSM 用算換存，讓執行時間先變慢；接著的除法優化再把執行時間壓低 9.6%；最後發現原始實作沿 V 維度切塊，導致同樣的 FP32 正規化與閘控計算重複跑了四次，合併切塊、把中間結果留在暫存器、改用單一 warp 層級的歸約之後，拿到相對前一版 1.71 倍的加速。模型在這裡做的事，是把自己推論時要跑的核心，親手調快。

自述與可核對之間：讀這份報告該畫的分線

把證據攤開後，這份報告的結構其實分成兩層。可核對的那一層很硬：PR #1180 存在且內容相符，DeepEP 原始碼的 GIL 落差與註解逐字吻合，Ox Alpha 的認領時間與 OpenRouter 條目建立的時間戳對得上。自述的那一層則完全依賴智譜單方：十萬張卡的規模、六天 62 兆 token 的調用量、兩週時程、三倍吞吐、與 NVIDIA 相當的利用率與成本，以及「大量工作由 Infra Agent 執行」的參與程度。報告沒有提供量測方法細節或原始紀錄，也沒有第三方覆核。

對 RSI 的定位也一樣。標題雖然掛著遞迴自我改進，內文卻明確寫著「我們尚未抵達」，選擇目標、設定邊界、評估風險仍然是人類的職責，而且智譜認為在很長一段時間裡，人都應該繼續守住這條線。文末那句「模型優化系統，系統執行模型」，總結的是一個已經閉合的工程迴路，不是 RSI 的完成式。真正被自動化的是優化執行，不是目標設定。與其把它讀成奇點將至，不如讀成一份推論工程的自動化案例報告，這也是它對工程讀者最有用的讀法。

與其他實驗室的路線對照，更能看出這份報告的位置。Google 與 DeepMind 的 Dream-RSI 走的是把探索歷史讀成可重播的模擬器、被改進的是外層探索策略；智譜這份走的是代理直接改生產系統的程式碼，改進的是基礎設施本身。兩者都被冠上 RSI 之名，也都在名稱上比實際做到的更激進。至於把 GPU 核心安全搬進編譯期的工程趨勢，可以對照 CUDA Rust 兩條路的分析：推論基礎設施的底層工程，正在同時被語言層與代理層兩股力量改寫。

不用改用法，但有兩個入口可以自己驗證

實際使用面不需要任何動作。GLM-5.3-Flash 的生產推論本來就在這套系統上運作，OpenRouter 上也有正式條目（z-ai/glm-5.3-flash），API 使用者感覺不到差別。報告的價值在於知情：你呼叫的這個模型，背後的推論叢集是用這套方式建起來的。

想驗證的人有兩個入口。看 PR #1180，確認精度修正是真的合併進了上游；抓 DeepEP 的 v1.2.1 標籤，對照 internode 與 intranode 兩條路徑的 GIL 處理。這兩個都是幾分鐘內能完成的檢查，也是這份報告比一般廠商部落格更有引用價值的原因：它把最容易吹牛的部分（規模與倍數）留在自述，把最技術的部分（兩個案例的改動）留在了公開的地方。

後續要追蹤的點有三個：智譜會不會把量測方法或更完整的量測數字拿出來（目前兩者都缺席）；中國製加速卡的廠牌與型號會不會在後續文件揭露；以及這套 Infra Agent 加稠密回饋的組合，會不會從推論工程擴散到訓練叢集。文末那句話最好原樣記住：兩週、三倍吞吐、十萬張加速器這些數字告訴我們，這條邊界上的進展不會因為我們希望它慢下來就慢下來。數字是智譜自己報的，但方向感，工程圈普遍感受到了。