GLM-5 → 5.1 → 5.2：稀疏索引、Agent 后训练与百万上下文服务

1. 先划证据边界：三代名称不代表三代同等公开的架构

这张表是全页的约束：架构演进、后训练演进和产品/engine 支持不应混成一件事。尤其 GLM-5.1 只能被写成已公开的 agent 行为与兼容性更新，不能被当作一个未见技术报告的全新基础模型。

2. GLM-5：DSA、MoE、预训练与异步 RL 为什么构成后续路线的底座

GLM-5 的技术报告给出家族可核验的底层基线：744B total / 40B active，预训练从 GLM-4.5 的 23T 扩到 28.5T token，并引入 DSA（DeepSeek Sparse Attention）与 Slime 异步 RL 基础设施。DSA 的系统意义是：长上下文不必让每层对所有历史做 dense score，而先经 indexer 选择相关上下文；MoE 则把每 token 的 FFN 计算集中在少数 experts，却把 expert placement 和 all-to-all 通信交给并行系统。

Slime 是将 rollout、环境、奖励和 trainer 解耦并异步执行的 RL 系统，不属于 inference kernel。它会通过后训练吞吐、长尾 rollout、prefix reuse 与 tool environment 成本，限制可用的 agent trajectory 数量；在线用户请求本身并不会“运行 Slime”，因此这部分应留在训练/RL 层讨论。

3. GLM-5.1：当模型卡只披露 Agent 能力时，应怎样完整解释

GLM-5.1 的官方模型卡强调长程 agentic engineering，包括数百轮和数千工具调用的任务能力，并给出 SGLang、vLLM、xLLM、Transformers、KTransformers 等部署入口。可靠的结论是：模型族在 post-training、工具轨迹、上下文管理或 serving support 上发生了可观察更新；不可靠的结论是：它一定增加了 experts、换成另一种 attention，或用某个未披露数据集重训。

把“架构未知”写清并不会让页面变浅，反而会把读者带到可验证的问题：在同一硬件、相同工具、相同最大步骤数下，5.1 相对于 5 是否减少回合、提高工具成功率、降低重试，或改变缓存/模板要求？这些结果可由实验观察；其内部原因若没有报告则保持未知。

4. GLM-5.2 已公开什么

家族沿革与当前版本需要不同证据。GLM-5 技术报告可以解释 5.2 为何延续 MoE、长上下文和大规模 RL 路线；当前 checkpoint 的具体事实仍要以 GLM-5.2 发布页、模型卡和专门论文为准。

5. 前置知识：长上下文 decoder 的三类瓶颈

自回归 decoder 的 prefill 一次处理 prompt，decode 再逐 token 生成。把 context 拉到一百万后，模型同时遇到 attention 计算、KV cache 容量和调度不均衡三个问题。

稀疏 attention 可以避免每个 query 与全部历史位置相乘，但它先要回答“应该读取哪些位置”。若每一层都运行昂贵 indexer，检索本身会成为新瓶颈。GLM-5.2 的 IndexShare 正面处理的就是这项索引税。

6. GLM-5.2 试图同时解决什么

IndexShare 与 MTP 会分别改变 cache 结构、kernel 形态、speculative verification、批处理粒度和跨节点数据流，不能作为孤立的模型技巧评估。

7. 官方事实表，以及不能继承的上一代数字

GLM-5 报告披露 744B total、40B active、28.5T pretraining tokens 和异步 RL 基础设施。这些信息帮助理解家族路线，但 GLM-5.2 官方材料没有重新确认其 active 参数和训练 token，因此不能写成“5.2 仍是 40B active”。

8. 从请求到 token：完整架构与数据流

这条链路包含三个共享层次：IndexShare 跨若干 attention layer 复用位置索引，KVShare 在多 token 预测中复用缓存，MTP 则跨预测步共享参数。三者都能减少重复计算或状态，同时要求 runtime 明确缓存所有权、版本与失效边界。

9. IndexShare：为什么四层共用一个索引器

稀疏 attention 通常先为 query 与历史位置计算轻量相关性，选出 top-k，再对选中的 K/V 做完整 attention。若每层独立执行索引器，1M 长度下索引器也会扫大量状态。GLM-5.2 让每四个 sparse-attention layers 共用一个轻量 indexer：先计算一次候选位置，接下来的四层复用。

