Engram DRAM/SSD Offloading

导言

Engram 把反复出现的局部 token 模式存成可学习的查找表。表很大，但每次只读取少量行，而且地址可以提前计算。这让模型有机会把表放到主机内存，为 GPU 上的模型权重和 KV 缓存腾出空间。

本文逐段翻译 SemiAnalysis 提供的架构解释与卸载实验，保留原文图表。核心问题是：节省 HBM 容量，什么时候能转化为更好的推理服务性能和成本？

原文：《Engrams Embedding Entendre: Codesign for Efficient DRAM/SSD Offloading》，可译为“Engram 嵌入的双重含义：面向高效 DRAM/SSD 卸载的协同设计”。副标题：新模型架构对 DRAM/NVMe 总潜在市场的影响、DeepSeek-V4.1-Flash、AgentX、InferenceX 与 NVMe 实验。作者：Bryan Shan、Cam Quilici、Alec Ibarra 等，2026 年 9 月 18 日。

本文按所提供 HTML 的正文顺序翻译；下文的“我们”均指 SemiAnalysis 原作者，不代表译者进行过这些实验。性能比较和路线图判断对应原文发表时的配置与软件栈。图片保留英文标注，图注译为中文；表格的名称与代码片段保持原样。保存文件在“机制”章节开头结束，本文不包含未提供的后续内容。新增解释均标为“译注”。

架构与存储协同

Engram 在标准 token 嵌入的基础上，增加了可学习的多 token 查表机制。对于反复出现的局部模式，模型可以直接检索相应向量，从而减少通过注意力层和前馈层重新构建这些模式的需要。

Engram 对模型架构的优化，使模型在达到相同质量时，可以需要更少的 HBM（高带宽内存）。这并不意味着市场不会继续对 HBM 产生巨大的需求，而是说明模型架构会持续围绕资源约束进行创新。

这种模型架构天然适合与参数卸载协同设计：每个 token 只访问少数几行嵌入，而这些行的地址取决于 token ID，并不取决于隐藏状态。运行时可以在前面几层计算的同时，从主机 DRAM（内存）预取这些行，使整张表保留在 HBM 之外，而不必搬运整个权重矩阵。我们的 Memory Model 包含对 HBM、DRAM 和 NAND 逐季度供需情况的最新估计。

{ width="95%" }

图 1：Engram 的 GPU 计算路径、主机 DRAM 查表路径及可选的 SSD 层。来源：SemiAnalysis。

卸载可以为模型权重和 KV 缓存腾出 HBM 空间，从而有机会支持更大的批量或更多并发会话。当 DRAM 成为下一个容量约束时，NVMe 可以提供另一层存储。推荐系统已经采用类似做法：把经常访问或最近访问的嵌入行缓存在更快的内存中，同时用 SSD 存放较冷的行。NVIDIA 不得不调整路线图，将 Rubin Ultra 每芯片的 HBM 容量从 1024 GB 大幅降到如今的约 200 GB，因此，Engram 这样的模型架构优化或许能够发挥作用。

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

在这篇报告后面，我们会展示 Engram 卸载实验，以及 InferenceX 对 DeepSeek-V4.1-Flash 等 Engram 模型的官方 Agent 推理服务测试结果，覆盖 NVIDIA 的全部六款 GPU 型号和 MI355X。不出所料，在非常热门的 DeepSeek-V4.1-Flash 模型上，CUDA 的生态护城河仍让 MI355X 明显落后。

我们还会展示：即使 GPU 具有较大的 HBM 容量，把 Engram 卸载到 DRAM，在帕累托前沿的大部分区间中，也可能比将 Engram 保留在 HBM 中表现更好。

〔译注：帕累托前沿指同时考虑交互速度和每美元 token 产出时，无法在不牺牲另一项的情况下继续改善的配置集合。〕

我们的基准已被几乎所有主要算力买家广泛复现、验证或支持，包括 Google Cloud、Microsoft Azure、Oracle、Meta 等。此外，它也得到 vLLM、LMCache、SGLang、PyTorch、Hugging Face 等机器学习社区的支持，以及 OpenAI、MiniMax、ZAI、Qwen、Moonshot Kimi 等主要实验室的支持。

{ width="95%" }

