蚌埠市网站建设_网站建设公司_字体设计_seo优化-自贡市网站建设公司

DeepSeek发布的Engram技术通过条件记忆作为MoE模型的补充稀疏性维度，实现了O(1)复杂度的知识检索。该技术采用词表压缩、哈希方法、多头查表等创新机制，平衡了神经网络计算与静态记忆资源配比。实验表明，在同等参数量和计算量条件下，27B规模的Engram模型性能显著优于传统MoE基线，特别在事实知识任务上表现优异，为提升大模型效率和知识存储提供了新思路。

**一、背景

DeepSeek 这两天发布了 Engram，社区内引起了非常大的关注，本文中我们结合开源代码具体介绍一下相应的实现方案。

代码库：GitHub - deepseek-ai/Engram: Conditional Memory via Scalable Lookup: A New Axis of Sparsity for Large Language Models

二、摘要

尽管 MoE 模型通过条件计算实现了容量扩展，但是 Transformer 架构缺乏原生的知识检索机制，迫使其必须通过计算来低效地模拟检索过程。

为了解决这一问题，DeepSeek 引入了条件记忆（Conditional Memory）作为补充的稀疏性维度，并通过 Engram 模块实现 O(1) 复杂度的检索。通过构建稀疏分配问题的数学框架，也发现了 U 形 Scaling Law 的优化方案，有效平衡了神经网络计算（MoE）和静态记忆（Engram）之间的资源配比。

基于上述规律指导，作者将 Engram 扩展到 27B 规模，在保持同等参数量与计算量的严格对比条件下，其性能显著优于传统的 MoE 基线。

三、引言

3.1 N-gram

N-gram 模型是自然语言处理中最基础、最经典的概率语言模型之一。在深度学习和 Transformer（如 GPT）出现之前，它是处理文本预测和语音识别的主流方法。在现实中，一句话的第 100 个词可能与之前的任何一个词有关，但为了计算方便，N-gram 做了简化的假设（马尔可夫假设）。简单来说，N-gram 模型的核心思想是：假设一个词出现的概率，只与它前面 N-1 个词有关。

N 的选取是一个超参数，以 “Only Alexander the Great could tame the horse Bucephalus.” 为例：

Unigram (1-gram)：

假设每个词的出现都是独立的，完全不看之前的词。
对应：P(wt)。

Bigram (2-gram)：

假设当前词只与之前的一个词有关，模型会根据 “Alexander” 这个词去查找，发现后面接 “the” 的概率最高。
对应：P(wt | wt-1)。

Trigram (3-gram)：

假设当前词只与之前的两个词有关，模型会根据 “Alexander the” 这两个词去查找，发现后面接 “Great” 的概率最高。
对应：P(wt | wt-1, wt-2)。

N-gram 模型本质上就是一个巨大的统计计数表。比如训练一个 Bigram 模型，就是要统计每一个词对 (wi-1, wi) 出现的次数。如果 “Alexander the” 在数据里出现了 100 次，而 “Alexander” 总共出现 200 次，那么当看到 “Alexander” 时，下一个词是 “the” 的概率就是 50%。

N-gram 模型的优缺点也比较典型：

优点：完全基于统计，预测就是查表，速度极快 O(1)；除此之外可解释性也很强。
缺点：如果 N 比较大，整个统计表可能非常稀疏，模型泛化能力较差；除此之外，无法解决长距离依赖的问题。

3.2 基于哈希的 N-gram

如果使用传统的查表法，N-gram 的表大小会呈指数级增长，假设词的个数为 V，则：

Unigram (1-gram)：表大小为 V。
Bigram (2-gram)：表大小为 V2。
Trigram (3-gram)：表大小为 V3。

然而，实际上很多组合永远不会出现，也就是 N-gram 组合是非常稀疏的。基于哈希的 N-gram 正是为了解决这个空间复杂度浪费的问题，并保持高效的查询效率，其不预先为所有组合分配索引和空间，而是使用 Hash 只为遇到过的组合分配。

3.3 多项式滚动哈希（Polynomial Rolling Hash）

对于一个序列 (t0, t1, t2, …, tn-1)，可以使用如下的 Polynomial Rolling Hash 方式计算其哈希值：

H(t0, t1, t2, …, tn-1) = an-1 * t0 + an-2 * t1 + an-3 * t2 + … + a0 * tn-1

为了避免出现极大的哈希值，通常还会对上述结果取模（M），对应：

