从“会算”到“会查”:读懂 DeepSeek 的 Engram
DeepSeek的工作DeepSeek 在 2026 年 1 月提出的 Engram针对的是一个很基础、但过去常被埋在模型细节里的问题现在的大语言模型已经很擅长 computation(计算)却没有一种原生的 knowledge lookup(知识查表) 能力。论文把这个问题直接写成一句话“Transformers lack a native primitive for knowledge lookup.”Transformer 缺少一种原生的知识查表原语。意思是很多本来更适合直接“取出来”的局部静态模式例如固定短语、常见实体名、重复出现的代码模板最后还是被迫交给网络一层一层重新算出来。为了解决这件事论文提出了 conditional memory(条件记忆) 这条新路线而 Engram 就是这种路线的具体实现。找到“二级结论”先看它为什么会成为问题。传统 Transformer(转换器架构) 的强项是用 attention(注意力机制) 和前馈层不断组合上下文逐步形成更抽象的表示这很适合处理动态推理但不等于它擅长处理“本来就很固定”的局部模式。假设模型读到一句话“Only Alexander the Great could tame the horse Bucephalus.”只有亚历山大大帝才能驯服那匹名叫布西法拉斯的马。对人来说“Alexander the Great”通常会被直接当作一个整体概念来识别但对标准 Transformer 来说它往往还是先把这几个 token(词元) 分别编码成 embedding(嵌入表示)再依靠多层 attention(注意力机制) 和前馈网络在当前上下文里逐步恢复出“这是一个固定历史人物名称”的整体含义。也就是说本来更像“整体调取”的工作被迫走了一遍“拆开编码—再重新拼合”的流程。论文的 mechanistic analysis(机制分析) 也明确指出模型早层确实承担了很多 static reconstruction(静态模式重建) 的工作。Engram 的切入点就是把这条链改掉。它不是让模型完全不算而是把“局部且稳定”的那一部分先交给查表。还是以上面的实体名为例当模型处理到当前位置时Engram 会先从当前位置前面的局部上下文里抽取 suffix n-gram(后缀 N 元片段)也就是取连续的几个 token 组成一个短模式然后把这个短模式压缩、规范化再通过 hashing(哈希映射) 去静态 memory table(记忆表) 里查出一个候选向量。这样一来模型就不必每次都靠主干网络从零重建“Alexander the Great”这种局部固定模式而是先得到一个可复用的候选表示再看当前上下文是否支持它。论文把整个过程拆成 retrieval(检索) 和 fusion(融合) 两步并说明 Engram 的作用就是“retrieving static N-gram memory and fusing it with dynamic hidden states”检索静态 N 元片段记忆并把它与动态隐藏状态融合。代码场景下这条逻辑会更明显。比如模型看到for i in range(len(x)):或try: ... except:时真正重要的往往不是单个 token而是这整段局部组合已经形成了一个高度稳定的语法模板。标准 Transformer 仍然要逐个 token 编码再依赖多层 attention 去恢复“这是循环头”“这是异常处理结构”这样的整体意义Engram 则把这类高频、局部、重复出现的模板当作适合直接调用的静态模式。它先把局部上下文映射为 suffix n-gram再通过 deterministic hashing(确定性哈希) 从嵌入表里取回候选记忆后续由当前上下文决定是否采纳。于是Engram 不是替代 reasoning(推理)而是先接走那些本来更像“查表”的工作把主干网络的计算预算留给真正需要跨句、跨段整合的复杂推理。注意力的节流Engram 的第一阶段本质上是在做“把局部短模式变成可查表的记忆线索”。它不会直接拿原始分词结果去拼 n-gram因为同一个意思可能会被分成不同的 token。比如Apple和带前导空格的apple在普通分词器里可能是不同 ID但它们的语义其实很接近。Engram 会先做 tokenizer compression(分词压缩) 和 vocabulary projection(词表投影)把这些表面不同但意义接近的 token 尽量压到更统一的表示上再从当前位置前面的局部上下文中抽出几个短模式用 multi-head hashing(多头哈希) 分别算出地址去嵌入表里直接取回对应的 embedding vector(嵌入向量)。取回来的不是具体文本而是模型内部可以直接参与后续计算的向量表示不同长度短模式取回的向量再被拼接起来形成最终的 memory vector(记忆向量)。但“取到了记忆”不等于“这段记忆现在就一定对”。因为这些向量是静态的只反映这个短模式通常意味着什么却不知道当前句子到底在表达什么所以它们可能因为 hash collision(哈希冲突) 带来错误信息也可能因为 polysemy(一词多义) 和当前语境不一致。为了解决这个问题Engram 在第二阶段加入了 context-aware gating(上下文感知门控)它用当前 hidden state(隐藏状态) 去判断取回来的记忆和当前上下文是否匹配。匹配的就放大它的作用不匹配的就把它压低甚至接近不用。也就是说Engram 不是“查到什么就直接塞回模型”而是“先查再由当前上下文决定该用多少”。这也解释了为什么 Engram 不是“死记硬背”。还是以“apple”为例如果一句话是 “Apple released a new phone.”Apple 发布了新手机。那么静态记忆里可能同时存在与水果和公司相关的局部模式真正决定该选哪一边的不是记忆表本身而是当前 hidden state(隐藏状态) 已经聚合起来的上下文信息。因为句子里有 “released” 和 “phone” 这样的线索context-aware gating(上下文感知门控) 就更可能放大“Apple 公司”相关的记忆压低“水果”相关的噪声。换句话说Engram 的完整链条不是“看见局部模式就直接套用记忆”而是“先查到候选记忆再由当前上下文做筛选和调制”。理解了这条链之后就更容易明白一个看似反直觉的实验结果为什么一个 memory module(记忆模块) 不只提升知识题反而对 reasoning(推理)、code(代码)、math(数学) 也帮助很大。论文在 iso-parameter and iso-FLOPs(等参数量、等计算量) 的对照下报告Engram-27B 相比 MoE 基线在 MMLU 上提升 3.4 分、CMMLU 提升 4.0 分而在 BBH、ARC-Challenge、HumanEval、MATH 等推理、代码和数学任务上也出现了明显收益。论文给出的解释不是“它背了更多知识”而是它减轻了主干早层的 static reconstruction(静态模式重建) 负担因此“effectively deepening the network for complex reasoning”在功能上让网络对复杂推理显得更深。这里的意思不是物理层数增加了而是说原来前几层要分出很多能力去重建局部静态模式现在这部分工作被条件记忆接走主干层就能更早把容量投入真正复杂的抽象与推理。同样的分工变化也解释了它在长上下文上的提升。论文写得很直接by delegating local dependencies to lookups, Engram frees up attention capacity to focus on global context把局部依赖交给查表后Engram 释放了注意力容量使其更专注于全局上下文。这句话背后的逻辑是attention(注意力机制) 的能力本来就有限如果它既要重复处理很多固定局部模式又要负责远距离信息整合那么全局建模会被局部负担挤压。Engram 接走一部分局部依赖后attention 就能把更多精力花在长距离关联上。论文给出的结果是Multi-Query NIAH 从 84.2 提升到 97.0Variable Tracking 也有明显提升。与其余工作的区分再往外看Engram 真正新颖的地方还在于它把“稀疏化”多拆出了一条轴。以前谈 sparse models(稀疏模型)很多人首先想到的是 MoE(Mixture-of-Experts专家混合模型)因为它通过只激活少数专家来节省每步计算而这篇论文提出除了 conditional computation(条件计算)还可以有 conditional memory(条件记忆)。于是就出现了一个新的问题在总参数量和总计算量固定时到底该把多少稀疏容量分给 neural computation(神经计算)多少分给 static memory(静态记忆)论文把它称为 Sparsity Allocation(稀疏分配) 问题并报告了一个 U-shaped scaling law(U 形缩放规律)容量全压在 MoE 上未必最优全压在 Engram 上也未必最优中间存在更好的平衡点。因此Engram 与几种常见概念必须分开看。它不是 MoE 的替代品。MoE 解决的是“怎样更高效地算”Engram 解决的是“哪些东西本来就不该反复算而该直接查”。它也不是 RAG(Retrieval-Augmented Generation检索增强生成) 的变体。RAG 去的是模型外部的文档库、数据库、网页Engram 查的是模型内部训练出来的静态记忆表。前者更像“翻资料”后者更像“脑内固定模式的快速调用”。它同样也不是 KV cache(键值缓存)KV cache 是推理阶段缓存已经算过的注意力键值优化的是“同一段上下文别重复算”而 Engram 优化的是“有些局部模式本来就更适合查表不必每次都靠主干重建”。这些区别虽然有一部分是推论但都直接建立在论文对 Engram、MoE 和内部静态记忆机制的定义之上。向工程的一些探索除了建模意义Engram 还有很强的工程意义。论文和官方 README 都强调它使用 deterministic addressing(确定性寻址)。这意味着对于给定的局部片段系统可以提前知道需要访问哪些 memory slot(记忆槽位)从而进行 runtime prefetching(运行时预取)在 GPU 计算之前或同时先从 host memory(主机内存) 把相关嵌入拉过来。论文给出的结论是把一个 100B 参数量级的表下放到主机内存额外开销仍然可以做到很小README 也把这一点总结为可以将 massive embedding tables(大规模嵌入表) offload(下放) 到 host memory通常指CPU内存并保持 minimal inference overhead(很小的推理额外开销)。这说明 Engram 不只是理论上增加了一块静态记忆它连系统层面的访问方式也一并设计了。不过现阶段它更像一个很清晰的架构方向而不是现成可直接工业部署的完整方案。DeepSeek 官方仓库已经公开了 demo implementation(演示版实现)但 README 和示例代码都明确说明这份实现主要用于说明 core logic and data flow核心逻辑和数据流很多标准组件被 mock(模拟) 或简化真正的 production use(生产使用) 还需要进一步优化例如自定义 CUDA kernel、分布式训练支持等。也就是说Engram 的思想已经很完整但它距离通用高性能工程化还有一段实现工作。