剛剛，唐傑釋出智譜RSI首個成果

來源原標題

剛剛，唐傑釋出智譜RSI首個成果

作者

一水

原始標籤

資訊 · 智譜

原始連結

https://www.qbitai.com/2026/09/491357.html

摘要原文

剛剛，唐傑釋出智譜RSI首個成果 一水 2026-09-17 16:28:23 來源： 量子位 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(M_chunk, M) # 合併各分片的狀態變換 S_next = tl.dot(M, S) + H # 更新後續分片的初始狀態 原實現中，tl.dot即使接收FP32輸入，也預設採用TF32計算以提高效能。較低的計算精度使誤差在變換合併和狀態更新中不斷累積，在長上下文下更加明顯。 修復方法： 將這兩處計算顯式指定input_precision=“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中，intranode_dispatch和intranode_combine均未顯式釋放Python GIL；其中，dispatch在需要獲取接收token數量時，還會在CPU上等待GPU返回相關資訊。 關鍵在於，進入C++並不意味著自動釋放GIL。 在這段持鎖呼叫期間，同一程序內負責Mooncake Transfer的Python執行緒無法及時獲得GIL，傳輸任務的排程與提交因而被推遲，壓縮了KV Transfer與後續計算重疊的機會。 底層傳輸即使具備非同步執行能力，上層提交受阻也會讓預期的並行無法充分發生。 原始碼中還有一個直接的對照： 同版本的internode_dispatch已顯式釋放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，原本模糊的異常現象被逐步轉化為可以驗證的工程假設，複雜的系統問題也被拆解為一系列可觀測、可實驗、可歸因的迭代過程。