SemiAnalysis：Engram 嵌入如何为高效 DRAM/SSD 卸载做协同设计

Engram 通过学习的多 token 查找扩展了标准 token 嵌入。重复出现的局部模式直接检索向量，减少了通过注意力和前馈层重建它们的需要。

通过 Engram 模型架构优化，同等质量的模型所需的 HBM 容量得以降低。这并不意味着对 HBM 的需求不会变得疯狂，而只是意味着模型架构将继续围绕约束条件进行创新。

这种模型架构设计天然地与参数卸载协同设计：每个 token 访问几行嵌入，其地址取决于 token ID，而非隐藏状态。运行时可以在较早层计算时从主机 DRAM 预取这些行，从而将表保持在 HBM 之外，而无需传输整个权重矩阵。我们的 Memory 模型包含我们对 HBM、DRAM 和 NAND 供需逐季的最新估计。

卸载为模型权重和 KV 缓存释放了 HBM，可能支持更大的批次或更多并发会话。当 DRAM 成为下一个瓶颈时，NVMe 提供了另一层。推荐系统已经将频繁或最近访问的嵌入行缓存在更快的内存中，同时用 SSD 支持较冷的行。在 NVIDIA 路线图因将 Rubin Ultra 从 1024GB 大幅降规至如今每芯片约 200GB HBM 而不得不改变之后，像 emgram 这样的模型架构优化或许会有所帮助。

我们的 DeepSeek-V4.1-Flash 配置为 Engram 使用了大约 189 GiB 的内存。我们将其替换为内存映射（mmap）文件，并测量卸载到 SSD 时的服务性能。

在我们报告的后面部分，我们将展示我们的 Engram 卸载实验，以及在 DeepSeekv4.1 Flash 等 Engram 模型上，跨所有 6 个 NVIDIA GPU SKU 以及 MI355X 的官方 InferenceX 智能体推理服务结果。不出所料，CUDA 护城河在超受欢迎的 DeepSeekV4.1 Flash 模型上仍然碾压 MI355X。

我们还展示了，即使在高容量 HBM SKU 上，将 emgram 卸载到 DRAM 也可能为帕累托前沿的大部分带来比将 emgram 保留在 HBM 中更好的性能。

我们的基准测试已被几乎所有主要计算买家广泛复现、验证和/或支持，从 Google Cloud 到 Microsoft Azure 到 Oracle，再到 Meta 以及更多。此外，它还得到了 ML 社区的支持，包括来自 vLLM、LMCache、SGLang、PyTorch、Huggingface 的支持，以及 OpenAI、MiniMax、ZAI、Qwen、Moonshot Kimi 等主要实验室的支持。

如果你觉得这个开源基准测试和数据有用，请给 InferenceX GitHub 仓库点个 Star！。InferenceX 是世界上唯一一个拥有 TPUv7、Jalapeño、Nvidia Rubin NVL72、AMD，并且很快将拥有 SambaNova 和 Trainium 的推理基准测试。由于 AgentX 场景对真实世界智能体推理工作负载的高度真实性，AMD 已承诺在 MI455X UALoE72 上展开合作。

Engram 的优势

DeepSeek 并未发布原论文中两个经过训练的 Engram 模型。我们使用其发布的代码和训练超参数，在 fineweb-edu 上复现了其设置，每次运行估计为 6E18 FLOPs。我们观察到了相同的 U 形缩放规律：

Engram 相比纯 MoE 基线提升了性能。我们还复现了 DeepSeek 的结果，即带有 Engram 的较早层表示与较晚层的表示相似。

被记忆的是什么？

与原 Engram 论文一样，可以探查 Engram 的门控分数，以了解 DeepSeek-V4.1-Flash 最常利用哪些 n-gram。我们的门控扫描发现了人名、代码片段、关系性措辞和模板化文本。这些示例优先考虑的是趣味性，而非门控强度。

