NVIDIA 协同设计的五种方式可更大限度地提高 AI 工厂中每个字节的价值

在 AI 工厂中，高带宽内存 (HBM) 是速度最快、成本最高且最具争议的内存层。在冗余权重副本、空闲会话的 KV 缓存或重新计算的前缀上花费的每个字节都是一个不用于生成token的字节。问题不再是 GPU 有多少内存，而是每个字节提供了多少有用的工作。

下方图 1 中的代际数据说明了原因。从 GB300 到 NVIDIA Rubin，容量保持在 288 GB，带宽提升至 19.2 TB/s。

每兆瓦代理吞吐量的增长速度要快得多。在SemiAnalysis AgentX上，回放录制的编码代理会话时，NVIDIA Vera Rubin NVL72 能够以 160 tokens 的速度将 GB300 NVL72 的每兆瓦吞吐量提高 30 倍。

仅凭容量无法解释相同的每个 GPU 288 GB 所带来的 30 倍增益。区别在于每个字节提供的有用工作量。

NVIDIA 将此视为涉及 GPU 架构、纵向扩展互连、软件服务、CPU 和存储的联合设计问题。本文将探讨通过联合设计更大限度地提高每个字节内存价值的五种方法，从对单个权重进行编码的位，到在代理式转弯和节点之间保留和重用上下文的共享存储。

1. NVFP4 如何以更少的字节存储更多智能？

提高字节值最直接的方法是缩小每个值，而不丢失其编码的内容。NVFP4 使用一个 4 位 E2M1 元件和两个缩放级别来实现这一点：每个 16 值的微块共享一个 FP8 (E4M3) 缩放系数，每个张量的 FP32 缩放系数位于顶部。最终得到的格式足够小，可以释放重要的 HBM，但足够细粒度，可以在原生 4 位格式不足的情况下保持准确性。

在权重方面，NVFP4 将模型占用空间相对于 FP16 减少了约 3.5 倍，相对于 FP8 减少了约 1.8 倍，从而为最需要的代理式推理释放内存：更高的 KV 缓存容量、更大的批量和更高的并发性。NVFP4 已成为具有严格准确性要求的开放代理基准测试的默认精度，包括 AA-AgentPerf、SemiAnalysis AgentX 和 MLPerf Endpoints。在这些基准测试和领先的多专家模型 (MoE) 架构中，它在相同的交互性下提供了高达 FP8 基准 4 倍的吞吐量 (下方图 3) 。

同样的原理也延伸到了 KV 缓存本身。NVFP4 KV 缓存最多可将缓存占用空间减少 50%，因此驻留在设备上的上下文大约增加了 2 倍。减少撤离意味着预填充期间的缓存命中率更高，而较小的缓存意味着解码期间消耗的带宽更少。

NVFP4 会缩小字节。下一个问题是这些字节位于何处，以及 AI 工厂必须保留多少副本。

2. NVLink 纵向扩展域如何将 72 个 GPU 转变为一个内存池？

MoE 模型每个 token 仅激活一组参数，但每个专家的权重仍必须位于 HBM 中的某个位置。当专家们聚集在少量 GPU 上时，每个 GPU 都会在权重上占用大量内存，而且每个解码步骤都会为 MoE GroupGEMM 付出沉重的权重负载成本。字节是驻留字节，但它们并不努力工作。

NVIDIA TensorRT-LLM 中的宽专家并行 (Wide-EP) 通过将专家分布到 8 个或更多 GPU 来改变这一比例。在 EP64 上运行 DeepSeek-R1 时，每个 GPU 每层可容纳 4 个专家，即在完整模型中，在 14848 个 MoE 层中，有 58 个 MoE 层拥有 232 个专家块。减少每个 GPU 的专家权重意味着：

容量：每个 GPU 的 HBM 更多，可用于 KV 缓存、更大的批量和更高的并发性。
算术强度：GroupGEMM 内核会在更多 token 上重复使用每个加载的权重，从而提高每字节的 FLOPS。
平衡：专家并行负载均衡器 (EPLB) 可在前向传递之间重新分配冷热专家，因此当另一个 GPU 处于空闲状态时，GPU 的内存不会被过度占用。

这之所以有效，是因为扩展域使远程字节的用途几乎与本地字节相同。每个 MoE 层都会触发 all-to-all 调度和合并流量，如果没有高带宽结构，这些集合将抵消收益。在 GB200 NVL72 上，130 TB/s 的 NVLink 聚合带宽可以吸收这些流量，与以每位用户每秒 100 token 的速度运行的小型 EP (EP8) 相比，大型 EP (EP32) 可为每个 GPU 提供高达 1.8 倍的输出 token。

