智譜首秀工程實戰經驗！Coding Agent日均數億次調用，GLM-5把長上下文推理的底層問題全逼出來了

作者 ｜ 智譜團隊

編者按：

今年 2 月，智譜 GLM Coding Plan 上線后，曾一度“推出即售罄”。智譜隨后同步升級 GLM Coding Plan，主打從 Vibe Coding 走向 Agentic Engineering。有趣的是，近期一批海外開發者正試圖涌入中國平臺來搶購 GLM Coding Plan。

隨著用戶量和調用量快速上漲，Coding Agent 開始成為大模型最真實、最殘酷的壓力測試場。一些過去在普通聊天場景里幾乎不會暴露的問題，開始在高并發、長上下文、復雜工具調用中集中出現。這也是進入 Coding Agent 時代后，推理優化面臨的新問題。

“今年是 infra 的決勝年。”如果說過去一年，大模型競爭的焦點仍然集中在“誰的模型更強”，那么今年開始，真正的勝負手正在轉向“誰的基礎設施更能扛”。

4 月 30 日凌晨，智譜發布技術博客《Scaling Pain：超大規模 Coding Agent 推理實踐》，首次系統披露 GLM-5 系列模型在超大規模 Coding Agent 調用場景下的底層推理技術突破，包括兩個關鍵 Bug 的定位及修復、一項性能優化創新、以及一個意外的監控機制突破。

此外，智譜團隊還將過去半年積累下來的推理工程實踐經驗貢獻回 SGLang 開源社區。這意味著，相關經驗也可能對更多模型后續的推理優化、吞吐放量和 Agent 場景穩定性帶來幫助。

下面是智譜團隊的具體報告分享，完整技術 blog 鏈接如下：https://z.ai/blog/scaling-pain

1 Scaling Pain：超大規模 Coding Agent 推理實踐

對 Scaling Law 的信仰不僅驅動著我們在模型參數與數據規模上不斷突破，也同樣在不斷逼近 Infra 工程的極限，這一過程伴隨著不可避免的陣痛，我們稱之為“Scaling Pain”。

隨著大模型應用從簡單對話全面轉向更復雜的、更長程的 Coding Agent 任務，我們的推理基礎設施迎來了前所未有的壓力，每天承受著數億次 Coding Agent 調用。過去幾周，部分用戶在使用 GLM-5 系列模型執行復雜 Coding Agent 任務時，遭遇了多種異常：亂碼、復讀，以及偶現的生僻字。這些問題在標準推理環境下是不存在的，只在高并發、長上下文的 Coding Agent 場景下才會觸發，很難穩定復現。

我們經過數周的推演、排查與壓測，最終定位并修復了幾個相互獨立的底層競態 Bug，并對其中所反映的系統瓶頸進行了針對性優化，顯著提高了推理系統的穩定性和效率。

我們將在這段探索中收獲的經驗與教訓與大家分享，一起克服 Coding Agent 推理的 Scaling Pain。

2 從線下復現到異常識別

自 3 月起，我們在 GLM-5 的線上監控和用戶反饋中觀察到三類異常現象：亂碼（garbled output）、復讀（repetition），以及生僻字（rare character）。這些現象在表面上與長上下文場景下常見的“降智”相似，但由于我們并沒有上線任何降低模型精度的優化，一個更關鍵的問題是：異常究竟源于模型本身，還是源于推理鏈路？如果源于模型，異常會表現為針對特定輸入的穩定、可重復行為；反之，若異常與系統壓力或運行時狀態相關，則更可能指向推理基礎設施中的鏈路或狀態管理問題。

排查初期，我們先對用戶反饋的 bad cases 做本地回放，并將同一批請求重復推理數百次，但始終未能復現異常，說明大概率不是模型本身的問題。為進一步模擬線上環境的壓力，我們對線上日志做脫敏處理，并盡可能保留原始并發分布與請求時序，在本地進行全量回放。起初仍未復現異常，直到進一步調整 PD 分離比例并持續提高系統負載，模擬高峰期的 Prefill 堆積和 Decode 側 KV Cache 壓力后，才在約每萬次請求中穩定復現 3-5 次異常。這種“與請求內容無關、與系統壓力相關”的特征，說明問題可能來自高負載下的推理狀態管理。與此同時，線下復現的異常頻率仍低于線上反饋的頻率，說明現有檢測方法可能存在漏檢，或仍有部分觸發場景尚未覆蓋。

如何可靠識別異常輸出成為了新的挑戰。三類異常中，復讀相對容易檢測，而亂碼與生僻字比較棘手。我們嘗試過正則表達式、字符集匹配等啟發式方法，也嘗試過基于模型判別的方式，但前者存在明顯的漏判與誤傷，后者則難以滿足大規模消融實驗的效率要求。上述限制使異常檢測本身成為定位流程中的一個瓶頸。

圖 1：投機采樣指標可以作為異常檢測的重要參考

