百万上下文
GLM 模型如何实现并高效服务 100 万 token 上下文窗口：IndexShare 稀疏注意力、KVShare 与 MTP 技术，以及每 token FLOPs 降低 2.9 倍的关键改变。
GLM 模型如何实现百万上下文
将上下文上限从 200K 提升到 100 万 token 是一个工程问题，而非配置参数。三项改动是关键。
IndexShare 稀疏注意力
每四个 Transformer 层共享一个轻量索引器。它位于四个层中的第一个，其 top-k 索引被其余三层复用 — 消除了四分之三层中的索引器点积和 top-k 计算。结果：在 100 万上下文长度下每 token FLOPs 降低 2.9 倍。从训练中期 128K 序列长度开始引入 IndexShare。
MTP 配合 IndexShare 与 KVShare
多 token 预测层在首个草稿步运行一次索引器，并在后续步骤中复用索引，消除了限制上一代的训练/推理 KV 缓存不匹配。结合拒绝采样和端到端 TV 损失，接受长度从 4.56 提升至 5.47 — 约 20% — 跨越 7 个 MTP 步骤。
| 基线 | 4.56 |
| + IndexShare + KVShare | 5.10 |
| + 拒绝采样 | 5.29 |
| + 端到端 TV 损失 | 5.47 (+20%) |
高效服务百万上下文
超过几十万 token 后，瓶颈不再是计算，而是 KV 缓存容量、长上下文内核和 CPU 开销。三项修复：基于 LayerSplit 的细粒度内存管理和并行化、与缓存传输管道协调的上下文长度缩放内核优化，以及 CPU 侧缓存管理、请求调度和运行时路径调优。吞吐量优势随上下文增长而扩大。
归一化吞吐量优势
智能体强化学习训练
训练栈（slime）结合白盒和黑盒 rollout、紧凑轨迹和子智能体工作流。并行 OPD 训练在大约两天内合并了十余个专家模型，FP8 KV 缓存确保 rollout 内存不超预算。
反奖励黑客
长周期 RL 会诱生捷径，因此可疑动作先通过基于规则的召回过滤器，再经 LLM 裁判精确度检查。确认的黑客行为被在线拦截并以虚拟工具结果回应，使 rollout 得以继续而非被丢弃。基于 Critic 的 PPO 在单个 rollout 上保持压缩子轨迹的可训练性。