NVIDIA Vera Rubin NVL72首秀MLPerf推理
NVIDIA Vera Rubin NVL72 Delivers Leading Performance in MLPerf Inference v6.1 Debut
NVIDIA Vera Rubin NVL72在MLPerf Inference v6.1首次预览提交中,吞吐量最高达GB300 NVL72的3.7倍;GB300 NVL72在288 GPU四机架配置下实现99%扩展效率,软件优化带来最高1.6倍性能提升。
深度解读
NVIDIA用一份“预览提交”把下一代机架级平台Vera Rubin NVL72推上前台,在MLPerf Inference v6.1中相对GB300 NVL72最高打出3.7倍吞吐量,同时GB300 NVL72以288 GPU跨四机架实现99%的扩展效率,加上软件优化在v6.0到v6.1之间带来最高1.6倍性能提升——这三条信息合起来,才是这次发布真正的重点。
3.7倍不是一颗芯片的胜利,是整机架重新设计的胜利
先看Vera Rubin NVL72的具体成绩单。它首次亮相选了两个最吃力的基准:DeepSeek-R1和Qwen3-VL。在Qwen3-VL上,跨offline、server、interactive三种场景,Vera Rubin NVL72比GB300 NVL72最高快3.7倍,软件栈用的是vLLM加NVIDIA开源的Dynamo推理框架;在DeepSeek-R1上,用TensorRT-LLM库,吞吐量最高是GB300 NVL72的2.5倍。
注意这里有个容易被忽略的措辞:这是preview submission,不是正式提交。NVIDIA自己在文中也承认,这些是“early results”,后续还会随软件优化继续提升。换句话说,3.7倍是这一代平台在软件尚未完全成熟时交出的下限,而不是上限。
为什么能快这么多?NVIDIA给出的解释是full-stack codesign(全栈协同设计)。拆开看有三层:Tensor Cores和Transformer Engine同时加速推理的prefill和decode两个阶段;NVFP4精度把模型权重、attention和KV cache的内存占用一起压下来,在几乎不损失输出质量的前提下换吞吐;disaggregated serving把prefill和decode物理拆开,再配合面向mixture-of-experts层的大规模expert parallelism,让DeepSeek-R1、Qwen3-VL这类MoE模型在机架尺度上跑得更满。
Vera Rubin NVL72 delivers up to 3.7x higher throughput than GB300 NVL72 on Qwen3-VL across offline, server and interactive scenarios.
支撑这些技术动作的底座是NVL72 scale-up domain:第六代NVLink加NVLink Switch,包速率比通用以太网高10倍,延迟低3倍。这个数字的意义在于,disaggregated serving和expert parallelism这类技术只有在互连足够快、足够低延迟时才能真正兑现收益,否则拆得越细、通信开销越大。所以3.7倍不是某一颗GPU的功劳,而是芯片、互连、精度格式、服务架构一起改的结果。
99%扩展效率:比峰值性能更值钱的数字
如果说3.7倍是吸引眼球的头条,那99%这个数字才是给采购决策者看的。NVIDIA的DeepSeek-R1提交从单机架GB300 NVL72(72 GPU)扩到四机架(288 GPU),在offline场景下实现了99% scaling efficiency,吞吐量几乎随硬件线性增长。
这个数字为什么关键?因为加GPU从来不自动等于加吞吐。文中说得很直白:如果GPU数量接近翻倍、吞吐量却只有个位数百分比提升,基础设施成本就会远远跑在性能回报前面。现实里很多集群的扩展曲线在跨机架之后就开始弯折,瓶颈往往出在机架间网络、请求编排、KV cache跨节点传输这些地方。
NVIDIA把99%归因于三件事的组合:机架内高带宽低延迟的scale-up互连、机架间的高带宽网络、跨节点的请求编排效率。这三者缺一个,扩展效率就会掉。对正在规划大规模推理集群的团队来说,这个数字的参考价值甚至高于单机架峰值——因为它决定了你买到第1000张卡时,前面999张卡的投资还能不能继续产生线性回报。
同一份提交里还有一个值得单独拎出来的数据:GB300 NVL72在WAN 2.2文生视频基准上达到每秒0.65个720p视频、每个视频5.7秒,相对单节点吞吐量高9倍、延迟低7.5倍。视频生成是典型的计算密集加显存密集负载,这个结果说明机架级扩展的收益不局限于语言模型。
软件优化1.6倍:硬件之外的第二条增长曲线
这次发布里最容易被低估的是软件那条线。GB300 NVL72在Qwen3-VL上的性能,v6.1比v6.0最高提升1.6倍——硬件没换,只是软件变了。NVIDIA列出的优化手段包括:更低的KV cache精度、更多kernel fusion、更好的kernel实现、以及vLLM加Dynamo的disaggregated serving。
更值得注意的是,NVIDIA明确说优化在v6.1提交截止之后仍在继续,GPT-OSS-120B和DLRMv3上的提交后结果(尚未经MLCommons验证)显示出进一步提升。这句话的潜台词是:你现在看到的1.6倍和3.7倍,都不是这一代平台的终态。
Software optimizations in NVIDIA’s MLPerf Inference v6.1 submissions delivered up to 1.6x higher performance over v6.0.
对从业者来说,这意味着推理经济学里的“折旧”逻辑在变。传统硬件一旦部署,性能曲线就基本固定;而如果软件每季度能再挤出两位数百分比,同一批GPU的有效寿命和单位token成本会持续改善。这也是NVIDIA反复强调platform fungibility(平台通用性)的原因——同一套基础设施跑训练也跑推理、跑推荐也跑推理型agent、跑语言也跑视频,利用率越高,软件优化的复利效应越大。
Agentic推理正在改写基准本身
这次发布里还埋了一个趋势信号:AI agents。NVIDIA提到,能推理、规划、多步行动的agent正在改变推理性能的衡量方式。在SemiAnalysis AgentX这类为agent场景设计的基准上,Vera Rubin NVL72预览测试相对GB300 NVL72达到30倍性能。
30倍这个数字和3.7倍放在一起看,说明agentic负载对硬件代际差异的敏感度远高于传统吞吐基准。原因不难推:agent工作流是多步的、带状态的、prefill和decode交替频繁,对互连延迟、KV cache管理、调度效率的要求和单次前向推理完全不是一个量级。
NVIDIA同时预告了即将推出的MLPerf Endpoints基准,说要给agentic推理负载带来标准化测量,覆盖传统吞吐基准捕捉不到的部分。这句话的行业含义是:现有的MLPerf Inference基准体系正在被agent负载倒逼扩容,未来评估一套推理系统好不好,可能不再只看tokens/s,而要看多步任务的完成效率。
从Jetson AGX Thor到19家伙伴:全栈铺开的意图
这次提交的覆盖面也值得拆开看。除了Grace Blackwell和Vera Rubin NVL72,NVIDIA还提交了Jetson AGX Thor的结果,用TensorRT Edge-LLM跑新引入的Edge-Agentic基准和Qwen3.6-27B。从边缘设备到最大规模AI工厂,NVIDIA想证明的是同一套软件栈和架构节奏能覆盖全场景。
伙伴生态方面,19家合作伙伴参与提交,其中8家基于多节点Blackwell NVL72系统,名单包括ASUS、Azure、Cisco、CoreWeave、Crusoe、Dell Technologies、Fujitsu、Giga Computing、HPE、Inventec、Lambda、MiTAC Computing、Nebius、Oracle Cloud Infrastructure、Quanta Cloud Technology、Red Hat、ScitiX、Supermicro、Wiwynn。Nebius单独提交了Vera Rubin NVL72预览结果并展示了不错的表现。
这份名单的信息量在于:Vera Rubin NVL72不是NVIDIA自产自销的展示品,云厂商和OEM已经在同步跟进。对采购方来说,这意味着下一代平台的供给渠道从第一天起就是多源的,不会被单一供应商卡住。
所以这对行业意味着什么
第一,推理经济学的主战场正在从“单卡峰值”转向“机架级扩展效率加软件迭代速度”。99%扩展效率和1.6倍软件提升这两个数字,比3.7倍更值得写进采购评估表。
第二,NVFP4、disaggregated serving、大规模expert parallelism这些技术组合,正在成为MoE模型推理的默认打法。谁的服务栈不支持这些,谁的单位token成本就会在下一代模型上被拉开差距。
第三,agentic负载的30倍差距和MLPerf Endpoints的即将到来,预示着基准体系要换挡。今天用tokens/s做的容量规划,明天可能要用多步任务完成率来重算。
第四,NVIDIA的年度架构节奏加持续软件优化,实际上在把“买硬件”变成“买一条持续上升的性能曲线”。对基础设施决策者来说,评估供应商时问的问题应该从“这一代快多少”变成“下一代软件还能再挤出多少”。
