在AI工厂中,高带宽内存(HBM)是速度最快、成本最高、争夺最激烈的内存层级。每一个用于存储冗余权重副本、闲置会话KV缓存或重复计算前缀的字节,都意味着少了一个用于生成Token的字节。如今的问题已不再是GPU拥有多少内存,而是每个字节能带来多少有效工作量。

下面图1中的代际数据说明了这一点。从GB300到NVIDIA Rubin,内存容量维持在288 GB不变,而带宽则提升至19.2 TB/s。

智能体任务的单位功耗吞吐量增长远超这一比例。在SemiAnalysis AgentX测试中(该测试会重放真实编程智能体会话记录,包含真实的工具调用间隔和不断增长的上下文),NVIDIA Vera Rubin NVL72在每用户160 Token/秒的条件下,单位功耗吞吐量最高可达GB300 NVL72的30倍。

单凭容量无法解释这30倍的性能提升——毕竟每个GPU的容量同样是288 GB。真正的差异在于每个字节能产生多少有效工作量。

NVIDIA将这视为一项涵盖GPU架构、扩展互连、服务端软件、CPU及存储的协同设计问题。本文将探讨协同设计如何从五个方面提升每个内存字节的价值——从编码单个权重的比特,到在智能体多轮交互与多节点间保存并复用上下文的共享存储。

NVFP4如何用更少字节存储更多智能?

提升字节价值最直接的方法,就是在不损失信息的前提下缩小每个数值的大小。NVFP4通过4比特的E2M1元素和两级缩放机制实现这一点:每16个数值组成的微块共享一个FP8(E4M3)缩放因子,并在此基础上叠加一个张量级的FP32缩放因子。最终形成的格式既足够精简以释放大量HBM空间,又保持足够的粒度以在原生4比特格式表现不佳的场景下维持精度。

应用于权重时,相比FP16,NVFP4可将模型体积缩减约3.5倍;相比FP8则缩减1.8倍,从而为智能体推理最需要的资源——更大的KV缓存容量、更大的批处理规模以及更高的并发能力——释放出内存空间。NVFP4已成为AA-AgentPerf、SemiAnalysis AgentX和MLPerf Endpoints等具有严格精度要求的开放智能体基准测试的默认精度格式。在这些基准测试及主流混合专家(MoE)架构中,NVFP4在相同交互性条件下可实现FP8基线吞吐量的4倍(见下图3)。

同样的原理也适用于KV缓存本身。与FP8相比,NVFP4 KV缓存可将缓存占用空间减少最多50%,使设备上可驻留的上下文量提升约2倍。更少的驱逐意味着预填充阶段更高的缓存命中率,而更小的缓存也意味着解码阶段消耗的带宽更少。

NVFP4压缩了字节本身。下一个问题是:这些字节存储在哪里,以及AI工厂需要保留多少份副本。

NVLink扩展域如何将72个GPU整合为一个内存池?

MoE模型每个Token只激活一部分参数,但每个专家的权重仍必须驻留在HBM某处。当专家被集中分配到少量GPU上时,每个GPU都要耗费大量内存存储权重,并且每个解码步骤都要为MoE分组矩阵乘法付出高昂的权重加载成本。字节虽然驻留在内存中,却没有发挥应有的效用。

NVIDIA TensorRT-LLM中的宽域专家并行(Wide-EP)技术通过将专家分散到8个或更多GPU上来改变这一比例。以DeepSeek-R1在EP64配置下为例,每个GPU每层只需存储4个专家,在完整模型的14848个专家块中仅承担58个MoE层中的232个专家块。每GPU专家权重的减少带来以下好处:

容量方面:每个GPU上更多的HBM空间可用于KV缓存、更大批处理及更高并发。

计算密度方面:分组矩阵乘法内核能在更多Token间复用每个已加载的权重,提升每字节的浮点运算量。

负载均衡方面:专家并行负载均衡器(EPLB)在前向传播之间重新分配热点和冷门专家,确保不会出现某个GPU内存超载而另一个闲置的情况。

