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;">对于问题「北京是中国的首都」,需要推理吗?
应该是不需要,地球人都知道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-feature-settings: normal;font-variation-settings: normal;font-size: 14.4px;text-align: left;line-height: 1.75;color: rgb(17, 114, 221);background: rgb(241, 241, 241);padding: 3px 5px;border-radius: 4px;opacity: 0.9;">Conditional Memory via Scalable Lookup:A New Axis of Sparsity for Large Language ModelsingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 15px;color: rgb(63, 63, 63);">
ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size:15px;margin:0.1em auto 0.5em;border-radius:8px;box-shadow:rgba(0, 0, 0, 0.1) 0px 4px 8px;width:100%;"/>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;">这篇论文中,做了一个新方法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;">Engram,并给到观点:
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」这个实体时,内部发生了什么:
| |
| |
| |
| |
| 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,效果最好
这个比例在不同的计算预算下都稳定,有一定的普适性
效果数据
四个模型对比:
- • Engram-27B:把 MoE-27B 的 72 个路由专家减到 55 个,省出的参数给 5.7B 的 Engram
- • Engram-40B:进一步扩大 Engram 到 18.5B
全部训练 262B tokens,激活参数都是 3.8B(等算力)

挑几个关键数据:
知识类任务提升在预期内,毕竟加了个「记忆」模块
但推理类任务提升更大,这就有意思了
一个「记忆」模块,怎么让「推理」能力变强?
为什么推理也变强了
这是论文最有价值的部分
他们用了两个分析工具
LogitLens:看每一层输出的预测置信度
结果:Engram 模型在早期层就达到了高置信度,预测收敛速度明显更快
CKA:看不同层之间的表示相似度
结果:Engram 模型第 5 层的表示,和 MoE 模型第 12 层的表示最相似
这说明什么?
Engram 等效于增加了网络的有效深度
逻辑是这样的:有了 Engram 分担静态知识的检索,早期层不用再花深度做这件事。省出来的深度,可以用于更复杂的推理
Attention 的容量也被释放了。本来要处理局部依赖(比如识别「张仲景」是一个人名)的注意力头,现在可以专注于全局上下文
长上下文任务上这个效果更明显:

Engram 到底存了什么
做了个消融实验:把 Engram 的输出完全屏蔽,看各类任务的性能保留多少
结论很清晰:
事实知识主要存在 Engram 里,屏蔽后崩得厉害
阅读理解依赖上下文,答案就在文章里,Engram 帮不上忙
推理任务的提升是间接的,来自 Engram 释放的网络深度,而不是 Engram 直接提供推理能力
门控可视化

红色表示门控激活(采纳了查表结果),颜色越深激活越强
规律很明显:
- • 多 token 实体触发高激活:「Alexander the Great」「Milky Way」「Princess of Wales」
- • 中文也能识别:「四大发明」「张仲景」「医圣」「伤寒杂病论」
需要结合上下文理解的 token,门控会压低
工程:offload 效率
这部分对开发者有参考价值
Engram 的查表索引是确定的。知道输入是什么 token,就知道要查哪些行,不依赖中间计算结果
MoE 不一样,路由决策要等隐藏状态算出来才能做
这个区别让 Engram 可以做预取:模型在计算前几层的时候,同时从主机内存异步加载 Engram 需要的数据,两边并行
实测结果:
100B 参数的 Engram 表完全放主机内存,吞吐量下降不到 3%
N-gram 的访问还符合 Zipf 分布,少数高频模式占了绝大多数访问量。可以做多级缓存:热门的放 GPU 显存,长尾的放主机内存甚至 SSD
组件消融
哪些设计贡献最大:
- • 4-gram:在当前参数预算下不如 2-gram + 3-gram 组合
Engram 放在第 2 层效果最好,越往深层放效果越差
跑起来
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