应该是不需要，地球人都知道ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;letter-spacing: 0.1em;color: rgb(63, 63, 63);word-break: break-all;opacity: 0.9;">但现在，Transformer 只有一种处理方式：全靠算ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;letter-spacing: 0.1em;color: rgb(63, 63, 63);word-break: break-all;opacity: 0.9;">DeepSeek 大半夜的，发布了一篇新论文
ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: inherit;color: rgb(198, 110, 73);margin: 24px 0px 8px;">该查表的查表，该算的算，两件事分开处理ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 16px;letter-spacing: 0.1em;color: rgb(63, 63, 63);word-break: break-all;opacity: 0.9;">对此，他们 Engram 的模块，专门负责「查」，和负责「算」的 MoE 配合使用
结果就是，Engram-27B 在等参数、等算力条件下，全面超越纯 MoE baseline
代码已开源：https://github.com/deepseek-ai/Engram
一个具体的例子
论文里有个很直观的案例
模型处理「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，效果最好
这个比例在不同的计算预算下都稳定，有一定的普适性
效果数据
四个模型对比：
• Dense-4B：稠密模型，基线 • MoE-27B：纯 MoE 架构 • Engram-27B：把 MoE-27B 的 72 个路由专家减到 55 个，省出的参数给 5.7B 的 Engram • Engram-40B：进一步扩大 Engram 到 18.5B
全部训练 262B tokens，激活参数都是 3.8B（等算力）
挑几个关键数据：
| +5.0 | ||||
| +3.7 | ||||
知识类任务提升在预期内，毕竟加了个「记忆」模块
但推理类任务提升更大，这就有意思了
一个「记忆」模块，怎么让「推理」能力变强？
为什么推理也变强了
这是论文最有价值的部分
他们用了两个分析工具
LogitLens：看每一层输出的预测置信度
结果：Engram 模型在早期层就达到了高置信度，预测收敛速度明显更快
CKA：看不同层之间的表示相似度
结果：Engram 模型第 5 层的表示，和 MoE 模型第 12 层的表示最相似
这说明什么？
Engram 等效于增加了网络的有效深度
逻辑是这样的：有了 Engram 分担静态知识的检索，早期层不用再花深度做这件事。省出来的深度，可以用于更复杂的推理
Attention 的容量也被释放了。本来要处理局部依赖（比如识别「张仲景」是一个人名）的注意力头，现在可以专注于全局上下文
长上下文任务上这个效果更明显：
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 需要的数据，两边并行
实测结果：
100B 参数的 Engram 表完全放主机内存，吞吐量下降不到 3%
N-gram 的访问还符合 Zipf 分布，少数高频模式占了绝大多数访问量。可以做多级缓存：热门的放 GPU 显存，长尾的放主机内存甚至 SSD
组件消融
哪些设计贡献最大：
• 多分支集成：重要 • 上下文门控：重要 • Tokenizer 压缩：重要 • 轻量卷积：影响不大 • 4-gram：在当前参数预算下不如 2-gram + 3-gram 组合
Engram 放在第 2 层效果最好，越往深层放效果越差
跑起来
pip install torch numpy transformers sympy
python engram_demo_v1.pyGitHub 上的 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