本文為 Toward Recursive Self-Improvement: How GLM Built Its Own Inference Infrastructure 之繁體中文翻譯整理，原文版權歸原作者所有。
在開發 GLM 的過程中，模型有時會展現令我們驚訝、甚至感到不安的能力。
2025 年 10 月，我們開始研究如何強化它的資安能力。當時的想法很直接：資安是程式設計的自然延伸，能理解複雜程式碼的模型，也應該能理解其中的弱點。但我們沒有預料到後來的發展。不到一年，我們的資安合作夥伴便使用 GLM，在真實世界的程式碼庫中發現數千個漏洞。模型開始重塑資安領域，同時也帶來過去不存在的風險。為了讓這項能力能被負責任地使用，我們不得不設計一套可信任存取計畫。
最近一次令我們震撼的時刻，來自一個更根本的轉變：GLM 正日益參與 AI 本身的建造。我們看到模型完成一項基礎設施任務；在過去，這原本需要一群經驗豐富的基礎設施工程師花上數週。當我們意識到，這項工作將直接改變下一代模型的訓練方式時，我們更加確信：我們的繼任者，就是我們正在親手創造的 AI 系統。
坦白說，在 GLM-4.7 之前，我們在內部用 GLM 寫程式時，多少帶著一種義務感——畢竟這是我們自己的作品。當時，程式設計領域的產品市場契合度尚未真正到來。如今，GLM-5.3 已成為團隊每個人不可或缺的日常程式設計夥伴，而且正穩定地朝取代我們的方向前進。若此趨勢持續，在算力與時間都足夠的情況下，終點將是能完全自主設計並訓練自身繼任者的系統。這就是所謂的「遞迴自我改進」（Recursive Self-Improvement，RSI）。
我們尚未抵達那個階段，但它的早期形態已開始浮現。本文記錄的，正是其中一個早期案例。
要把一個模型從新硬體上的首次成功執行，推進到能可靠承載正式流量的高效能推理服務，是一項重大的系統工程。GLM-5.3-Flash 的上線也經歷了相同過程。我們在一個由超過 10 萬顆中國製 AI 加速器組成的叢集上，從零打造出完整的生產級推理服務。GLM-5.3-Flash 的所有正式環境推理，都在這套系統上運行。
這並不容易。此前沒有人以如此規模部署中國製加速器叢集。我們面對相對有限的晶片記憶體容量與頻寬，同時還必須支援新的模型架構、100 萬 token 的上下文視窗，以及多模態請求。整個生態系尚未成熟，kernel 支援不完整，許多理應有文件說明的部分只能靠猜測。最終，我們完成了這項工作；而它並不只是由基礎設施工程師團隊完成，其中很大一部分工作，是由 GLM-5.3 驅動的 Infra Agent 執行。
接下來發生的事已廣為人知。GLM-5.3-Flash 以匿名模型 Ox-Alpha 的名稱，在 OpenCode 與 OpenRouter 上接受真實使用情境的測試。上線一週內，它便成為兩個平台上使用量最高的模型，六天內處理超過 62 兆個 token。
我們實作了一系列積極的記憶體最佳化，包括以運算換頻寬、以通訊換裝置記憶體的客製方法。最終的技術棧結合了數項關鍵技術：針對線性注意力與 LM Head 的節點內張量平行、ReplaySSM、W8A8 量化、採用 INT8／FP8／BF16 的混合精度快取量化，以及 Layer Split。在此之上，我們又導入 Encode-Prefill-Decode（EPD）解耦架構。這些最佳化合計讓端到端服務效能提升約 3 倍，硬體利用效率與每 token 成本也達到可與主流 NVIDIA GPU 相提並論的水準。
在整個最佳化過程中，Infra Agent 的回饋迴路持續運作，使 GLM-5.3-Flash 從最初的模型適配到可投入正式環境，總共不到兩週；最終，端到端吞吐量相較初始基準提高了 3 倍。圖 1 顯示 GLM-5.3-Flash 從首次成功執行到正式上線的效能演進。
圖 1：GLM-5.3-Flash 端到端吞吐量的演進。
在這個過程中，我們逐漸理解，Infra Agent 的工程效能，不只取決於模型的程式碼生成與推理能力，更取決於系統是否能持續提供可追溯到具體原因的有效回饋。程式碼庫只能提供靜態脈絡；推理系統中的數值偏差、效能退步與未達成的最佳化目標，往往源自多個層級的動態互動，包括 kernel 實作、平行化策略、通訊行為、記憶體管理與服務協調。
即使代理能理解整個程式碼庫，修改後得到「數值精度測試失敗」、「首 token 延遲（TTFT）增加 30%」或「輸出吞吐量下降 20%」之類的回饋，它仍很難判斷是哪一層出了問題、目前的假設為何錯誤，以及下一步該測試什麼。端到端指標只能告訴代理結果變差，卻無法解釋原因。
因此，除了提升代理撰寫與修改程式碼的能力，我們還需要解決一個更根本的系統問題：如何把稀疏的端到端結果，轉化為細緻、可歸因，並能直接引導下一步行動的工程回饋？這也是替 Infra Agent 建立有效回饋迴路的關鍵。
從端到端指標走向可歸因的回饋
傳統推理系統最佳化並不缺少測試、日誌、分析工具或微基準測試，但它們通常分散在不同工具與工程階段中。經驗豐富的工程師會根據負載測試結果決定下一步觀察什麼，逐層檢查 kernel 輸出、執行時間線、通訊事件或執行緒狀態，再把不同工具的資訊串聯起來。
對代理而言，如果這些觀察與驗證方法沒有被整理成可直接存取、可重複執行的工作流程，它真正能使用的回饋仍然十分稀疏。它可能知道吞吐量沒有達標，卻仍無法判斷：
- 是某個 kernel 花太久，還是運算裝置處於閒置？
- 是 KV Transfer 本身太慢，還是上層排程未能及時推進傳輸？
- 一項最佳化對哪些輸入形狀有效，又會在哪些條件下退步？
單一端到端指標無法回答這些問題。因此，我們把正確性測試、執行期日誌、執行追蹤、執行期事件、微基準測試與端到端指標整合進代理的迭代流程，將完整的系統最佳化，拆成可在局部觀察與驗證的步驟。Kernel 層級比較用於驗證數值正確性；微基準測試衡量特定輸入條件下的局部效能；執行追蹤與執行期事件則揭示運算、等待與通訊之間的時序關係。代理可以依目前的假設選擇適當驗證方式，而不必每次修改後都等待完整服務部署與端到端負載測試。
我們稱這種方法為「密集回饋」（dense feedback）。這裡的「密集」不是指塞給代理越多日誌與指標越好，而是強調三項特質。
第一，回饋必須足夠局部。只要可能，回饋就應對應到特定引擎啟動參數、程式碼變更、kernel、輸入條件、執行緒、執行區間或程式路徑，以協助代理縮小問題範圍。例如，與其只說「融合最佳化後模型精度下降」，不如指出某個特定請求在修改前後的輸出差異，讓代理有更好的依據建立最小重現案例並分析原因。
第二，取得回饋的成本必須低，而且要及時。每當代理提出假設、做出修改或設計一組控制實驗時，都應有相應的驗證方式。能由 kernel 測試或局部微基準回答的問題，不該每次都要求完整部署與端到端負載測試。較短的驗證週期能讓代理迅速修正方向，減少浪費在無效假設上的努力。
第三，回饋必須支援客觀驗證。變更是否正確、效能是否改善，應由參考實作、測試結果與可比較的實驗指標判定。執行期訊號可協助代理找出可能原因，但觀察到的相關性本身不能證明根因；仍需透過控制實驗，確認對特定路徑的變更是否產生預期效果。
這三項特質共同決定回饋是否可採取行動。正確性回饋回答「計算是否正確？」；系統行為回饋指出「時間花到哪裡？」；效能回饋則判斷「哪種方法較好，又適用於哪些條件？」驗證方法不必遵循固定順序，而應配合當下假設，讓每個實驗都回答一個明確問題。
局部驗證與端到端測試在此扮演不同角色。前者能提早淘汰錯誤或無效的變更，找出值得繼續投入的候選方案；後者則確認局部收益能否轉化為真實服務改善，以及變更是否在實際工作負載下引入新的退步。
基於這些原則，GLM-5.3-Flash 的上線建立了一個由工程師、Infra Agent 與實驗環境共同組成的最佳化迴路。工程師定義目標與系統邊界；代理負責分析、提出假設與修改程式碼；實驗環境提供分層、及時且可驗證的回饋。三者共同把過去依賴工程師經驗串接的診斷流程，轉化為代理可持續執行的工程工作流。
圖 2：以密集回饋為核心建立的 Infra Agent 最佳化迴路。
這個過程既包括直接提高吞吐量的效能最佳化，也包括不會立刻提升吞吐量、卻是系統正確可靠上線所不可或缺的錯誤修復。以下三個案例說明，密集回饋如何協助代理確保系統「算得正確」、解釋「為何跑得不夠快」，並探索「如何讓它跑得更快」。
正確性回饋：協助代理判斷模型是否正確運算
推理效能最佳化必須建立在數值正確性之上。對代理而言，驗證的第一步是釐清推理引擎實際執行了哪些運算。高層平行化策略會改變 kernel 輸入的切分方式、採用的執行路徑，以及結果的合併方式。只測試 kernel 在未切分條件下的輸出，不足以涵蓋它在真實部署中的行為。
為此，我們建立了從推理引擎平行化策略到 kernel 實作的對應關係，把系統層級部署設定轉成代理可逐項驗證的 kernel 層級任務。這份對應協助代理辨識每種平行設定涉及哪些 kernel、輸入如何切分，以及哪些運算路徑需要和未切分實作比較。
在此基礎上，我們讓代理比較不同切分與未切分執行路徑的數值精度。對相同輸入，在對齊運算語意與輸出位置後，檢查不同執行方式的結果是否落在數值誤差容許範圍內。這將平行設定、kernel 路徑與觀察到的誤差連結起來。一旦測試暴露差異，代理便能針對對應的切分方法與運算路徑繼續調查，而不必從整個模型層級重新開始診斷。
正是在這個 kernel 驗證流程中，我們發現 KDA kernel 的 Context Parallelism（CP）路徑存在數值精度問題。CP 與非 CP 結果的差異，把調查方向指向平行執行所引入的狀態傳播與合併運算。
CP 切分需要合併不同上下文分片的狀態，其核心運算可簡化如下：
M = tl.dot(M_chunk, M) # 合併不同分片的狀態轉換
S_next = tl.dot(M, S) + H # 更新下一分片的初始狀態
原始實作中，即使輸入為 FP32，tl.dot 為追求效能仍預設使用 TF32 計算。這種較低的運算精度會在轉換合併與狀態更新期間累積誤差，並在長上下文下變得更加明顯。
修正方式是在兩個運算中明確設定 input_precision="tf32x3"。它結合三次 TF32 Tensor Core 運算以產生更高精度的結果，在盡量保留 Tensor Core 效能優勢的同時，降低累積誤差。
在這個案例中，回饋環境甚至在問題浮現前就開始發揮作用。平行策略到 kernel 的對應定義了該測什麼；切分與未切分路徑的比較暴露數值差異；運算精度分析解釋差異來源；迴歸測試則提供持續驗證修改的依據。對代理而言，這套流程把系統層級平行設計轉換為可執行、可追蹤的正確性任務。完成局部驗證後，候選實作仍需回到目標部署環境，接受模型層級精度與服務效能的最終驗收。
這項數值精度修正已合併回 Flash Linear Attention 上游專案，詳情請見 PR #1180。
系統行為回饋：精確找出 KV Transfer 的並行瓶頸
面對系統層級效能問題，定義清楚的測試情境與效能限制，能提供代理辨識異常與選擇分析方向的起點。
推理最佳化工程師替代理定義了 Prefill 單獨執行、Prefill 加 KV Transfer，以及 Decode 單獨執行等測試情境，用來隔離不同執行階段及其組合對效能的影響，並為每個情境設定驗收標準。例如，在相同工作負載下，Prefill 加 KV Transfer 與僅執行 Prefill 的基準之間，效能差距不得超過 5%。
然而，代理發現某些情境下的差距超過 20%。這項回饋把調查範圍縮小到 KV Transfer 額外引入的負擔與並行互動。代理接著詳細檢查 KV Transfer 時間線，發現一項異常：在這些情境中，Python 端的 KV Transfer 執行，從未與 DeepEP 的 dispatch／combine 呼叫區間重疊。
這項觀察促使代理沿呼叫鏈追查 DeepEP 與 Mooncake Transfer 之間的並行關係，一路來到 Python／C++ 邊界。在我們使用的 DeepEP v1.2.1 中，intranode_dispatch 與 intranode_combine 都沒有明確釋放 Python GIL。此外，當 dispatch 需要取得接收 token 數量時，它會在 CPU 端等待 GPU 回傳資訊。
關鍵在於，進入 C++ 並不會自動釋放 GIL。這些呼叫持有鎖期間，同一處理程序內負責 Mooncake Transfer 的 Python 執行緒無法及時取得 GIL，因此傳輸任務的排程與提交被延遲，使 KV Transfer 與後續運算重疊的機會減少。即使底層傳輸機制支援非同步執行，上層提交受阻仍可能讓預期的平行性無法充分實現。
原始碼也提供了直接對照：同版本中的 internode_dispatch 已明確釋放 GIL，並以註解說明此舉是為了避免 CPU 等待期間阻塞其他執行緒的 KV Transfer。這進一步支持代理對節點內路徑的判斷。
關鍵修正是在相關 C++ 執行區間釋放 GIL，讓 Mooncake Transfer 的 Python 執行緒可以及時推進任務。修正後必須同時根據時間線與原始效能限制驗證：前者確認排程與傳輸是否獲得與運算重疊的機會；後者則判斷變更是否改善實際服務效能。在相同測試條件下，修正後 Prefill 加 KV Transfer 與 Prefill 單獨執行之間的效能差距降至 1% 以下。
圖 3：發現並修正 KV Transfer 並行瓶頸。
在此案例中，效能限制先把「未達預期」轉化為定義清楚的測試差異；時間線再把調查範圍縮小到兩個元件間的並行；最後，程式碼分析精確指出 GIL 的持有區間。密集回饋連結了端到端效能、跨層執行期行為與具體實作細節，替代理分析的每一步提供證據。
效能回饋：在既有 kernel 最佳化經驗上，創造系統層級收益
Kernel 最佳化必須回答兩個問題：如何判斷最佳化是否有效，以及去哪裡尋找有希望的最佳化方向。
首先，kernel 效能必須在推理引擎的真實執行環境中評估。例如，提供某個運算 kernel 更多資源，可能縮短它自己的執行時間，卻也可能讓 KV Transfer kernel 可用資源減少，最後反而拖慢整條管線。因此，代理不能只看單一 kernel 的延遲，而必須在目標工作負載、資源限制、任務重疊與端到端收益的脈絡下，建立正確的最佳化目標。
其次，大量最佳化經驗蘊藏在 SGLang、Flash Linear Attention 與 DeepGEMM 等專案的手寫 kernel 中。代理需要從程式碼萃取最佳化技巧及其適用條件，為目前的 kernel 與目標硬體提出候選方法，再透過實驗驗證實際效果。既有程式碼提供方向，系統回饋則決定這些方法在實務上是否成立。
我們讓 GLM-5.3 驅動的 Infra Agent，跨不同程式碼庫、語言與硬體平台，學習既有 kernel 的最佳化技巧。透過漸進式實驗與消融實驗，它把這些技巧提煉成「最佳化骨架」，其中包含適用條件、轉換方式、資源限制與驗證證據。面對新的 kernel，代理先從這些骨架出發，再利用效能分析與分層測試重新評估切片、記憶體存取及資源配置策略。通過驗證的修改及其適用條件會回饋到骨架庫。工程師主要負責定義目標與限制，並審查涉及數值語意、並行行為與正式環境風險的關鍵變更。
圖 4：具代表性的 KDA Decode kernel，從基準實作到正式環境版本的效能演進。
圖 4 展示一個代表性 KDA Decode kernel 的效能演進。導入 ReplaySSM、以運算換記憶體後，kernel 執行時間從 v0 到 v1 首先上升。接著，代理的除法最佳化使 v1 執行時間降低 9.6%。之後，在收到「運算是主要瓶頸」的回饋後，Infra Agent 發現原始實作沿 V 維度切片，導致相同的 FP32 正規化與 gating 運算重複執行四次。它把這些切片合併進單一 thread block，將共享的中間結果保留在暫存器中，並以一次 warp 層級歸約取代各切片的重複計算。它犧牲部分平行性，從源頭消除冗餘運算，最終相較 v2 達成 1.71 倍加速。
在這個案例中，GLM-5.3 驅動的 Infra Agent 從既有實作萃取最佳化經驗，再把這些經驗應用於運行自身推理的 kernel。它以骨架為起點調整各元件，透過分層驗證決定保留哪些修改，並以端到端效能確認實際價值；通過驗證的洞見再回流到骨架庫。於是，模型開始參與最佳化自己的推理系統，而每次部署所累積的經驗，也降低了下一輪最佳化所需的工程成本。
讓回饋驅動行動，讓實驗檢驗假設
這三個案例共同說明：回饋的價值不在數量，而在它是否能協助代理回答眼前的問題。大量未整理的日誌可能掩蓋關鍵訊號；涵蓋不完整的效能分析可能造成錯誤歸因；在微基準測試中有效的最佳化，也未必能轉化為端到端收益。因此，建立回饋環境不只是提供測試、日誌與效能資料，還必須說明每種觀察能支持哪些判斷、其限制為何，以及哪些結論仍需進一步實驗確認。
工程師在這個過程中有三項關鍵責任：定義最佳化目標與系統限制；建立代理可直接使用的回饋環境；審查涉及系統架構、非同步並行與正式環境風險的關鍵變更。在此框架下，代理提出假設、實作變更並執行實驗，再依回饋保留、修正或放棄目前的方法。正確性、穩定性與端到端效能，共同構成最終驗收標準。
回顧 GLM-5.3-Flash 的上線過程，kernel 的數值精度錯誤、橫跨 Python／C++ 邊界的並行問題，以及關鍵 kernel 的效能最佳化，分別代表不同層級的工程挑戰。透過局部測試、跨層觀察與分層基準測試，起初模糊的異常，被逐步轉化為可測試的工程假設；複雜系統問題也被拆成一連串可觀察、可實驗檢驗，而且結果可歸因的迭代。正是在這個回饋迴路中，代理的程式設計與推理能力，轉化為可驗證的工程進展。
由 GLM-5.3 驅動的 Infra Agent 協助打造推理基礎設施；而由工程師與代理共同最佳化的系統，又反過來讓 GLM-5.3-Flash 能可靠地為使用者提供服務。模型最佳化系統，系統運行模型。這項工作顯示，要縮短系統工程週期，不能只依賴更強的模型能力；還需要一套代理工程迴路，讓模型能持續取得回饋、檢驗自身判斷並修正行動。
當然，我們尚未達到遞迴自我改進。選擇目標、設定邊界與評估風險，仍是人類的責任。我們相信，在未來很長一段時間內，人類都應守住這條界線。但兩週、三倍吞吐量，以及 10 萬顆加速器這些數字告訴我們：這條邊界上的進展，不會因為我們希望它慢下來就真的減速。
Hacker News 網友討論
這篇文章在 Hacker News 引發熱烈討論；頁面顯示已有數百則留言。討論焦點大致分為以下幾類：[1]
- 出口管制是否反而加速中國自主化：不少留言者認為，美國限制先進晶片出口，迫使中國企業加快自研 AI 晶片、軟體棧與大規模推理基礎設施；也有人以「需求是發明之母」概括這種反作用。另一派則認為，中國原本就會推進自主晶片，限制只是提高急迫性，而不能據此斷言管制完全失敗。
- 管制仍可能造成實質延遲：反方指出，中國企業若能同時自由取得美國與中國硬體，選擇當然更多；出口限制仍會提高成本、限制供應，並讓美國 AI 實驗室在算力取得上保持優勢。部分留言者主張，問題不應簡化成「管制幫助或傷害中國」的單一結論，而要區分短期阻礙與長期產業自主化。
- 「媲美 NVIDIA」的含義：有人注意到，文章宣稱在相同硬體上將端到端服務效能提高 3 倍，並使硬體效率及每 token 成本接近主流 NVIDIA GPU；但也有人提醒，NVIDIA 的護城河不只在單一推理效能，還包括成熟生態系、軟體支援與供應能力，而且推理市場本來就存在 TPU、AMD 等替代硬體。
- 規模與資料可信度：留言者嘗試從「10 萬顆裝置、六天 62 兆 token」推算單裝置吞吐量，同時指出模型可能跨多張卡，因此粗略除法不足以得出可靠結論。也有人質疑文章中的晶片型號、基準條件與成本比較缺乏足夠細節，難以獨立驗證。
- AI 參與建造 AI：部分討論聚焦於 Infra Agent 代表的早期自我改進：模型能否透過最佳化自身推理系統，逐步形成更強的遞迴改進能力。支持者認為這會讓 AI 從各類硬體中榨出更多效能；懷疑者則強調，文中的工作仍由人類設定目標、建立測試、提供回饋並審查高風險變更，距離自主 RSI 仍有明顯距離。
- 地緣政治與「贏者全拿」爭論：後續留言延伸到超人 AI 是否能帶來決定性的國家力量。有些人認為高度自主的 AI 可透過網路攻擊、社交工程與快速研發形成壓倒性優勢；其他人反駁，超人智慧不等於超能力，仍需面對實體世界、核嚇阻、隔離系統及執行路徑等限制。
整體而言，討論對文章的工程成果普遍感到驚訝，但對其政策含義與「遞迴自我改進」的詮釋分歧很大。較審慎的共同結論是：這個案例有力展示了代理式工程與密集回饋如何縮短基礎設施最佳化週期；至於它是否證明出口管制失效、國產晶片已全面追平，或 RSI 已經到來，現有公開資訊仍不足以下定論。[1]