剛剛，唐傑發佈智譜RSI首個成果

GLM已經開始參與構建GLM了 GLM，已經開始參與構建GLM了。清華大學計算機系教授、智譜創始人唐傑剛剛分享了一個他們內部觀察到的RSI早期案例： GLM-5.3驅動的Infra Agent，在超過10萬張國產芯片組成的集群上，從零參與搭建並優化了一套生產級推理系統。不到兩週，端到端吞吐直接提升至初始基線的3.2倍。關鍵是，這背後可不是簡單的“AI寫代碼”。從算子精度問題，到Python/C++跨層併發瓶頸，再到Kernel性能優化，Agent已經能自己讀取系統反饋、提出假設、修改代碼、跑實驗，再根據結果繼續迭代。

比如它定位出了KV Transfer場景中Python GIL導致的併發阻塞，把Prefill+KV Transfer相比單獨Prefill超過20%的性能損失，壓到了1%以內；還在KDA Decode算子上，通過重新組織計算拿到了1.71×的性能提升。也就是說，一個有點“套娃”的閉環已經出現了： GLM優化運行GLM的系統，而這套被優化後的系統，又繼續承載新的GLM。唐傑把它概括成一句話： 模型優化系統，系統承載模型。當然，這距離真正意義上“AI完全自主設計並訓練自己的繼任者”還很遠。目標怎麼定、邊界怎麼劃、風險怎麼判斷，目前依然是人類工程師在負責。智譜自己也明確強調，他們還沒有實現RSI。

但這篇分享值得仔細看的原因正在這裡： RSI第一次有了非常工程化、甚至已經跑進生產環境的雛形，超越了“未來某一天AI會自己變強”的抽象討論。以下是唐傑分享的技術Blog原文，enjoy。“最近一次感到震動的時刻” 在GLM的研發過程中，模型時常會湧現出一些令我們驚喜、甚至讓我們感到不安的能力。2025年10月，我們開始啟動安全能力增強研究。當時的判斷很樸素： 安全能力是代碼能力的自然延伸，能夠讀懂複雜代碼的模型，理應也能夠理解代碼中的漏洞。我們沒有預料它此後的走向，不到一年，安全夥伴使用GLM在真實代碼庫中發現了數千個漏洞。模型開始改變網絡安全的格局，也帶來了過去不曾存在的危險。

為了讓這種能力能夠被負責任地使用，我們不得不為它設計受信訪問計劃。最近一次感到震動的時刻，來自一個更加根本的變化： GLM開始越來越多地參與構建人工智能本身。我們看到模型完成了一項過去需要一支資深Infra團隊數週才能完成的基礎設施工作，並意識到這項工作將直接改變下一代模型的訓練方式，我們更加確信：我們的繼任者，正是我們親手創造出來的AI。坦白說，在GLM-4.7之前，我們內部用GLM寫代碼多少帶著被迫的成分，畢竟是自己的“親兒子”。那時，Coding的PMF還未到來；今天，GLM-5.3已經成為每個人每天離不開的Coding夥伴，正一步步走向取代我們。

如果這一趨勢延續下去，給足算力、給足時間，它的終點是一個能夠完全自主設計並訓練出自己繼任者的系統，這被稱為遞歸自我改進（Recursive Self-Improvement, RSI）。儘管我們還沒有走到那裡，但它的早期形態已經出現。這篇文章記錄的，正是其中一個早期案例。用稠密反饋驅動Infra Agent優化推理系統 從讓模型在新硬件上成功運行，到構建一套能夠穩定承載生產流量的高性能推理服務，是一個龐大的系統工程。GLM-5.3-Flash的上線同樣經歷了這一過程。在超過10萬卡國產芯片組成的集群上，從零搭建了一套完整的生產級推理服務，GLM-5.

