【arXiv】Conditional Memory via Scalable Lookup: A New Axis of Sparsity for Large Language Models

大模型读到一个熟悉的多 token 名称时，仍要在内部把这些 token 组合成实体表示。Engram 提出的改变是：让模型根据短 token 序列，直接查到训练时学好的向量，再结合上下文决定怎样使用它。这样，一部分熟悉模式的重建可以交给记忆表，后续 Transformer 层继续处理上下文和推理。

这首先是一项模型架构设计。Engram 仍然逐 token 自回归生成；lookup 返回的是隐藏向量，不会直接吐出一段答案。论文的主要能力证据是在相同总参数量和计算预算下优于 MoE 基线，而不是给现有模型打开一个加速开关。本文先解释它怎样接进模型，再看实验支持了什么，以及工程代价在哪里。

论文与本文范围

论文原题为 Conditional Memory via Scalable Lookup: A New Axis of Sparsity for Large Language Models，作者包括 Xin Cheng、Rui Tian、Wangding Zeng、Damai Dai 等，机构为北京大学与 DeepSeek-AI。论文来源为 arXiv 预印本，本文依据 arXiv:2601.07372v2：首版发表于 2026 年 1 月 12 日，v2 修订于 2026 年 7 月 12 日。

代码参考 deepseek-ai/Engram，固定提交为 fb7f84a。配图引用该提交的官方原图，部分图号沿用早期版本；正文的节号和表格数据以 v2 为准。本文没有重训论文模型，也没有复测吞吐；下面的实验数字均为论文报告。

先看一次生成：查表后，大模型还要做什么

官方架构图用这句话举例：

Only Alexander the Great could tame the horse Bucephalus.

在图示的 token 切分下，模型处理到 Great 时，Engram 取以当前位置结束的局部片段，例如 the Great 和 Alexander the Great，查出相关向量。这里取到的是已经读入的 token，包括当前位置，没有读取尚未生成的下一个 token。真实切分取决于 tokenizer，n-gram 也不一定对应完整单词。

图来自官方仓库。左侧是它在 Transformer block 中的位置，右侧展开查表与融合；标准输入 embedding 和输出 LM Head 保留。点击图片可查看原图。

对一次预测，可以把数据流简化为：

flowchart TD
  A[当前已知 token 序列] --> B[压缩 ID 与短 n-gram 哈希]
  B --> C[取出训练好的记忆向量]
  C --> D[与当前隐藏状态门控融合]
  D --> E[后续 Attention 与 MoE]
  E --> F[LM Head 预测下一个 token]

图省略了前序 Transformer 层、多个记忆注入层和短卷积，只保留查表如何参与预测。下一 token 生成后加入序列，再进行下一步计算；Engram 没有跳过这个循环。论文 §2

可以用“可学习的短语索引表”来建立直觉，但表里没有一行写着“Alexander the Great 的完整介绍”。它保存的是数字向量，只有配套的投影、门控和模型主干才能把这些表示用到预测中。模型原来的权重也仍然承载知识，不能把所有事实都理解成搬进了这张表。

核心设计：固定寻址，学习表示，按上下文使用

n-gram 为什么要压缩和哈希

n-gram 指连续的 n 个 token。若为所有可能的二元、三元组合分别建表，组合空间会迅速膨胀。Engram 先把部分规范化后等价的 token ID 映射到共同 ID，再通过固定哈希函数映射到有限表槽。

这里的 tokenizer compression 是记忆分支的 ID 归一化，没有把主干输入重新编码成更短的序列。论文采用 NFKC、转小写等规范化；官方 demo 还展示了去重音和空白处理。其目的在于减少重复占用记忆容量，主干仍保留原始 token 信息。论文 §2.2、CompressedTokenizer 源码

对位置 $t$，记忆分支构造后缀片段 $g_{t,n}$，用多个哈希头查不同的 embedding 表，然后拼接结果：

不同片段可能落到同一个槽，这就是哈希碰撞。多头设计使某一个头的碰撞不至于完全混淆整个表示，但不能消除碰撞。它也不是用 query embedding 在全库做语义近邻搜索：地址由局部 token ID 确定。论文 §2.2，式 1–2

论文所谓 $O(1)$ lookup，是指固定 n-gram 阶数和头数时，单位置查表次数不随表容量增长。它不意味着访存延迟为零，也不意味着整个 Transformer 的复杂度变成常数。

门控让同一条记忆适应不同上下文

同一局部片段可能出现在不同语境里，查表向量本身又是静态的。Engram 因此把前序层的隐藏状态 $h_t$ 当作 query，将记忆投影成 key 和 value，计算门值后再融合：

地址取决于 token，使用强度取决于上下文。这也是“条件记忆”的两层含义。门控不是事实正确性检查，它只是训练得到的融合函数；不合适的记忆是否真的被抑制，要由模型行为和评测来判断。论文 §2.3

