智譜

智通財經APP獲悉，智譜(02513)公眾號發文，首次系統披露GLM-5系列模型在超大規模Coding Agent調用場景下的底層推理技術突破。包括兩個關鍵Bug的定位及修復、一項性能優化創新、以及一個意外的監控機制突破。針對Context Parallel策略中的KV Cache冗餘存儲問題，智譜設計實現了KV Cache分層存儲方案 LayerSplit，這一優化直接大幅提升智譜在Coding場景下的服務能力上限。此外，公司推理優化還在進一步加速，大幅提升單位算力token吞吐效率，降低推理成本。

智譜表示，當智能真正進入高併發、長上下文的 Coding Agent 場景後，推理基礎設施的挑戰已經不只是吞吐、延遲和可用性，維護它的輸出質量變得至關重要。每一次對 Scaling Law 的追求，都必須有同等強度的系統工程作為支撐。

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

本次披露的工程突破具備明確的技術深度——團隊不僅在自有推理鏈路中定位並修復了PD分離架構下的KV Cache跨節點複用競態，更進一步在主流開源推理框架SGLang的源代碼層面發現並修復了HiCache模塊的加載時序缺失(read-before-ready)問題，修復方案被SGLang開源社區採納，其底層基礎設施能力不僅服務於自身模型，也正在成為大模型行業的公共基礎設施之一。

從線下復現到異常識別

自 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 時，系統主動中止當前生成，並將請求交由負載均衡器重試。該策略使投機採樣從單純的性能優化技術，拓展為輸出質量的實時監控信號，成為後續消融實驗中的關鍵工具。

BugFix#1：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 分離架構中，需要對跨節點的數據傳輸與顯存複用建立明確的一致性約束，以避免類似問題。

BugFix#2: 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 #22811 提交至 SGLang 社區。

優化：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 場景下的處理能力。