在反復分析推理日志后，我們發現了一個意想不到的切入點：投機采樣（Speculative Decoding）指標可以作為異常檢測的重要參考。投機采樣原本是一個性能優化技術，先由草稿模型生成候選 token，再由目標模型校驗并決定是否接受，從而在不改變最終輸出分布的前提下提升 decode 效率。如圖 1 所示，我們觀察到，兩個指標（spec_accept_length：目標模型連續接受的 draft token 前綴長度；spec_accept_rate：draft token 被接受的比例）在異常發生時呈現出穩定模式：

• 亂碼和生僻字：通常伴隨極低的 spec_accept_length，即草稿模型生成的候選 token 幾乎全部被目標模型拒絕，表明目標模型所看到的 KV Cache 狀態與草稿模型預期之間存在顯著偏差。

• 復讀：通常伴隨偏高的 spec_accept_rate，表明損壞的 KV Cache 可能使注意力模式退化，并將生成過程推向高置信度的重復循環。

基于上述觀察，我們進一步實現了一套在線異常監控策略：當 spec_accept_length 持續低于 1.4 且生成長度已超過 128 token，或 spec_accept_rate 超過 0.96 時，系統主動中止當前生成，并將請求交由負載均衡器重試。該策略使投機采樣從單純的性能優化技術，拓展為輸出質量的實時監控信號，成為后續消融實驗中的關鍵工具。

3 BugFix：PD 分離架構下的 KV Cache 競態

在觀察到異常輸出與并發壓力具有明顯相關性后，我們進一步分析其原因。通過對請求生命周期以及推理引擎中 PD 分離執行時序的分析，我們發現該問題源于請求生命周期與 KV Cache 回收與復用時序之間的不一致，從而引發的 KV Cache 復用沖突。

1. 原因分析：異步 Abort 引發的 KV Cache 復用競態

為限制尾延遲，我們在推理引擎中引入了基于超時的請求終止機制：當 Prefill 階段未在規定時間內完成時，Decode 側會對請求執行 Abort，并回收其占用的 KV Cache 資源。然而，該 Abort 信號未被正確傳播至 Prefill 側，同時 Decode 側也缺乏判斷 KV Cache 是否可安全回收與復用的充分信息。因此，在 Decode Abort 并將對應 KV Cache 空間分配給新請求之后，先前已發起的 RDMA 寫入以及正在執行的 Prefill 計算仍持續執行，未被同步取消。

圖 2：PD 分離場景下 KV Cache 競態示意圖

圖 2 中展示了在 PD 分離架構下，兩個請求在 Prefill 與 Decode 之間交互的時序關系，以及由此引發的 KV Cache 競態。

在初始階段，Req1 被發送至 Prefill-1（P1）和 Decode（D）。由于調度或排隊等原因，Req1 在 P1 側經歷了一段等待后才開始執行 Prefill Forward。與此同時，Decode 側在一段時間內未收到對應的 KV Cache 數據，觸發超時機制，并對 Req1 執行 Abort。

隨后，Decode 側回收 Req1 占用的 KV Cache 槽位，但沒有正確通知 P1。緊接著，新請求 Req2 到達，并被分配至 Prefill-2（P2）和 Decode。由于內存復用策略，Req2 被分配到與 Req1 相同的 KV Cache 地址。P2 開始執行 Prefill Forward 并進行 KV Transfer，并在較短時間內完成，使 Decode 側進入生成階段。

與此同時，P1 側針對 Req1 發起的 KV Cache 寫入仍在繼續，其數據會寫入已被 Req2 復用的顯存區域，從而覆蓋 Req2 的部分 KV Cache。最終，Req2 在 Decode 階段讀取到被覆蓋的數據，導致生成結果異常。

2. 修復方案：KV Cache 釋放的時序一致性保證

為消除上述競態，我們在推理引擎中引入了更嚴格的時序約束，在請求終止與 KV Cache 寫入完成之間建立顯式同步關系。

具體而言，Decode 在觸發 Abort 后，會向 Prefill 側發送通知。Prefill 僅在以下條件滿足時返回“可釋放”信號：相關 RDMA 寫入尚未開始，或所有已提交寫入均已完成。Decode 僅在收到該確認后，才允許回收并復用對應的 KV Cache 槽位。該機制確保 KV 寫入不會跨越顯存復用邊界，從而避免跨請求的 KV Cache 覆蓋。

修復效果：該修復上線后，異常輸出的發生率由約萬分之十幾下降至萬分之三以下。結果表明，在 PD 分離架構中，需要對跨節點的數據傳輸與顯存復用建立明確的一致性約束，以避免類似問題。

4 BugFix: HiCache 加載時序缺失

Coding Agent 場景顯著提高了輸入長度（平均超過 70K tokens），同時伴隨較高的前綴復用率。這類負載使 HiCache（多級 KV Cache）成為線上服務中的關鍵優化手段。然而，在 KV Cache 換入與計算重疊執行的情況下，當前實現未能保證數據在使用前已完成加載，導致可能出現未就緒 KV Cache 被訪問的情況。

1. 原因分析：流水線同步缺失導致的 read-before-ready