3-Flash的全部線上推理都運行在這套系統之上。這項工作並不容易。此前沒人成功部署過如此大規模的國產卡集群，面對芯片內存容量和帶寬相對受限的挑戰，以及需要支持新結構的模型1M上下文窗口和多模態的請求，生態不成熟，算子不完備，許多文檔基本靠猜。最終這件事做成了，做成它的不是一支團隊，而是GLM-5.3驅動的Infra Agent。後面的故事大家都已經知道了。GLM-5.3-Flash以匿名模型“Ox-Alpha”在OpenCode與OpenRouter上接受真實調用檢驗。上線一週成為雙平臺調用量最大的模型，6天token調用量超過62萬億。

這次我們實施了一系列激進的內存優化，包括以算力換帶寬、以通信換顯存等定製化方案。最終形成的技術棧融合了多項關鍵技術： 針對線性注意力和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工程效果的，不只是模型自身的代碼生成與推理能力，更取決於系統能否持續為它提供有效、可歸因的反饋。代碼庫只能提供靜態上下文，而推理系統中的精度異常、性能退化或者性能優化目標未達成預期，往往來自算子實現、並行策略、通信行為、內存管理與服務調度等多個層面的動態交互。

即使Agent能夠理解整個代碼庫，如果一次修改後得到的反饋僅僅是“精度測試未通過”“TTFT增加30%”或“輸出吞吐下降20%”，它仍然難以判斷問題出現在哪一層、當前假設為何不成立，以及下一步應當驗證什麼。端到端指標可以告訴Agent“結果變差了”，卻無法解釋“為什麼變差”。因此，在增強Agent編寫和修改代碼能力的同時，我們還需要解決一個更基礎的系統問題： 如何將稀疏的端到端結果，轉化為細粒度、可歸因且能夠直接指導下一步行動的工程反饋？這也是構建高效Infra Agent反饋閉環的關鍵。

從端到端指標到可歸因反饋 在傳統的推理系統優化中，測試、日誌、性能分析工具和微基準測試並不缺失，但它們通常分散在不同工具和工程階段中。經驗豐富的工程師會根據一次壓測的結果選擇下一種觀測手段，逐步檢查算子輸出、執行時間線、通信事件或線程狀態，並將來自不同工具的信息聯繫起來。對於Agent而言，如果這些觀測和驗證手段沒有被組織成可直接訪問、反覆執行的工作流，真正可用的反饋仍然是稀疏的。它可能知道吞吐沒有達到目標，卻無法進一步判斷： 是某個算子執行時間過長，還是計算設備處於空閒等待狀態？是KV Transfer本身性能不足，還是上層調度未能及時推進傳輸？

某項優化對哪些輸入形狀有效，又會在哪些條件下發生退化？單一的端到端指標無法回答這些問題。為此，我們將正確性測試、運行日誌、執行Trace、運行時事件、微基準測試和端到端指標納入Agent的迭代流程，把完整的系統優化過程拆分為可以局部觀測和驗證的環節。算子級對比用於驗證數值正確性，微基準測試用於衡量特定輸入條件下的局部性能，執行Trace和運行時事件則用於呈現計算、等待與通信之間的時間關係。Agent可以根據當前假設選擇相應的驗證手段，而不必在每次修改後都等待完整服務部署和端到端壓測。我們將這種組織方式稱為“稠密反饋”。

這裡的“稠密”並不意味著向Agent輸入儘可能多的日誌和指標，而是強調反饋具有三個特徵。第一，反饋需要足夠局部。它應儘可能關聯到具體的引擎啟動參數、修改的代碼、算子、輸入條件、線程、執行區間或代碼路徑，幫助Agent縮小問題範圍。例如，相比“引入融合優化後模型精度下降”，定位到某個具體請求在優化前後的輸出差異，更有助於Agent構造最小復現並分析原因。第二，反饋需要能夠低成本、及時地獲得。Agent每提出一個假設、執行一次修改或構造一組對照實驗，都應有相應的驗證入口。能夠通過算子測試或局部微基準回答的問題，無須每次都等待完整服務部署和端到端壓測。

