OpenAI SemiAnalysis 视角：Vera Rubin NVL72 超越 GB200，但 TCO 优势更为有限

NVIDIA 的 Vera Rubin NVL72 公布了首批实测芯片结果，声称在相同交互性下，每兆瓦吞吐量达到 GB200 NVL72 的十倍。OpenAI SemiAnalysis 之间的关联来自 Triton：其对 Rubin 的支持有助于让这一架构进入被广泛使用的 AI 软件生态。

这个 headline 很有吸引力，但其比较对象是 2025 年初的 GB200 软件基线。SemiAnalysis 发现，与 2026 年 7 月的 Blackwell 结果相比，Rubin 的优势更小，尽管它在所测试的整个交互性范围内仍保持领先。

这一区别界定了真正的竞争。Rubin 不只是替代旧款 GPU 的更快 GPU，而是一套机架级系统，旨在当模型规模、内存流量和 token 需求同时上升时，持续提供响应迅速的推理能力。

这一结果给 GB200 运营商、竞争性加速器厂商以及维护自定义内核的开发者带来压力。同时，它也留下了一个重要的验证缺口：初始测试使用的是工程样品机架、较旧的推理模型和单轮工作负载。

Rubin 的首个结果改变了 NVL72 的比较方式

Rubin 的早期领先看来真实存在，但十倍这一数字代表的是最佳情形下的比较，而非普适的性能比率。

CoreWeave 于 2026 年 7 月 21 日发布了首个实测 Vera Rubin NVL72 芯片基准测试。其工程师在 Rubin 和 GB200 NVL72 上运行 DeepSeek R1，并启用了相同的主要推理优化。

测试衡量了相对于交互性的每兆瓦输出 token 吞吐量；交互性以每位用户每秒 token 数表示。这一点很重要，因为推理服务必须在总容量与可接受的响应速度之间取得平衡。

在相同交互性下，实测芯片结果显示，每兆瓦输出 token 吞吐量最高可提升十倍。该比较采用了 2025 年的 GB200 NVL72 基线。

CoreWeave 表示，两套系统均采用 NVFP4 精度、投机解码、广泛的专家并行，以及预填充与解码解耦。TensorRT-LLM 和 NVIDIA Dynamo 提供服务软件。

NVFP4 是 NVIDIA 的四位数值格式，用于降低模型存储和计算需求。投机解码会在最终验证前生成候选 token，当预测成功时可提高输出速度。

解耦式服务将预填充和解码分配给不同的 GPU 组。预填充负责处理提示词，而解码则逐个 token 地生成回答。

这些优化很关键，因为基准测试结果往往衡量的软件质量与芯片性能同样重要。较旧的内核、调度器或并行化方案，可能让 GPU 的很大一部分容量处于闲置状态。

SemiAnalysis 调整了自己的 InferenceX 数据，以匹配 CoreWeave 的统计口径。原始基准测试计入了预填充和解码 GPU 的功耗，却只报告输出 token。

与 2026 年 7 月的 GB300 NVL72 结果相比，Rubin 在每位用户每秒 100 token 以内实现了近两倍吞吐量。在每秒约 200 token 时，其优势扩大至约四倍。

在每秒 300 token 时，报告的比率达到 5.4 倍。不过，SemiAnalysis 指出，GB300 当时正运行在其可行性能曲线的边缘。

GB200 在测试配置下无法达到这一交互性水平。Rubin 则持续到每秒 350 token，此时每兆瓦每秒可产出 70,703 个输出 token。

这并不否定 CoreWeave 的主张。早期 Rubin 显然比实测的 Blackwell 系统能够维持更高的交互性。但这改变了采购方应当从 headline 中得出的结论。

十倍这一数字描述的是某一种工作负载、运行点、软件基线和统计方法。它并不意味着每个 Rubin 部署都会立刻替代十个 GB200 机架。

更有力的结论更为有限，也更有实用价值。随着服务转向更小的批次和更快的单用户响应，Rubin 仍能维持效率；而此时 Blackwell 的吞吐量会急剧下降。

这种表现会直接影响编程智能体、搜索系统和安全应用。这些服务会产生大量顺序模型调用，因此很难通过大批次来掩盖延迟。

为什么每兆瓦性能如今比峰值 FLOPS 更重要

电力容量已成为现实上限，因此每兆瓦可用 token 数可能比理论算力吞吐量更重要。