一个出乎意料的结果是 Wright : Ace Attorney。

这些示例表明，学习到的记忆优化的是训练目标，而不是判断哪些事实值得存储。许可证、参考文献片段、API 脚手架和网站装饰性内容可以提供预测捷径，因此额外 Engram 容量的价值可能取决于数据准备后留存下来的内容。这并不表明表格容量被“浪费”了：对评估语料的扫描既无法确定训练暴露情况，也无法确定每个类别占用的容量。

对于卸载而言，强门控并不能识别缓存热行。低门控也不会自动节省读取：计算门控需要检索到的键，从而抵消了融合内核带来的性能提升。要跳过读取，需要在检索之前有一个单独的实用性预测器。

移除 Engram

在原论文的推理时消融实验中，事实知识基准仅保留了原始性能的 29–44%，而阅读理解则保留了 81–93%。这是由于训练与推理之间的不匹配。因此，由此产生的性能下降衡量的是该训练模型对 Engram 的依赖程度，而不是使用和不使用 Engram 训练的模型之间的性能差异。

在我们的消融实验中，抑制 Engram 会降低所有评估领域中的 token 似然，尤其是百科全书文本和若干代码语料库。令人惊讶的是，GSM8K 准确率仍处于测量到的运行间波动范围内，移除 Engram 没有影响。

Engram 并不是一个位于未改变的 MoE 旁边的可拆卸字典。移除它会改变下游特征和专家选择。

我们通过一项在 CRUXEval 上固定 token 的教师强制实验，测试了重路由是有害还是具有补偿作用。CRUXEval 是一个由小型 Python 函数组成的代码推理基准，模型根据函数代码和输入预测函数输出，并对参考答案进行评分。

移除 Engram 使答案损失从 0.2848 比特/token 上升到 0.3093 比特/token。强制消融后的模型使用原始 Engram 开启时的专家选择，结果更糟，为 0.3375 比特/token。

重路由部分补偿了缺失的记忆。记忆特征和专家选择协同工作，而不是遵循“记忆存储事实；专家进行推理”这种清晰的划分。

在同一个 CRUXeval 上，在任一阶段移除 Engram 都会降低准确率并增加生成的 token 数；全程移除它带来的变化最大。

在预填充阶段保留 Engram 比在解码阶段保留能带来更多正确答案，这可能是因为传递给解码工作节点的 KV 缓存语义更丰富，从而能够缓解部分性能损失。

智能体推理服务性能

Engram 的表很大，但每次查找很小。DeepSeek-V4.1-Flash 在两个 Engram 层各请求 24 行，在整个模型中每个已处理 token 位置约 12.4 KiB，当拆分到四个 GPU 上时每个 GPU 约 3.1 KiB。

截至模型发布后的第 7 天，即使按 MI355X 更低的 TCO 进行归一化，MI355X 的每美元性能仍比 B200 差 2-4 倍。我们完整的总体拥有成本明细来自我们的 AI Cloud TCO 模型，以及对 100 多家 GPU 云和 GPU 云客户的月度市场调查。

在 DeepSeekv4.1 Flash 发布当天，NVIDIA vLLM 在所有 6 个 SKU 上开箱即用、零问题：H100、H200、B200、B300、GB200、GB300！这要归功于 NVIDIA 和 Interact 团队的出色工作！相比之下，AMD vLLM 在 DeepSeekv4.1 Flash 发布当天无法使用。来源：SemiAnalysis InferenceX

AMD 的 vLLM 文档指出要使用 vllm/vllm-openai-rocm:deepseekv41-flash-0909，但从模型发布第 0 小时到第 23 小时，AMD 一直没有公开发布该镜像。AMD 声称“速度是护城河”，但直到第 23 小时仍未发布。我们希望 AMD 团队今后在模型发布第 0 小时的支持方面能有更好的流程。