这一切之所以能够实现,是因为扩展域使远程字节几乎与本地字节同样可用。每个MoE层都会触发全互联的分发与合并通信,若没有高带宽互连结构,这些集合通信将抵消上述收益。在GB200 NVL72上,总计130 TB/s的NVLink聚合带宽足以吸收这些通信流量,在每用户100 Token/秒条件下,大规模专家并行(EP32)相比小规模专家并行(EP8)每GPU可多输出最多1.8倍的Token。

Vera Rubin NVL72延续了相同的设计理念。每个Rubin GPU配备最高288 GB的HBM4内存和3.0 TB/s的NVLink 6带宽,整机柜HBM4总容量约达20.7 TB。Rubin还新增了内联内存张量加速器(TMA)描述符更新功能,使单个共享描述符即可服务于所有采用通用布局的专家,从而降低随专家数量增长而增加的元数据开销。

宽域专家并行决定了权重字节的存储位置。下一个关键在于:KV缓存字节一旦被计算出来,是否还需要被重复计算。

NVIDIA Dynamo如何让每个缓存字节都物尽其用?

键值(KV)缓存存储了先前处理过的Token的中间注意力计算结果,使模型能够复用这些结果而非重新计算。这种推理状态是短暂的,可以在需要时被驱逐并重新计算,但只有被复用时,KV缓存才有价值。智能体工作负载中充满了复用机会:系统提示词、工具模式定义、共享文档以及多步骤任务不断增长的历史记录。但是,如果某个请求被分配到不持有其前缀内容的GPU上,或者该前缀刚刚被驱逐,系统就必须再次为预填充付出代价。这些字节本来是存在的,只是出现在了错误的位置。

NVIDIA Dynamo是弥合这一差距的分布式服务层。它将KV缓存视为整个集群范围内的资源,而非单个GPU的附带产物,并通过三项协同设计的能力实现这一点:

KV感知路由:Dynamo路由器会追踪KV块所在的位置,在分配请求时综合考虑缓存前缀的重叠程度与工作节点的负载情况。它在现有上下文与将任务发送至已占用GPU的成本之间进行权衡,将潜在的重复计算转化为缓存命中。

分离式服务:预填充与解码运行在各自独立的GPU资源池中,每个资源池均按照自身的计算和内存特征进行规划配置。解码GPU可以将HBM专门用于KV缓存和批处理规模,而不必为突发的预填充任务预留余量。

KV缓存运行器(KVCR):该组件追踪每个数据块在已配置的GPU、固定CPU内存及存储层级(包括本地SSD和挂载的网络文件系统)中的位置。保存在HBM之外的前缀内容,可在后续请求需要时被恢复,使有用的上下文能够在GPU驱逐后继续存活,并持续节省预填充工作量。KVCR使用NVIDIA推理传输库(NIXL)处理其存储传输路径,使缓存数据块能够在GPU处理其他任务的同时进行迁移。KVCR还支持分布式复用:路由器提供的提示信息可帮助指定的工作节点从对等节点检索缓存上下文,同时推理引擎仍保留对GPU内存和本地主机卸载的控制权。此外,KVCR-Guard功能可在引擎发生故障时,只要守护服务和主机保持可用,就能保留已提交的KVCR管理的主机内存缓存。

Dynamo的KV缓存卸载依赖于快速检索:当加载前缀内容的速度快于重新执行预填充时,将其保存在HBM之外才有意义。NIXL将这一卸载路径与外部存储系统相连接。在各自独立的验证测试中,存储供应商VAST Data通过GPUDirect Storage实现了对单个H100 GPU达35 GB/s的传输速率,而WEKA通过定制的NIXL插件在8个H100 GPU间实现了最高270 GB/s的聚合读取吞吐量。这些测试表明,外部存储能够为所测试的GPU系统提供KV缓存,而不会成为传输瓶颈,从而支持超出HBM容量限制的缓存能力。另一项由VAST进行的测试则展示了响应时间方面的收益:在一台DGX H100系统上使用vLLM和LMCache,对于拥有13万Token提示词的Qwen3-32B模型,加载已存储的KV缓存而非重新计算,缩短了生成首个Token所需的时间。

