前沿三强：通往 1M 上下文的三条路
M7 解剖了一家，M8 把三家并排
从「读懂这一份报告」升级到「读懂这一类报告」。
M7 我们把 Kimi K3 从头拆到尾。那是一次纵向的深挖：一家、一份报告、47 页。
这一节换个方向——横着切。
2026 年的这个夏天，三份开放权重先后落地：
| 模型 | 权重落地 | 规模 | 上下文 |
|---|---|---|---|
| DeepSeek V4（Pro / Flash） | 4 月 24 日官方公布，6 月 22 日 HF 仓库更新 | 1.6T / 49B · 284B / 13B | 1M |
| GLM-5.2 | 6 月 17 日 | 753B / 40B | 1M |
| Kimi K3 | 7 月 26 日 | 2.78T / 104.2B | 1M |
三家互不相干，规模差了 10 倍，却在同一个夏天交出了同一个数字：1,048,576。
而且——它们改的是同一个地方。三份材料翻到架构那一章，动的都不是 MoE、不是激活函数、不是优化器，而是注意力层本身。
上游： M2 的注意力与 N² · M6 的 KV cache 与 MLA · M7 的 KDA 与混合栈。
本节： 把三条通往 1M 的技术路线并排拆开，看它们各自省了什么、代价是什么。
下游： 你获得的能力是——打开 2026 年任何一份前沿模型报告，能读懂它的注意力章节，并且知道哪些结论该信、哪些该标「我不知道」。
关于本节的材料来源，必须先说清楚，因为三家不一样：
- Kimi K3：47 页技术报告 + 官方仓库 + config.json（M7 已精读）
- DeepSeek V4：arXiv:2606.19348 完整技术报告（约 55 页，逐页精读过）+ HF 模型卡 + NIST CAISI 独立评测
- GLM-5.2：没有自己的技术报告。 能拿到的一手材料是 GLM-5 的报告（arXiv:2602.15763，40 页）加上 5.2 的模型卡与 config.json——而 GLM-5 的报告里既没有 IndexShare，也没有 1M。
所以你会在这一节里反复看到「未核实」三个字，尤其集中在 GLM-5.2 那一列。这不是偷懒，是这一节最重要的训练：在材料到不了的地方，学会不说话。
1M 上下文到底难在哪
回扣 M2 的 N² 与 M6 的 KV cache——把它们放到 100 万这个量级上重算一遍。
「支持 1M 上下文」听起来只是一个参数调大。把 M2 和 M6 的两条公式拿出来算一算，就知道它为什么必须动架构。
难点一：注意力矩阵是 N²（M2）
M2 讲过，自注意力要算一张 N×N 的分数表。N = 1,048,576 时：
1,048,576² ≈ 1.1 × 10¹² —— 一万一千亿个注意力分数。
FlashAttention（M3）解决的是「不把这张表存下来」，它并不能让这张表不用算。分块、融合、省显存，改变不了这是 N² 的事实。
难点二：KV cache 随长度线性膨胀（M6）
这条更要命，因为它吃的是显存。用 M6 那条公式，取一个很常规的配置：
32 层 · 32 个注意力头 · GQA 8 组（即 4 个 KV 头）· head_dim 128 · BF16
每个 token 的 KV = 2（K 和 V）× 32 层 × 4 个 KV 头 × 128 维 × 2 字节 = 65,536 字节 = 64 KB
1M token = 64 KB × 1,048,576 = 68.7 GB
一张 H100 是 80 GB。一条 1M 的序列，光 KV cache 就吃掉 86%——模型权重一个字节还没放进去。
把下面这个 M6 的计算器拖到最右（128K），看到的是 8.59 GB；1M 就是它再乘 8。
三件事：① 保持 GQA、把序列拖到 128K，记下那个数字，然后心算 ×8 就是 1M 的量；② 切到 MHA 再看一遍——GQA/MQA 只是把斜率压小，线还是直的、还是往上走的；③ 想一想：如果斜率再压 10 倍，1M 下还是 6.9 GB。要在 1M 上活下来，必须让这条线不再是直线。
于是本节的核心问题：怎么让「KV cache 随长度线性增长」这件事不再成立？
数学上只有三种可能：
- 别让它增长——把历史压进一个大小固定的东西（K3 的路）
- 让它增长得慢一点——每 m 个 token 才存 1 条（V4 的路）
- 让它照常增长，但别每次都读全部——存全量、只读 top-k（GLM-5.2 的路）
这三条就是这一节的全部内容。 它们不是三种「实现」，是三种对同一个物理约束的不同妥协。
不存 · 存少 · 全存但少读
本节核心。K3 已在 M7 详讲，这里重点是 V4 的 CSA/HCA 与 GLM-5.2 的 DSA/IndexShare。
先把三条路一句话摆开：
| 做法 | 省了什么 | 代价 | |
|---|---|---|---|
| Kimi K3 | 线性注意力：69/93 层用 KDA 的固定大小循环状态，24 层留完整 Gated MLA | 显存与算力同时省，且与序列长度无关 | 固定状态装不下所有细节，所以必须每 3 层插 1 层 MLA 兜底 |
| DeepSeek V4 | 压缩 + 稀疏：每 m 个 token 压成 1 条 KV，再用 indexer 从压缩条目里 top-k 选 | 三条路里省得最狠（KV 与算力都省） | 压缩是有损的；且短序列下固定开销摊不薄，可能比稠密还慢 |
| GLM-5.2 | 检索式稀疏：KV 一条不压全存着，indexer 每次只挑 top-k 送进注意力 | 只省算力 | 一点显存都不省——1M 的 KV 该有多大还是多大 |
① Kimi K3：不存
M7 已经完整拆过了，这里只提一句它在三条路里的位置：K3 是唯一一条「历史不再以 token 为单位存在」的路。KDA 把前文压进一个 dk×dv 的循环状态矩阵，读 100 万个 token 之后它还是那么大。
代价也很直接：固定容量必然丢细节，所以 93 层里留了 24 层完整的 Gated MLA 做全局兜底——那 24 层仍然有随长度增长的 KV cache。K3 省的是「层数比例」这个常数因子，不是把增长本身消掉了。
详见 M7。 那里有 KDA 状态更新的公式解剖和逐步实验。
② DeepSeek V4：压缩后再稀疏选
V4 的定位在论文标题里写得很直白：Towards Highly Efficient Million-Token Context Intelligence——它不是「更大的 V3」，是围绕 1M 上下文效率重新设计的注意力层。
核心机制叫 CSA（Compressed Sparse Attention），三步流水：
第一步：压缩。 每 m 个 token 的 KV 压成 1 条。注意这不是平均池化——压缩权重是学出来的，在窗口内做 softmax 归一化后加权求和。而且是两路（Ca / Cb），两路的窗口错位重叠。序列长度到这里就变成了 1/m。
第二步：稀疏选。 压缩之后条目少了 m 倍，但 1M / 4 还有 26 万条，仍然算不起。所以接一个 Lightning Indexer（这套东西承自 DeepSeek 更早的 V3.2 的 DSA）：给每条压缩条目打一个分，只把 top-k 条送进真正的注意力。
第三步：读取。 被选中的压缩条目既当 Key 又当 Value，走共享 KV 的 MQA；query 从那个共享的压缩潜向量升维产生；输出走分组投影再合并，省计算。
除了 CSA，V4 还交错排布了 HCA（Heavily Compressed Attention）：同构的压缩，但压缩率 m′ ≫ m、不重叠、不做稀疏选择——对全部压缩条目做 dense 注意力。定位是更粗粒度的「全局概览」层。
看出这个结构和 K3 的对称了吗？
K3：KDA 管长程（便宜、有损）+ MLA 定期兜底（贵、精确）
V4：压缩管长程（便宜、有损）+ 未压缩滑窗管局部（贵、精确）
同一个权衡的两种切法。 一个按「层」切，一个按「距离」切。V4 为什么非要加那条未压缩的滑动窗口？因为压缩块内的 token 由于因果性约束互相看不见，而近处的 token 恰恰是最重要的——压缩对近处伤害最大。
🔍 V4 注意力层里还有三个值得单独记的小设计
① 部分 RoPE + 一个反向技巧。V4 只对最后 64 维施加 RoPE。麻烦在于压缩条目既是 K 又是 V，于是注意力输出会带上绝对位置信息——解法是再对输出施加位置 −i 的 RoPE，把绝对位置转回相对位置。
对比 M7 的 K3：K3 是把位置编码整个删掉（NoPE），V4 是少量、巧用。两家在同一个问题上的判断完全相反，而两家都做到了 1M——说明这里没有唯一正解。
② Attention sink。一个可学习的 sink logit 直接加进 softmax 的分母（Eq.27）。效果是每个头的注意力权重总和可以 < 1，甚至趋近 0——翻译成人话：「这个头这一次可以选择什么都不看」。标准 softmax 强制权重和为 1，等于强迫每个头必须往某处分配注意力，哪怕没有任何相关内容。
③ QKV RMSNorm 取代 QK-Clip。V4 对 query 和压缩 KV 条目都做 RMSNorm 来防注意力 logits 爆炸，并在 §2.4 明说：因此不需要 K2 那套 QK-Clip。M7 讲过 K2 的 MuonClip = Muon + QK-Clip——V4 用一个归一化把这个组件整个换掉了。
③ GLM-5.2：全存，但只读一小撮
GLM-5.2 这一段要先说归属，因为这里最容易搞错。
DSA 不是 GLM 发明的。
- DSA = DeepSeek Sparse Attention，DeepSeek 的东西（出自 DeepSeek-V3.2-Exp，约 2025 年 9 月）。
- GLM-5 的论文摘要用的动词是 “adopts”（采用），不是 “proposes”。模型卡用的是 “integrates”。
- 它底下叠的 MLA 也是 DeepSeek 的（出自 DeepSeek-V2，M6 学过）。
- transformers 库里 GLM 的 indexer 类，源码注释直接写着 “Same as DeepseekV32Indexer.forward”。
GLM 自己的贡献，被它自己的文档界定得很窄：IndexShare（跨层索引复用）。
这不是黑 GLM——恰恰相反，一家在自己的论文里老老实实写 “adopts” 的公司，比满篇 “we propose” 的更值得信任。 但你在引用的时候必须归对：说「GLM 的稀疏注意力」可以，说「GLM 提出的 DSA」就错了。
那 DSA 本身怎么工作？和 V4 的 indexer 是同一个思路，但少了压缩那一步：序列一条不压、一条不丢，全部留在 KV cache 里；每次注意力之前，用一个轻量 indexer 给全部 S 个 token 打分，挑出 top-k 送进注意力。
于是问题很明显：indexer 要扫全序列。 1M 上下文下，光打分这一步就成了新的瓶颈。V4 用「先压缩再打分」把候选数降到 S/m；GLM-5.2 的选择是——不减少候选数，而是减少「打分的次数」。
这就是 IndexShare：每 4 层共用一个 indexer 的选择结果。第 1 层真算，后 3 层直接拿它挑好的 top-k 索引来用。
IndexShare 是 GLM-5.2 的「版本定义特性」——正是它第一次把 GLM 推到真正的 1M 上下文。
**GLM-5 和 GLM-5.1 的 config.json 里，max_position_embeddings 都是 202,752（约 200K）。**只有 5.2 是 1,048,576。官方博客的措辞是「for the first time… on a solid 1M-token context」。
所以：拿 GLM-5 的技术报告去解释 GLM-5.2 的 1M，是行不通的——那份报告全文既没有 “IndexShare”，也没有 “1M”。（这一点我们直接对 40 页的 PDF 做过全文检索：IndexShare 出现 0 次。）
📐 计算口径（点开看完整公式与每一个常数的出处）
基准：同一序列长度 S 下的 BF16 · GQA8 稠密注意力，每层每 token 记为 100%。
「要存」的单位 = 一条 KV 条目；「要算」的单位 = 一次 query×KV 点积。三列的百分比都是相对同一个 S 下的这个基线，不是相对彼此。
存 = (24/93)·S + (69/93)·64 算 = (24/93)·S + (69/93)·128 24/93 层是 MLA（官方，技术报告 Table 1：69 KDA + 24 MLA）——只有这些层存 KV。
64 / 128 是示意折算：KDA 的循环状态是 dk×dv=128×128 的矩阵，一条 KV 条目是 K+V=2×128 → 状态 ≈ 64 条 KV 的体积；每 token 的状态更新约 128 个点积单位。head_dim=128 是我们假设的，报告未给。
n = S/m W = min(1024, S) 存 = (n + W) × 0.25 × 0.55 算 = 0.25·n + min(k, n) + W m = 4（压缩率）来自 Raschka 的独立技术博客，调研档案明确标注它没有对上论文公式——按示意值用。
× 0.25：核心注意力是共享 KV 的 MQA（论文 Eq.19，压缩条目既当 K 又当 V），一份 KV 对上基线 GQA8 的 4 组 → 再省 4×。
× 0.55：KV 混合精度存储（RoPE 维 BF16 + 其余 FP8，论文 §2.3.4）。
W = 1024 滑窗、k = 512：论文有滑窗分支与 top-k 选择（Eq.17），但没给具体数值，这两个是示意值。
0.25·n：lightning indexer 扫全部压缩条目，单条成本按稠密点积的 1/4 计（indexer 用 FP4 且维度低，具体维度报告未给，示意）。
存 = S × 0.56 算 = 0.25·S/g + min(k, S) g = 4 或 1 存全量：DSA 不压缩序列，每个 token 的 KV 都留着，只是选择性地读。
× 0.56：MLA 低秩潜向量（按 DeepSeek-V2 的 512+64=576 维对上 GQA8 的 4×2×128=1024 维折算）——GLM-5.2 自己的 MLA 维度调研档案未覆盖，示意。
g = 4：IndexShare——每 4 层只有第 1 层真算 indexer，另 3 层复用它的 top-k（官方，2.9× 的来源）。关掉时 g = 1。
⚠️ 这个模型只算注意力那一部分。官方的「27% FLOPs」「2.9× FLOPs」都是整模型单 token FLOPs——里面占大头的是 MoE 前馈层，跟注意力路线没关系。所以本图的百分比会比官方数字更极端，这不是矛盾，是口径不同。这正是读对比表时最容易踩的坑。
试三件事：
① 先把滑杆推到最右（1M），看三列的「要存」那一行——GLM 是 56%，K3 是 26%，V4 是 3% 出头。三条路省的完全不是同一样东西。
② 再把滑杆拖回最左（1K）：V4 的「每 token 要算」会超过 100%——比朴素的稠密注意力还贵。滑窗和 indexer 是固定开销，序列太短时根本摊不薄。这三条路都是为 1M 设计的，不是为 4K。
③ 点开底部的「计算口径」面板，把每一个常数的出处读一遍。里面有一条最该记住：官方说的「27% FLOPs」「2.9×」是整模型单 token FLOPs（大头是 MoE 前馈层），而这个实验只算注意力那一部分。同一个词、两个口径——这正是对比表最常见的骗人方式。
试三件事：
① 一层一层点，别一键走完。走到第 2 层时停下来读解说——复用的是「选哪些 token」这个决定。
② 盯住最右边那一列：无论第几层，Q/K/V、注意力、FFN 都照做。IndexShare 一点注意力都没省，它省的只有 indexer。
③ 走完之后看最后那段口径提醒：indexer 单项是 4×，官方整模型口径是 2.9×，IndexShare 依据的论文（IndexCache）实测又是 1.82× / 1.48×。**三个数字，三个口径。**能把它们分清，你就已经比大部分转述文章更专业了。
IndexShare 的代价，官方没有报。
后 3 层被迫使用别的层挑出来的 token。不同层学到的表示不一样，第 4 层想看的未必是第 1 层认为重要的——这是一个用「选择新鲜度」换算力的交易。
但调研档案里找不到任何关于这项副作用的对照数据（没有「关掉 IndexShare 掉几分」的消融）。所以正确的说法是：官方未报副作用数据——不是「没有副作用」。
顺带一个可以核验的旁证：Raschka 的独立分析确认了 IndexShare 的排布模式确实是 full, shared, shared, shared 的四层循环，并且明确指出 2.9× 是架构层面的 FLOPs 估算，不是实测墙钟加速。
除了注意力，它们还改了什么
这张表里有 5 个格子标着「未核实」——空格本身就是这一节要教的东西。
注意力是主线，但三份材料里还有一堆值得并排看的东西：残差怎么改的、用什么优化器、后训练怎么做的、许可证能不能商用。
下面这张表可以逐行点开。 请特别注意标红的「未核实」——那不是我懒得查，是调研档案确实没有覆盖。
三件事：
① 先点「🤝 独立收敛到同一处」——K3 和 V4 两支互不相干的团队，把后训练做成了几乎同构的范式：专家分开练、蒸馏合成一个。这种独立收敛比任何一家的自吹都更说明问题。
② 再点「⚠️ 含未核实」——5 个「未核实」全在 GLM-5.2 那一列，因为它没有自己的技术报告。
③ 点「参数规模」那一行读详情——里面埋着本模块最经典的两颗雷：291B 徽章伪影和 753B vs 744B 口径。
「未核实」和「没有」是两回事，这是本节最重要的一条写作纪律。
「GLM-5.2 的残差改造：未核实」= 我们不知道。
「GLM-5.2 用的是常规残差」= 一个我们没有证据支持的断言。
绝大部分错误的技术转述，都诞生在这两句话之间的那一步——为了让表格好看，把空格填上了。你以后写任何对比材料，宁可留一个显眼的空格。
CAISI 给 DeepSeek V4 的那一巴掌
本模块的方法论高潮。M7 教你把评测分三层，这一节给你看第三层塌掉是什么样子。
M7 教过把评测数字分三层。先快速复习：
| 层级 | 含义 | 可信度 |
|---|---|---|
| ① 第三方独立 | 外部机构自己评测并发布 | 最高，尤其是含非公开基准的 |
| ② 自跑但披露了偏差 | 官方自己跑，但主动说明与标准配置的差异 | 中，且披露密度本身是可信度指标 |
| ③ 纯自报、结构上不可复现 | 依赖内部训练过程或内部基准 | 最低——不是说它假，是说没人能检验 |
M7 的 K3 是这套分层的正面样本：报告专列一节放第三方评测，甚至主动交代自己哪些数字用了非标准配置。
这一节给你看反面样本。
案例：DeepSeek V4 的自报 vs NIST CAISI 的独立评测
V4 自己怎么说：
- 推理能力超 GPT-5.2 / Gemini-3.0-Pro，略逊 GPT-5.4 / Gemini-3.1-Pro
- 内部 agent 评测超 Claude Sonnet 4.5、接近 Opus 4.5
- 官方自评：「落后 SOTA 约 3–6 个月」
这个自我定位其实相当坦率——把「我们落后」写进技术报告的公司不多。
NIST CAISI 怎么说：
美国国家标准与技术研究院下属的 CAISI（Center for AI Standards and Innovation）在 2026 年 4 月对 DeepSeek V4 Pro 做了独立评测，5 月 1 日发布报告（5 月 2 日更新）。结论一句话：
V4「在 DeepSeek 自报的评测上得分，比在 CAISI 的评测上更好」。
具体到数字——CAISI 用 IRT 估计的 Elo：
| 模型 | CAISI 估计 Elo |
|---|---|
| GPT-5.5 (xhigh) | 1260 ± 28 |
| Opus 4.6 (max) | 999 ± 27 |
| DeepSeek V4 Pro (max) | 800 ± 28 |
| GPT-5.4 mini (xhigh) | 749 ± 46 |
读一下这张表的位置关系：
按 DeepSeek 自己的数据，V4 大约相当于 Opus 4.6 / GPT-5.4（发布早约 2 个月的机型）。按 CAISI 的评测，它更像 GPT-5——发布早约 8 个月。而在这张 Elo 表上，V4 Pro 离 GPT-5.4 mini 比离 Opus 4.6 更近。
CAISI 的总结论：DeepSeek V4 落后美国前沿约 8 个月。而 V4 自评是 3–6 个月。
为什么 CAISI 的结论能压过官方自报？关键只有一句：CAISI 的评测里包含非公开基准。
公开基准的题目和答案都在互联网上。任何一个训练数据管线，都可能——哪怕完全无意地——把它们吃进去。你没法证明一个模型「没见过」某个公开基准。
非公开基准不存在这个问题。这不是「谁的评测更权威」的问题，是结构上能不能被针对性优化的问题。
以后看到任何模型的分数，先问一句：这个基准的题目公开吗？
🔍 一个反面示范：我们在这一节里主动删掉了两个数字
调研过程本身也是可以被检验的。在写这一节时，有两条关于 Artificial Analysis 的说法没有通过对抗验证：
① 「AA 的智能指数给 V4 Pro（Max Effort）打 45 分，而开放权重中位数是 26」——1-2 票被驳回；
② 「AA 明确把 DeepSeek 自报的 MMLU-Pro / LiveCodeBench 数字标注为未经验证」——0-3 票被驳回。
这两个数字看起来都挺好用，尤其第一个还能给 V4 加分。但没通过验证就是没通过，所以它们不出现在正文里。
「1M 窗口」不等于「1M 有效」
这是长上下文时代最需要立刻建立的一条直觉。
架构上的 1M 是确认的：V4 与 GLM-5.2 的 config.json 里 max_position_embeddings = 1,048,576，可以直接 curl 下来核对。K3 也走完了 8K→64K→256K→1M 的四段式课程。
但第三方的长上下文评测（NIAH / MRCR 一类）报告：在满 1M 长度上，有效检索质量会掉到 100% 以下。
「窗口长度」是架构参数，config.json 里写着，可独立核验；
「有效长度」是能力指标，只能测，而且随任务类型变化。
这两个数字被混着用，是 2026 年模型宣传里最普遍的一种偷换。你要做的很简单：看到「支持 1M」，接着问「在 1M 上 NIAH / MRCR 是多少」。
对比表的口径陷阱
本模块出现过的每一个亮眼数字，都带着一个限定条件。放在一起看：
| 数字 | 真实口径 | 混用会怎样 |
|---|---|---|
| V4 27% FLOPs / 10% KV | 1M 上下文下、V4-Pro、对比 V3.2、整模型单 token | 换个基线、换个长度、只算注意力，全都不是这个数 |
| V4-Flash 10% / 7% | 同上，但这是 Flash 的数字，且出现在正文不是摘要 | 张冠李戴到 Pro 上 |
| V4 KV ≈ 2% | 对比 BF16 GQA8 基线 | 和上面那个 10% 不是一回事——基线不同 |
| GLM 2.9× | 1M 上下文下、理论 FLOPs 估算、整模型 | 说成「快了 2.9 倍」就错了 |
| IndexCache 1.82× / 1.48× | 30B 的 DSA 模型、200K 上下文、prefill / decode 实测 | 拿来给 GLM-5.2 的 1M 背书 |
| K3 2.5× scaling 效率 | Moonshot 内部训练 run 拟合，第三方无法复现 | 当成第三方结论引用 |
看完这张表，回头再看任何一张「三家对比」的表格，你应该产生的第一反应是：这几列真的是在同一个条件下测的吗？
顺带记一笔：V4 的论文摘要自称 “a preview version of DeepSeek-V4 series”。 preview 版的数字随时可能在正式版里变。引用时最好带上版本与日期。
十四个坑 + 该带走的
| 坑 | 症状 | 怎么办 |
|---|---|---|
| HF 合集页显示 V4-Flash 是 291B | 参数量对不上 | 徽章伪影——HF 系统统计 FP4/FP8 量化 safetensors 的已知问题。论文、模型卡正文、所有第三方推理商都是 284B |
| GLM-5.2 到底是 753B 还是 744B | 以为有一方写错了 | 两个都对：753.33B 是 HF 从 safetensors 机械数出的张量总数，744B 是 GLM-5 报告的架构级口径，差约 9B（1.2%），可能来自 MTP 模块 / 未共享 embedding / indexer 权重 |
| 说「GLM 提出的 DSA」 | 归属错误，找不到方法原文 | DSA 是 DeepSeek 的（V3.2-Exp，2025-09），MLA 也是 DeepSeek 的（V2）。GLM 自己的贡献是 IndexShare |
| DeepSeek 自己的文档里两套名字 | 搜 CSA 搜不到、搜 DSA 也搜不到 | 官方 API 文档新闻页说的是「Token-wise compression + DSA」，arXiv 论文与 HF 模型卡说的是「CSA + HCA」。两套术语在不同官方文档里都真实存在，二者是否指同一机制没有被任何确认结论解决 |
| 以为 V4 的 1M 是原生 RoPE 外推 | 高估长上下文的可靠性 | config.json：65,536 基础长度 × YaRN rope scaling 16 = 1,048,576。是插值扩展出来的 |
| 以为 GLM-5 系列都支持 1M | 选型直接翻车 | 只有 5.2。GLM-5 / 5.1 的 max_position_embeddings 都是 202,752 |
| 拿 GLM-5 的技术报告解释 5.2 | 讲了半天讲的是另一个模型 | GLM-5 报告全文 IndexShare 出现 0 次、1M 出现 0 次。5.2 没有自己的技术报告 |
| 把 preview 版的数字当定论 | 引用了会变的数 | V4 摘要自称 “a preview version”。引用带版本与日期 |
| 把「27% FLOPs」当注意力层的降幅 | 数量级错 | 那是整模型单 token FLOPs，大头是 MoE 前馈层。注意力单项的降幅比这更极端 |
| 把 2.9× 当实测加速 | 性能预期错 | 那是理论 FLOPs 估算（Raschka 独立分析明确指出这一点）。IndexCache 论文的实测是另一组数（30B / 200K：1.82× prefill、1.48× decode） |
| 信 NVIDIA NIM 文档把 DSA 解释成 “Dense-Sparse-Alternating” | 概念完全跑偏 | 那是该文档页的错误。GLM-5.2 自己 README 引用的论文（arXiv:2603.12201）明确定义 DSA = DeepSeek Sparse Attention |
| 把「窗口 1M」当「有效 1M」 | 生产环境上翻车 | 窗口是 config.json 里的架构参数；有效长度要看 NIAH / MRCR 的衰减曲线 |
| 只比架构不比可信度 | 高估自报强的那一家 | CAISI 案例：V4 自评落后 3–6 个月，独立评测说 8 个月 |
| 把 Kimi Linear 的 48B 当 K3 | 差约 58 倍（M7 讲过） | 那是方法论源头（arXiv:2510.26692），不是 K3 的 2.8T |
这一模块你应该带走的
- 三条路是三种妥协，不是三种实现：K3 不存（固定状态）· V4 存少（压缩 + top-k）· GLM-5.2 全存但少读（DSA + IndexShare）；
- 省算力 ≠ 省显存——GLM-5.2 是最干净的例子：FLOPs 降 2.9×，KV cache 一条没少；
- 凡是「省」的方案都要回答「省掉的万一有用怎么办」：K3 用 24 层 MLA 兜底，V4 用 HCA + 未压缩滑窗兜底，GLM 靠「本来就没丢」；
- 这些机制的收益全部依赖序列长度——短序列下它们可能比稠密注意力更慢（实验 A 里 V4 在 1K 下超过 100%）；
- CSA 的压缩是学出来的加权，不是池化；两路窗口错位重叠是为了救回被硬切在边界上的关联；
- Lightning Indexer 用 ReLU 不用 softmax，因为打分环节自己不能变成新瓶颈；
- IndexShare 共享的是「选哪些 token」的决定，注意力本身每层照算；代价是选择的新鲜度，官方未报副作用数据；
- 同一个问题可以有相反的正解：位置编码上 K3 全删（NoPE）、V4 少量巧用（部分 RoPE + 输出 −i），两家都做到了 1M；
- 独立收敛是强证据：K3 与 V4 各自走到「专家分练 + 蒸馏合一」，比任何一家的自述都更有说服力；
- 含非公开基准的独立评测 > 一切自报——因为公开基准在结构上就可能被针对性优化；
- 「未核实」和「没有」是两回事，宁可留一个显眼的空格。
概念索引（本模块登场）： CSA · HCA · 压缩注意力 · 两路错位重叠窗口 · Lightning Indexer · index score · top-k 稀疏选择 · 共享 KV 的 MQA · 分组输出投影 · 未压缩滑动窗口分支 · 部分 RoPE · 输出侧 −i RoPE · attention sink · QKV RMSNorm · mHC · Hyper-Connections · 双随机矩阵 / Birkhoff 多面体 · Sinkhorn–Knopp 迭代 · 混合 Newton–Schulz · Hash 路由 MoE · Sqrt(Softplus) 亲和度 · DSA · IndexShare · 跨层索引复用 · KVShare · YaRN rope scaling · NIAH / MRCR · IRT 估计 Elo · 非公开基准 · 张量口径 vs 架构口径 · 量化徽章伪影 · on-policy 蒸馏 / reverse KL · FP4 量化感知训练
本模块的任务单
| 步骤 | 你的动作 | 说明 |
|---|---|---|
| 1. 精读 V4 §2.3 | CSA / HCA / 三个小设计 | 配着上面两个公式解剖读 |
| 2. 核对一次 config.json | 去 HF 上把 V4-Pro 和 GLM-5.2 的 max_position_embeddings、rope_scaling 拉下来 | 这是你唯一能独立核验的部分——训练侧全是厂商自述 |
| 3. 自己填一遍空格 | 把 s4 那张表默写一遍，标出你敢确定的和不敢的 | 重点不是记住答案，是养成标「未核实」的手感 |
| 4. 追一条引用链 | DSA：GLM-5.2 → DeepSeek-V3.2-Exp → MLA (DeepSeek-V2) | 三家的稀疏注意力全都汇到 DeepSeek 这一条线上 |
| 5. 记问答 | 把读不懂的地方问我 | 记录到 05-问答记录/M8-前沿三强-问答.md |
有不明白的？ 随时在对话里问我，我会记录到 05-问答记录/M8-前沿三强-问答.md。
你真正带走的能力： 下一份前沿报告发布时，你能翻到架构那一章，用三句话定位它：它是「不存 / 存少 / 全存但少读」里的哪一条？它的兜底机制是什么？它的收益是在哪个序列长度上测的？ 然后翻到评测那一章，把数字分成三层，找出那些没有第三方背书的格子。这比记住 CSA 的任何一条公式都值钱。
一手来源优先，且三家的可得性不一样
V4 有完整报告，K3 有完整报告，GLM-5.2 没有——查资料时这个差别决定了你能走多深。
🎮 想更直观 20–40 分钟
DeepSeek-V4-技术报告原文解析.md（逐页精读的公式与机制）· ② DeepSeek-V4-深度调研对抗验证.md（发布事实 / 许可证 / NIST CAISI）· ③ GLM-5.2-深度调研对抗验证.md（753B/744B 口径、IndexShare、1M 是 5.2 独有）· ④ Kimi-K3-技术报告原文解析.md。🔬 想吃透原理 3–5 小时
⚠️ 注意摘要自称 preview version，数字可能在正式版变。
但它对本模块仍然必读的部分是 DSA 那一节：它用 MLA 与 DSA 两个基座模型做了长上下文基准和 SFT loss 的直接对照，还给了「DSA 把注意力计算降约 1.5–2×」这个自报数——这是理解 GLM 为什么选这条路的唯一一手材料。
📄 想追引用链 按需
我替你排除了什么：
- 所有「DeepSeek V4 / GLM-5.2 深度解读」类二次转述——三个模型都在几周内发布，解读文章的信噪比极低，且已经确认多篇在参数量（291B）和归属（把 DSA 说成 GLM 的）上抄错。
- NVIDIA NIM 的 GLM-5.2 文档页（作为术语来源）——它把 DSA 解释成 “Dense-Sparse-Alternating”，与所有一手来源冲突。作为 API 参考可以用，作为概念解释不要用。
- HuggingFace 合集页的参数徽章——V4-Flash 那个 291B 是量化统计伪影。
- Artificial Analysis 的两条具体分数说法——在对抗验证里被 1-2 / 0-3 票驳回（详见正文的深挖框）。
- 把 Kimi Linear 48B 当 K3 的资料（M7 已排除，这里继续沿用）。
- 一切用 GLM-5 报告解释 GLM-5.2 的 1M 上下文与 IndexShare 的材料——那份报告里这两样东西根本不存在。