梁文锋署名开源"记忆"模块，DeepSeek V4更细节

代码生成开发者生态开源模型推理优化架构优化

2026-01-13 17:33

256 浏览

0 点赞

AI 速览

DeepSeek发布新论文并开源Engram记忆模块，展示下一代稀疏大模型的架构演进方向。核心事实 - 研究主体：DeepSeek与北京大学合作，梁文锋署名 - 核心技术：提出“条件记忆”机制，通过Engram模块实现O(1)时间复杂度的知识查找 - 性能提升：在MMLU、CMMLU等基准测试中显著提升，长上下文检索准确率从84.2%提升至97.0% - 开源进度：Engram相关代码已上传至GitHub，DeepSeek V4形态愈发清晰价值点为开发者提供理解大模型稀疏化与记忆增强技术的最新实践参考，助力跟进前沿架构优化。

就在十几个小时前，DeepSeek发布了一篇新论文，主题为《Conditional Memory via Scalable Lookup:A New Axis of Sparsity for Large Language Models》，与北京大学合作完成，作者中同样有梁文锋署名。

论文地址：https://github.com/deepseek-ai/Engram/blob/main/Engram_paper.pdf

简单总结一波这项新研究要解决的问题：目前大语言模型主要通过混合专家（MoE）来实现稀疏化，这被称为「条件计算」。但是，现有的Transformer缺少原生的知识查找机制，只能被迫通过计算过程低效地模拟检索行为。

针对这一现状，DeepSeek提出了条件记忆（conditional memory），从而与MoE的条件计算互补，并通过引入一个新模块Engram来实现。

目前，模块「Engram」相关的实现已经上传到了GitHub。

项目地址：https://github.com/deepseek-ai/Engram

这让网友们感慨：「DeepSeek is back！」

此外，结合元旦期间公布的研究《mHC:Manifold-ConstrainedHyper-Connections》，我们可以明确的是DeepSeek v4的模样愈发清晰，就等上新了！

除了条件计算（MoE），LLM还需要一个独立的条件记忆Engram

MoE模型通过条件计算实现了模型容量的扩展，但现有的Transformer架构缺乏原生的知识查找原语，只能通过计算过程低效地模拟检索行为。

为了解决这一问题，DeepSeek提出了条件记忆（conditional memory）这一与条件计算互补的稀疏化维度，并通过Engram模块加以实现。Engram在经典𝑁-gram嵌入的基础上进行了现代化改造，使其能够以O(1)时间复杂度完成知识查找。

通过形式化提出稀疏性分配问题，DeepSeek还发现了一条呈U型的扩展规律，用以刻画神经计算（MoE）与静态记忆（Engram）之间的最优权衡关系。

在这一规律的指导下，DeepSeek将Engram扩展至270亿参数规模，并在严格等参数量、等FLOPs的条件下，其整体性能显著优于纯MoE基线模型。

尤为值得注意的是，尽管记忆模块本身主要被用于提升知识检索能力（如MMLU提升+3.4、CMMLU提升+4.0），但DeepSeek观察到其在通用推理能力（如BBH提升+5.0、ARC-Challenge提升+3.7）以及代码与数学推理任务（HumanEval提升+3.0、MATH提升+2.4）上带来了更为显著的增益。

进一步的分析表明，Engram能够将静态知识的重建负担从模型的浅层中剥离出来，从而有效加深网络用于复杂推理的有效深度。此外，通过将局部依赖关系交由查表机制处理，Engram释放了注意力机制的容量，使其能够更专注于全局上下文建模，从而显著提升了长上下文检索能力（例如Multi-Query NIAH的准确率从84.2提升至97.0）。

最后，Engram在系统层面同样展现出基础设施感知的高效性：其确定性的寻址方式支持在运行时从主机内存进行预取，几乎不会带来额外的性能开销。

DeepSeek认为，条件记忆将成为下一代稀疏大模型中不可或缺的核心建模原语。

Engram架构如下，其设计目标是在结构上将静态模式存储与动态计算过程从Transformer主干网络中分离出来，从而对其进行增强。该模块对序列中每一个位置依次执行两个功能阶段：检索与融合。

在运行过程中，DeepSeek首先对当前位置的后缀N-gram进行提取与压缩，并通过哈希机制以确定性的方式检索对应的静态嵌入向量。随后，这些被检索到的嵌入会在当前隐藏状态的调制下进行动态调整，并进一步通过一个轻量级卷积操作加以精炼。最后，Engram与多分支架构进行集成。

好文章，需要你的鼓励

# 报错信息分析与调试指南 ## 任务说明请分析用户提供的报错信息，推测可能的错误原因，并提供系统性的调试步骤。 ## 分析要求 1. **错误类型识别** - 确定是语法错误、运行时错误、逻辑错误还是环境配置错误 - 识别具体的错误类别（如空指针、数组越界、类型不匹配等） 2. **原因推测** - 基于错误信息中的关键线索进行合理推断 - 考虑常见的导致此类错误的编程场景 - 分析可能的代码问题或环境问题 3. **调试步骤** - 提供从简单到复杂的逐步调试方法 - 包括代码检查、日志添加、环境验证等具体操作 - 给出预防类似错误的最佳实践建议 ## 输出格式 - **错误类型**：[具体的错误分类] - **可能原因**： 1. [原因1] 2. [原因2] 3. [原因3] - **调试步骤**： 1. [步骤1] 2. [步骤2] 3. [步骤3] 4. [步骤4] - **解决方案**：[具体的修复建议] ## 示例 **输入**：【报错信息】 ``` TypeError: Cannot read property 'length' of undefined at processData (app.js:25:18) at main (app.js:10:5) ``` **输出**： - **错误类型**：运行时错误 - TypeError - **可能原因**： 1. 变量未正确初始化就被访问其 length 属性 2. 函数参数传递了 undefined 值 3. 异步操作中数据还未加载完成就尝试访问 - **调试步骤**： 1. 检查 app.js 第25行附近的变量声明和赋值 2. 在访问 length 属性前添加类型检查：`if (variable && variable.length)` 3. 使用 console.log() 输出相关变量的值确认其状态 4. 检查函数调用时传入的参数是否正确 - **解决方案**：在访问对象属性前先验证对象是否存在，或确保变量在使用前已被正确初始化。