加速器的峰值 FLOPS 指标衡量其在特定条件下所能达到的最大浮点运算次数。它并不能说明一整套机架如何高效地为推理模型提供服务。

推理需要在内存与计算单元之间移动权重、激活值和 KV-cache 数据。KV cache 会存储早期 token 的注意力信息，避免模型重新计算整个序列。

更长的上下文会扩大该缓存。混合专家模型还会在专门的子网络之间发送 token，从而在 GPU 之间产生通信流量。

Rubin 以完整 NVL72 系统的形式应对这些约束。该机架集成 72 块 Rubin GPU、36 颗 Vera CPU、ConnectX-9 网络、BlueField-4 处理器和 NVLink 6 交换机。

NVIDIA 表示，整套机架拥有 20.7 TB 的 HBM4 内存，并标称 260 TB/s 的 NVLink 6 交换机总带宽。

每块 GPU 可获得 3.6 TB/s 的全互连纵向扩展带宽。纵向扩展网络将加速器连接在一个大型计算域内，使其能够像统一设备一样协同工作。

因此，Rubin 从多个层面提升推理效率。更快的张量运算负责矩阵计算，HBM4 提供权重，NVLink 则在专家之间移动 token。

Vera CPU 管理数据移动和 CPU 密集型智能体任务，其中可包括工具调用、代码编译、编排和沙箱执行。

NVIDIA 的 NVL72 specifications宣称，机架级 NVFP4 推理性能达到 3,600 petaflops。该公司还声称，与 GB200 NVL72 相比，token 成本可降至十分之一。

这些数字仍是取决于工作负载的厂商主张。不过，机架架构解释了为何 Rubin 的优势会随着交互性提升而扩大。

大批次有助于 GPU 保持繁忙，因为许多用户可共享每次权重加载。快速交互式服务会减少批处理机会，从而增加对内存带宽和调度能力的压力。

Rubin 每块 GPU 22 TB/s 的 HBM4 带宽，使其在这些条件下拥有更大的余量。SemiAnalysis 估计，这相当于 Blackwell Ultra 全局内存带宽的 2.8 倍。

更高带宽并不会自动降低内存延迟。它能够每秒移动更多数据，但单次访问仍可能耗费相近的时间。

因此，Rubin 在高交互性下更大的优势，反映的是多种机制共同作用。任何单一的峰值规格都无法完整解释这一点。

功耗指标还包括基础设施选择。冷却设备、网络、主机处理器、存储和转换损耗，都会消耗 GPU 封装之外的电力。

NVIDIA 为 Rubin 设计了入口温度为 45 摄氏度的液冷方案。在兼容设施中，这一温度支持无需传统冷水机的干冷却。

该公司表示，其闭环方案可降低用水量和冷却开销。这些收益取决于设施设计，不应假定适用于所有现有数据中心。

SemiAnalysis 对液冷系统采用了相同的电源使用效率假设。这一保守选择避免 Rubin 的设施设计夸大芯片比较结果。

结果仍然有利于 Rubin。更重要的是，它表明机架架构已与加速器经济性密不可分。

采购方不能仅通过比较 GPU FLOPS 来评估 Rubin。相关单位应是能够在固定功耗上限内提供所需响应速度的服务系统。

OpenAI SemiAnalysis 的软件支持让 Rubin 获得更早的起跑线

Rubin 可以复用重要的 Blackwell 内核，在开发者开始进行架构专属调优前缩短部署工作。

OpenAI SemiAnalysis 的切入点并非 OpenAI 与硬件厂商的合作关系，而是 Rubin 支持已出现在 OpenAI Triton、PyTorch、vLLM、CUDA 和其他公开项目中。

Triton 是一种开源语言和编译器，可使用类似 Python 的语法编写 GPU 内核。内核是在 GPU 上执行计算操作的专用程序。

OpenAI 推出 Triton programming，旨在让高性能内核开发比底层 CUDA 代码更易于使用。PyTorch 编译器和推理项目如今依赖 Triton 生成的内核来完成许多操作。

NVIDIA 已发布支持 Rubin 的 CUDA 13.4 开发者预览版，并更新了 PTX 指令。PTX 是 NVIDIA 用于描述 GPU 操作的中间指令语言。

CUDA preview让开发者能够检查 Rubin 的新功能并开始移植软件。NVIDIA 警告称，该预览版为预发布软件，不适合用于生产基准测试。

SemiAnalysis 报告称，Rubin 相关变更也已进入 PyTorch、vLLM 和 OpenAI Triton 代码库。这种公开可见性让框架开发者能够在大规模云端可用之前进行适配。

