一、DSA 稀疏以后，Indexer 反而显眼了
DSA 把昂贵核心 attention 限制到 Top-k token，但 lightweight indexer 仍在每层对全长上下文打分。上下文到 1M token 时，“轻量但重复 78 次”依然是可观成本。
相邻 Transformer 层处理的是逐步变化的表示，它们选出的重要历史位置往往高度重叠。IndexShare 把这种经验相关性变成明确架构约束。
二、一组四层只建立一次索引
每四层中的第一层是 Full layer：运行自己的 indexer 并产生 Top-k indices；随后三层是 Shared layers：跳过 indexer dot product 与 Top-k，直接复用这组 indices，但仍用各自的 query、K/V 和参数执行核心 attention。
只共享“看哪些 token”的索引集合。每层如何对这些 token 分配 softmax 权重、如何变换 value，仍由本层参数决定。
三、一个计算次数算例
假设 76 个稀疏注意力层都独立运行 indexer，需要 76 次全长索引。按每四层一组，则约需 19 次，删除 75% 的 indexer 运行。GLM-5.2 官方报告称在 1M context 下，每 token FLOPs 降低 2.9 倍；这是整体架构特定配置的厂商结果，不是简单的“四倍加速”。
四、为什么需要训练时就让模型适应共享
直接在已经训练好的 DSA 模型上复用索引可能造成质量下降，因为 Shared layer 的表示已经变化。IndexCache 论文给出两条路线：训练后用校准集搜索 Full layers；或训练时用多层蒸馏，让保留的 indexer 拟合其服务层的平均注意力分布。
GLM-5.2 官方说明从 128K 序列的 mid-training 阶段加入 IndexShare。这意味着 5.2 的长上下文能力是在共享索引约束下继续训练出来的，而不是部署时临时打开一个开关。
五、共享越多并不一定越好
| 共享跨度 | 索引成本 | 选择新鲜度 | 风险 |
|---|---|---|---|
| 每层独立 | 最高 | 最高 | 吞吐和成本压力 |
| 每 4 层 | 约四分之一 | 中等 | 依赖跨层相似性 |
| 更长跨度 | 更低 | 更低 | 后层可能需要不同 token |
当任务要求深层逐步重解释上下文，或者某些层形成专门注意力模式时，过度共享可能漏掉关键位置。合理跨度需要校准、蒸馏和长上下文评测共同决定。
评论加载中...