图 2：InferenceX 的支持机构。来源：[InferenceX](https://github.com/SemiAnalysisAI/InferenceX)。

如果你认为这些开源基准和数据有用，请给 InferenceX 的 GitHub 仓库点一个 Star！InferenceX 是全球唯一覆盖 TPUv7、Jalapeño、NVIDIA Rubin NVL72、AMD，并且即将覆盖 SambaNova 和 Trainium 的推理基准。由于 AgentX 场景非常贴近真实世界的 Agent 推理负载，AMD 也已承诺在 MI455X UALoE72 上开展合作。

{ width="95%" }

图 3：InferenceX 开源基准仓库。来源：[SemiAnalysis](https://github.com/SemiAnalysisAI/InferenceX)。

Engram 的收益

DeepSeek 没有发布原始论文中训练的两个 Engram 模型。我们使用公开代码和训练超参数，在 fineweb-edu 上复现了它的设置，估计每次训练运行需要 6 × 10¹⁸ FLOPs。我们观察到了相同的 U 形缩放趋势：

{ width="95%" }

图 4：参数分配比例与验证损失：复现实验中的 U 形趋势。来源：SemiAnalysis。

与纯 MoE（混合专家）基线相比，Engram 提升了性能。我们也复现了 DeepSeek 的结果：加入 Engram 后，较早层的表示会接近较晚层的表示。

{ width="95%" }

图 5：纯 MoE 与 Engram 的逐层 KL 散度比较。来源：SemiAnalysis。

模型究竟记住了什么

和原始 Engram 论文一样，我们可以探查 Engram 的门控分数，观察 DeepSeek-V4.1-Flash 最依赖哪些 n-gram。我们的门控扫描发现了人名、代码片段、表达关系的短语，以及样板文本。这里选择这些例子时，优先考虑的是它们是否有趣，而不是门控强度有多高。

〔译注：门控分数控制检索出的记忆向量对当前表示的影响强度。〕

表 1：部分活跃的 n-gram

主题	示例	意义
人名	Daisy Buchanan able Kimmy Schmidt Tim Robbins Ian Goodfellow	名字组合在一起时，可能具有截然不同的含义。
可复用的代码惯用片段	response = ur get_context_data(** cloud import WordCloud	代码短语通常具有更高的门控分数。
题目内容与关系表达	第 1 层：pints of frozen yogurt 第 14 层：three times as many	不同层有不同偏好：偶然出现在题目中的对象，与可复用的关系表达。
标识符与任务指令	第 1 层：SumOfPrimeDivisors 第 14 层：Write a function to 第 14 层：find a sum to 第 14 层：calculate the sum of	指令在较晚层具有更高的门控分数。
跨语料反复出现的字面模式	0-393- 0-321- 0-471- &list=PL email.mime.text There was a problem	参考书目片段、ISBN 片段、URL 参数、API 路径和错误消息用语，会跨越不同语料的边界反复出现。
网页样板文本	All Rights Reserved. this article is licensed All Rights Reserved. 微信扫一扫分享 本文仅代表作者	文档模板会跨语言调动 Engram。第 14 层的中文例子意思分别是“用微信扫码分享”和“本文仅代表作者……”。

来源：SemiAnalysis 原文中的 Datawrapper 表格“Some active N-grams”。译注：n-gram 指连续 n 个 token 构成的片段；样例中的不完整词、代码片段，以及重复的 All Rights Reserved. 均按原表保留。

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

{ width="95%" }

图 6：与《逆转裁判》相关的原文配图。来源：SemiAnalysis。

〔译注：图中文字意为：“Dylan Patel：DeepSeek 的基础设施并没那么好，他们只是有 5 万块 Hopper GPU。”下方台词为：“你不是一个小丑，你是整个马戏团。”这是原文的戏谑配图。〕

这些例子提示，学习得到的记忆是在优化训练目标，而不是在判断哪些事实值得存储。许可证文本、参考书目片段、API 样板代码和网页模板元素，都可以提供预测捷径。因此，增加 Engram 容量的价值，可能取决于数据准备后留下了什么。这并不能说明表容量被“浪费”了：对评估语料的扫描，既不能确定模型是否在训练中见过这些内容，也不能确定每一类内容占用了多少容量。

对于卸载来说，门控强并不能识别出缓存中的热点行。门控弱也不会自动减少读取：计算门控需要用到检索得到的 key，这会抵消融合 kernel 带来的性能收益。若想跳过读取，就需要在检索之前另行预测条目是否有用。

移除 Engram 的影响

在原始论文的推理阶段消融实验中，事实知识基准只保留了原来 29%–44% 的性能，而阅读理解保留了 81%–93%。这是由训练与推理不一致造成的。因此，这种性能退化衡量的是已训练模型对 Engram 的依赖程度，而不是“训练时使用 Engram 的模型”与“训练时不使用 Engram 的模型”之间的性能差异。

{ width="95%" }

图 7：推理阶段移除 Engram 后，不同基准保留的相对性能。来源：[DeepSeek](https://arxiv.org/pdf/2601.07372#page=17)。

在我们的消融实验中，抑制 Engram 会使所有评估领域的 token 似然变差，百科文本和若干代码语料尤其明显。令人意外的是，GSM8K 准确率的变化仍处于不同运行之间的实测波动范围内，移除 Engram 没有产生可辨别的影响。

Engram 并不是附在一个保持不变的 MoE 旁边、可以随手拆下的字典。移除它会改变后续的特征和专家选择。

我们通过 CRUXEval 上一个固定 token 的教师强制实验，测试重新路由到底是在造成损害，还是在起补偿作用。CRUXEval 是一个代码推理基准，包含一些小型 Python 函数：模型根据函数代码和输入预测输出，然后我们对参考答案进行评分。

〔译注：教师强制固定模型所读的 token 序列，使实验可以比较同一参考答案的损失，而不是任由生成内容变化。〕

{ width="95%" }

图 8：CRUXEval 的函数输入与输出预测示例。来源：[CRUXEval](https://arxiv.org/pdf/2401.03065)。

移除 Engram 后，答案损失从 0.2848 bits/token 上升到 0.3093 bits/token。如果强制消融后的模型继续使用原来启用 Engram 时的专家选择，结果会更差，达到 0.3375 bits/token。

{ width="95%" }

图 9：启用 Engram、自由重新选择专家，以及固定原专家选择时的答案损失。来源：SemiAnalysis。

重新路由会部分补偿缺失的记忆。记忆特征与专家选择是协同工作的，并不存在整齐划一的“记忆存储事实、专家负责推理”的分工。

在同一个 CRUXEval 基准上，无论是在 prefill（输入预填充）阶段，还是在 decode（逐 token 生成）阶段移除 Engram，准确率都会降低，生成的 token 数都会增加；全程移除时，变化最大。

{ width="95%" }

图 10：在 prefill、decode 或两个阶段移除 Engram 后的准确率和生成 token 数。来源：SemiAnalysis。

在 prefill 阶段保留 Engram，比在 decode 阶段保留 Engram 能得到更多正确答案。这可能是因为，传递给 decode 工作进程的 KV 缓存包含了更丰富的语义信息，从而能够缓解一部分性能损失。

Agent 推理服务性能

Engram 表很大，但每次查表读取的数据很少。DeepSeek-V4.1-Flash 在两个 Engram 层中，各请求 24 行；在整个模型中，每个被处理的 token 位置大约读取 12.4 KiB，如果切分到四块 GPU 上，则每块 GPU 大约读取 3.1 KiB。

{ width="95%" }

图 11：DeepSeek-V4.1-Flash 在不同 GPU 上的每美元总 token 产出与 P90 交互速度。来源：[InferenceX](https://inferencex.semianalysis.com/inference/deepseek-v41-flash)。

〔译注：图中横轴的 P90 Interactivity 表示按第 90 百分位口径统计的交互指标，单位为每用户每秒 token 数；纵轴 Total Tokens/$1 TCO 表示每 1 美元总拥有成本对应的总 token 产出。曲线用于比较速度与成本之间的取舍。〕

截至模型发布后的第 7 天，即使把 MI355X 更低的 TCO（总拥有成本）纳入归一化，MI355X 的每美元性能仍然只有 B200 的约 1/2 至 1/4。我们的完整总拥有成本分解，来自 AI Cloud TCO Model，以及每月对 100 多家 GPU 云服务商和 GPU 云客户开展的市场调查。

{ width="95%" }

图 12：B200 与 MI355X 的推理服务曲线比较。来源：[InferenceX](https://inferencex.semianalysis.com/inference/deepseek-v41-flash)。

DeepSeek-V4.1-Flash 发布当天，NVIDIA vLLM 在 H100、H200、B200、B300、GB200、GB300 这六款型号上都能开箱即用，没有出现问题！这得益于 NVIDIA 和 Interact 团队的出色工作！相比之下，AMD vLLM 在发布当天还不能运行 DeepSeek-V4.1-Flash。来源：SemiAnalysis InferenceX。

{ width="95%" }

图 13：原文关于模型发布当天 NVIDIA 与 AMD 支持情况的配图。来源：[InferenceX](https://inferencex.semianalysis.com/inference/deepseek-v41-flash)。

AMD 的 vLLM 文档指向 vllm/vllm-openai-rocm:deepseekv41-flash-0909，但从模型发布后的第 0 小时到第 23 小时，AMD 都没有公开发布这个镜像。AMD 宣称“速度就是护城河”（SPEED IS THE MOAT），但到了第 23 小时，这个镜像仍未发布。我们希望 AMD 团队今后能为模型发布当天的支持建立更好的流程。

{ width="95%" }

图 14：AMD vLLM 文档中的 DeepSeek-V4.1-Flash 镜像配置。来源：vLLM AMD。

{ width="95%" }

图 15：原文截取的 Docker Hub 镜像标签查询页面。来源：vLLM, AMD, DockerHub。

当他们最终公开发布提供“首日”支持的镜像时，其每美元性能在最不利的比较点上，仅为 H200 的约 1/14.8，以及 B200/B300 的约 1/42。

CUDA 护城河的力量，来自 NVIDIA 与庞大的 600 万开发者社区生态之间的协作，其中包括 vLLM、SGLang 和 Tokenspeed 的大多数维护者。这意味着，CUDA 在模型发布当天就已经得到优化。

{ width="95%" }

图 16：AMD 首次提供支持时与 NVIDIA 的每美元性能比较。来源：[InferenceX](https://inferencex.semianalysis.com/inference/deepseek-v41-flash)。

总体而言，AMD 的确取得了显著改进，但其每美元性能当时仍然只有 B200 的约 1/2 至 1/4。

{ width="95%" }

图 17：AMD 随后的性能改进及其与 B200 的比较。来源：[InferenceX](https://inferencex.semianalysis.com/inference/deepseek-v41-flash)。

DRAM 卸载如何改善性能

HBM 驻留和 DRAM 卸载使用同一个 GPU kernel 来选择嵌入行并执行反量化。使用 HBM 时，它读取 GPU 内存；使用统一虚拟寻址（Unified Virtual Addressing，UVA）时，它直接读取页锁定的主机内存。

两种方式都支持完整的 decode 执行图。把表移到 HBM，只会加速稀疏查表，解码器的计算和通信并没有变化，因此总体收益很小，却会消耗本来可以留给 KV 缓存的内存。

把 Engram 卸载到 DRAM 的另一个好处，是每个模型副本可以使用更少的带 HBM 的 GPU，从而减少通信开销。例如，在 B300 上启用 Engram 卸载后，我们可以从 TP4 改为 TP2，使帕累托前沿最高改善到原来的 1.6 倍。

〔译注：TP4 与 TP2 分别表示每个副本用 4 块、2 块 GPU 做张量并行。〕

{ width="95%" }

图 18：B300 在 Engram DRAM 卸载与 TP 配置调整前后的曲线。来源：SemiAnalysis InferenceX。

在模型质量相同的前提下，由于 Engram 可以卸载到主机 DRAM，模型所需的 HBM 更少。因此，HBM 带宽比 HBM 容量重要得多。对于最依赖内存带宽的推理负载，4-hi HBM 提供了最佳的每美元带宽，从而带来最低的每 token 成本。如果中国继续推出更多具有革命性的模型架构创新，也许很快甚至有可能出现“0Hi HBM 堆栈”。

〔译注：4-hi 指 HBM 的 DRAM 芯片堆叠层数为 4；“0Hi”是原作者对进一步减少 HBM 依赖的推测性表述。〕

关联文章：《低堆叠 HBM 为何胜出》（Long Live the Short King: Why 4-hi HBM Wins）。作者：Myron Xie、Bryan Shan 等；保存页面显示日期为 9 月 14 日。

{ width="140" }

图 19：原文关联文章《低堆叠 HBM 为何胜出》的缩略图。来源：SemiAnalysis 原文关联文章卡片。

此外，在 B300 和模型发布第一周的软件栈上，把 Engram 表移回 HBM 并没有改善结果，变化仍处于不同运行之间的波动范围内。这是异步处理、传输与计算重叠等 DRAM 卸载优化工作的结果。

SSD 卸载

在 B200 上，我们创建了一个尚未优化的 vLLM 分支，并将 Engram 表存放在本地 SSD 上的内存映射文件中。使用文件作为后端，使操作系统能够在其他应用需要 RAM 时回收表对应的内存页。已经缓存在内存中的页面，可以直接提供数据，不必再次读取 SSD。另外，我们没能启用 GDS。

〔译注：GDS 指 GPUDirect Storage，用于支持存储与 GPU 之间的直接数据传输；此处实验未启用它。〕

这个尚未优化的 SSD 实现，改变了嵌入行到达 GPU 的方式。它先将行 ID 复制到 CPU，去重，把请求的行收集到页锁定缓冲区中，再将这些行复制回 GPU 并执行反量化。这些工作在 GPU 执行图的不同片段之间运行。原生 UVA 则直接在 GPU 上完成行选择和反量化，省去了 CPU 往返。

预热后的文件系统缓存可以消除实际的 SSD 读取，但协调、收集行以及数据传输仍然存在。因此，即使文件已经缓存在 RAM 中，它的性能仍可能低于页锁定的 DRAM 表。这项比较测量的是整个推理服务路径，并没有分别统计上述每个操作耗费的时间。

在 B200 上，以每美元产出的总 token 数和 P90 交互速度衡量，DRAM 都优于测得的两条 SSD 推理服务曲线。在接近每用户 125 tokens/s 的位置，DRAM 每美元可以产出 1.21 亿个总 token，而 SSD 为 5200 万个。

{ width="95%" }

图 20：DRAM 与 SSD 卸载下，每芯片输入吞吐与 P90 交互速度的比较。来源：SemiAnalysis InferenceX。

〔译注：该图纵轴是“每芯片输入 token 吞吐”，与上文“每美元总 token 产出”的指标不同。这里分别保留原文文字与原图，不将两种指标等同。〕

图内原注译文：

• 分离式推理配置（例如 MoRI SGLang、Dynamo TRTLLM）按 decode 芯片或 prefill 芯片数量计算输入吞吐，而不是按全部芯片数量计算。因此，直接将其输入吞吐与一体式配置比较，并不是同口径比较。
• 该图标有“非官方叠加数据”（UNOFFICIAL overlays）。图内提示：此部署不托管在 inferencex.semianalysis.com，与 SemiAnalysis 无隶属关系，也未获其背书；显示的数据可能是非官方的、经过修改的或过时的。权威 InferenceX 结果应以官方网站为准。

对于生产推理服务，SSD 卸载很可能不值得。在我们测量的 B200 配置中，SSD 卸载在两个指标上都落后：对每一个观测到的 SSD 点，都有一个 DRAM 方案，能够提供更高的 P90 交互速度，以及更多的每美元总 token 产出。只有那些……的点。〔译注：该段最后一句在保存文件中仅剩 “The only points where”，句子被截断，缺失部分未补写。〕

存储更便宜，并不会自动让推理服务更便宜。把 Engram 移到 SSD，仍然保留着同样四块昂贵的 GPU，以及服务器的其余部分。只有回收 RAM 能使服务器配置变得更便宜，或者创造额外的可用容量时，才会产生经济收益。当前尚未优化的路径没有带来这两项收益；而且，当表对应的内存页驻留在内存中时，文件系统缓存仍然会消耗 RAM。

机制

接下来，我们将讨论 DeepSeek-V4.1-Flash、LongCat 和 Qwen3.8 Flash Next 中 n-gram 的机制与具体实现。

〔译注：所提供的保存文件在上面这句之后结束。原网页后续“机制”分析属于订阅内容，本文尚无对应原文，因此未翻译或补写。〕