Vera Rubin NVL72 扩展了相同的设计点。每个 Rubin GPU 可提供高达 288 GB 的 HBM4 和 3.0 TB/s 的 NVLink 6 带宽，整个机架的 HBM4 带宽约为 20.7 TB。Rubin 还添加了内联内存张量加速 (TMA) 描述符更新，因此一个共享描述符可以为每个具有通用布局的专家提供服务，从而减少随着专家数量增加而增加的元数据开销。

Wide-EP 决定权重字节的位置。下一个杠杆决定是否再次计算 KV 缓存字节。

3. NVIDIA Dynamo 如何计算每个缓存的字节数？

键值 (KV) 缓存会存储之前处理过的 token 的中间注意力计算，因此模型可以重复使用这些 token，而无需重新计算它们。这种推理状态是短暂的，可以在需要时排除和重新计算，但 KV 缓存只有在重复使用时才有价值。代理式工作负载充满了重复使用的机会：系统提示、工具模式、共享文档，以及多步骤任务不断发展的历史。但是，如果请求落在不包含其前缀的 GPU 上，或者该前缀更早被逐出，则系统会再次支付预填充的费用。字节存在；它们位于错误的位置。

NVIDIA Dynamo 是能够弥合这一差距的分布式服务层。它将 KV 缓存视为整个集群范围的资源，而不是每个 GPU 的副作用，并通过三种共同设计的功能来实现这一点：

KV 感知路由：Dynamo 路由器跟踪 KV 块驻留的位置，并在发出请求时同时考虑缓存前缀重叠和工作负载。它平衡了现有上下文与将工作发送到已使用的 GPU 的成本，并将潜在的重新计算转化为缓存命中。
分类服务：预填充和解码在单独的 GPU 池上运行，每个池的大小都有自己的计算和内存配置文件。解码 GPU 可以将 HBM 专用于 KV 缓存和批量大小，而无需为突发预填充预留空间。
KV 缓存运行器 (KVCR): 追踪每个块在已配置 GPU、固定 CPU 和存储层 (包括本地 SSD 和已安装的网络文件系统) 中的位置。保留在 HBM 外部的前缀可以在后续请求需要时恢复，从而使有用的上下文在 GPU 驱逐中存活下来，并继续保存预填充工作。KVCR 使用 NVIDIA 推理 Xfer 库 (NIXL) 实现存储传输路径，允许在 GPU 处理其他工作时移动缓存块。KVCR 还支持分布式重用，通过路由器提供的提示帮助选定的工作者从对端检索缓存的上下文，同时推理引擎保留对 GPU 显存和本地主机卸载的控制。附加的 KVCR-Guard 功能可在引擎发生故障时保留已承诺的 KVCR 管理的主机内存缓存，只要 Guard 服务和主机仍然可用即可。

Dynamo 的 KV 缓存卸载依赖于快速检索：在 HBM 外部保留前缀可以节省时间，因为加载前缀的速度比重复预填充快。NIXL 将这种卸载路径连接到外部存储系统。在单独的验证测试中，存储供应商 VAST Data 和 WEKA 分别使用 GPUDirect Storage 向一个 H100 GPU 展示了 35 GB/s 的速度，并通过自定义 NIXL 插件分别在 8 个 H100 GPU 上展示了高达 270 GB/s 的总读取吞吐量。这些测试表明，外部存储可以为测试的 GPU 系统提供 KV 缓存，而不会成为传输瓶颈，支持 HBM 以外的缓存容量。一项单独的 VAST 测试展示了响应时间优势：在 DGX H100 系统上使用 vLLM 和 LMCache，加载存储的 KV 缓存而不是重新计算，可通过 130K token提示将 Qwen3-32B 的时间缩短到第一个token。

Dynamo 坐标是缓存字节的所在位置和返回位置。从 CPU 内存开始，接下来的两个工具可扩展该环境的可用容量。

4. NVIDIA Vera CPU 如何防止闲置上下文浪费 HBM？

代理式推理不会在一次不间断的传递中运行。单个会话在 GPU 模型步骤和 CPU 端工作之间交替进行：工具调用、代码执行、检索、数据库查询和沙盒评估。在每个间隙期间，HBM 中保留的任何会话 KV 缓存都会占用容量，而不提供活动token生成服务，而其他请求则争夺相同的字节。

在完全订阅的 AI 工厂中，GPU 无需等待。在工具调用运行时，它需要处理新请求，而且差距越长，原始会话的 KV 缓存被逐出以腾出空间的可能性就越大。工具返回时，GPU 可能必须通过完整的预填充重建该上下文，而不是从缓存状态恢复。因此，CPU 速度缓慢会给 HBM 带来两倍的成本：首先是空闲驻留，然后是重新计算。

NVIDIA Vera CPU 攻击了这个问题的双方：