H(t0, t1, t2, …, tn-1) = (an-1 * t0 + an-2 * t1 + an-3 * t2 + … + a0 * tn-1) mod M

a 和 M 的选择至关重要，与哈希冲突密切相关。

3.4 哈希冲突

在传统的数据结构中，可以使用“拉链法”或“开放寻址法”等解决哈希冲突的问题，以保证即使不同的 Key 有相同的哈希值，也能得到正确的 Value。然而，这种方式并不适合 GPU，GPU 更喜欢固定大小、连续内存的静态数组，在 GPU 上做大规模的“指针跳转”或“动态链表遍历”效率极低，会打破并行性；除此之外还可能频繁分配存储，导致碎片化问题。

因此在 GPU 中通常会避免哈希冲突的出现，并且如果 Hash 值是 Index，还会取模（Size）的方式限制大小。

四、方案

4.1 方案概览

如下图所示为 Engram 模型的基本结构，这里有几点需要关注：

Engram 可以插入 Transformer Block 中，并且不是每个 Layer 都有，不然 N-Gram Embedding 参数太多。（PS：需要额外的关注有几个 Engram Block，在那些层需要？）
蓝色框中是并行的 Transformer Block，这个对应 DeepSeek 前段时间刚发布的 [2512.24880] mHC: Manifold-Constrained Hyper-Connections。（PS：对于标准的 Transformer Block 也适用）
Engram Block 的输入，除了上一个 Transformer Block 输出的 Hidden State，还有 Input IDs，并且红框中的计算不依赖 Hidden State。（PS：因此，红色框中的计算就可以与之前的计算异步 Overlap 起来，避免成为瓶颈）

4.2 Engram 实现细节

4.2.1 词表压缩

在 Engram 中首先会对 Tokenizer 进行归一化处理。这样做是因为在原始文本中 “Hello” 和 “hello” 是两个不同的 token ID，对于 N-gram 查找来说略显冗余，会浪费巨大的存储空间。如下图源码所示，_build_lookup_table() 方法建立了一个映射表，将变体统一映射到一个唯一的 ID 上（例如去除大小写、前导空格等）：

如下是一个简单示例，比如：

原始词表为：[“Hello”, “hello”, “HELLO”, “世界”, “World”]
首先标准化，映射到：[“hello”, “hello”, “hello”, “世界”, “world”]
然后去重，压缩词表：[“hello”, “世界”, “world”]

论文中作者介绍，对于一个 128K 的 Tokenizer，可以将词表大小压缩 23%。

4.2.2 Hash

论文中没有直接采用多项式滚动哈希，而是采用了一种近似方法：

H(t0, t1, t2, …, tn-1) = (m0 * t0 ⊕ m1 * t1 ⊕ m2 * t2 ⊕ … ⊕ mn-1 * tn-1) mod M

也就是用一个预先生成的随机乘数 mk 代替 an-1-k；并使用 ⊕（位异或 XOR）替代加法。这样做有几个好处：

确定性和随机性的结合：

确定性：固定层，固定输入，固定的 N-gram，其对应的哈希值永远是一样的。
随机性：不同层，不同的 base_seed, 会生成不同的随机乘数 mk（每一层都不同，每个 N-gram 长度不同）；此外，每个 Head 会有不同的 M（互不相同的质数）；这样可以确保不同层、不同 Head 具有不同的 Hash 值，并且具有位置敏感性：(m0*A)⊕(m1*B) ≠ (m0*B)⊕(m1*A) 。

整数乘法和 XOR 都非常高效。

如下图所示，每一层，每个 N-gram，每个 Head 都会有不同的 M（质数）：

4.2.3 多头查表

为了节约存储空间，要控制 Hash 值的范围，本文采用的多项式滚动 Hash 也就无法避免哈希冲突的存在。为此，DeepSeek 采用 Multi-head 机制，同一个 N-gram 的不同 Hash 虽然有相同的随机乘数 mk，但是有不同的 M，Multi-head 组合就极大概率降低了全部冲突的可能。

以 Demo 中目标 Embedding 维度 D=512 为例：

方案 A（1 个大 Head）：一个巨大的表，每一项存 512 维向量。一旦冲突，512 维全错。
方案 B（8 个小 Head）：8 个小表，每一项只存 64 维向量。最后拼起来变成 64×8=512 维向量。这样，即使 Head 1 冲突，意味着 512 维向量中的前 64 维是脏的/混合的，但剩下的 448 维（来自其他 7 个 Head）可能是准确的。