更短的驗證週期可以幫助Agent及時修正方向，減少在無效假設上的投入。第三，反饋需要支持客觀驗證。修改是否正確、性能是否改善，應由參考實現、測試結果和可比較的實驗指標判斷。運行信號可以幫助Agent提出候選原因，但不能僅憑現象之間的相關性確認根因，還需要通過控制變量的對照實驗，驗證針對特定路徑的修改是否產生了預期變化。這三項特徵共同決定了反饋是否具有可行動性： 正確性反饋回答“是否算對”，系統行為反饋定位“時間消耗在哪裡”，性能反饋則判斷“哪個方案在什麼條件下更好”。驗證手段不必按照固定順序執行，而應與當前假設相匹配，使每輪實驗都能回答一個明確的問題。

局部驗證與端到端測試在這一過程中承擔不同職責： 前者用於儘早排除錯誤或無效的修改，篩選值得繼續推進的候選方案；後者則負責確認局部收益能否轉化為真實服務收益，以及方案是否會在實際工作負載下引入新的退化。圍繞上述思路，GLM-5.3 Flash的上線過程形成了一套由工程師、Infra Agent和實驗環境共同組成的優化閉環： 工程師定義目標與系統邊界，Agent負責分析、假設和修改，實驗環境提供分層、及時且可驗證的反饋。三者共同將原本依賴工程師經驗串聯的診斷過程，轉化為Agent可以持續執行的工程工作流。

△圖2：基於稠密反饋的Infra Agent優化閉環 這一演進過程既包含直接推動吞吐增長的性能優化，也包含不會立即體現為吞吐提升、卻決定系統能否正確和穩定上線的缺陷修復。下面選取三個案例，分別說明稠密反饋如何幫助Agent保證“算得正確”、解釋“為什麼跑不快”，並進一步探索“怎樣跑得更快”。正確性反饋：Agent知道模型是否算對 推理性能優化必須以數值正確性為前提。對於Agent，驗證從明確推理引擎實際執行了哪些計算開始。高層並行策略會改變算子的輸入切分、執行路徑和結果組合方式；僅驗證一個算子在非切分條件下的輸出，還不足以覆蓋它在實際部署中的行為。

為此，我們建立了推理引擎並行策略到算子實現的映射，將系統層面的部署配置轉化為Agent可以逐項驗證的算子任務。這一映射幫助Agent明確： 一種並行配置涉及哪些算子，輸入如何被切分，以及哪些計算路徑需要與非切分實現進行對照。在此基礎上，我們組織Agent對不同並行切分與非切分路徑進行精度比較。對於同一組輸入，在對齊計算語義與輸出位置後，檢查不同執行方式產生的結果是否滿足數值誤差要求。這樣，並行配置、算子路徑和誤差結果就被關聯起來。測試一旦暴露偏差，Agent可以從對應的切分方式和計算路徑繼續檢查，而不必從整個模型重新開始定位。

正是在這一算子驗證過程中，我們發現了KDA算子上下文並行（Context Parallel，CP）路徑的精度問題。CP與非CP結果之間的偏差，使檢查重點落到了並行執行引入的狀態傳播與合併計算上。CP切分需要合併不同上下文分片的狀態，其核心計算可以簡化為： M = tl.dot(Mchunk, M) # 合併各分片的狀態變換 Snext = tl.dot(M, S) + H # 更新後續分片的初始狀態 原實現中，tl.dot即使接收FP32輸入，也默認採用TF32計算以提高性能。較低的計算精度使誤差在變換合併和狀態更新中不斷累積，在長上下文下更加明顯。

修復方法：將這兩處計算顯式指定inputprecision=“tf32x3”，通過三次TF32 Tensor Core運算組合出更高精度的結果，在減輕累積誤差的同時，儘量保留Tensor Core的性能優勢。這個案例中，反饋環境的作用從問題出現之前就已經開始： 並行策略到算子的映射確定了驗證對象，切分與非切分路徑的對照暴露了數值偏差，計算精度分析解釋了偏差來源，迴歸測試則為修改提供了持續檢驗的依據。對Agent而言，這條路徑把系統層面的並行設計轉化為可以執行和追蹤的正確性任務。局部驗證之後，候選實現仍需回到目標部署，完成模型級精度與服務性能的最終驗收。