Rubin 的流式多处理器采用 SM107 目标。更重要的是，它能够运行 CUTLASS、DeepGEMM 和 FlashMLA 等库中的主要 Blackwell SM100 系列内核。

Blackwell 并未从 Hopper 获得同样的便利。其张量核心编程模型需要进行大量内核重写，开发者才能接近硬件潜力。

Rubin 保留了更多这类投入。团队可以从功能完备的 Blackwell 内核开始，更早部署，然后再优化最有价值的操作。

兼容性不应与最高性能混为一谈。SemiAnalysis 表示，要达到实际速度上限，仍需进行架构专属调优。

Rubin 将共享内存从 Blackwell 的 228 KiB 增加至可选的 328 KiB 模式。Tensor Memory 也增至 256 KiB，为内核中的累加器和缩放信息提供更多空间。

该架构增加了内联 Tensor Memory Accelerator 描述符更新。TMA 是一种硬件机制，可移动多维数据，而无需普通执行单元管理每一次传输。

在混合专家层中，每位专家拥有独立的权重矩阵。当活跃专家发生变化时，Blackwell 可能需要重写并同步描述符。

Rubin 可以通过传输指令传入新地址。这样，一个描述符便可服务多个专家，无需在中间重写内存。

这降低了低批次解码期间的调度开销。它也说明，真正的推理增益来自细微的数据移动改进，而不仅仅是更大的矩阵引擎。

根据 NVIDIA 的架构披露，Rubin 的 FP8 和 FP4 Tensor Core 吞吐量相比 Blackwell 翻倍。它还在存在依赖关系的线程块之间加入了更精细的同步机制。

这些功能有助于开发者构建更大的融合内核。融合会将多个操作合并，减少重复启动以及不必要的内存数据移动。

软件优势并不止于发布就绪。兼容工具让更多开发者能够检视 Rubin 的行为、报告缺陷，并优化常见模型架构。

然而，公开支持仍处于早期阶段。CUDA 的预览限制表明，代码可用并不等同于拥有成熟的生产级软件栈。

PyTorch 和 vLLM 的集成可以实现功能可用，但仍有大量优化尚未完成。运营方应区分“能在 Rubin 上运行”和“能高效利用 Rubin”。

历史规律支持这种谨慎态度。随着内核、调度器和分布式服务方案逐步成熟，GB200 的推理性能在其首年内有所提升。

Rubin 起步时拥有更强的兼容性基础。但它最终能否领先，仍取决于框架维护者能否将新指令转化为可靠的、模型层面的收益。

3 位 LUT Tensor Core 瞄准内存瓶颈

Rubin 最有趣的推理特性是在 Tensor Core 内部压缩权重，无需单独的反量化步骤即可降低内存流量。

Rubin 为矩阵乘加指令新增了查找表 B 操作数模式。SemiAnalysis 将其描述为 NVIDIA 首种采用内部非均匀码本的 Tensor Core 格式。

在这一模式下，每个存储权重都会变成一个三位索引。该索引从一个由权重块共享的查找表中，选择八个八位 E4M3 值之一。

Tensor Core 会在矩阵运算内部重建所选值。软件无需在乘法前生成单独的解压缩权重矩阵。

计入共享码本后，SemiAnalysis 计算得出，每个权重的存储占用为 3.125 位。该码本包含 64 位，由 512 个权重共享。

这一设计不同于 NVFP4 和 MXFP 格式。后两者采用块缩放，对一组低精度数值施加统一缩放系数。

查找表可以非均匀地设置其八个数值。它可以将更多条目集中在密集的权重簇附近，也可以表示不对称的正负分布。

这种灵活性可能比相近位宽下的均匀舍入保留更多信息，但并不保证模型质量更好。

一个码本覆盖 512 个权重，而 NVFP4 可以在更小的分组内调整缩放系数。结果将取决于校准数据、码本拟合以及模型敏感性。

一些层可能还需要更高精度。激进的量化方案可以节省内存，却可能损害推理准确性或导致输出不稳定。

这一硬件机制仍然直击推理的核心限制。在低批量解码期间，GPU 经常需要等待模型权重从 HBM 传入。

减小每个权重的存储尺寸，可以让内存每秒传输更多权重，也能降低在系统中搬运这些比特所消耗的能量。