通過對 HiCache 執行時序分析，我們將問題定位在 DSA HiCache 的緩存讀取路徑上。系統會從 CPU 內存異步換入（swap-in）歷史前綴緩存，并通過 Load Stream 與 Forward Stream 的重疊執行來提高吞吐。

如圖 3(a) 所示，Load Stream 負責加載 KV Cache 與 Indexer Cache，而 Forward Stream 依次執行 Index 計算與后續的 Sparse Attention。理論上，Forward Stream 中的 Indexer 計算應在對應的 Indexer Cache 完成加載后才能啟動。然而，在原始實現中，該依賴未被顯式表達。

具體而言，Indexer 算子在啟動時未對 Load Indexer Cache 的完成建立同步約束（圖 3 中紅色虛線區域）。因此，Forward Stream 可能先于 Load Stream 完成數據加載而開始執行，從而出現 Read-before-Ready 的訪問模式，即在數據尚未完成加載時即被讀取。

該問題會導致 Index 計算基于不完整或未初始化的數據執行，進而影響后續 Sparse Attention 的計算結果，并最終反映為輸出異常。

圖 3：HiCache 讀取流水線時序異常與修復示意圖

2. 修復方案：重構算子流水線的原子性

為解決上述問題，我們對 HiCache 的讀取流水線進行了修改（如圖 3(b) 所示），在數據加載與計算之間引入顯式的同步約束：

• 顯式同步約束：在 Indexer 算子啟動前引入與 Load Stream 的同步點，確保對應層級的 Indexer Cache 已完成加載。Forward Stream 僅在數據就緒后才啟動計算，從而避免 read-before-ready 的訪問。

該修復上線后，在相同負載條件下，由執行時序不一致引起的異常完全消失，系統行為趨于穩定。該修復已通過Pull Request提交至 SGLang 社區。

5 優化：KV Cache 分層存儲 LayerSplit

上述兩個競態問題揭示了一個共同的系統瓶頸：在長上下文的 Coding Agent Serving 場景中，Prefill 階段主導了系統性能。

為了控制 Prefill 排隊帶來的 TTFT，我們引入了超時 Abort；為了緩解 Prefill 側 KV Cache 容量壓力，我們引入了 HiCache。在修復這些狀態一致性問題后，我們進一步回到瓶頸本身：如何提升 Prefill 吞吐、降低 Prefill 側 KV Cache 顯存壓力。為此，我們設計并實現了 KV Cache 分層存儲方案LayerSplit。

Coding Agent 負載通常呈現出上下文長度較長、Prefix Cache 命中率較高的特征。在這一場景下，Prefill 階段往往成為系統的主要性能瓶頸，因此 Context Parallel（CP）成為線上 Prefill 節點的主要并行策略。然而，現有的 SGLang 開源實現存在 KV Cache 冗余存儲的問題，導致有限的 KV Cache 容量成為 GPU 計算資源利用率的限制因素。

圖 4：LayerSplit、KV Cache 分層存儲方案

針對這一問題，我們設計并實現了一種 KV Cache 分層存儲方案（LayerSplit）。在該方案中，每張 GPU 不再保存全部層的 KV Cache，而是僅持有部分層的 KV Cache（如圖 4(a) 所示），從而顯著降低單卡的顯存占用。

在計算過程中，不同 CP rank 按照圖 4(b) 所示的方式協同完成 Prefill：具體而言，持有某一層 KV Cache 的 rank 會在執行 Attention 計算前，將該層 Cache 廣播給其他相關 rank。為降低通信開銷，我們進一步設計了 KV Cache 廣播與 indexer 計算的重疊機制，使二者在時間上相互掩蓋。最終，整個流程中僅引入了 Indexer Cache 廣播的額外開銷，其規模約為 KV Cache 的 1/8，因此整體通信成本較低，對性能影響可以忽略。

圖 5：GLM-5.1 + LayerSplit 在不同長度下的吞吐提升

圖 5 展示了在 Cache 命中率達到 90% 的條件下，該優化在請求長度從 40k 到 120k 區間內帶來的性能提升。實驗結果表明，系統吞吐量提升幅度在 10% 至 132% 之間，且隨著上下文長度的增加，收益更加顯著。整體來看，該優化顯著提升了系統在 Coding Agent 場景下的處理能力。

6 總結

當智能真正進入高并發、長上下文的 Coding Agent 場景后，推理基礎設施的挑戰已經不只是吞吐、延遲和可用性，維護它的輸出質量變得至關重要。每一次對 Scaling Law 的追求，都必須有同等強度的系統工程作為支撐。我們分享這些經驗，希望幫助社區少走一些彎路，共同打磨出能夠承載 AGI 未來的推理基礎設施。

會議推薦

世界模型的下一個突破在哪？Agent 從 Demo 到工程化還差什么？安全與可信這道坎怎么過？研發體系不重構，還能撐多久？

AICon 上海站 2026，4 大核心專題等你來：世界模型與多模態智能突破、Agent 架構與工程化實踐、Agent 安全與可信治理、企業級研發體系重構。14 個專題全面開放征稿。

誠摯邀請你登臺分享實戰經驗。AICon 2026，期待與你同行。