相關精度修復已合併至Flash Linear Attention上游，詳見PR #1180。系統行為反饋：定位KV Transfer的併發瓶頸 對於系統級性能問題，明確的測試場景和性能約束，是Agent判斷異常、選擇分析方向的起點。我們的推理優化工程師為Agent定義了單獨Prefill、Prefill + KV Transfer、單獨Decode等測試場景，用來隔離不同執行階段及其組合對性能的影響，併為各場景設定驗收條件。例如，在相同workload下，以單獨Prefill為基準，Prefill + KV Transfer的性能差距不應超過5%。

然而，Agent在測試中發現，部分場景的性能差距超過了20%。這個反饋將排查範圍縮小到引入KV Transfer後的額外開銷與併發交互。Agent隨後深入分析KV Transfer的時間線，發現一個異常： 在這些場景中，KV Transfer的Python側執行始終沒有與DeepEP dispatch/combine的調用區間重疊。這一現象使Agent開始檢查DeepEP與Mooncake Transfer的併發關係，並沿調用鏈進入Python/C++ 邊界。我們使用的DeepEP v1.2.

1中，intranodedispatch和intranodecombine均未顯式釋放Python GIL；其中，dispatch在需要獲取接收token數量時，還會在CPU上等待GPU返回相關信息。關鍵在於，進入C++並不意味著自動釋放GIL。在這段持鎖調用期間，同一進程內負責Mooncake Transfer的Python線程無法及時獲得GIL，傳輸任務的調度與提交因而被推遲，壓縮了KV Transfer與後續計算重疊的機會。底層傳輸即使具備異步執行能力，上層提交受阻也會讓預期的並行無法充分發生。

源碼中還有一個直接的對照： 同版本的internodedispatch已顯式釋放GIL，註釋說明這樣做是為了避免CPU等待期間阻塞其他線程中的KV Transfer。這進一步支持了Agent對intranode路徑的判斷。修復的關鍵，是在相關C++執行區間釋放GIL，讓Mooncake Transfer的Python線程能夠及時推進任務。修復效果需要同時通過時間線與原有性能約束驗證： 前者檢查調度與傳輸是否獲得了重疊執行的機會，後者判斷這一變化是否改善了實際服務性能。在相同測試條件下，修復後的Prefill + KV Transfer與單獨Prefill的性能差距小於1%。

△圖3：發現並修復KV Transfer併發瓶頸 這個案例中，性能約束先把“沒有達到預期”轉化為明確的測試偏差，時間線再將排查方向收斂到兩個組件的併發關係，最終由代碼分析定位到GIL的持有範圍。稠密反饋由此把端到端性能、跨層運行行為和具體實現連接起來，為Agent的每一步分析提供依據。性能反饋：讓算子優化從存量經驗出發，並轉化為系統性能提升 算子優化需要解決兩個問題：如何判斷一次優化是否有效，以及優化方向從哪裡來。首先，算子性能必須放在推理引擎的真實執行環境中評價。例如，計算Kernel佔用更多資源可能縮短自身耗時，卻壓縮KV Transfer Kernel的執行空間，最終拖慢整體流水線。

因此，Agent不僅需要關注算子耗時，還要結合目標Workload、資源約束、任務重疊和端到端收益，建立正確的優化目標。其次，大量優化經驗隱含在SGLang、Flash Linear Attention和DeepGEMM等項目的手寫Kernel中。Agent需要從這些代碼中提煉優化技巧及其適用條件，形成面向當前算子和目標硬件的候選方案，再通過實驗驗證其實際效果。已有代碼提供優化方向，系統反饋判斷優化是否真正成立。我們讓GLM-5.

