超大规模 Coding Agent 推理的
来自 Z.ai Research · 期号 2026-04-30
摘要
智谱 AI 的 GLM-5 模型在服务高并发、长上下文的 Coding Agent 任务时，出现了乱码、复读和生僻字等异常。这些异常在标准推理环境下不会出现，只在系统压力大时才会触发，且难以稳定复现。 团队通过分析推理日志发现，投机采样（Speculative Decoding）的指标可以作为异常检测的参考：乱码时草稿 token 几乎全被拒绝，复读时接受率异常偏高。基于此，他们实现了在线监控策略，在异常发生时主动中止并重试请求。 排查定位到两个底层竞态 Bug：一是 PD 分离架构下，请求超时被 Abort 后，KV Cache 的回收与 Prefill 侧的写入不同步，导致新请求的 KV Cache 被旧数据覆盖；二是多级 KV Cache（HiCache）在加载与计算之间缺少同步约束，导致数据未就绪就被读取。修复后，异常发生率从万分之十几降至万分之三以下。 针对长上下文场景下 Prefill 阶段的瓶颈，团队提出了 KV Cache 分层存储方案 LayerSplit：每张 GPU 只保存部分层的 KV Cache，通过广播与计算重叠来降低通信开销。在 Cache 命中率 90% 的条件下，系统吞吐量提升了 10% 至 132%，且上下文越长收益越明显。 本文是智谱 AI 对 Coding Agent 推理基础设施工程挑战的详细复盘，附有具体的竞态分析图和性能数据。
深读
导读 当 Coding Agent 任务从简单对话转向高并发、长上下文场景时，推理基础设施的稳定性成为新的瓶颈。智谱 AI 分享了 GLM-5 模型在服务数亿次调用时遇到的乱码、复读等异常，以及如何通过分析推理日志、定位底层竞态 Bug 并修复的过程。读完可以带走一套从异常检测到根因定位的系统工程方法论，以及 PD 分离架构下 KV Cache 管理的具体教训。 关键信息 - 异常现象包括三类：乱码（garbled output）、复读（repetition）和生僻字（rare character），仅在系统压力大时触发，无法在标准推理环境下稳定复现。 - 线下复现时，需调整 PD 分离比例并持续提高系统负载，模拟高峰期 Prefill 堆积和 Decode 侧 KV Cache 压力后，才能在约每万次请求中稳定复现 3-5 次异常。 - 投机采样（Speculative Decoding）的两个指标——spec_accept_length（连续接受的 draft token 前缀长度）和 spec_accept_rate（draft token 被接受的比例）——在异常发生时呈现稳定模式：乱码时 spec_accept_length 极低，复读时 spec_accept_rate 偏高。 - 基于上述观察实现的在线监控策略为：spec_accept_length 持续低于 1.4 且生成长度超过 128 token，或 spec_accept_rate 超过 0.96 时，主动中止当前生成并重试。 - BugFix#1 修复后，异常发生率由约万分之十几下降至万分之三以下；BugFix#2 修复后，由执行时序不一致引起的异常完全消失。 - 优化方案 LayerSplit 在 Cache 命中率 90% 的条件下，请求长度 40k 到 120k 区间内，系统吞吐量提升 10% 至 132%。 逐节讲解 异常现象的识别与复现 智谱 AI 在 GLM-5 的线上监控和用户反馈中观察到乱码、复读和生僻字三类异常。团队首先通过本地回放 bad cases 并重复推理数百次，未能复现异常，排除了模型本身的问题。随后对线上日志脱敏并保留原始并发分布与请求时序，在本地进行全量回放，起初仍未复现。直到调整 PD 分离比例并持续提高系统负载，模拟高峰期压力后，才在约每万次请求中稳定复现 3-5 次。这种“与请求内容无关、与系统压力相关”的特征，指向高负载下的推理状态管理问题。 利用投机采样指标进行异常检测 团队发现，投机采样（Speculative Decoding）的指标可以作为异常检测的参考。投机采样先由草稿模型生成候选 token，再由目标模型校验并决定是否接受，在不改变输出分布的前提下提升 decode 效率。异常发生时，两个指标呈现稳定模式：乱码和生僻字伴随极低的 s…