差距更短：88 个 Olympus 核心可将单线程性能提高 1.8 倍，峰值加载延迟比 x86 CPU 低 40%，每个核心的显存带宽高达 14 GB/s。更快、更可预测的工具调用会缩小 KV 缓存面临压力的窗口。
快速停车环境：每个 Vera CPU 可提供高达 1.5 TB 的 LPDDR5X，是单个 Rubin GPU 的 HBM4 容量的 5 倍以上。NVIDIA NVLink-C2C 以 1.8 TB/s 的速度与 Rubin 紧密连接，大约是 x16 PCIe Gen 6 链路的 256 GB/s 的 7 倍。

这些功能共同改变了空闲会话的经济效益。Dynamo 的 KV Block Manager 无需在 HBM 中保留或丢弃其 KV 缓存，而是可以在工具调用期间将其暂存在 Vera 内存中，并在代理恢复时通过 NVLink-C2C 将其恢复。HBM 专注于主动生成 token 的会话，暂停的会话可避免两次支付预填充费。

Vera 内存是暖层，大小适合会在某一回合中返回的上下文。对于必须在各个回合、智能体和节点之间生存下来的上下文，AI 工厂需要一个更大的层。

5. NVIDIA CMX 如何在整个 POD 中扩展上下文内存？

在 GPU 或主机显存中保留每个可重复使用的 KV 缓存字节会限制主动推理的容量，但丢弃它可能会强制进行重新计算。多轮会话、长地平线任务和共享工作内存的多智能体工作流都会生成再次需要的 KV 缓存，这些缓存通常会在几分钟后生成，而且通常会在不同的节点上生成。更长的上下文窗口和更多的并发会话会增加 KV 缓存容量需求，超出 GPU HBM (图 9 中的 G1) 和主机内存 (G2) 。传统的层次结构并非为这些数据而设计。本地 SSD (G3) 绑定到一个节点，而共享企业存储 (G4) 专为耐用数据而构建，并带有临时 KV 缓存不需要的复制和元数据用度。

NVIDIA CMX 上下文内存存储通过新的 G3.5 层弥补了这一差距：以太网连接闪存，在 POD 级别共享，并专门针对 KV 缓存进行了优化。它基于 NVIDIA STX 参考设计构建，并跨四个层共同设计：

存储处理：NVIDIA BlueField-4 STX 存储处理器管理 NVMe SSD，运行存储服务，卸载 KV-cache 的数据移动、数据完整性和加密。其集成的 NVIDIA Vera CPU 可加速 CPU 端存储处理，将用于智能体执行的相同 CPU 架构扩展到存储数据路径中。
网络：NVIDIA Spectrum-X 以太网可在计算节点和 CMX 存储节点之间提供低延迟、高带宽的 RDMA 访问。
KV 感知服务：NVIDIA DOCA Memos 在 BlueField-4 上提供 KV 感知服务和 I/O 控制，将上下文作为放置和共享的第一资源。
服务集成：Dynamo 和 NIXL 使 CMX 在整个 POD 中显示为一个无缝的上下文层，将上下文和路由请求预置到 KV 缓存已驻留的位置。

Pod 级设计提高了每个字节的价值。在一个节点上计算一次的前缀可以在 pod 中的兼容模型实例中重复使用，因此共享文档、工具或工作内存的代理可以避免重复的预填充。跨 POD 池化上下文存储可减少节点间的 KV 缓存重复和搁浅容量，从而扩展用于推理的有效 GPU 显存。通过将可重复使用的上下文预存到 GPU 或主机显存中，CMX 可减少推理停顿，而其 KV 缓存优化存储层可降低为该上下文提供服务的功耗。与用于长上下文推理的传统存储相比，这些功能可帮助 CMX 每秒提供高达 5 倍的 token，并将能效提高 5 倍。

这五个杠杆如何协同工作？

每个操纵杆都可以消除不同类型的浪费。NVFP4 消除不需要的值，Wide-EP 消除冗余权重复制，Dynamo 消除重新计算，Vera 消除工具调用期间的空闲驻留，CMX 实现跨节点的 KV 缓存共享和重用。由于这些杠杆设计为一个内存系统，而不是作为独立的部件，因此增益堆栈：4 位 KV 块可节省 HBM、Vera 内存和 CMX 等设备中的空间。

其结果是，AI 工厂不仅根据容量衡量内存，还根据每个字节产生的有用 token 来衡量内存。Vera Rubin NVL72 显示了这一点：每兆瓦 GB300 NVL72 的吞吐量高达 30 倍，而每个 GPU 的吞吐量为 288 GB。随着代理式工作负载的增长，每个字节都很重要。

视频 1. 在本期《 Inside the Architecture》中，我们将探讨 NVIDIA 优化整个 AI 工厂内存使用的五种方式。了解模型权重、KV 缓存和内存层如何协同工作，以及效率为何取决于整个系统。

了解详情

这项工作得益于 Wei-ming Chen、Shiyang Chen、Chao Ni、Mengti Wang 和 Jeff Pool 的专业知识和工程贡献。