3驅動的Infra Agent從不同代碼庫、編程語言和硬件平臺的存量Kernel中學習優化經驗，並通過增量與消融實驗，將其提煉為包含適用條件、變換方式、資源約束和驗證證據的“優化骨架”。面對新算子，Agent以這些骨架為起點，結合Profiling與分層測試重新確定分塊、訪存和資源分配策略；驗證通過的修改及其適用條件繼續迴流骨架庫。工程師主要負責定義目標與約束，並審核涉及數值語義、併發行為和線上風險的關鍵修改。△圖4：典型KDA Decode算子從基礎實現到生產版本的性能演進 圖4展示了典型KDA Decode算子的性能演化過程。

引入ReplaySSM以算換存，導致算子執行時間第一次延長（v1相比v0）；Agent進行的除法優化將v1的執行時間縮短了9.6%。進一步地，在獲得“計算是關鍵瓶頸”的反饋信息後，Infra Agent發現原實現沿V維度分塊，使相同的FP32歸一化與門控計算被重複執行四次。它將這些分塊合併到同一線程塊，提前批量計算並共享中間結果，以犧牲部分並行度為代價從源頭消除了重複計算，獲得了1.71× 的性能提升。這個案例中，GLM-5.

3驅動的算子Agent從存量實現中抽取優化經驗，再把這些經驗用在承載自身推理的算子上： 它以骨架為起點逐項調優，由分層驗證判斷每一步去留，由端到端性能判斷實際價值，通過驗證的經驗迴流骨架庫。模型由此參與了自身推理系統的優化，而每一次上線積累的經驗，又降低了下一次優化所需的工程師投入。讓反饋驅動行動，讓實驗驗證假設 三個案例共同說明，反饋的價值不在於數量，而在於能否幫助Agent回答當前問題。大量缺少結構的日誌可能掩蓋關鍵信號，觀測範圍不完整的Profiling可能導致錯誤歸因，在Microbenchmark中成立的優化也未必能夠轉化為端到端收益。

因此，構建反饋環境不僅需要提供測試、日誌和性能數據，還需要明確每類觀測能夠支持什麼判斷、存在怎樣的邊界，以及哪些結論必須通過進一步實驗才能確認。工程師在這一過程中承擔三項關鍵職責： 定義優化目標與系統約束，構建Agent可以直接使用的反饋環境，以及審核涉及系統架構、異步併發和線上風險的關鍵修改。在此基礎上，Agent提出假設、實施修改並執行實驗，再根據反饋保留、修正或否定當前方案。正確性、穩定性與端到端性能共同構成最終的驗收標準。回顧GLM-5.3 Flash的上線過程，算子精度缺陷、跨越Python與C++ 邊界的併發問題，以及關鍵算子的性能優化，分別對應不同層次的工程挑戰。

藉助局部測試、跨層觀測與分層Benchmark，原本模糊的異常現象被逐步轉化為可以驗證的工程假設，複雜的系統問題也被拆解為一系列可觀測、可實驗、可歸因的迭代過程。正是在這樣的反饋閉環中，Agent的代碼與推理能力才真正轉化為可驗證的工程進展。由GLM-5.3驅動的Infra Agent參與推理基礎設施的建設；經過工程師與Agent共同優化的系統，又反過來支撐GLM-5.3 Flash穩定地面向用戶提供服務。模型優化系統，系統承載模型。這次實踐表明，真正縮短系統工程週期的，不只是更強的模型能力，更是一個能夠讓模型持續獲得反饋、驗證判斷並修正行動的Agent工程閉環。

當然，我們還沒有走到遞歸自我改進。選擇目標、設定邊界、判斷風險，仍然是人的工作，而且我們認為，在相當長的時間裡，這條線應當由人來守。但兩週、三倍、十萬卡這些數字告訴我們，這條線不會因為我們希望它慢一點就慢下來。（全文完） 參考鏈接： https://x.com/jietang/status/2100482019088060470 版權所有，未經授權不得以任何形式轉載及使用，違者必究。