随后，模块用短的 depthwise causal convolution 补充局部处理，并通过残差连接把结果加入隐藏状态，再执行 Attention 和 MoE。论文主干使用 mHC 多分支连接，各分支共享查表向量和 value 投影，使用各自的 key 投影来门控；上面的公式只展示共同逻辑。论文 §2.3–2.4

图来自官方仓库，正文对应 v2 §6.5。红色越深，表示所展示分支的门值越大；高亮落在片段末尾，是因为 lookup 使用以该 token 结束的后缀 n-gram。作者从多个门控中挑选了与语义模式匹配最相关的值来展示，因此这是定性例子，不能解释成所有分支都具备同样清晰的语义分工，更不能把红色当作模型的“确信程度”。

“训练一个 lookup”究竟训练了什么

更准确的说法是：用固定哈希寻址，联合训练记忆表里的 embedding、融合参数和模型主干。训练时，被访问的表行参与前向计算，损失通过反向传播更新这些行以及投影、门控等参数；寻址规则本身不是通过语言模型损失学出来的路由器。论文 §2.2、§2.5、§4.1

因此，推理期间它通常是静态模型参数，而非可以直接增删条目的外部知识库。想获得有效的 Engram，需要匹配的架构、tokenizer 映射、哈希配置和训练权重；给普通 checkpoint 插入随机表，并不能复用论文结论。

与 MoE 配合：把稀疏容量分给计算和记忆

MoE（Mixture-of-Experts，混合专家）通过隐藏状态路由，每个 token 只执行部分专家网络。Engram 根据 token 片段取少量向量。它们都允许总参数量大于每步实际使用的参数量，但被选择的参数承担不同工作。

前两项是论文比较的稀疏模型组件；后两项用于区分常见的“记忆”概念。Engram 可以与这些机制共同使用，但它们不能互相替代。

论文真正检验的问题是：固定总参数量和训练计算后，是否值得把一部分专家容量换成记忆容量？作者定义 $\rho$ 为稀疏参数预算中分给 MoE 的比例，$\rho=1$ 对应全部交给 MoE；其余部分分给 Engram。论文 §3.1

图来自官方仓库。左图固定总容量，右图允许增加总容量，不能混成同一个对照。左图在两档计算预算下呈 U 形：将约 20%–25% 的稀疏参数预算分给 Engram，比全部分给 MoE 更好；记忆比例继续升高，又会损失计算容量。右图则显示，在论文测试范围内，固定主干并扩充记忆槽可以进一步降低损失。论文 §3

这里的 20%–25% 是所测模型和训练条件下的结果，分母是论文定义的稀疏参数预算，不是整机内存，也不是一个可直接套用到所有模型的最佳比例。

实验收益：同预算更强，机制解释仍有边界

27B 对照不是单纯多加一张大表

论文的 MoE-27B 和 Engram-27B 都有 26.7B 总参数，训练 262B tokens，每 token 激活参数均为约 3.8B（不计 token embedding）。Engram-27B 把路由专家数从 72 降到 55，保留每 token 选择 6 个路由专家的设置，将腾出的容量分给 5.7B 参数的记忆模块。论文 §4.1、表 1

以下是表 1 的部分结果。准确率、EM（Exact Match，完全匹配率）和 Pass@1 均按百分制列出，增益为百分点；不同任务的指标不能直接横向比较。

数据来源：v2 表 1。有一处需要注意：摘要仍写 MMLU +3.4，但正文 §4.2 和表 1 给出 +3.0；+3.4 对应表中的 MMLU-Redux。本文采用正文和表格的数值。

这些结果支持“在这套训练配方下，用部分查表记忆替换专家容量可以提高能力”。它们不证明给一个已经训练好的普通模型额外接表，也能获得相同收益。

为什么局部查表还能改善长上下文

作者的解释是：如果局部依赖和熟悉模式可以从表中获取，Attention 与后续层就可能把更多容量用在全局关系上。这是一条值得检验的机制解释，不能仅凭 n-gram 表本身推出。

长上下文实验把模型扩展到 32,768 tokens，进行相同的 5,000 步扩展训练，并在 LongPPL 与 RULER 上评测。相同预训练步数的 50k checkpoint 对照中，Multi-Query NIAH 从 84.2 到 97.0，Variable Tracking 从 77.0 到 89.0。论文 §5、表 2

图来自官方仓库，点击可放大。还有一个更有参考价值的对照：Engram 的 46k checkpoint 与 MoE 的 50k checkpoint 具有相同的预训练验证损失，再执行同样的扩展训练；此时 Multi-Query NIAH 仍为 97.0 对 84.2，Variable Tracking 为 87.2 对 77.0。这减弱了“只是起点模型更强”的一种混淆，但对齐单一验证损失，不等于所有基础能力都完全一致。论文 §5.1–5.2