官方称 1M context 下 per-token FLOPs 降低 2.9×，但整个服务吞吐不会自动提高 2.9×，因为 MoE、MLP、通信、cache 读写和调度不在同一个缩放项里。训练上，IndexShare 从 128K 的 mid-training 阶段引入，无法作为推理期组件直接替换到最终模型上。

10. 算子层会发生什么变化

一次稀疏层不再只有 QKV projection、dense score、softmax 和 value aggregation，还多出 index projection、候选打分、top-k、gather 和稀疏 attention。性能取决于这些操作是否融合，以及 gather 是否产生随机 HBM 访问。

1. 为层组运行轻量 indexer，生成候选位置或 block id。
2. 将共享索引写入组内可复用 buffer，避免四次重复 top-k。
3. 各层按自身 K/V cache gather 被选中的条目。
4. 运行稀疏 attention kernel，再进入 MoE router。
5. MoE dispatch/all-to-all 把 token 发给所在 rank 的 experts，计算后 combine。

共享索引减少计算，也增加跨层 buffer 生命周期。若 scheduler 在中途迁移或重算请求，index cache 必须与对应 prefix、position 和模型 revision 一致；否则“命中 cache”可能得到结构合法但语义错误的结果。

11. 共享参数 MTP：它不是另一个独立小模型

多 token prediction 为当前位置预测多个未来 token。GLM-5.2 的公开方案在不同 MTP step 之间共享参数，避免为每个未来位置复制完整预测模块。KVShare 进一步减少各草稿步重复建立状态的成本。

这类方法的速度取决于平均接受长度。确定性、局部可预测的代码通常更容易一次接受多个 token；高熵推理、工具返回后的转折或高 temperature 采样更容易早拒绝。因此“7-step MTP”表示最多提出的结构深度，不等于每轮稳定产出七个 token。

12. rejection sampling 与端到端 TV loss

训练时只让 MTP 模块拟合未来 token，并不能保证草稿分布与目标模型验证规则相容。rejection sampling 把“能否被目标接受”带入训练数据或训练过程；端到端 total variation（TV）目标则直接缩小草稿分布与目标分布的差异。

官方 Bebop MTP 消融在一个 7-step coding 设置下报告：baseline 4.56；加入 IndexShare+KVShare 后 5.10；再加 rejection sampling 为 5.29；加入端到端 TV loss 达到 5.47，相对 baseline 约提升 20%。这些数字是论文特定评测指标，不能直接当作 tokens/s。

13. 权重、KV 与并行：一张卡为什么不是一个数字

官方模型卡给出的 753B 是模型规模，不是单 token 的计算量，也不是可直接使用的显存。只做最粗的静态权重换算：

真实服务还要容纳 KV cache、activations、CUDA graph、top-k/index buffer、MoE dispatch buffer 和通信 workspace。tensor parallel 切分矩阵，pipeline/layer split 切分层，expert parallel 切分 experts；数据并行复制部分或全部权重以提高吞吐。实际“放几张卡”必须同时指定精度、每卡 HBM、并行轴和目标并发，官方没有给出一个跨硬件通用的最低值。

14. LayerSplit：把模型放置与请求阶段分开优化

Z.ai 的 serving 文章将 LayerSplit 描述为细粒度内存与并行方案。不同层、请求阶段和缓存命中率对应不同的计算与内存需求，因此可以把层和资源拆得更细，而不必强行使用同一种并行拓扑。

例如 prefill 更重计算和大块 KV 写入，decode 更重权重读取、小 batch 延迟与既有 KV 读取。层级拆分后可以为不同 worker 选择更合适的并行度和容量，但代价是新增激活或 KV 的跨设备传输、更多故障边界和更复杂的 placement planner。

15. 数据中心里的 KV：GPU、CPU、网络和生命周期

高并发 coding Agent 请求的 prompt 可以很长，Z.ai 披露其相关请求平均长度超过 70K。热门仓库前缀、系统 prompt 和工具定义若被重复使用，prefix cache 能省下 prefill；但 GPU HBM 不足以永久保留所有 session，需要把冷 cache 放到 CPU 内存，必要时再迁回 GPU。

跨节点 RDMA 使 cache 传输与计算重叠，但请求取消、重试和异步回收会形成竞态：旧传输可能在 block 已重新分配后写回。官方文章称相关异常率从约 0.1% 降到低于 0.03%。这个数字同时说明了两件事：优化有效，但极低比例的 cache 生命周期错误在大规模流量下仍值得专门观测。

