打开网易新闻 查看精彩图片

作者 ｜ 智谱团队

编者按：

今年 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，期待与你同行。