NVIDIA Vera Rubin:HBM 容量不变,推理效率如何提升
NVIDIA 将 NVFP4、宽专家并行、Dynamo、Vera 与 CMX 组织成跨层内存系统。收益取决于能否减少权重占用、闲置缓存和重复预填充,同时控制精度损失、通信和恢复延迟;最高 30 倍的每兆瓦吞吐量来自特定基准下的厂商系统比较。
THE BRIEF
博客要点
依据 NVIDIA Technical Blog 2026 年 11 月 5 日文章;规格和性能数字均为来源披露。本文未做独立测试,文中的验证步骤均为建议。
来源公告日期 ·
变化:从显存容量转向有效驻留
NVIDIA 于 11 月 5 日发布技术文章,解释 Vera Rubin 如何在每 GPU 仍为 288 GB HBM 的条件下提高推理效率。其宣称,在回放编码代理会话、保留工具调用间隙和增长上下文的 SemiAnalysis AgentX 中,Vera Rubin NVL72 相对 GB300 NVL72,在每用户每秒 160 token 的条件下,每兆瓦吞吐量最高达到 30 倍。NVIDIA Technical Blog
对服务运营者,容量规划需要同时考虑权重占用、活跃上下文和缓存恢复成本。相同显存容量可以容纳更多有效工作,但上下文放错位置,仍会带来重复预填充和排队。本文判断,这套设计的价值是减少无效驻留与重复计算;30 倍是特定条件下的系统比较,不能据此拆出单个部件的贡献。给定材料也不足以推导任意模型的速度、成本或部署规模。
NVFP4 与专家并行分别释放什么空间
NVFP4 用 4 位 E2M1 数值、每 16 个值共享的 FP8 E4M3 缩放因子,以及张量级 FP32 缩放保存数据。来源报告,权重占用相对 FP16、FP8 的压缩比分别约为 3.5 倍、1.8 倍,KV 缓存相对 FP8 最多减少 50%。缩放元数据会占空间,因此不能直接按位宽推算全部节省;精度表现仍需按模型和任务核验。NVIDIA Technical Blog
TensorRT-LLM 的宽专家并行把 MoE 专家分散到至少八张 GPU,降低每卡专家权重份额,为缓存和更大批次留出空间。作者推论,只有专家能汇集足够 token,权重重复利用才会明显增加算术强度;每层分发与汇聚产生的 all-to-all 通信,也可能吞掉收益。专家负载均衡器可以重新分配冷热专家,却无法消除网络代价。所谓内存池应理解为协同放置与访问,远端 HBM 仍有自身的延迟和带宽约束。
Dynamo 把缓存复用变成调度问题
Dynamo 负责让已算出的 KV 缓存继续产生价值。来源描述的路由器同时看前缀命中与工作节点负载;预填充和解码可分离到不同 GPU 池;KV Cache Runner 跟踪 GPU、固定页主机内存和存储中的缓存块,通过 NIXL 支持传输。推理引擎仍管理 GPU 内存和本地主机卸载。缓存容量扩展还需要服务层协调,异步搬运本身并不保证请求恢复时没有等待。NVIDIA Technical Blog
本文的调度判断是,复用成立的条件应写成总时间比较:查找、排队、传输及必要转换在关键路径上的耗时,要低于重新预填充同一段前缀的耗时。命中率提高也可能伴随热点节点排队。跨实例复用还需核验模型权重版本、输入 token 与位置语义,以及缓存格式的兼容性;相同文档文字不保证相同 KV 状态。共享缓存保存的是计算中间结果,不能直接当作代理之间可自由交换的语义记忆。
Vera 与 CMX 为暂停的上下文安排去处
工具调用会让会话暂停生成,仍留在 HBM 的 KV 缓存此时占用容量。来源称,Vera 每颗 CPU 可提供最高 1.5 TB LPDDR5X,并通过 1.8 TB/s 的 NVLink-C2C 连接 Rubin,使暂停会话的上下文可暂存主机内存。这里的带宽是互连规格,实际恢复速度还取决于访问和调度。更快 CPU 对本地计算型工具可能有益;远端 API 等待占主导时,不能假定工具间隙会同步缩短。
更远一层是 CMX:来源将其描述为计算资源组共享、通过以太网连接的闪存 G3.5 层,由 BlueField-4 STX、Spectrum-X、DOCA Memos 与 Dynamo/NIXL 协同管理。它为跨节点复用提供空间,提前把缓存搬回 GPU 或主机内存则有望减少停顿。作者推论是,较长等待和较高复用概率更可能覆盖搬运开销;很快返回的会话,或几乎不会复用的前缀,未必值得经过这些层级。NVIDIA Technical Blog
验证要覆盖暂停、恢复与完整功耗
具体看一个代码代理:读入仓库内容,生成工具调用,等待测试,再带着结果继续生成。容量紧张时,可复用前缀可保留在较低层级,暂停会话腾出 HBM,恢复时再取回。待验证的假设是,长前缀、高复用和足够长的工具间隙会放大收益;短请求、低复用或链路拥塞可能使迁移不划算。为云端代理设计评估时,应回放真实的暂停与恢复过程,持续解码测试不足以覆盖这种压力。
验证时应固定模型、请求轨迹、上下文分布和交互延迟目标,在平台支持范围内逐项启停量化、专家并行、缓存路由与分层策略,再观察组合效果。同时记录任务正确性、首 token 延迟、会话恢复延迟、队列尾延迟、命中率和迁移字节数。跨代比较应采用一致的工作负载与功耗边界,纳入 CPU、网络和存储。来源另引的存储吞吐及首 token 测试采用其他硬件或软件栈,不能充当完整 Rubin 系统的独立复测;各项最高增益也不能直接相乘。
实践清单
- 固定模型、输入 token、工具等待轨迹与交互延迟目标,再比较平台支持的不同配置。
- 同时记录任务正确性、首 token 与会话恢复延迟、缓存命中和系统功耗;峰值互连带宽仅作规格参考。
- 核验 KV 兼容条件,将缓存恢复总时间与同一段前缀的重新预填充时间比较。
参考来源
Token4AI 独立技术分析。文中厂商能力与本站模型可用性分别核验;实际接入范围与价格请以控制台为准。