（一）GLM-5.2 开源：读完 1M 上下文的实现原理，你能更懂 AI
先从你遇到过的一个场景说起
你跟 AI 聊了半天，把需求、背景、代码全交代清楚了，结果它突然”忘了”你十轮前说过的一句话。或者你把一整份 50 页的文档丢给它，它却只回答了前面几页的内容。你会不会纳闷——AI 的”记忆”到底是怎么工作的？为什么有时候过目不忘，有时候转眼就忘？
答案藏在一个叫”上下文(context)“的东西里。而你用 AI 遇到的那些别扭，不管是它忘了前文、答串了，还是长文档只看了开头几页，根子多半都在上下文这一件事上。
为什么你应该懂一点 AI 的原理
搞懂这个原理，不是为了炫技。最近看到一位技术博主说的一句话我很认同：“AI 是个人能力的放大器”。但放大器有个前提：你得先有”被放大的东西”。把 AI 当黑盒用，它放大的只是你的运气；懂一点它背后的原理，知道它为什么会忘、为什么会答偏，你才能真正驾驭它。
具体到上下文这件事，懂了原理你能得到三个判断力：什么时候该拆分对话、什么时候可以放心丢整份文档；为什么不同模型在长任务上表现差那么多；以及**“请记住前面的约定”到底什么时候有用、什么时候纯属浪费**。这三个问题，下面拆完架构你都会有答案。
正好，GLM-5.2 刚开源了
它是开源模型里把上下文做到 1M(100 万 token)的其中一员。之前内测的时候我已经拿它真刀真枪跑过一轮实测，从写小函数一路加码到给真实开源库修 bug。那时它是闭源 API，我只能用，看不见里面长什么样。
现在权重公开了——MIT 协议，放在 HuggingFace 和 ModelScope 上，代码仓库在 GitHub，官方也发了介绍博客。
权重的链接刚挂出来，我就把它们拉下来了。第一件事不是跑 benchmark，而是把它的架构配置文件和权重清单拆开看——一个模型的 config.json 和 tensor 清单，就是它的”出生证明”，藏不住任何东西。我想搞清楚一个问题：“宣称支持 1M 上下文”和”工程上真的跑得动 1M 上下文”，中间到底差了多少架构功夫？
什么是 HuggingFace？它和 GitHub 有什么区别？ 简单说：GitHub 放代码，HuggingFace 放模型权重。 GitHub 你应该熟——程序员存代码、协作的地方。但一个 AI 模型除了代码，还有动辄几十 GB 到上 TB 的”权重文件”(就是模型训练完学到的那些数字)。这种大文件放 GitHub 不合适，所以业界用 HuggingFace 专门托管模型、数据集，配套版本管理、在线试跑。GLM-5.2 这种 1.51TB 的模型，代码在 GitHub 看逻辑，权重在 HuggingFace 下载——两边分工。
1M 这个数字，开源里已经有几个模型宣称支持了，除了 GLM-5.2,DeepSeek V4-Pro、Qwen3.7-Max 也宣称到了 1M(这几家的具体上下文口径以各自官方资料为准)。但”宣称支持 1M”和”工程上跑稳 1M”中间隔着一道沟。正如 GLM 官方博客自己说的：“宣称 1M 上下文很容易，但在真实工程压力下保持可靠却困难得多。” 我想搞清楚的就是后者：靠什么架构，让 1M 不只是个数字，而是能扛住长程编码任务的能力。
先说结论：五刀，刀刀都在给”长上下文”清障
我拆完 config.json 和 model.safetensors.index.json(这个文件列了 59585 个权重张量，张量数也是笔者读取所得)反推出 GLM-5.2 在架构上一共动了五个地方。其中四刀直接砍”把上下文拉到 1M”时挡路的成本，剩下一刀(MoE)砍的是更靠前的前提——模型本身别太大。每一刀砍的：
| 改了什么 | 砍掉的是哪块成本 | 量级 |
|---|---|---|
| DSA(动态稀疏注意力) | 注意力的计算量(N² 爆炸) | 1M 长度下每 token 只算 2048 个，而非 100 万个 |
| IndexShare(每 4 层共享索引器) | DSA 那个”粗筛”本身的计算量 | 3/4 的层不再重算 indexer |
| MLA(低秩 KV 压缩) | KV Cache 的显存占用 | KV 维度从上万维压到 512 |
| MTP(投机解码) | 生成速度(一个 token 一个 token 蹦) | 接受长度 4.56 → 5.47 token |
| MoE(混合专家) | 模型太大跑不动(753B 全激活) | 256 专家选 8 + 1 共享，只激活 3.5% |
这五件事任何一件单独拎出来，都不够撑起 1M。这也是为什么别的开源模型卡在 128K/256K——它们可能只做了其中一两件。GLM-5.2 的核心叙事是：五件一起做，1M 才从”理论可行”变成”工程上跑得动”。
下面挨个说，每一刀在权重清单里都能找到证据。这篇只讲”架构上动了什么刀”，数学推导留给后续连载。
刀一：DSA——每个 token 不再和 100 万个 token 都算一遍
长上下文最贵的一件事，是注意力机制的 N²：序列里每个 token 都要和所有其他 token 算一次相关性。1M token 就是 1M × 1M = 一万亿次点积。而且这还只是读一次输入、跑一层——乘上 78 层，量级还要再翻。
GLM-5.2 的 config.json 里有这么几个字段，直接交代了它的解法：
index_topk: 2048
index_head_dim: 128
index_n_heads: 32翻译成人话：每个 token 在算注意力之前，先用一个叫”索引器(indexer)“的小网络，从 100 万个历史 token 里粗筛出最相关的 2048 个，然后只在这 2048 个上面算完整的注意力。
1M 长度下，计算量从”每 token 算 100 万次”降到”每 token 算 2048 次”——约为原来的 1/500(单看注意力这一步；后面 IndexShare 还会再把整 token 的 FLOPs 往下压)。
⚠️ 这里我先不展开”索引器凭什么筛得准""筛错了怎么办”——这是整个架构里最精巧、也最反直觉的部分，我会单开一篇讲(对应连载第 5 篇)。现在你只需要知道：有一个粗筛机制，把 N² 砍成了 N×2048。
💡 这对你用 AI 意味着什么： DSA 这个”每 token 只看 2048 个最相关的”机制，直接解释了一个常见现象——你把一整份长文档丢给 AI，它不一定每个字都”仔细看”了。它做的是相关性筛选，和问题无关的部分可能被粗筛跳过。所以：把关键信息放在和问题语义相近的位置(而不是埋在第 47 页)，理论上能提升 AI 找到它的概率。这是 DSA 原理给你的一个实用直觉。
刀二：IndexShare——索引器本身也要省，每 4 层复用一个
DSA 已经够聪明了，但 GLM-5.2 还多砍了一刀，这是我拆权重清单时最意外的一个发现。
78 层 transformer 里，每一层理论上都需要一个自己的索引器去粗筛。但权重清单显示：78 层里只有 21 个层有自己的索引器(full)，其余 57 个层(shared)是复用别人的。 这 21 个的分布是：前 3 层(first_k_dense_replace: 3)各自带一个索引器，之后 sparse 层按每 4 层共享一个，所以不是简单的 78÷4，而是 3 + 18 = 21。
规律藏在 index_topk_freq: 4 这个配置里——每 4 层共享同一个索引器：博客原文说 “the indexer is placed at the first of 4 layers and topk indices are used for 4 layers”。也就是说每 4 层里只有第 1 层跑索引器，后 3 层复用它的 top-2048 名单，粗筛这一步在 3/4 的层里被省掉。
这个设计官方叫 IndexShare。它在博客里被专门点名，说”在 1M 上下文长度下把每 token FLOPs 降低 2.9 倍”。注意这个 2.9× 指的是整个 token 的 FLOPs(粗筛 + 全算加起来的总账)，不是粗筛单步——粗筛单步能省 3/4，但因为它只占总开销的一部分，摊到整 token 上是 2.9 倍。
更有意思的是，这个 IndexShare 还被复用于 MTP(见刀四)——博客里有个 index_share_for_mtp_iteration 的配置项专门管这件事。一个设计同时服务两件事，这种”复用”在工程上往往比单独优化更值钱。
顺带说一句：GLM 的索引器只在每组的第一步算、后续层复用——这就是后面对比表里说的”单步 indexer”(本文用这个词概括 GLM 的做法)，区别于 DeepSeek 那种每层都跑完整流程的设计。
刀三：MLA——KV Cache 从 ~5TB 压到 ~88GB
就算注意力算得动了，还有个拦路虎：KV Cache。
模型在生成时，要把所有历史 token 的中间结果(K 和 V)存起来复用，不然每生成一个新字都要重算前面全部。1M token × 78 层 × 巨大的维度，这个缓存能撑到 ~5TB——没有任何单机能装下。
GLM-5.2 的解法叫 MLA(Multi-head Latent Attention)，和 DeepSeek-V2 引入的 MLA 同属一条技术路线。配置里这几个字段交代了它的核心：
q_lora_rank: 2048
kv_lora_rank: 512kv_lora_rank: 512 是关键——它把 KV 压缩到了 512 维。原本每个 token 要存的 KV 是上万维的大向量(config 里每层 64 个注意力头 × 256 维)，现在只存一个 512 维的”压缩包”，用到的时候再用训练学好的矩阵解压还原。
按上述维度粗算，1M 长度下 KV Cache 从约 ~5TB 降到 ~88GB(约 57 倍，这个倍数是笔者按 config 维度估算，非官方公布数字)。MLA 这条路线的设计目标就是在大幅压缩的同时尽量保住质量——具体到 GLM-5.2 上的质量影响，需要实测消融验证，这里先讲架构动作。
💡 这对你用 AI 意味着什么： MLA 解决的是”AI 记得住多少”的上限——KV Cache 压缩后，同样一块显存能装下多得多的对话历史。这也是 GLM-5.2 追求 1M 可靠性的设计意图之一。你不需要担心喂得太多它记不住，但要警惕另一种情况：有些模型标称支持长上下文，实际是靠外推硬撑的，质量会随长度衰减。 怎么分辨这两种？这是第 2 篇会讲的。
刀四：MTP——一个 token 一个 token 蹦太慢，改成”一次确认 5.47 个”
前面三刀砍的都是”读”这一侧的成本——注意力、Cache、参数量。这一刀换了个方向，砍”写”这一侧：生成速度。
大模型生成是自回归的——每蹦一个 token，都要把整个 78 层跑一遍。1M 上下文下，跑一遍是极慢的。
GLM-5.2 用 MTP(Multi-Token Prediction，投机解码) 解决。配置里：
num_nextn_predict_layers: 1这个额外的预测层(通常编号为 layer 78)不是 transformer 主体(主体是 0–77 层)，而是一个额外的预测头。机制简化讲：
- MTP 头先快速”蒙”出接下来的几个 token(草稿)
- 主模型一次性并行验证这批草稿——不是判对错，而是”主模型愿不愿意认领”
- 蒙对的一起通过，蒙错的地方之后全丢，从那里重新生成
博客公布的消融表里，MTP 方案由四项叠加而成(博客原文把前两项写作 “IndexShare + KV Share”，即索引器跨步复用 + KV Cache 跨步复用):
| 改进项 | 接受长度 | 累计提升 |
|---|---|---|
| 基线 | 4.56 | — |
| + IndexShare + KV Share | 5.10 | +11.8% |
| + 拒绝采样 | 5.29 | +16.0% |
| + 端到端 TV loss | 5.47 | +20.0% |
注意：+20% 是四项叠加的总账，不是 TV loss 单项的贡献(它这一步只约占 +3.4%)。接受长度从 4.56 涨到 5.47，意味着主模型每跑一遍平均能确认 5.47 个 token——生成速度直接快了一截。
刀五：MoE——753B 参数，只激活 3.5%
前面四刀都围着”长上下文”本身做文章，这刀砍的是更靠前的一个前提：模型本身太大。GLM-5.2 按权重清单累加是约 753B 参数(1.51TB 权重)(这两个数是笔者根据 model.safetensors.index.json 的张量累加得到，官方博客未直接公布)——全激活的话，推理根本不可承受，更别提 1M 上下文了。
GLM-5.2 的解法是混合专家(MoE):256 个路由专家里，每个 token 只路由到 8 个，再加 1 个始终激活的共享专家。
n_routed_experts: 256
num_experts_per_tok: 8
n_shared_experts: 1算下来，每个 token 实际只激活 9 个专家(8 路由 + 1 共享)，占 257 个专家池的约 3.5%。换个口径：路由激活是 8/256=3.125%，再加 1 个始终激活的共享专家，总激活比例约 3.5%。FFN 层的算力开销约为全激活时的二十几分之一，但知识容量还是完整的 753B——花小模型的钱，拿大模型的脑子。
MoE 严格说不是”长上下文”专属的创新，但它是五刀里的”地基前提”——没有它，753B 的体量本身就跑不动，1M 上下文更是无从谈起。所以它和其余四刀一样，是 1M 能跑起来的不可或缺一环。第 6 篇会单独深讲。
为什么这五刀缺一不可？
这五刀是相互绑定的，任意三件都不够：
- 只有 DSA 不行——注意力算得动了，但 KV Cache 还会爆显存
- 只有 IndexShare 不行——它是给 DSA 打补丁的，DSA 本身没解决 N² 就谈不上共享索引
- 只有 MLA 不行——Cache 压下来了，但 N² 注意力还是算不动
- 只有 MoE 不行——参数省了，但注意力爆炸和 Cache 爆显存都不归它管
- 只有 MTP 不行——它只加速生成，不解决”读 1M 输入”这件事
这就是为什么别的开源模型卡在 128K/256K——它们可能只做了其中一两件，撞上了剩下的墙。五刀一起上，1M 才从”理论可行”变成”工程上跑得动”。
这套架构，和同行比处在什么位置？
拆完之后，我把 GLM-5.2 放回行业版图里。下表列的是各家”怎么把上下文拉到 1M”的核心机制(MTP 是写侧加速、MoE 是模型规模前提，性质不同，单独放在表外说明):
| 模型 | 上下文 | 1M 靠什么(读侧) | 独特之处 |
|---|---|---|---|
| GLM-5.2 | 1M | DSA(单步 indexer)+ IndexShare + MLA | 每 4 层共享 indexer,1M 下每 token FLOPs 降 2.9× |
| DeepSeek-V4-Pro | 宣称 1M | CSA + HCA 混合稀疏 + MoE | V4 新方案（非早期 NSA），细节据其公开资料 |
| Qwen3.7-Max | 宣称 1M | 混合线性注意力 + MoE | 细节未公开 |
| Gemini 3.1 Pro | 1M(Pro)/ 2M(Ultra) | 机制未公开 | 依赖 TPU 集群，部署门槛通常较高 |
| Llama 3 | 128K | 分阶段扩展训练(θ=500K)+ GQA | 训练拉长到 128K，作路线对比保留 |
(GLM-5.2 完整的五刀里还有 MTP 加速生成、MoE 控规模，这两刀属于”能不能跑”的通用前提，各家基本都有等价设计，所以表里只对比”读侧注意力/Cache”这条最能体现差异的主线。)
有意思的是：开源已经集体冲进了 1M 时代(GLM、DeepSeek、Qwen 都是)，所以”GLM 是否首创”不是重点。真正的差异在”怎么做到 1M”的工程路径：
- GLM-5.2 走”单步 indexer”路径——粗筛 top-2048 个，只算这些；再加 IndexShare(每 4 层共享索引器)砍掉 3/4 的粗筛成本。博客原文说 “the indexer is placed at the first of 4 layers and topk indices are used for 4 layers”。这个 IndexShare 在主流 1M 方案的公开材料里未见相同的层间共享设计。
- DeepSeek 走 CSA + HCA 混合路径——一层压缩+稀疏选远距离(CSA)，一层重度压缩+稠密抓全局(HCA)，多层分工(据 DeepSeek V4 公开资料，已从早期 NSA 演进)。
两条路径都达到了 1M。GLM 官方公布自己的 1M 下每 token FLOPs 降低 2.9×(博客数据)。所以 1M 阵营里的差异，已经不在”能不能到 1M”，而在”到 1M 之后各自怎么省算力”——GLM-5.2 押的就是 IndexShare 这条路径。
至于 Gemini,Google 没公开 3.1 Pro 的注意力细节，但它依赖大规模 TPU 集群、部署门槛极高这一点是确定的。开源这边则只能靠算法创新换 1M——这也是为什么这份权重清单值得拆。
写在最后：为什么你该花时间搞懂这些？
回到开头那个问题——AI 为什么会”忘事”?
读完这篇你应该有感觉了：AI 的”记忆”是工程，不是魔法。它记得住什么、记不住什么，背后是注意力机制在挑哪些 token 相关，是 KV Cache 还剩多少显存，是模型训练时见没见过这么长的距离——全是有迹可循的机制，不是黑盒。
而搞懂原理，回报是实打实的：
- 你会知道为什么把一整份 50 页文档丢给 AI，它可能只关注了开头几页——因为传统注意力的 N² 让它”顾不过来”，而 DSA 这种稀疏机制改变了它的注意力分布。这直接影响你怎么组织输入。
- 你会知道为什么不同模型在长任务上表现差那么多——同样是 128K，有的模型是真”记得住”，有的只是零样本外推硬撑出来的”显得支持”。这决定你怎么选型。
- 你会知道什么时候”请记住前面的约定”有用、什么时候纯属浪费 token——如果信息已经掉出有效注意力范围，再多提醒也白搭。
说到底，搞懂这些原理的回报很实在：让你从一个被动的 AI 用户，变成一个知道背后在发生什么、能主动优化自己用法的人。
如果你想把这套”底层直觉”补齐，我准备写一个 8 篇连载，从地基讲到封顶。每篇的读者收益是这样的：
| 篇 | 主题 | 读完你能 |
|---|---|---|
| 1 | 没有长上下文，我们到底卡在哪？ | 说清 AI”忘事”的几个根本原因 |
| 2 | 业界怎么解决？四条技术路线全景 | 看懂不同模型的选型差异，不再被跑分忽悠 |
| 3 | 预备知识：注意力到底在算什么？ | 建立”注意力=N² 对照”的底层直觉 |
| 4 | KV Cache 太大怎么办——MLA | 理解为什么 AI 能记住这么多，以及显存是怎么省的 |
| 5 | 注意力 N² 太贵怎么办——DSA + IndexShare | 看懂长文档处理背后的核心机制(最关键的一篇) |
| 6 | 千亿参数怎么跑得动——MoE | 理解大模型的”便宜推理”是怎么实现的 |
| 7 | 一个字一个字蹦太慢——MTP | 看懂 AI 生成速度背后的工程 |
| 8 | 四管齐下：1M 怎么变可能 | 把前 7 篇串成完整图景 |
第 5 篇(DSA + IndexShare)是核心——它直接对应”AI 处理长文档时到底在看哪里”，读完你对”怎么给 AI 喂长输入”会有完全不同的理解。
不想被 AI 的”记忆”玄学牵着鼻子走的话，跟着这个系列走。
本文架构配置字段(index_topk、kv_lora_rank、num_nextn_predict_layers、专家数等)均来自 GLM-5.2 公开的 config.json；IndexShare 2.9×、MTP 消融表(4.56→5.47)、FrontierSWE 74.4、SWE-bench Pro 62.1、Terminal-Bench 81.0 等数据来自官方博客及基准表。文中标注”笔者按维度估算/张量累加”的数字(KV Cache ~5TB/~88GB/57 倍、753B 参数、1.51TB 权重、59585 张量数)非官方公布，为笔者据 model.safetensors.index.json 推算。DeepSeek-V4 用 CSA + HCA 混合稀疏(据其 HuggingFace 模型卡与 vLLM 博客，NSA 为 2025 年早期论文、V4 已演进)、Llama 3.1 用分阶段扩展训练(非 YaRN 外推，据 Meta 官方)，各家上下文口径以各自公开资料为准。无任何闭源信息。
感谢 GLM 团队把权重开源——闭源模型再强，我们只能用；开源模型，我们才看得懂它为什么强。这是写这篇解读的前提。