SemiAnalysis 使用一个假设的 2.8 万亿参数模型来说明容量影响。其计算显示，采用 Rubin 格式时，原始权重负载约为 1.09 TB。

该比较未计入 KV 缓存、激活值、副本以及服务开销。因此，它展示的是权重存储，而不是总体部署内存。

按照每块 Rubin GPU 配备 288 GB HBM4 计算，压缩后的权重大约需要四个封装单元。示例中的另一种低精度表示则需要约六个。

参与的 GPU 数量更少，可以减少通信和副本开销，也能为更长上下文、更大批量或 KV 缓存留出更多内存。

不过，LUT 模式存在实现限制。SemiAnalysis 指出，它不能转置 B 矩阵，这限制了能够直接使用它的运算类型。

公开基准测试似乎也并未使用这一特性。因此，Rubin 的初步领先不能归功于三位查找表推理。

这既令人鼓舞，也存在不确定性。Rubin 具备未来软件可利用的额外芯片能力，但其准确性和生产价值仍未得到验证。

NVIDIA 还加入了运行时 2:4 激活稀疏性。这种方法在每四个值中保留两个，并在受支持的运算中跳过另外两个。

与早期的权重稀疏性不同，运行时激活稀疏性不要求永久剪枝并重新训练模型。硬件可以在模型运行时压缩中间值。

然而，NVIDIA 尚未发布关于在后续运算前丢弃一半选定激活值的准确性证据。CoreWeave 的结果似乎也没有使用这一特性。

这些尚未利用的能力构成了 Rubin 的优化空间。它们不应作为确定的未来收益纳入当前 TCO 计算。

买方应在吞吐量之外要求模型层面的质量测试。只有在生成模型达到相同准确性和可靠性目标时，更低位宽格式才会降低服务成本。

Rubin 赢得 TCO 测试，但基线决定优势幅度

尽管拥有成本更高，Rubin 的每个交付 token 成本似乎更低；但与完全调优的 Blackwell 系统相比，其优势会缩小。

总拥有成本结合了硬件、电力、设施、网络、维护和运营支出。它提供的视角比单独的每瓦性能更全面。

SemiAnalysis 将其运营商拥有成本模型应用于归一化输出吞吐量。分析避开了云端租用价格，因为其中可能包含稀缺性、合同条款和服务商利润。

分析发现，在所有测得的交互性水平下，相对于 2026 年 7 月的 GB200 和 GB300 结果，Rubin 的每个输出 token 成本更低。响应速度越高，优势越明显。

相对于当前的 GB200 基线，Rubin 在每用户每秒 100 token 以内的成本约低 1.5 倍。在每秒 200 至 250 token 左右，其相对优势达到约三倍。

将 Rubin 与 2025 年 GB200 软件基线对比，得到的结果更大。在每用户每秒约 150 token 时，Rubin 的成本优势峰值接近八倍。

这一旧基线解释了 NVIDIA 的营销标题与实际采购比较之间的大部分差异。经过调优的 2026 年 GB200 比其早期部署状态更强大。

SemiAnalysis 还估计，Rubin 的单 GPU 拥有成本高于 GB200 和 GB300。它的吞吐量增益必须抵消更高的系统负担。

在所考察的工作负载中，它确实做到了，尤其是在要求苛刻的交互性目标下。响应速度较慢时，经济性就没那么具有决定性，因为 Blackwell 可以有效采用更大批量。

这使采购决策取决于具体工作负载。

对于高交互性推理

• Rubin 能够维持测试配置下 GB200 无法达到的响应速度。

• 随着批量规模缩小，其内存带宽和机架互连变得更有价值。

• 编程智能体和实时搜索服务符合这一特征。

对于以吞吐量为重点的推理

• 成熟的 Blackwell 软件可以缩小 Rubin 的相对收益。

• 既有基础设施和预留容量可能比理论效率优势更重要。

• 迁移成本应纳入运营商的 TCO 模型。

对于长上下文模型

• Rubin 更大的内存池为权重和 KV 缓存提供了更多空间。

• 初始单轮基准测试并未直接衡量这一优势。

• 多轮智能体测试将提供更具代表性的信号。

该基准测试采用了 DeepSeek R1 671B，输入为 8,000 token，输出为 1,000 token。该模型和序列形态并不代表所有 2026 年的生产工作负载。

SemiAnalysis 认为，较新的多万亿参数模型应当更受益于 Rubin 的容量和带宽。在比较结果出炉之前，这一说法仍只是技术预期。

