Engram 嵌入扩展：面向高效 DRAM/SSD 卸载的协同设计

Engram通过学习得到的多标记查找表扩展了标准的标记嵌入。对于重复出现的局部模式，可以直接检索向量，从而减少通过注意力机制和前馈层进行重建的需求。

借助Engram的模型架构优化，在保持同等质量的前提下，可降低对HBM容量的需求。这并不意味着对 HBM 的需求不会激增，只是意味着模型架构将继续围绕约束进行创新。

这种模型架构设计天然适用于参数卸载：每个标记仅访问少数几行嵌入，其地址取决于标记ID而非隐藏状态。运行时可在前几层计算的同时从主机DRAM预取这些行，使嵌入表保留在HBM之外，而无需传输整个权重矩阵。

我们的内存模型包含了我们对季度HBM、DRAM和NAND供需的最新估计。

卸载可释放HBM用于存储模型权重和KV缓存，从而可能支持更大的批量或更多并发会话。当DRAM成为新的瓶颈时，NVMe又提供了一个层级。

推荐系统早已将频繁或近期访问的嵌入行缓存在更快的内存中，而较冷的数据则由SSD承载。在NVIDIA因大幅降规格将Rubin Ultra从1024GB降至现在每颗芯片约200GB后，路线图不得不调整，像Engram这样的模型架构优化或许也能发挥作用。

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

在报告的后续部分，我们将展示我们的Engram卸载实验以及官方InferenceX代理推理在Engram模型如DeepSeekv4.1 Flash上，涵盖所有6款NVIDIA GPU的SKU及MI355X。

。毫不意外，CUDA护城河仍在超受欢迎的DeepSeekV4.1 Flash模型上压制MI355X。

我们还展示了，即使在高容量HBM配置下，将Engram卸载至DRAM，对于大多数帕累托最优点而言，其性能仍优于将Engram保留在HBM中。

我们的基准已被几乎所有主要买家广泛复制、验证和/或支持的算力来自谷歌云、Microsoft Azure、神谕者，、元文化等众多资源。此外，它还拥有支持机器学习社区，包括vLLM、LMCache、SGLang、PyTorch、Huggingface，并得到像OpenAI、MiniMax、ZAI、Qwen、Moonshot Kimi等大型实验室。

的支持。

如果你觉得开源基准和数据有用，给InferenceX GitHub仓库点星！。InferenceX是全球唯一一个同时支持TPUv7、Jalapeño、Nvidia Rubin NVL72、AMD，以及即将加入的SambaNova和Trainium的推理基准测试平台。

鉴于AgentX场景与真实世界代理型推理工作负载的高度拟真性，AMD也承诺将在MI455X UALoE72上开展合作。

Engram的优势

DeepSeek并未公开原论文中的两套经过训练的Engram模型。我们基于fineweb-edu数据集，采用其发布的代码和训练超参数进行了复现，每次运行的FLOPs估算约为6E18。

我们观察到相同的U型缩放趋势：

Engram相较于纯MoE基线提升了性能。我们也重现了DeepSeek的结果：使用Engram时，早期层的表示更接近于后期层。

究竟在记忆什么？

与原始Engram论文类似，我们也可以通过探查Engram的门控分数来了解DeepSeek-V4.1-Flash最常使用的n元组。我们的门控扫描发现了人名、代码片段、关系性表达及模板化内容。

这些示例侧重于信息的趣味性而非门控强度。

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

这些例子表明，所学的记忆是为了优化训练目标，而非判断哪些事实值得存储。许可证信息、参考文献片段、API脚手架以及网页模板等都能提供预测捷径，因此额外Engram容量的价值可能取决于数据准备阶段保留的内容。

这并不意味着嵌入表容量被“浪费”：评估语料库的扫描既无法确定训练过程中的暴露情况，也无法量化各类别所占用的容量。

就卸载而言，强门控并不能标识缓存热点行。弱门控也未必能节省读取操作：门控的计算需要先检索键值，反而抵消了融合内核带来的性能提升。

若要跳过读取，则必须在检索前配备独立的有效性预测器。