Dynamo协调着缓存字节的去向及其返回时机。接下来的两项举措则进一步扩展了可用于容纳上下文的容量,首先从CPU内存说起。

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块管理器不必将闲置会话的KV缓存保留在HBM中或直接丢弃,而是可以在工具调用期间将其暂存至Vera内存中,待智能体恢复运行时通过NVLink-C2C将其取回。HBM始终专注于服务正在主动生成Token的会话,而暂停的会话也无需为预填充付出两次代价。

Vera内存是一个“温层”级存储,适用于会在同一轮交互内返回的上下文。而对于需要跨越多轮交互、多个智能体乃至多个节点持续存活的上下文,AI工厂还需要一个容量更大的存储层级。

NVIDIA CMX如何在整个计算池范围内扩展上下文内存?

将每个可复用的KV缓存字节都保留在GPU或主机内存中会限制活跃推理的可用容量,而将其丢弃则可能导致重复计算。多轮次会话、长周期任务以及共享工作内存的多智能体工作流,都会产生需要再次使用的KV缓存——这种需求往往在数分钟后出现,且常常发生在不同的节点上。更长的上下文窗口和更多的并发会话,使KV缓存容量需求超出了GPU HBM(见下图9中的G1)和主机内存(G2)的承载能力。传统的存储层级体系并非为此类数据而设计。本地SSD(G3)仅绑定于单个节点,而共享企业级存储(G4)则专为持久化数据构建,承载着复制和元数据方面的开销,而这些对于短暂存在的KV缓存而言并无必要。

NVIDIA CMX上下文内存存储通过引入全新的G3.5层级弥补了这一空白:以太网连接的闪存存储,在计算池级别共享,并专门针对KV缓存进行了优化。该方案基于NVIDIA STX参考设计构建,并在四个层面上进行了协同设计:

存储处理:NVIDIA BlueField-4 STX存储处理器负责管理NVMe SSD、运行存储服务,并为KV缓存提供数据完整性与加密方面的卸载处理。

网络连接:NVIDIA Spectrum-X以太网为计算节点与CMX存储节点之间提供低延迟、高带宽的RDMA访问能力。

KV感知服务:NVIDIA DOCA Memos在BlueField-4上提供KV感知服务及I/O控制能力,将上下文视为一种可被独立调度和共享的一级资源。

服务集成:Dynamo与NIXL使CMX在整个计算池范围内呈现为一个统一无缝的上下文层级,能够预先部署上下文数据,并将请求路由至KV缓存已存在的位置。

正是这种计算池级别的设计,提升了每个字节的价值。某一节点计算出的前缀内容,可以在整个计算池内兼容的模型实例间复用,因此共享文档、工具或工作内存的多个智能体能够避免重复的预填充过程。在整个计算池范围内汇聚上下文存储,减少了各节点间的KV缓存重复和闲置容量,从而有效扩展了可用于推理的GPU内存。通过将可复用的上下文预先部署到GPU或主机内存中,CMX减少了推理过程中的停滞现象,而其针对KV缓存优化的存储层级也降低了服务该上下文所需的功耗开销。综合这些能力,在长上下文推理场景下,CMX相比传统存储方案最高可实现5倍的Token处理速度提升和最高5倍的能效提升。

这五项举措如何协同发挥作用?

每一项举措都消除了不同类型的浪费:NVFP4消除了数值中不必要的比特位,宽域专家并行消除了冗余的权重副本,Dynamo消除了重复计算,Vera消除了工具调用期间的闲置占用,而CMX则实现了跨节点的KV缓存共享与复用。由于这些举措被作为一个统一的内存系统而非独立部分进行设计,其收益能够相互叠加:一个4比特的KV数据块无论存储在HBM、Vera内存还是CMX中,都能同样节省空间。

最终呈现出的,是一个不再仅以容量衡量内存价值,而是以每个字节所产生的有效Token数量来衡量内存价值的AI工厂。Vera Rubin NVL72正体现了这一理念:在每GPU同样288 GB容量的条件下,单位功耗吞吐量可达GB300 NVL72的30倍。随着智能体工作负载不断增长,每一个字节都至关重要。

NVIDIA