CoreWeave 还在一套没有横向扩展互连的 Dell 工程样品机架上进行了测试。横向扩展互连用于连接多个机架，而内部 NVLink 背板提供纵向扩展连接。

成功测试支持了该机架内部的专家并行运行能力，但并未证明其在大规模多机架部署中的性能、可靠性或效率。

竞争也带来另一项约束。AMD 的 MI455X 每个加速器提供 432 GB HBM4，而 Rubin 为 288 GB。

AMD 的 Helios 设计在 72 个加速器上提供 31.1 TB 内存。Rubin 的 NVL72 机架则在 72 个加速器上提供 20.7 TB。

AMD 的容量优势可能对大模型和长上下文至关重要。NVIDIA 则凭借成熟的软件生态、NVLink 互连以及更早的机架级运营经验应对竞争。

Google 的 TPU 系统提供了另一条集成路径。它们将定制加速器、互连、编译器和云服务整合在同一运营商体系下。

因此，TCO 竞争并不局限于 Rubin 与 GB200。买方必须在相同模型、准确性目标、延迟、上下文长度和功耗核算条件下，比较完整的服务方案。

Rubin 目前拥有最强的公开早期结果。但现有证据尚不足以确立一个适用于生产推理的固定成本比率。

下一轮基准测试必须证明什么

三个信号将决定 Rubin 的早期工程成果能否转化为持久的生产优势。

第一个信号是 NVIDIA 承诺在 2026 年第三季度提交的 InferenceX 成绩。SemiAnalysis 表示，NVIDIA 已承诺通过该基准提供可独立验证的 Rubin 数据。

一份可信的提交应在有据可查的服务配置下测试当前模型，并同时报告交互性、输出吞吐量、功耗边界和优化设置。

与 2026 年 7 月的 GB200 和 GB300 系统进行对比，将加强当前比较。若重用较旧的 GB200 基线，则核心的方法论疑虑仍未解决。

第二个信号是多轮智能体工作负载。单轮推理无法复现智能体会话中反复的工具调用、不断增长的 KV 缓存，以及变化的提示词长度。

SemiAnalysis 正与基础设施和开源服务贡献者开发 AgentX 场景。其 Rubin 分析 将长上下文智能体工作视为可能的架构优势。

当内存容量和带宽占据主导时，Rubin 应当扩大领先优势。如果优势保持不变或缩小，机架在长上下文场景下的说服力就会减弱。

第三个信号是成熟的公开软件。开发者应关注 CUDA、PyTorch、vLLM、Triton、TensorRT-LLM 和 Dynamo 的生产版本。

功能兼容性会先于优化性能到来。决定性证据将来自稳定的内核，它们能够利用 Rubin 特有的内存移动、同步和低精度功能。

三位 LUT 推理尤其值得密切审视。公开测试必须报告准确性、校准方法、受影响的层，以及相对于 NVFP4 的端到端吞吐量。

激活稀疏性也需要同样的检验。若质量损失迫使运营商使用更大的模型，或重复失败请求，更高的算术速率意义不大。

Feynman 还带来了一个更长期的软件问题。NVIDIA 已将其下一代架构确定为 SM140，而 Rubin 使用 SM107。

SemiAnalysis 预计，Feynman 将需要更大范围的内核重写，类似于困难的 Hopper 到 Blackwell 过渡。因此，Rubin 的兼容性优势可能只能维持一代。

对于基础设施买方而言，眼下的决定并不是 Rubin 的规格是否更好——它确实更好。

更难的问题在于，某个特定工作负载是否能从中获益到足以证明部署变更的合理性。运营商需要基于自身模型、上下文分布、响应目标和现有供电能力进行测试。

对于开发者而言，现在有价值的行动是跟踪内核支持与基准测试方案。早期性能分析可以揭示应用究竟受限于计算、HBM 流量、网络还是调度。

对于 AI 产品团队而言，应关注用户层面的实际结果。更快的 token 只有在能够缩短任务完成时间、提升智能体可靠性，或支持更多客户同时使用时才有意义。

OpenAI 与 SemiAnalysis 的讨论最终连接了三个层面：开放的内核工具、独立的性能分析，以及 NVIDIA 的机架级硬件。但这些层面都无法单独验证 Rubin 的表现。

Rubin 能否在现代模型、多轮智能体和可由独立方复现的测试中保持优势？决定下一步推理基础设施投入的，应当是这些证据，而非某一个醒目的倍数标题。