16. 一个长代码 Agent 请求的端到端例子

1. 请求带入系统提示、工具 schema、仓库文件和历史终端输出，前缀超过 70K。
2. router 查询 GPU/CPU prefix cache。命中旧仓库快照时还要验证模型 revision、token ids 和 block 边界。
3. prefill 在 sparse-attention 层组中每四层计算一次共享索引，各层读取自己的 K/V。
4. MoE router 将 token dispatch 到持有相应 experts 的设备；网络拓扑影响 all-to-all 尾延迟。
5. decode 阶段由共享参数 MTP 提出多个 token，目标模型并行验证并接受连续前缀。
6. 模型发起工具调用；执行期间 session KV 可保留、降级到 CPU 或回收。工具结果追加后重新调度。
7. 若客户端取消，scheduler 必须同步结束 KV 迁移和 MTP 验证，避免 block 被下一请求误用。

这条路径解释了为什么 Agent serving 的主要难点不只在模型输出质量，而在长生命周期请求、共享前缀、异步工具、KV 所有权和可恢复调度。

17. 官方 benchmark 数字应该怎样读

这些分数可以证明官方在其 harness 下得到对应结果，不能单独证明任何业务 Agent 的成功率。严谨比较要求固定 prompt、最大 token、temperature、工具、失败重试、成本和 wall-clock SLO，并公开未完成与超时请求。

18. 部署路径：引擎选择与上线顺序

官方模型卡列出 SGLang、vLLM、Transformers、KTransformers 和 Unsloth 等入口；Ascend 生态列出 vLLM-Ascend、xLLM 和 SGLang。列入模型卡表示有官方指向的接入路径，不代表每个引擎对 IndexShare、共享 MTP、量化和长上下文 kernel 的功能与性能完全相同。

1. 固定模型 revision、tokenizer 与 chat template，先验证短请求输出。
2. 核对引擎是否原生实现 GLM-5.2 architecture，而非用兼容层静默回退 dense kernel。
3. 从较短 context 开始测权重常驻显存、KV bytes/token、TTFT、TPOT 与吞吐。
4. 再启用 expert parallel、prefix cache、CPU offload/cache、MTP 和跨节点传输，每次只改变一个变量。
5. 用真实的长 Agent trace 测取消、重试、工具等待、cache eviction 和 worker 故障。

卡数要从目标精度下的权重下界算起，同时为 cache 与 runtime 留出容量，再按 SLO 确定 decode worker 副本数，并判断是否拆分 prefill/decode 或 layers。脱离这些条件写一个固定 GPU 数没有意义。

19. 局限与未公开部分

• GLM-5.2 的 active params 未在本页所引用的当前官方材料中重新披露。
• 当前材料不足以独立复现完整预训练数据、训练集群、训练成本和 post-training recipe。
• 1M context 是支持窗口，不保证任意百万 token 任务都能准确检索和推理。
• IndexShare 复用跨层索引，节省 FLOPs，但共享位置集合可能限制各层完全独立选取历史的自由度。
• MTP 加速依赖接受率；高熵生成和高并发调度下收益可能与论文消融不同。
• LayerSplit、CPU cache 和 RDMA 的收益来自特定流量分布，部署前必须按本地命中率和网络重测。
• 官方 benchmark 是模型方自报，跨模型比较仍受 harness 与推理预算影响。

20. 最小复现与验证清单

1. 保存模型 repo、commit SHA、config、tokenizer、引擎版本和所有启动参数。
2. 检查实际加载的 architecture 与 kernel 日志，确认 IndexShare/MTP 没有静默禁用。
3. 测 8K、128K、256K、1M 四个长度，分别记录 prefill FLOPs/时间、decode TPOT 和 KV 占用。
4. 对 MTP 做关闭/开启 A/B，记录平均 draft length、accept length、验证开销和输出一致性。
5. 对 prefix cache 做 GPU hit、CPU hit、miss 三组实验，并加入取消、超时、重试和 worker crash。
6. 验证 cache key 包含模型/tokenizer revision 与精确 token prefix，检查 block 引用计数和回收。
7. 业务 benchmark 同时报告正确率、成功率、TTFT、端到端延迟、GPU-hours 与失败类型。

21. 一手来源