最终当他们确实公开发布“第 0 天”镜像支持时，就性能而言，目前其每美元性能比 H200 差高达 14.8 倍，比 B200/B300 差高达 42 倍。

CUDA 护城河的力量在于 NVIDIA 与其庞大的 600 万开发者社区生态系统的合作，其中包括大多数 vLLM、SGLang 和 Tokenspeed 维护者，这意味着 CUDA 在第 0 天就得到优化。

总体而言，AMD 确实取得了显著改进，但每美元性能目前仍比 B200 差 2-4 倍。

AgentX Engram DRAM 卸载提升性能

HBM 和 DRAM 卸载使用相同的 GPU 内核来选择和解量化行。使用 HBM 时，它读取 GPU 内存；使用统一虚拟寻址（UVA）时，它直接读取固定主机内存。

两者都支持完整的解码图。将表移入 HBM 只会加速稀疏查找，而解码器计算和通信保持不变，因此整体收益很小，同时还会消耗原本可用于 KV 缓存的内存。

将 Engram 卸载到 DRAM 的另一个好处是，你可以通过减少每个副本使用的 HBM GPU 来降低通信开销。例如，在 B300 上启用 Engram 卸载时，我们能够从 TP4 切换到 TP2，从而将帕累托曲线提升高达 1.6 倍。

在同等模型质量下，所需的 HBM 更少，因为 engram 可以卸载到主机 DRAM。因此，HBM 带宽远比 HBM 容量重要。对于内存带宽最为关键的推理工作负载，4-hi HBM 提供最佳的 $/带宽，因此每 token 成本最低。如果中国继续做出越来越多革命性的模型架构创新，很快就有可能实现 0Hi HBM 堆栈。

此外，在 B300 和 week-0 堆栈上，将 Engram 表移回 HBM 并未改善结果，且处于运行间方差范围内。这是优化 DRAM 卸载（如异步和重叠）工作的结果。

SSD 卸载

在 B200 上，我们创建了一个未优化的 vLLM 分支，并将 Engram 表存储在本地 SSD 上的内存映射文件中。文件后备让操作系统在其他应用程序需要 RAM 时回收表页。已缓存在内存中的页无需再次读取 SSD 即可提供。此外，请注意我们无法开启 GDS

未优化的 SSD 实现改变了行到达 GPU 的方式。它将行 ID 复制到 CPU，去重，将请求的行收集到固定缓冲区，将这些行复制回 GPU 并反量化。这项工作在 GPU 执行图的各段之间运行。原生 UVA 直接在 GPU 上执行行选择和反量化，避免了 CPU 往返。

热文件系统缓存消除了物理 SSD 读取，但仍保留了协调、行收集和传输。这就是为什么已缓存在 RAM 中的文件仍可能比固定 DRAM 表表现更差。该比较衡量的是整个服务路径；它并未区分这些操作各自花费的时间。

B200 DRAM 在每美元总 token 数和 P90 交互性两项指标上均优于两条实测 SSD 服务曲线。在接近 125 tokens/s/user 时，DRAM 每美元提供 1.21 亿总 token，而 SSD 为 5200 万。

对于生产服务，SSD 卸载很可能不值得这种权衡。在我们测量的 B200 配置上，SSD 卸载在两项指标上均落后：每个观察到的 SSD 点都有一个 DRAM 替代方案，提供更高的 P90 交互性和每美元更多总 token。唯一的情况是

更便宜的存储不会自动产生更便宜的推理服务。将 Engram 移到 SSD 后，同样的四块昂贵 GPU 和服务器其余部分仍然保留。回收 RAM 只有在能够实现更便宜的服务器配置或额外有用容量时才会产生经济效益。当前未优化的路径两者都无法提供，而且当表页驻留时，文件系统缓存仍会消耗 RAM。

机制

接下来我们将探讨来自 DeepSeekv4.1 Flash、LongCat、Qwen3.8 Flash Next 的 ngram 机制和具体实现。

阅读更多