原表也显示边界：单针检索等任务并非每项都上涨。因此应按子任务报告收益，不能说 Engram 在所有长上下文任务上全面领先。

证据分别支持哪一层结论

论文提供了几种不同强度的证据，适合分开理解：论文 §6

LogitLens 用最终输出头观察中间层，CKA 用来比较表示相似性。作者把它们解释为“释放早期层，增加有效深度”；这些 probe 与该解释相符，但没有单独测出“释放了多少计算给推理”的中介贡献。关闭输出又会制造训练与推理不一致，不能把能力下降简单理解成对知识位置的精确划分。

系统代价：低计算量不等于免费记忆

Engram 的工程优势来自地址可提前计算。MoE 通常要等当前层隐藏状态到达路由器，才知道选择哪些专家；Engram 在本步 token ID 已知时，就能算出稍后注入层需要哪些表行。于是可以让表驻留主机内存，提前读取并搬运这些行，与前序 Transformer 层计算重叠。论文 §2.5

这只是把已知 token 对应的未来层访问提前，不是在预测尚未生成的 token。把模块放得较深，通常有更长的预取窗口；较早注入又可能更有利于模式重建，因此位置选择同时受模型质量和系统延迟约束。

论文用基于 nano-vLLM 的原型，在 NVIDIA H800 上测试两种 dense 主干，各接入一张 100B 参数、完全驻留 host DRAM 的表。工作负载为 512 条序列，长度按 Uniform(100, 1024) 设置；以下是端到端吞吐，不是单请求 Decode tokens/s。论文 §6.4、表 4

下降比例由表 4 数值计算。这个实验说明，在所测硬件和负载下，大表访存的额外吞吐代价可以被较好地隐藏；结果本身仍是吞吐略降，不能改写成“Engram 加速了生成”。它也不是 Engram-27B 与 MoE-27B 的生产服务测速。

表容量越大，仍要付出存储、训练分片、随机访存与传输成本。每步取少量行，只减少本步需要读取的数据，没有让整张表的保存成本消失。论文还讨论了按访问频率分层缓存的方向，但不能将其理解为已经证明 SSD 上的超大表也具有同样吞吐。

对手机或 MNN 部署，我的判断是先评估经训练的小型变体：除了端到端质量，还要测表的实际字节数、冷/热访问、首 token 延迟、Decode 速度和功耗。本文没有端侧实测，论文的 H800 结果也不能替代这些测量。关于“参数按需使用仍可能受 I/O 限制”，可继续看 端侧 MoE 专家流式推理。

怎样动手理解，以及怎样才算真的用上

官方仓库提供的 engram_demo_v1.py 适合阅读数据流。以下命令依据官方 README 整理，本次未执行 demo，也没有验证生产模型推理：

git clone https://github.com/deepseek-ai/Engram.git
cd Engram
git checkout fb7f84a21f91223715394a33a1dc24bbfb7f788e
python -m venv .venv
source .venv/bin/activate
pip install torch numpy transformers sympy
python engram_demo_v1.py

脚本会下载 DeepSeek-V3 的 tokenizer，随机初始化相关权重，完成一次前向并打印张量形状。其 Attention、MoE 和复杂连接被省略或模拟，没有提供训练好的聊天模型，也没有完整文本生成循环。默认记忆表仍可能占用数 GB 内存；内存有限时，应先检查并缩小 EngramConfig.engram_vocab_size。官方 README 与源码

读代码可以沿这条路径：CompressedTokenizer → NgramHashMapping → MultiHeadEmbedding → Engram.forward → TransformerBlock。前半段回答怎样找地址、取向量，后半段回答怎样用隐藏状态门控并残差接回模型。demo 的配置也不能当作论文模型配置：例如 demo 使用 layer_ids=[1,15]，论文 Engram-27B 报告的是 [2,15]。源码、论文附录 A

如果目标是实际使用，需要确认 checkpoint 原本包含 Engram，并由运行时实现一致的 tokenizer 压缩、哈希、查表、门控、卷积和增量状态管理。运行这个 demo，只能说明数据流可以跑通，不能说明现有普通模型已经获得 Engram 的能力。

这篇论文值得关注的地方，是把“按输入模式取用可学习表示”作为一种可扩展的模型组件。它为同一预算下的计算与记忆分工提供了实验依据；最终是否更适合某个任务或硬件，则要把质量、存储和实际延迟一起比较。

参考资料

• 论文 v2 摘要与版本记录
• 论文 v2 全文 HTML 与 PDF
• DeepSeek Engram 官方仓库，固定提交 fb7f84a
• 官方数据流 demo

图片版权归原作者，均链接至上述官方仓库的原图，未改动；仓库提供 Apache-2.0 许可证。