如下图所示，查询后会将不同 Head，不同 N-gram 的 Embedding 拼接成一个一维的大 Embedding：

如上的 Hash 和多头查表也就对应论文中的公式（1）和公式（2）：

4.2.4 Context-aware Gating —— 动态门控

检索到的 Embedding 向量可以作为上下文无关的先验信息，由于是静态的，缺乏语境适应性，并且可能因为哈希冲突或多义性而产生噪声。为了增强表达能力并消除这种歧义，作者采用了受注意力启发的上下文感知门控方案（Context-aware Gating）。

如下图红色框中就是上述的多头哈希查表，蓝色框就是动态门控处理：

Key 和 Value 都会经过一个投影，实现不同 Head Embedding 的融合，并投影到预期的维度。
为了确保梯度稳定性，投影后的 Key 和 Value 都需要经过 RMSNorm。
计算相关性得分，其实就是一个点积注意力的变体：Score = K*Q/sqrt(d)。
数值稳定性和非线性处理：

abs()：取绝对值。
clamp_min(1e-6)：确保数值不小于 1e-6，防止下溢。
sqrt()：起到放大微小信号（比如 sqrt(0.01)=0.1），缩小大信号的作用，相当于进行了非线性的扩张/压缩处理。
* gate.sign()：恢复符号。

使用 sigmoid() 生成门控值 αt。
对 Value 进行门控处理。

上述实现对应论文中的公式（3）和公式（4）：

4.2.5 Context-aware Gating —— ShortConv

上述得到的 Value（N-gram Embedding）本质上是基于某些历史 Token（例如 2-gram, 3-gram）检索出来的，各个 Token 相互独立，之间没有直接的交互。为了扩充感受野，增强非线性，作者增加了一个短的 Depthwise Causal Convolution，这样每个 Token 都会融合前面多个 Token 的信息，也就相当于提取了当前位置及之前少量 Token 的局部特征。

具体的实现如下图所示：

前面提到其兼容 mHC，实际上对于每个 mHC 输入都是独立处理的，也就是有独立的 Engram Block。不过为了高效实现（减少 Kernel Launch，提升并行性），这里会将其 Concat 到一起处理，对应红色框部分。
红色框之间的部分对应的就是 Depthwise Causal Convolution：

groups=total_channels，表示为 Depthwise Convolution，每个 Channel 只和自己的卷积核计算，Channel 之间不混合。
dilation 被设置为 max_ngram_size=3，实际上每个 Token 已经包含 N-gram 信息，因此可以采用空洞卷积。
kernel_size：默认为 4，和 dilation 共同决定了感受野，也就是融合的 Token 个数。
Padding：卷积核 Padding，实现 Causal 特性，每个 Token 看不到之后的 Token。

上述计算对应论文中的公式（5）：

4.3 训练和推理

4.3.1 训练

训练中如果在每个 GPU 都存储完整的 N-gram Embedding Table 会存在巨大的空间浪费，为此，也可以采用分片策略（推荐系统很常见，比如 torchrec 中的 ShardedEmbedding），将 Embedding Table 存储在不同的 GPU。当然，这也就需要额外引入一些 All2All 操作来获取分布式的 Embedding。当然，这里有很多种切分方案，比如：

对于 mHC，其包含多个输入 Hidden States，它们之间不会交叉，对应的 Engram 计算可以放在不同的设备上，但是会受 mHC 数量的制约Embedding 共享，仍需要All2All。
按照 Head 切分，由于通常至少有 2-gram 和 3-gram，每个 N-gram 可能至少 4 个 Head，比较容易切分到常见的同一台机器的 8 个 GPU 中。这样在多头哈希之前和之后增加 All2All 即可，并且 All2All 可以在机内使用高速 NVLink + NVSwitch。
当然，也可以切分的更碎，比如直接切分到所有 GPU 中，需要全局的 All2All 操作。

4.3.2 推理

我们前面提到过，多头哈希查表操作只与 Input IDs 相关，因此其查找、传输操作可以与 Engram 之前的计算进行 Overlap。这也就给 N-gram Embedding Offload 到 CPU 内存甚至是层级化存储提供了很多机会。（PS：这里也需要 Trade-off，如果 Engram 放的位置太靠近输入层，比如在 Layer 1，那么多头哈希查表操作可能无法被 Overlap 掉；但是放置的太靠后效果又可能不好）

