DeepSeek 凌晨开源 ：给 Transformer 加个「查字典」的能力

DeepSeek 凌晨开源 ：给 Transformer 加个「查字典」的能力 DeepSeek 凌晨开源 ：给 Transformer 加个「查字典」的能力 Modified January 13 这个比例在不同的计算预算下都稳定，有一定的普适性 效果数据 四个模型对比： • Dense 4B：稠密模型，基线 • MoE 27B：纯 MoE 架构 • Engram 27B：把 MoE 27B 的 72 个路由专家减到 55 个，省出的参数给 5.7B 的 Engram • Engram 40B：进一步扩大 Engram 到 18.5B 全部训练 262B tokens，激活参数都是 3.8B（等算力） 挑几个关键数据： 任务类型 具体任务 MoE 27B Engram 27B 提升 知识 MMLU 57.4 60.4 +3.0 知识 CMMLU（中文） 57.9 61.9 +4.0 推理 BBH 50.9 55.9 +5.0 推理 ARC Challenge 70.1 73.8 +3.7 代码 HumanEval 37.8 40.8 +3.0 数学 MATH 28.3 30.7 +2.4 知识类任务提升在预期内，毕竟加了个「记忆」模块 但推理类任务提升更大，这就有意思了 一个「记忆」模块，怎么让「推理」能力变强？ 为什么推理也变强了 这是论文最有价值的部分 他们用了两个分析工具 LogitLens ：看每一层输出的预测置信度 结果：Engram 模型在早期层就达到了高置信度，预测收敛速度明显更快 CKA ：看不同层之间的表示相似度 结果：Engram 模型第 5 层的表示，和 MoE 模型第 12 层的表示最相似 这说明什么？ Engram 等效于增加了网络的有效深度 逻辑是这样的：有了 Engram 分担静态知识的检索，早期层不用再花深度做这件事。省出来的深度，可以用于更复杂的推理 Attention 的容量也被释放了。本来要处理局部依赖（比如识别「张仲景」是一个人名）的注意力头，现在可以专注于全局上下文 长上下文任务上这个效果更明显： 任务 MoE 27B Engram 27B Multi Query NIAH 84.2 97.0 Variable Tracking 77.0 89.0 Engram 到底存了什么 做了个消融实验：把 Engram 的输出完全屏蔽，看各类任务的性能保留多少 • 事实问答（TriviaQA）：只剩 29% • 阅读理解（C3）：保留 93% • 推理任务：居中 结论很清晰： 事实知识主要存在 Engram 里，屏蔽后崩得厉害 阅读理解依赖上下文，答案就在文章里，Engram 帮不上忙 推理任务的提升是间接的，来自 Engram 释放的网络深度，而不是 Engram 直接提供推理能力 门控可视化 红色表示门控激活（采纳了查表结果），颜色越深激活越强 规律很明显： • 多 token 实体触发高激活：「Alexander the Great」「Milky Way」「Princess of Wales」 • 固定搭配触发高激活：「By the way」 • 中文也能识别：「四大发明」「张仲景」「医圣」「伤寒杂病论」 需要结合上下文理解的 token，门控会压低 工程：offload 效率 这部分对开发者有参考价值 Engram 的查表索引是确定的。知道输入是什么 token，就知道要查哪些行，不依赖中间计算结果 MoE 不一样，路由决策要等隐藏状态算出来才能做 这个区别让 Engram 可以做预取：模型在计算前几层的时候，同时从主机内存异步加载 Engram 需要的数据，两边并行 实测结果： 配置 吞吐量 Dense 4B 9,031 tok/s Dense 4B + 100B Engram（CPU offload） 8,858 tok/s Dense 8B 6,315 tok/s Dense 8B + 100B Engram（CPU offload） 6,140 tok/s 100B 参数的 Engram 表完全放主机内存，吞吐量下降不到 3% N gram 的访问还符合 Zipf 分布，少数高频模式占了绝大多数访问量。可以做多级缓存：热门的放 GPU 显存，长尾的放主机内存甚至 SSD 组件消融 哪些设计贡献最大： • 多分支集成：重要 • 上下文门控：重要 • Tokenizer 压缩：重要 • 轻量卷积：影响不大 • 4 gram：在当前参数预算下不如 2 gram + 3 gram 组合 Engram 放在第 2 层效果最好，越往深层放效果越差 跑起来 Code block Plain Text pip install torch numpy transformers sympy python engram demo v1.py GitHub 上的 demo 是演示版，mock 了 Attention/MoE 等标准组件，用于展示 Engram 的数据流 总结一下： MoE 管算，Engram 管查，两种机制处理两类任务 代码： https://github.com/deepseek ai/Engram 论文： https://raw.githubusercontent.com/deepseek ai/Engram/refs/heads/main/Engram paper.pdf 这个比例在不同的计算预算下都稳定，有一定的普适性 效果数据 四个模型对比： • Dense 4B：稠密模型，基线 • MoE 27B：纯 MoE 架构 • Engram 27B：把 MoE 27B 的 72 个路由专家减到 55 个，省出的参数给 5.7B 的 Engram • Engram 40B：进一步扩大 Engram 到 18.5B 全部训练 262B tokens，激活参数都是 3.8B（等算力） 挑几个关键数据： 任务类型 具体任务 MoE 27B Engram 27B 提升 知识 MMLU 57.4 60.4 +3.0 知识 CMMLU（中文） 57.9 61.9 +4.0 推理 BBH 50.9 55.9 +5.0 推理 ARC Challenge 70.1 73.8 +3.7 代码 HumanEval 37.8 40.8 +3.0 数学 MATH 28.3 30.7 +2.4 任务类型 任务类型 具体任务 具体任务 MoE 27B MoE 27B Engram 27B Engram 27B 提升 提升 知识 知识 MMLU MMLU 57.4 57.4 60.4 60.4 +3.0 +3.0 知识 知识 CMMLU（中文） CMMLU（中文） 57.9 57.9 61.9 61.9 +4.0 +4.0 推理 推理 BBH BBH 50.9 50.9 55.9 55.9 +5.0 +5.0 推理 推理 ARC Challenge ARC Challenge 70.1 70.1 73.8 73.8 +3.7 +3.7 代码 代码 HumanEval HumanEval 37.8 37.8 40.8 40.8 +3.0 +3.0 数学 数学 MATH MATH 28.3 28.3 30.7 30.7 +2.4 +2.4 知识类任务提升在预期内，毕竟加了个「记忆」模块 但推理类任务提升更大，这就有意思了 一个「记忆」模块，怎么让「推理」能力变强？ 为什么推理也变强了 这是论文最有价值的部分 他们用了两个分析工具 LogitLens ：看每一层输出的预测置信度 结果：Engram 模型在早期层就达到了高置信度，预测收敛速度明显更快 CKA ：看不同层之间的表示相似度 结果：Engram 模型第 5 层的表示，和 MoE 模型第 12 层的表示最相似 这说明什么？ Engram 等效于增加了网络的有效深度 逻辑是这样的：有了 Engram 分担静态知识的检索，早期层不用再花深度做这件事。省出来的深度，可以用于更复杂的推理 Attention 的容量也被释放了。本来要处理局部依赖（比如识别「张仲景」是一个人名）的注意力头，现在可以专注于全局上下文 长上下文任务上这个效果更明显： 任务 MoE 27B Engram 27B Multi Query NIAH 84.2 97.0 Variable Tracking 77.0 89.0 任务 任务 MoE 27B MoE 27B Engram 27B Engram 27B Multi Query NIAH Multi Query NIAH 84.2 84.2 97.0 97.0 Variable Tracking Variable Tracking 77.0 77.0 89.0 89.0 Engram 到底存了什么 做了个消融实验：把 Engram 的输出完全屏蔽，看各类任务的性能保留多少 • 事实问答（TriviaQA）：只剩 29% • 阅读理解（C3）：保留 93% • 推理任务：居中 结论很清晰： 事实知识主要存在 Engram 里，屏蔽后崩得厉害 阅读理解依赖上下文，答案就在文章里，Engram 帮不上忙 推理任务的提升是间接的，来自 Engram 释放的网络深度，而不是 Engram 直接提供推理能力 门控可视化 红色表示门控激活（采纳了查表结果），颜色越深激活越强 规律很明显： • 多 token 实体触发高激活：「Alexander the Great」「Milky Way」「Princess of Wales」 • 固定搭配触发高激活：「By the way」 • 中文也能识别：「四大发明」「张仲景」「医圣」「伤寒杂病论」 需要结合上下文理解的 token，门控会压低 工程：offload 效率 这部分对开发者有参考价值 Engram 的查表索引是确定的。知道输入是什么 token，就知道要查哪些行，不依赖中间计算结果 MoE 不一样，路由决策要等隐藏状态算出来才能做 这个区别让 Engram 可以做预取：模型在计算前几层的时候，同时从主机内存异步加载 Engram 需要的数据，两边并行 实测结果： 配置 吞吐量 Dense 4B 9,031 tok/s Dense 4B + 100B Engram（CPU offload） 8,858 tok/s Dense 8B 6,315 tok/s Dense 8B + 100B Engram（CPU offload） 6,140 tok/s 配置 配置 吞吐量 吞吐量 Dense 4B Dense 4B 9,031 tok/s 9,031 tok/s Dense 4B + 100B Engram（CPU offload） Dense 4B + 100B Engram（CPU offload） 8,858 tok/s 8,858 tok/s Dense 8B Dense 8B 6,315 tok/s 6,315 tok/s Dense 8B + 100B Engram（CPU offload） Dense 8B + 100B Engram（CPU offload） 6,140 tok/s 6,140 tok/s 100B 参数的 Engram 表完全放主机内存，吞吐量下降不到 3% N gram 的访问还符合 Zipf 分布，少数高频模式占了绝大多数访问量。可以做多级缓存：热门的放 GPU 显存，长尾的放主机内存甚至 SSD 组件消融 哪些设计贡献最大： • 多分支集成：重要 • 上下文门控：重要 • Tokenizer 压缩：重要 • 轻量卷积：影响不大 • 4 gram：在当前参数预算下不如 2 gram + 3 gram 组合 Engram 放在第 2 层效果最好，越往深层放效果越差 跑起来 GitHub 上的 demo 是演示版，mock 了 Attention/MoE 等标准组件，用于展示 Engram 的数据流 总结一下： MoE 管算，Engram 管查，两种机制处理两类任务 代码： https://github.com/deepseek ai/Engram 论文： https://raw.githubusercontent.com/deepseek ai/Engram/refs/heads/main/Engram paper.pdf 🔗 原文链接： https://mp.weixin.qq.com/s/w4eeBiR ... https://mp.weixin.qq.com/s/w4eeBiR ... 原创 金色传说大聪明 赛博禅心2026年1月13日 01:30 广东 对于问题「北京是中国的首都」，需要推理吗？ 应该是不需要，地球人都知道 但现在，Transformer 只有一种处理方式：全靠算 DeepSeek 大半夜的，发布了一篇新论文 Conditional Memory via Scalable Lookup:A New Axis of Sparsity for Large Language Models https://github.com/deepseek ai/Engram 这篇论文中，做了一个新方法 Engram ，并给到观点： 该查表的查表，该算的算，两件事分开处理 对此，他们 Engram 的模块，专门负责「查」，和负责「算」的 MoE 配合使用 结果就是，Engram 27B 在等参数、等算力条件下，全面超越纯 MoE baseline 代码已开源： https://github.com/deepseek ai/Engram 一个具体的例子 论文里有个很直观的案例 模型处理「Diana, Princess of Wales」这个实体时，内部发生了什么： 层数 模型此时「认为」这是什么 第 1 2 层 Wales，一个国家 第 3 层 Wales，欧洲的一个国家 第 4 层 Princess of Wales，一个头衔 第 5 层 Princess of Wales，威尔士亲王的妻子 第 6 层 Diana, Princess of Wales，戴安娜王妃 层数 层数 模型此时「认为」这是什么 模型此时「认为」这是什么 第 1 2 层 第 1 2 层 Wales，一个国家 Wales，一个国家 第 3 层 第 3 层 Wales，欧洲的一个国家 Wales，欧洲的一个国家 第 4 层 第 4 层 Princess of Wales，一个头衔 Princess of Wales，一个头衔 第 5 层 第 5 层 Princess of Wales，威尔士亲王的妻子 Princess of Wales，威尔士亲王的妻子 第 6 层 第 6 层 Diana, Princess of Wales，戴安娜王妃 Diana, Princess of Wales，戴安娜王妃 六层网络，才把这个实体识别出来 但「戴安娜王妃」这个知识是固定的，不会因为上下文变化而变化。模型花六层来「算」出这个结果，本质上是在用计算重建一个静态的查找表 这六层深度，本可以用来处理更复杂的推理任务 Engram 怎么做 技术方案不复杂：用连续几个 token（N gram）作为「查询词」，从一个大表里查出对应的向量，融合到模型的中间状态里 几个关键设计： 词表压缩 标准分词器会给「Apple」和「apple」分配不同的 ID，但它们语义上是同一个东西。Engram 先做一层归并，把这类 token 映射到同一个规范化 ID 实测 128k 词表压缩了 23% 多头哈希 不可能真的存下所有 N gram 组合，那是天文数字。用哈希函数把 N gram 映射到有限大小的表里，牺牲一点精度换存储空间 上下文门控 查出来的向量是「静态先验」，可能和当前上下文不匹配。比如「苹果」在讨论水果时和讨论手机时含义不同 解决方案：用当前位置的隐藏状态（已经通过 Attention 聚合了上下文信息）作为「裁判」，给查出来的向量打分。语义不匹配时，把这个向量的权重压低 放在哪一层 Engram 不是每层都加。放太浅，隐藏状态还没积累足够上下文，「裁判」不准；放太深，错过了分担早期层负担的时机 实验发现：放在第 2 层效果最好。如果要放两个，第 2 层和第 15 层的组合最优 参数怎么分配 这里有个核心问题：给定固定的参数预算，多少给 MoE，多少给 Engram？ 论文定义了一个分配比例 ρ • ρ = 100%：全给 MoE，没有 Engram • ρ = 0%：全给 Engram，没有 MoE 的路由专家 实验扫了一遍，结果是 U 型曲线： 这两个极端，都不好 全给 MoE（ρ = 100%）：没有专门的记忆模块，模型被迫用计算来重建静态知识 全给 Engram（ρ → 0%）：失去了动态计算能力，复杂推理做不了 最优点在 75% 80% 也就是说，把 20 25% 的稀疏参数从 MoE 转给 Engram，效果最好