（二）同样是 1M 上下文，大模型走的路为什么完全不同
先把镜头从 GLM-5.2 拉远
上一篇我把 GLM-5.2 拆成了五刀：DSA、IndexShare、MLA、MTP、MoE，每一刀在它的 config.json 和权重清单里都能找到证据。但写完我心里一直有个问题没回答透：为什么偏偏是这几招？
Llama、Gemini、DeepSeek、Qwen——哪家没号称自己支持长上下文？如果答案都是”1M”，那 GLM 这套组合拳到底特别在哪？还是说，大家其实各走各的路，只是终点都叫 1M？
要回答这个，得把镜头从 GLM-5.2 身上移开，看看整个行业。结论可能出乎你意料：长上下文这道题，业界至少有四条完全不同的路线，各家选的组合差别很大。 底层技术当然有共享——比如 MLA 是 DeepSeek 提的、GLM 直接拿来用，MoE 也是好几家的标配——但在”走哪条路”这件事上，分化很明显。
长上下文到底卡在哪？
先统一语言。一个模型想把上下文做到 1M（100 万 token），会撞上四道坎。上一篇拆五刀时我零散提过，这里正式列一下，因为它们是理解四条路线的坐标：
坎 1:算不动 —— 注意力是 N²，100 万 token 就是万亿级点积
坎 2:放不下 —— 存历史 token 的 KV Cache 会撑爆显存
坎 3:推不动 —— 模型参数动辄千亿，全算一遍太贵
坎 4:蹦得慢 —— 一个字一个字生成，每蹦一个都要跑完整个模型面对这几道坎，业界的破法分成了四条路线。 先说范围：坎 3（推不动）、坎 4（蹦得慢）上一篇五刀里的 MoE、MTP 已经拆过，这篇只聊长上下文专属的算法路线——下面四条路分别破的是：位置编码不够远（路线一）、算不动（路线二）、放不下（路线三），再加一条干脆用硬件硬扛所有坎的（路线四）。先看全景，再挨个拆。
路线一：改位置编码——便宜，但有天花板
这条路破的，是一道容易被忽略的隐性坎：模型怎么知道”一个字在第几个位置”？
注意力机制本身是”位置无关”的——它只看 token 的内容，不管这个 token 在第 1 位还是第 100 万位。如果不额外注入位置信息，模型分不清”我吃苹果”和”苹果吃我”。主流方案叫 RoPE（旋转位置编码）：把 token 向量旋转一个角度，位置越远旋转越多，两个 token 的角度差天然就反映了它们的距离。
但有个坑：模型训练时只见过一定范围内的位置。 比如只训到 4 万，推理时给它第 100 万位，它就”晕”了——这叫外推问题。
路线一的解法都围着 rope_theta（旋转的基础频率）做文章。这个值越大，“钟表的时针”转得越慢，能编码的位置就越远：RoPE 论文默认 1 万，Llama 3.1 提到 50 万，GLM-5.2 干脆拉到 800 万。
但光调大 theta 不够，模型还得真见过那么长的序列。Llama 3.1 是分阶段扩展训练（8K→128K）把上下文拉到 128K；GLM-5.2 训练时也是分阶段扩到 128K（官方博客口径），区别在它把 theta 拉到 8M，让位置编码的覆盖范围一直撑到 1M——1M 不是”训出来的长度”，是”大 theta 撑出来的支持范围”。
还有一种更便宜的玩法：训完不重训，推理时用 YaRN/NTK 零样本”拉伸”位置编码，社区常用，但质量会随长度衰减。
但这条路有硬天花板。靠位置编码策略单独撑，到 128K 以上质量就开始明显下滑，最典型的毛病是**“中间遗忘”**——长上下文里，模型对开头和结尾记得清楚，中间的内容容易被忽略。尤其是零样本外推（YaRN 那类、不重训）出来的长上下文，这个问题最明显。
这对你选模型意味着什么： 看到一个模型”宣称支持 256K”，别急着高兴。问一句：它是训练时就拉到这个长度的（分阶段或原生），还是推理期用 YaRN 零样本外推出来的？同样是 256K，零样本外推的那个很可能在长文档中间”走神”。标称长度不等于有效长度——这是这篇我最想给你的一句话。
路线二：改造注意力——从根本上破 N²
这条路直接砍坎 1（算不动）。
标准注意力里，每个 token 要和序列里所有 token 算相关性，总量是 N²。但仔细想想：句子里那个”的”字，真的需要和另外 100 万个 token 都算一遍吗？显然不需要——它只关心它修饰的那个词，其他 99.99% 的 token 和它无关。
核心思路就是这一句：别让每个 token 和所有人算，只算最相关的几个。 至于”怎么只算几个”，业界分出了两条子路：
- 稀疏注意力：用一个轻量级 indexer 先粗筛出最相关的 top-k，只对这些精算。DeepSeek 从 2025 年的 NSA 论文一路演进到 V4 的 CSA + HCA（压缩+稀疏的多层分工），GLM-5.2 用的是 DSA——两家思路同源，路径不同。
- 线性注意力：换一种更省的数学形式，把 N² 直接降到线性 N。Qwen 在 Qwen3-Next 上走的是这条——用 Gated DeltaNet（线性注意力）和标准注意力做 3:1 混合，和稀疏注意力是平行的另一套思路。主线 Qwen3.7-Max 的具体方案未公开。
GLM-5.2 的 config.json 里，这几个字段直接交代了它走的是稀疏这条路：
index_topk: 2048
index_topk_freq: 4每个 token 先用索引器从 100 万个历史 token 里粗筛出 2048 个，只在这 2048 个上算完整注意力。N² 被砍成了 N×2048——1M 长度下，单 token 的精算量从 100 万次降到 2048 次，约为原来的 1/500（上下文越长，省得越多）。
再加 IndexShare 每 4 层复用同一个索引器，把粗筛成本也省掉 3/4。
这条路是从根上解决计算量，代价是实现复杂，而且理论上”有损”（粗筛可能漏掉真正相关的 token）。GLM 靠 2048 的冗余 + 多层覆盖 + 训练来弥补。这是开源模型能冲到 1M 的关键一招，后面第 5 篇会单独深讲。
这对你用 AI 意味着什么： 为什么你把一整份 50 页文档丢给 AI，它有时只”认真看了”开头几页？因为稀疏注意力做的本来就不是逐字精读，而是相关性筛选。和你的问题语义无关的部分，可能被粗筛跳过。所以把关键信息放在和问题语义相近的位置，比埋在第 47 页更容易被它捞到。
路线三：压缩 KV Cache——让中间结果放得下
这条路破坎 2（放不下）。
就算注意力算得动了，还有个拦路虎：模型生成时，要把所有历史 token 的中间结果（K 和 V）存起来复用，不然每生成一个新字都要重算前面全部。1M token 的 KV Cache 能轻松达到几 TB——没有任何单机装得下。
压缩 KV Cache，开源阵营内部又分了两派，做法不一样：
| 派别 | 思路 | 压缩比 | 代表 |
|---|---|---|---|
| GQA | 让多个查询头共享同一组 K/V | ~4–8×（看头组配比） | Llama 3、Qwen3 |
| MLA | 用训练好的矩阵把 K/V 压成低维”潜在向量” | ~57×（GLM 口径） | GLM-5.2、DeepSeek-V3（V4 已转混合稀疏） |
GLM-5.2 选的是 MLA。上一篇算过，kv_lora_rank: 512 把 KV 压到 512 维，1M 长度下 KV Cache 从约 ~5TB 压到 ~88GB（约 57 倍，这个倍数是我按 config 维度估算的，非官方数字）。
为什么 GLM 不用更简单的 GQA？ 因为 GQA 是”共享头”，压缩有限；MLA 是”低秩压缩”，压得更狠。冲 1M 需要更激进的压缩，GQA 的力度不够。 这个选择和它走稀疏注意力是配套的——两者都指向”开源、可部署、不依赖海量硬件”。第 4 篇会把 MLA 的低秩压缩讲透。
路线四：堆硬件——闭源巨头的秘密武器
前三条路都在改算法。第四条换了个思路：既然算法优化有上限，那就用硬件硬扛。
代表技术是 Ring Attention（环形注意力）。它的想法是：把一个超长序列拆到几十张卡上，数据在卡之间”沿环形拓扑接力传递”，边传边算，把通信开销藏在计算时间里。1 张卡能存 X 个 token，N 张卡就能存 N×X——理论上加够多卡，上下文能无限长。
这条路最妙的一点：它不改注意力的结果，质量无损。 不像 DSA/MLA 有损压缩，Ring Attention 算出来的是和标准注意力一模一样的结果，只是分摊到了多张卡上。Google 的 Gemini 能撑到 2M（Ultra），业界普遍推测靠的就是 Ring Attention + TPU 集群的组合——Google 没正式公开架构。
但这条路有个致命门槛：它需要海量同构加速器 + 超高速互联。 普通开源用户只有 1～8 张卡，跑不了 Ring Attention。这就是开源模型必须走路线二、三的算法创新，而不能靠路线四硬扛的根本原因——不是不想，是玩不起。
这对你意味着什么： 同样是”长上下文”，Gemini 背后可能是一个 TPU 机房在硬撑，GLM-5.2 背后是一套算法在精打细算。对你这个使用者来说，区别在部署门槛：前者只能通过 API 用，后者权重开源、你自己有卡就能跑。
一张大表：各家到底怎么组合
把四条路线汇总，这是整个行业的技术地图（以 GLM-5.2 发布时点的主要模型为例，各家细节据其公开资料）：
| 模型 | 上下文 | 路线一 位置编码 | 路线二 注意力改造 | 路线三 KV 压缩 | 路线四 硬件 |
|---|---|---|---|---|---|
| GLM-5.2 | 1M | RoPE θ=8M（训 128K 撑到 1M） | DSA + IndexShare | MLA | 推理框架 |
| DeepSeek-V4-Pro | 宣称 1M | RoPE | CSA + HCA 混合稀疏 | 混合压缩（~10% KV，相对 V3.2） | — |
| Qwen3.7-Max | 宣称 1M | — | 混合线性注意力（Qwen3-Next 方向，主线未公开） | — | — |
| Gemini 3.1 Pro | 1M（Ultra 2M） | 未公开 | 未公开 | 未公开 | TPU 集群 |
| Llama 3 | 128K | 分阶段扩展训练（θ=500K） | 无 | GQA | FlashAttention |
路线二的”注意力改造”是个总称：降 N² 有稀疏注意力（GLM、DeepSeek）和线性注意力（Qwen）两条平行子路，思路不同，目的相同。
从这张表能看出三件事。
第一，长上下文不是单一技术，是组合拳。 没有任何一家只用一条路线。开源三强（GLM、DeepSeek、Qwen）都到了 1M，但组合各不相同——GLM 是单步 DSA + IndexShare，DeepSeek 是 CSA + HCA 混合稀疏，Qwen 走混合线性注意力。
第二，差异已经不在”能不能到 1M”，而在”到 1M 之后各自怎么省算力”。 GLM 官方公布自己的 1M 下每 token FLOPs 降低 2.9×（博客数据）。同样是 1M，谁更省、谁在长程任务上更稳，才是真正的竞争点。
第三，GLM-5.2 的差异化在 IndexShare。 它和 DeepSeek 都押稀疏注意力（路线二），但路径不同——GLM 单步 indexer + 每 4 层共享，DeepSeek 是 CSA + HCA 多层分工（CSA 压缩后稀疏选相关 token，HCA 重度压缩后稠密抓全局）。“每 4 层复用索引”这个设计，在主流 1M 方案的公开材料里我没见到相同的层间共享，是 GLM 的工程贡献。
我拆 config 时最确认的一件事：GLM 没走推理期外推
写这篇时我又翻了一遍 config.json，注意到一个细节，正好印证 GLM 走的是哪条路：
rope_parameters:
rope_theta: 8000000
rope_type: "default"
max_position_embeddings: 1048576rope_type: "default" 说明 GLM 没上任何推理期位置缩放——不是 YaRN/NTK 那种训完再外推的手段。它的 1M 是训练期就把 theta 拉到 8M、序列扩到 128K（官方博客口径），让位置编码覆盖范围撑到 1M：长上下文能力是训练期做进去的，不是推理时硬撑。这也是它敢把 max_position_embeddings 写成 1048576 的设计意图。
四条路的演进：一条时间线
这四条路不是同时冒出来的，而是随着上下文越拉越长，被逼着一步步演进出来的：
第一波:调位置编码 + 长序列训练（便宜但不彻底）
Llama/Qwen 调大 rope_theta + 分阶段训练把 8K 扩到 128K（推理期也可叠 YaRN）
→ 靠位置编码单独撑，卡在 128K 以上，中间遗忘严重
第二波:压缩 KV Cache（让中间结果放得下）
GQA/MLA 把 Cache 压小
→ 解决了存储，但注意力的 N² 还在
第三波:改造注意力（让算得动）
NSA(2025 论文)→ DeepSeek 演进到 CSA+HCA、GLM 用 DSA，把 N² 降到 N×k
→ 真正解锁 1M+
第四波:堆硬件并行（闭源巨头独门）
Ring Attention 用多卡硬扛
→ Gemini 2M 的秘密，但开源玩不起
GLM-5.2 的选择，是把第一波（RoPE θ=8M 扩长）+ 第二波（MLA）+ 第三波（DSA + IndexShare）+ MoE 全部组合起来，做到开源 1M。它没走第四波——因为它没有 Google 级别的专用硬件，也必须保证普通多卡能部署。
为什么 GLM 偏要走最难的路？
你可能会问：GLM 这套组合（超大 theta 扩长 + 稀疏注意力 + KV 压缩 + MoE）是技术难度最高的。为什么不学 Llama 停在分阶段训练的 128K？为什么不学 Gemini 堆硬件？
一句话：开源的处境，决定了它必须走架构创新这条路。
学 Llama（分阶段训练到 128K），省事，但天花板卡在 128K，再往上靠零样本外推质量衰减，GLM 想冲 1M 这条路不够。学 Gemini（Ring Attention），质量好，但需要 TPU Pod 级硬件，开源用户根本部署不了，违背”人人可用”的初衷。
只有走架构创新这条路——技术难度最高、研发投入最大，但部署门槛低，普通多卡就能跑。用最难的路，换最广的可部署性。 这是 GLM-5.2 最值得讲的故事，也是后面六篇连载要逐刀拆解的这条路。
写在最后：怎么用这张路线图
读完这篇，我希望你带走一个选型直觉。以后再看到模型宣传”支持 N 万上下文”，别只看那个数字，按这张图问它三个问题：
- 它是训练时就拉到这个长度的，还是 YaRN 零样本外推出来的？（决定长文档中间会不会走神）
- 它的算法有改造吗（注意力稀疏化、KV 压缩）？还是纯靠堆硬件硬撑？（决定你能用开源权重自己跑，还是只能调 API）
- 它的 KV Cache 压缩够激进吗？（决定同样一块显存能装下多长的对话）
能问出这三个问题，你就从”被跑分牵着走”变成了”看懂各家在走哪条路”的人。
但这里有个前置：要真正看懂路线二（改造注意力）和路线三（KV 压缩），你得先搞清楚标准注意力到底在算什么、为什么是 N²、KV Cache 到底是个什么东西。这些是地基。下一篇就是来打地基的。
下篇预告：《预备知识：注意力到底在算什么？》
本文架构配置字段（rope_theta、rope_type、max_position_embeddings、index_topk、index_topk_freq、kv_lora_rank 等）均来自 GLM-5.2 公开的 config.json；IndexShare 2.9× 来自官方博客。各家技术路线（DeepSeek-V4 的 CSA+HCA 混合稀疏、Qwen3-Next 混合线性注意力 / Gated DeltaNet、Gemini Ring Attention/TPU 集群、Llama 3.1 分阶段扩展训练 / GQA）据其公开技术报告、论文与 HuggingFace / vLLM 资料；其中 DeepSeek NSA 为 2025 年论文、V4 已演进到 CSA+HCA，Qwen3.7-Max 主线方案细节未公开，Gemini 架构 Google 未正式公开、为业界推测。无任何闭源信息。