五、消融实验

5.1 缩放法则和稀疏分配

如下图 Figure 3 所示，作者通过实验证实，MoE 参数量与 Engram 参数量的比例呈 U 型关系，也就是纯 MoE 或纯 Engram 都不是最优的，当 ρ = 75%-80%（也就是 MoE）最优，也就是：

MoE 中路由专家参数量占 75%-80%。
Engram 中 Embedding 参数占 20%-25%。

两种模块之间存在结构互补性：

MoE 主导（ρ → 100%）：模型缺乏用于静态模式的专用记忆，不得不通过增加深度和计算量来低效地重建这些模式。
Engram 主导（ρ → 0%）：模型失去条件计算能力，削弱了对需要动态、上下文相关 Reasoning 的任务的表现；在该区域，记忆无法替代计算。

5.2 Engram 放置位置

如下图 Figure 5 所示，作者也进行了消融实验，在一个 12 层的 3B Dense 模型中添加 1.6B 的 Engram（单层）。如果只有一个 Engram，在 Layer 2 是效果最好（loss 最低），往后面层放置效果会变差。当然，一个 1.6B Engram 也可以切分为 2 个 0.8B 的 Engram，作者实验发现将其放置在 Layer 2 和 Layer 6 可以进一步提升性能，也更容易 Overlap。

5.3 Engram 消融

为了验证 Engram 模块的贡献，作者通过在 Inference 过程中完全抑制 Engram 模块输入输出并保持 Backbone 不变的方式进行评估。如下图 Figure 6 所示：

Factual knowledge 基准测试出现了灾难性崩塌，仅保留原始性能的29%–44%（例如TriviaQA 仅剩 29%），证实了 Engram 模块是参数化知识的主要存储库。
阅读理解任务展现出惊人的稳定性，保留了 81%–93% 的性能（例如 C3 任务达到 93%），表明基于上下文的任务主要依赖 Backbone 的注意力机制而非 Engram 模块。

5.4 效率

如下图 Table 4 所示，作者进行了端到端的 Inference 吞吐评估，4B 和 8B Dense 模型分别外挂 100B 的 Engram（CPU Offload），其 Inference 吞吐都只有略微下降。

蚌埠市网站建设_网站建设公司_字体设计_seo优化

**一、背景

二、摘要

三、引言

3.1 N-gram

3.2 基于哈希的 N-gram

3.3 多项式滚动哈希（Polynomial Rolling Hash）

3.4 哈希冲突

四、方案

4.1 方案概览

4.2 Engram 实现细节

4.2.1 词表压缩

4.2.2 Hash

4.2.3 多头查表

4.2.4 Context-aware Gating —— 动态门控

4.2.5 Context-aware Gating —— ShortConv

4.3 训练和推理

4.3.1 训练

4.3.2 推理

五、消融实验

5.1 缩放法则和稀疏分配

5.2 Engram 放置位置

5.3 Engram 消融

5.4 效率

如何系统的学习大模型 AI ？

01.大模型风口已至：月薪30K+的AI岗正在批量诞生

02.大模型 AI 学习和面试资料

第一阶段（10天）：初阶应用

第二阶段（30天）：高阶应用

第三阶段（30天）：模型训练

第四阶段（20天）：商业闭环

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【`保证100%免费`】

热门文章

文章分类

标签云

需要专业的网站建设服务？

蚌埠市网站建设_网站建设公司_字体设计_seo优化

**一、背景

二、摘要

三、引言

3.1 N-gram

3.2 基于哈希的 N-gram

3.3 多项式滚动哈希（Polynomial Rolling Hash）

3.4 哈希冲突

四、方案

4.1 方案概览

4.2 Engram 实现细节

4.2.1 词表压缩

4.2.2 Hash

4.2.3 多头查表

4.2.4 Context-aware Gating —— 动态门控

4.2.5 Context-aware Gating —— ShortConv

4.3 训练和推理

4.3.1 训练

4.3.2 推理

五、消融实验

5.1 缩放法则和稀疏分配

5.2 Engram 放置位置

5.3 Engram 消融

5.4 效率

热门文章

文章分类

标签云

相关文章

大模型编程进阶：从零散使用到系统化开发，程序员收藏必备

大模型Agent架构设计：上下文压缩5大实战方案，助你轻松应对长文本处理挑战

超越提示词工程：上下文架构六大核心组件深度解析

需要专业的网站建设服务？