5039 积分	0 好友	658 主题

发消息

智谱“降智”秘密复盘：GLM-5大规模推理的Scaling Pain与避坑指南

发表于 3 小时前 | 查看: 4| 回复: 0

智谱最近放出了一篇画面有点不一样的技术博客——没有硬核炫技，反而大倒苦水，把从 GLM-5 以来碰到的各种“Scaling Pain”都摊开了讲。当 Scaling Laws 被推到极致时，推理基础设施其实正在承受巨大压力，尤其是每天要为 Coding Agent 提供数亿次调用。

有用户反馈，用 GLM-5 系列模型跑复杂 Agent 任务时，偶尔会出现乱码、复读、生僻字符等古怪现象。更让人头疼的是，这些异常在标准推理环境里根本复现不了。

惊恐的猫配文help咪

经过数周排查，团队不仅揪出了真凶，还给出了一套一线实战味十足的避坑指南。如果你正打算给自己的 Agent 加码，下面这些经验或许能帮你少走不少弯路。

呆萌猫配文 well~well~well

关键 Bug 定位

事情是这样的——GLM-5 上线后，智谱从用户大规模 Coding Agent 的推理日志里发现了三类异常：

乱码输出：内容杂乱无意义；
重复生成：模型不停输出相同内容；
生僻字：出现异常字符。

团队先是本地回放用户请求，重复运行数百次，结果一次异常都没触发。这说明模型本身不是根因。进一步模拟在线环境，调整 PD 分离比例并持续加高系统负载后，异常终于在每 10000 个请求里冒出 3~5 次。由此初步锁定是高负载下的推理状态管理出了问题，指向底层推理链路。不过，线下的复现率仍低于用户线上反馈，意味着现有检测方法有遗漏。

为了提高检测覆盖率，工程师们把目光投向了投机采样（Speculative Decoding）的指标。投机采样原本是用来提升推理性能的：小模型先生成草稿 token，再由大模型验证，它可以在不改变输出分布的前提下提高 decode 效率。而在异常场景里，这些指标成了很好的“探伤仪”。

推测解码异常检测示意图

在 GLM-5 的三种异常中，乱码和生僻字的 spec_accept_length 非常低，意味着目标模型的 KV 缓存与草稿模型之间明显不匹配；复读的 spec_accept_rate 则异常高，损坏的 KV 缓存可能使注意力模式退化，把生成推入高置信度的重复循环。

基于这些观察，团队总结了一套在线监控策略：当 spec_accept_length 持续低于 1.4 且生成长度超过 128 token，或者 spec_accept_rate 超过 0.96，系统会主动中止当前生成，把请求重新扔给负载均衡器。

接下来就是对根因的更深层拆解。

PD 分离架构下的 KV Cache 竞态

通过分析请求生命周期和推理引擎中 PD 分离的执行时序，问题被归结为 请求生命周期与 KV Cache 回收/复用时序不一致 引发的 KV Cache 复用冲突。

KV Cache竞态时序图

为了消除这类竞态，团队在推理引擎中引入了更严格的时序约束，在请求终止和 KV Cache 写入完成之间建立显式同步。具体做法是：解码阶段发出中止指令后，会通知预填充阶段；预填充阶段只有在未启动任何 RDMA 写入，或所有已发出的写入都完全完成后，才会返回安全回收信号；解码阶段只有收到这个确认，才会回收并重用对应的 KV Cache 槽位。这样一来，KV Cache 的写入就不会跨越内存复用边界，从而避免跨请求的缓存损坏。

修复后，异常输出发生率从约万分之十几降到了万分之三以下。

HiCache 加载时序缺失

另一个坑出现在 KV Cache 换入与计算重叠时。原来的实现没有保证数据在计算前已经加载完毕，可能导致“未就绪的 KV Cache”被访问。

HiCache加载时序修复对比

为此，团队重构了 HiCache 读取流程，在 Indexer 算子启动前插入一个 Load Stream 同步点，确保对应层的 Indexer 缓存已完全加载。Forward Stream 只有数据就绪后才会开始计算，从根本上消除了 read-before-ready 的问题。应用该修复后，同等负载下由执行时序导致的异常彻底消失，系统恢复稳定。

Prefill 侧优化：LayerSplit

上述两个 Bug 实际上都指向同一个系统瓶颈：在长上下文的 Coding Agent 场景中，Prefill 阶段已经成为性能的主要制约因素。为了缓解 Prefill 在高并发下的内存和带宽压力，团队设计了一套 KV Cache 分层存储方案——LayerSplit。

LayerSplit架构示意图

该方案让每个 GPU 只存储部分层的 KV Cache，显著降低了单卡的内存占用。在执行 Attention 前，再把对应层的 KV Cache 广播给其他相关 rank。为了进一步省通信开销，KV Cache 广播被设计成与 Indexer 计算重叠，将通信延迟隐藏在计算中。这样一来，唯一的额外通信成本只是 Indexer Cache 的广播，其大小仅为 KV Cache 的八分之一，整体通信开销几乎可以忽略。

吞吐量对比柱状图