DeepSeek V4的最大遗憾之处在于它未能包含Engram。
JayEngram去哪了？
Engram是DeepSeek与北京大学于今年一月共同发布的一项开源技术，主要研究大型模型的记忆效率问题。
自1月初论文发布以来，人们普遍认为Engram将是V4架构的重要基石。然而，在V4的正式推出后，许多人都在寻找有关Engram的具体内容，但最终没有找到任何相关信息。
这导致一些网友甚至觉得没有包含Engram的V4是不完整的。
Engram去哪了？
没有集成Engram，可以说是DeepSeek V4的一个重大遗憾。
尽管如此，关于Engram的研究并未停止。自V4发布后不久，就有多篇相关的论文相继问世：
一篇论文探讨了如何通过CXL内存池化技术来解决大规模模型部署中的存储问题；
另一篇则对多头哈希优化进行了实证检验，否定了某些直觉上的改进方案；
还有一篇将Engram应用于视觉模态的工作。
虽然V4没有直接使用Engram，但其概念和后续应用已悄然铺开，并为下一代模型奠定了基础。
Engram究竟是什么呢？
时间倒回到2026年1月12日。DeepSeek与北京大学联合发布了一篇题为《Conditional Memory via Scalable Lookup》的论文，作者是Cheng Xin和梁文锋等人。
一句话概括Engram的功能就是：给Transformer模型添加了一个原生的知识查询模块，能够直接检索预存信息。
团队的核心发现在于，语言建模实际上包含了两种完全不同的任务——一种需要深度动态计算的组合推理，另一种则是静态知识的查找。
- 传统上，Transformer模型将这两项任务混为一谈。当识别一个实体时，它必须消耗好几层注意力和前馈网络来完成特征拼凑工作。
- 例如，“Diana, Princess of Wales”的标识过程就需要经过6层才能最终解析出来。
- 前几层会纠结于“Wales是英国的一个地区”、“Princess of Wales是一种头衔”等中间状态，直到最后一层才明确这是戴安娜王妃的称呼。
这种将静态查找表重建为动态计算的过程消耗了大量资源，而这些本可以用于更复杂的推理任务。
因此，Engram的核心思想是直接在Transformer模型中嵌入这种能力。具体做法是在第2层和第15层之间插入一个Engram模块。
这个模块的工作原理是在输入序列触发哈希查找时，将当前token及其前后若干token组成的N-gram映射到一个庞大的嵌入表中，并直接检索出对应的向量。
门控机制则确保查找到的内容与当前上下文不匹配时自动屏蔽。例如，“张”是一个常见的姓氏，但“张仲景”三个字组合起来则是特定的历史人物实体，门控就负责识别这种区别。
Engram的作用类似于MoE（混合专家）模型中的稀疏计算轴，只不过它侧重于存储的优化而非计算效率。这两者相辅相成，并不冲突。
实验结果显示，在固定总参数和每token激活参数的情况下，将大约20%-25%的稀疏参数分配给Engram时，模型损失达到最低点。
在大规模语言模型中应用后，知识密集型任务性能提升符合预期（MMLU+3.4, CMMLU+4.0），而通用推理和代码数学任务则超出预期（BBH+5.0, ARC-Challenge+3.7, HumanEval+3.0, MATH+2.4）。
特别是在长上下文场景下，Multi-Query NIAH从84.2%跃升至97.0%。
那么为什么记忆模块还能提高推理能力呢？
LogitLens和CKA的分析表明，在Engram模型中，第5层的表现与MoE基线模型中的第12层最为接近。这意味着早期层从知识重建任务中解放出来，可以专注于更复杂的推理。
工程上来看，将一个巨大的记忆表卸载到主机DRAM中，以减少对HBM的依赖，在高性能计算设备如英伟达H800上的性能损失也只有2.8%。
由于Engram索引完全取决于输入token序列，并且可以提前计算并由CPU异步预取，因此可以在GPU计算与内存访问之间实现重叠。
尽管这项技术在V4中未得到应用，但在其他方面已经取得了显著进展。
自论文发布以来的三个月内至少出现了三项重要成果：
一项是探讨如何将Engram模块部署到CXL内存池；
另外一个研究者则验证了多头哈希优化方案，并发现其实现效果并不理想，反而在某些情况下性能有所下降；
AutoArk团队则成功地将Engram技术应用于视觉模型。
总的来说，在发明者保持沉默的同时，其他人正在各个方向上推进这项工作的发展。
按这个曲线指导，团队把Engram扩到27B验证。激活参数3.8B，训练262B tokens，严格跟MoE-27B基线对齐。
结果知识密集型任务的提升符合预期(MMLU +3.4，CMMLU +4.0)，但通用推理和代码数学的提升超出预期(BBH +5.0，ARC-Challenge +3.7，HumanEval +3.0，MATH +2.4)，长上下文场景更夸张，Multi-Query NIAH从84.2%跃升到97.0%。
那么，为什么记忆模块还能反过来提升推理?
LogitLens和CKA给出了答案，Engram-27B第5层的表征，跟MoE基线第12层的表征最相似。
Engram把模型的早期层从「重建静态知识」这种苦力活里解放出来，这部分网络深度被腾出来做更复杂的推理。Engram不是新增了一块记忆，它还变相把网络加深了。
工程上。论文把一个1000亿参数的Engram表整个甩到host DRAM，在H800上跑推理，8B-Dense的吞吐损失只有2.8%。
靠的是Engram索引的确定性，只取决于输入token序列，完全可以提前算，CPU异步预取跟GPU计算重叠。
可以说，这个模块天生就不靠HBM，只可惜如今V4来了，Engram没来。
没在v4，但在其他地方
发明者把它放在那里没动，但路上还是有人。三个月里，至少出现了三个值得说一下的工作。
把Engram塞进CXL内存池
3月10日，北大、阿里云、山东英信、人大、港大联合发了一篇系统论文，《Pooling Engram Conditional Memory in Large Language Models using CXL》。
他们没改Engram本身，而是回答了一个更工程的问题，如果Engram真的成了下一代标配，内存放哪。
答案是CXL内存池化。GPU HBM放计算权重，本地DRAM做二级缓存，CXL池做三级。8台服务器共享4TB内存池，XConn XC50256交换芯片做拓扑，512GB/s带宽。
整套集成进SGLang，做了预取-计算重叠，跑下来端到端吞吐损失小于5%。Engram论文里那句「1000亿嵌入表卸载DRAM」的轻描淡写，被他们做成了27B和40B两个规模的真实测试。
结论很清楚，Engram这种确定性寻址、可预取的负载，几乎是为CXL量身定做的。
一个反直觉的实验
Engram论文上线第十一天，1月23日，一个叫TaoLin的研究者，单作者，放出了《A Collision-FreeHot-Tier Extension for Engram-Style Conditional Memory》。
他想验证一个看上去显然的优化，Engram用多头哈希查表会有冲突，如果把高频N-gram用Minimal Perfect Hash Function完全消除冲突，模型会不会更好。
他设计了Engram-Nine，把记忆分成无冲突的「热层」和保留多头哈希的「冷层」。
结果反直觉。在严格iso-parameter控制下，无冲突设计没有稳定提升验证loss。
route-stratified评估还发现，训练初期热路径(高频)loss更低，但训练后期冷路径反过来超过热路径。
一个看上去显然的优化方向，被一个真做实验的人证伪了。
把Engram推到视觉(AutoArk/TinyEngram)
GitHub上一个叫AutoArk的团队搞了Tiny Engram。
基于Qwen-3完整复现文本Engram之后，他们做了一件论文里没做的事，把Engram搬到Stable Diffusion上。
视觉patch经过分层编码，底层抓纹理，中层抓部件，高层抓风格，然后整套丢进哈希查表。
跟LoRA比下来，达到同等效果，Engram需要的额外参数只有LoRA的15%到30%。连续注入多个新概念时，LoRA会出现明显的概念退化，Engram不会。
Engram原本是为文本设计的。AutoArk等于把这扇门撞开了，凡是能离散化、能哈希的模态，Engram都能搬。
三个月里，Engram这条路上，发明者最沉默，跟进者各自走了一步。
一个团队替它解决多机内存层级，一个独立研究者证伪了它一个看似显然的优化方向，一个开源团队把它推到了视觉。
而deepseek-ai/Engram这个仓库，最后一次提交还停在1月14日。
One more thing
Engram论文的摘要结尾有一句话：
我们认为条件记忆将是下一代稀疏模型不可或缺的建模原语。
看来，这个下一代得是V5了，难不成会是V4.1?
参考链接
[1]https://arxiv.org/pdf/2601.07372
[2]https://arxiv.org/pdf/2603.10087
[3]https://arxiv.org/pdf/2601.16531