移除Engram

在原论文的推断时间消融中，事实知识类基准的性能仅保留了原来的29%–44%，而阅读理解则保留了81%–93%。这是由于训练与推理之间的不匹配所致。

因此，由此产生的性能下降反映的是该模型对Engram的依赖程度，而非有无Engram训练的模型之间的性能差异。

在我们的消融实验中，抑制Engram会使所有评估领域的标记似然度均有所恶化，尤其是在百科全书文本和若干代码语料上。令人惊讶的是，GSM8K的准确率仍维持在各次运行间的正常波动范围内，移除Engram并无显著影响。

Engram并非一个可拆卸的词典，置于不变的MoE之外。移除它会改变下游特征及专家选择机制。

我们通过CRUXEval这一小型Python函数的代码推理基准测试，检验了重新路由是否会造成损害或带来补偿。在该任务中，模型根据函数代码及输入预测其输出，并以参考答案作为评分依据。

移除Engram后，答案损失从0.2848位/标记上升至0.3093位/标记。若强制消融后的模型沿用原始Engram选定的专家，则进一步恶化至0.3375位/标记。

重新路由能在一定程度上弥补缺失的记忆。记忆特征与专家选择相互协作，而非简单遵循“记忆存储事实；专家负责推理”的分工。

在同样的CRUXEval测试中，无论是在哪个阶段移除Engram，都会降低准确率并增加生成的标记数；全程移除则导致最大幅度的变化。

在预填充阶段保留Engram，比在解码阶段保留更能产生正确答案，这可能是因为语义更丰富的KV缓存被传递给解码工作进程，从而在一定程度上缓解了性能损失。

代理型推理服务性能

Engram的嵌入表虽大，但每次查找却很小。DeepSeek-V4.1-Flash在两个Engram层中每次请求24行，整个模型每处理一个标记位置约需12.4 KiB，分配到四张GPU上则每张约3.1 KiB。

截至模型发布第7天，MI355X的单位性能仍比B200低2至4倍，即便已按MI355X较低的TCO进行归一化。我们完整的总拥有成本分布来自我们的AI云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镜像，但从模型发布时刻起至23小时后，AMD仍未公开该镜像。

AMD声称“速度就是护城河”，但截至第23小时仍未发布。我们期待AMD团队在未来针对首发时刻的模型发布建立更完善的流程。

最终，当他们终于公开了“首日”镜像支持时，从性能上看，其单位性能仍比H200低14.8倍，比B200/B300低42倍。

CUDA护城河的力量源于NVIDIA与其庞大的600万开发者社区生态系统的紧密协作，其中包括大部分vLLM、SGLang和Tokenspeed的维护者，这意味着CUDA在首发当天便已完成优化。

总体而言，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倍。

在模型质量相同的情况下，由于Engram可卸载至主机DRAM，所需的HBM容量得以减少。因此，HBM带宽的重要性远高于容量。对于内存带宽至关重要的推理工作负载，4-Hi HBM方案提供了最佳的单位带宽性价比，从而实现最低的单位标记成本。

如果中国继续推出更多革命性的模型架构创新，未来甚至有可能实现0-Hi HBM配置。

此外，在B300及首周部署的配置中，将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 token/s/用户时，DRAM的总token数/美元达到1.21亿，而SSD仅为5200万。

对于生产级服务，SSD卸载很可能得不偿失。在我们测量的B200配置中，SSD卸载在这两项指标上均处于劣势：每一个SSD观测点都有对应的DRAM替代方案，其P90交互性和总token数/美元均更高。

唯有在某些情况下，

更廉价的存储并不必然带来更廉价的推理服务。将Engram移至SSD后，服务器中仍然保留着四块昂贵的GPU及其他组件。只有当回收RAM能够带来更经济的服务器配置或额外的有用容量时，才具有实际意义。

而当前的非优化路径既未带来上述任何好处，文件系统缓存还在表页驻留时消耗RAM。

机制

接下来我们将探讨DeepSeekv4.1 Flash、LongCat、Qwen3.8 Flash Next等模型中n元组的具体机制与实现细节。