CoreWeave 上线多机架 Vera Rubin 集群，MLPerf v6.1 证实 3.7 倍性能提升
NVLink 6 纵向扩展遇上 Spectrum-X 横向扩展；新的存储功能瞄准训练检查点的痛点
CoreWeave 于 9 月 16 日宣布，已在其云平台上启用多机架的英伟达 Vera Rubin NVL72 配置，把上百块 Rubin GPU 连接成一个横向扩展集群 —— 它是第一家做到这一点的 AI 云服务商。这一消息与 MLCommons 发布 MLPerf Inference v6.1 结果恰在同一个上午，后者首次独立证实，在多模态推理工作负载上，Vera Rubin NVL72 的吞吐量最高可达英伟达上一代 GB300 NVL72 的 3.7 倍。两件事合在一起，标志着 Vera Rubin 从一个令人兴奋的硬件项目，转变为拥有第三方性能验证的生产级集群平台。
CoreWeave 还为其 AI 对象存储服务推出了两项新功能：跨区域写入加速 —— 让训练检查点以本地 NVMe 的延迟落盘，同时异步复制到第二个区域；以及一个不收取取回费、删除费和出口流量费的 Archive 归档存储层。
从单机架到集群：横向扩展这一里程碑究竟改变了什么
单个英伟达 Vera Rubin NVL72 机架本身就是一件了不起的硬件：72 块 Rubin GPU 和 36 颗 Vera CPU 通过第六代 NVLink 互连，英伟达公布的规格显示，每个机架拥有 20.7 TB 的 HBM4 GPU 显存、1400 TB/s 的内存带宽，以及 3600 PFLOPS 的稀疏 NVFP4 推理算力。机架采用无线缆中板设计，72 块 GPU 之间全部以完整的 NVLink 带宽通信，中间没有任何物理线缆 —— 与前几代相比，这在可靠性上是一大优势。
但一个机架终究只是一个机架。对于大规模前沿模型训练来说，真正要紧的任务往往同时横跨数百乃至数千块 GPU。当多步智能体工作负载在一个会话里调用模型几十甚至上百次 —— 每次调用都建立在之前调用的上下文之上 —— 底层基础设施就必须让每一块 GPU 保持同步、持续获得数据，并以足够的带宽与其他每一块 GPU 相连，才能不必等待地执行分布式集合通信操作。
在这次宣布之前，Vera Rubin 在 CoreWeave 上是一座座彼此孤立的 72 GPU 孤岛。一次所需算力超过单个机架的模型训练任务，会遇到拖慢一切分布式任务的机架间网络瓶颈。9 月 16 日宣布的多机架配置跨越了这道边界，把上百块 Rubin GPU 作为一个统一的资源池提供给运行中的工作负载。
「借助多机架 Vera Rubin，我们正把上百块 Rubin GPU 连接成一个横向扩展集群。」CoreWeave 产品与工程执行副总裁 Chen Goldberg 在公司的新闻稿中说，「对于构建智能体 AI 的客户来说，这意味着随着模型和智能体不断学习和改进，他们能获得更大的规模、更快的迭代和更高的生产力。」
多机架架构内部：NVLink 6、Spectrum-X 与慢节点问题
构建多机架集群的工程难点，并不只是把机架插在一起。在每个 NVL72 机架内部，NVLink 6 提供纵向扩展网络 —— 一种全对全互连，让同一机架内的任意 GPU 都能以完整带宽、亚微秒级延迟向任意其他 GPU 发送数据。跨机架的通信路径则完全不同：英伟达 Spectrum-X 以太网通过基于融合以太网的 RDMA（RoCE）承载机架间流量，这种协议能提供低延迟、高吞吐的网络传输，而没有传统 TCP/IP 数据传输的开销。
CoreWeave 的实现为每块 Rubin GPU 配备两张英伟达 ConnectX-9 SuperNIC，使每块 GPU 获得 1.6 Tb/s 的横向扩展连接能力。网络被设计为两层、无阻塞、多轨、多平面的架构 —— 也就是说，任意两块 GPU 之间的流量在网络中有多条相互独立的路径，不会有任何单条链路成为拖累整个集群的瓶颈。公司表示，其目前的模块化设计每条轨道可支持约 12.8 万块 GPU，新增机架可以直接加入，无需重新设计网络。这个数字代表的是设计容量，而不是在这一规模上已经实现的部署。
纵向扩展与横向扩展之间的技术区别，关系到工作负载的实际表现。NVLink 6 负责单个模型张量并行执行中那种紧耦合、低延迟的通信 —— 一块 GPU 把激活矩阵发给相邻的 GPU。Spectrum-X 负责流水线并行和数据并行训练中粒度更粗的通信，那里的梯度更新需要跨越机架边界。在持续负载下让两条路径同时保持良好性能，正是多机架 AI 基础设施在实践中的难点所在。
分布式训练中一种特别重要的失效模式是 GPU 慢节点（straggler）：一块表现不佳的加速器，会迫使集合通信操作中的其他所有 GPU 在同步屏障处等待。一条性能下降的 PCIe 连接、一个处于临界状态的散热情况，或者一处固件不一致，都可能产生一块能通过诊断测试、但在负载下明显慢于同伴的 GPU —— 而在一个 1000 块 GPU 的训练任务中，一块慢 GPU 可能在每一次 AllReduce 步骤中拖住另外 999 块。
CoreWeave 的上线流程通过一条多阶段验证流水线来应对这个问题。每个节点在被纳入机架之前，都要经过单 GPU 诊断、PCIe 带宽测试和训练负载基准测试。单个节点通过之后，机架级集合通信基准会让全部 72 块 GPU 同时运行，并把结果与已知良好的性能区间比对。任何测试结果低于区间的机架都会进入故障排查，而不是投入生产。机架级验证之后，分布式工作负载会横跨多个机架运行，并强制流量经过后端网络，以验证连接起来的系统整体运行可靠 —— 而不只是一堆各自通过测试的机架。
冷却基础设施由 Valvey 管理，这是一套软件定义的液冷控制系统，CoreWeave 称它能让冷却液回路变得可编程、可观测。在 Vera Rubin 部署的功率密度下 —— 英伟达规定的液冷进水温度要求为 45°C —— 冷却已经不是一项可以被动监控的设施职能。Valvey 与 Racky（机架控制层）以及 Rack LifeCycle Controller（一个 Kubernetes 原生的编排器，把整个 NVL72 机架当作单个可编程实体来对待）一起，构成了 CoreWeave 用来让机架以已知状态上线、并保持在该状态的自动化技术栈。
延伸阅读：英伟达首次公布 Vera Rubin 实测数据：智能体工作负载能效提升 30 倍
MLPerf v6.1：Vera Rubin 拿到首个第三方成绩的这一天
把多机架的消息和 MLCommons 于 9 月 16 日发布的 MLPerf Inference v6.1 放在一起看，这个时间点的意义就更清楚了 —— Vera Rubin NVL72 在这一轮基准中首次亮相。
MLPerf 是由 MLCommons 运营的行业标准 AI 推理基准，MLCommons 是一个由研究人员和企业组成的联盟。Vera Rubin 结果所在的数据中心封闭组（Datacenter Closed division）使用标准化的模型和评估流程，在同一基础上比较各个系统。结果在发布前由 MLCommons 验证，这让它们具有与企业自报的基准数字不同的证据地位。
在其预览提交中，英伟达 Vera Rubin NVL72 在 Qwen3-VL-235B-A22B（一个 2350 亿参数的多模态混合专家模型）上，于离线、服务器和交互三种推理场景下的吞吐量最高可达 GB300 NVL72 的 3.7 倍 —— 数据来自英伟达关于 MLPerf v6.1 的博客。在部署广泛的 6710 亿参数推理模型 DeepSeek-R1-671B 上，Vera Rubin 的吞吐量达到 GB300 NVL72 的 2.5 倍。两项对比中的系统使用的都是同一代英伟达以太网网络。
这些基准测试采用了分离式服务 —— 把预填充阶段（处理输入提示词）和解码阶段（生成输出 token）分配到不同的 GPU 池中。这种分离让计算密集的预填充和受内存带宽限制的解码可以各自独立优化，在任一阶段都不必等待另一阶段的情况下提升整体系统吞吐量。专家并行把 token 在 MoE 专家层之间的路由分布到 Vera Rubin 的多块 GPU 上，NVFP4 精度则降低了模型权重、注意力张量和 KV 缓存的内存占用 —— 让系统能用更大的有效批大小而不触及内存上限。
MLPerf 基准有其重要局限。它们测量的是受控条件下的吞吐量，而不是生产负载模式下的每 token 成本或延迟波动。它们使用特定的模型版本和软件栈，随着软件更新，结果可能出现显著变化。英伟达自己的博客指出，提交之后的软件优化在 GPT-OSS-120B 和 DLRMv3 上带来了进一步的性能提升，但这些尚未经过 MLCommons 验证。CoreWeave 在 MLPerf v6.1 中提交了 Blackwell 和 Blackwell Ultra 的结果，并在若干模型类别上领先于其他云服务商，但它还没有以自己的名义单独提交 Vera Rubin 结果 —— 这一轮的 Vera Rubin 结果是由英伟达提交的。
CoreWeave 此前也在 2026 年 7 月测量并公布了自己在 DeepSeek R1 上对 Vera Rubin 与 GB200 NVL72 的对比，发现在相同交互性目标下，每兆瓦每秒生成的 token 数是后者的 10 倍。这一测量是公司自行报告的，未经 MLCommons 验证，而且是在开启了包括多 token 预测和分离式预填充在内的全部主要推理优化的条件下进行的。MLPerf v6.1 的数字经过独立验证，用于比较时更可靠 —— 不过它们使用的基线硬件不同（GB300 而非 GB200）。
AI 对象存储：智能体训练循环中被忽视的瓶颈
同一份公告还包括两项新的存储功能，针对的是 GPU 性能基准捕捉不到的一个问题：当训练任务需要跨区域读写数据时会发生什么。
智能体 AI 训练的特殊之处在于，它包含紧密耦合的循环：模型执行一步推理、产生输出，这个输出被评估或交给某个工具使用，结果又成为下一轮输入上下文的一部分。这个循环中的每一步都对延迟敏感 —— 不只是 GPU 延迟，还包括从存储中检索上下文、提交训练检查点，或把状态复制到备份区域所需的时间。在常规训练中，写检查点相对不那么频繁；而在强化学习循环和多步智能体后训练中，检查点的频率可能会大幅上升。
CoreWeave 的跨区域写入加速，针对的是训练算力在一个区域、而训练数据的权威副本在另一个区域的情况。过去，一个写检查点的任务要么等待写入在两个区域都完成（增加与区域间往返时间成正比的延迟），要么接受检查点只在一个区域可用的风险。新功能以 NVMe 延迟在本地写入 —— 训练任务立即可见 —— 同时由 CoreWeave 在后台把数据异步复制到第二个区域。由于应用看到的是单一存储桶，无需修改代码，而且无论写入来自哪个区域，访问控制策略都一致生效。
Archive 层针对的是另一个问题：有些数据被删掉，不是因为它没有价值，而是因为保留它要花钱。实际中，AI 团队经常删掉那些差一点就成功的训练运行的检查点、复现某个结果可能用得到的数据集版本，以及几个月后做对比或调试时可能需要的模型版本。Archive 的定价就是为了让保留这些数据在经济上可行：没有取回费，没有提前删除罚金，从该层内部读取也不收出口流量费。
Cohere 内部基础设施总监 Cécile Robert-Michon 在公告中表示，跨区域的数据集访问延迟此前曾限制了他们的训练排期：「我们的数据集分布在多个区域，我们不能让训练排期被跨区域检索的延迟牵着走。」CoreWeave 称，LOTA（本地对象传输加速器，在每个 Kubernetes 服务节点上以 NVMe 速度缓存数据）让 Cohere 工作负载的跨区域读取延迟降低到了原来的八分之一。这个数字是客户通过厂商公告报告的，未经独立审计，但与把远程存储读取转换为本地缓存读取的预期收益在方向上是一致的。
竞争格局：还有谁在运行多机架 Vera Rubin
英伟达最近的几代机架级平台，CoreWeave 每次都是第一家部署的云服务商：GB200 NVL72 首先在 CoreWeave 上全面可用，接着是 GB300 NVL72，现在是多机架 Vera Rubin NVL72。这一规律既反映了英伟达的分配策略 —— 历来优先照顾那些能快速消化和运营新平台的合作伙伴 —— 也反映了 CoreWeave 的运营基础设施：它是专为机架级 GPU 部署打造的，而不是从通用云架构改造而来。
从 Yandex 分拆出来的欧洲 AI 云服务商 Nebius 已宣布计划从 2026 年下半年起在美国和欧洲提供 Vera Rubin NVL72，并与英伟达一起提交了 Vera Rubin NVL72 的 MLPerf v6.1 预览结果。截至本文撰写时，尚未发现 Nebius 专门就多机架 Vera Rubin 发布过任何公告。
几家主要的超大规模云厂商 —— AWS、谷歌云和微软 Azure —— 都还没有经过确认的多机架 Vera Rubin NVL72 部署。Azure 被列为 MLPerf v6.1 中 Blackwell 时代系统的生态合作伙伴之一。AWS 和谷歌云都尚未宣布任何机架配置的 Vera Rubin 可用。这就形成了一个短期窗口：需要 Vera Rubin 的算力密度和能效的前沿 AI 实验室和大规模推理运营方，可选的云服务有限。
CoreWeave 提供的竞争差异化，并不只在于能更早拿到新平台。SemiAnalysis 将 CoreWeave 评为铂金级（Platinum），而且是在其 ClusterMAX 评级体系的两个版本中都获此评级 —— 该体系评估 AI 云的性能、可靠性和效率，CoreWeave 是唯一在两个版本中都拿到这一评级的云服务商。这一评级是独立商业分析机构的评估，而不是基准测试结果。独立 AI 基础设施基准测试公司 Artificial Analysis 在推理速度和性价比上把 CoreWeave 排在第一，评测对象是月之暗面（Moonshot AI）的 Kimi K2.6 和 Kimi K2.7 Code 模型。
局限，以及仍需独立验证的说法
这份公告中的几项重要说法是公司自报或客户自报的，没有经过独立验证，阅读时应当考虑到这一点。
比较 Vera Rubin 与 GB200 NVL72 的「每兆瓦 token 数提升 10 倍」这个数字，是 CoreWeave 于 2026 年 7 月在自有硬件上测得、并发布在其工程博客上的。这一对比是在开启全部主要推理优化的条件下、针对特定工作负载（DeepSeek R1）进行的，并不是经过 MLCommons 或中立第三方验证的数字。MLPerf v6.1 的对比 —— 相对 GB300 NVL72（而非 GB200）的 2.5 到 3.7 倍 —— 使用的基线和测量条件都不同，而且经过了独立验证，但覆盖的是不同的模型系列。
Spectrum-X 网络每条轨道支持约 12.8 万块 GPU 的说法，代表的是设计容量，而不是在这一规模上已经实现的部署。还没有任何云服务商公开报告在单个无阻塞网络中运营过接近 12.8 万块 GPU。这个数字描述的是该架构的理论上限，而不是经过生产规模验证的能力。
Cohere 报告的跨区域数据集访问延迟改善 8 倍，来自 CoreWeave 引用一位 Cohere 高管的新闻稿，尚未经过独立测量或 Cohere 自己的公开文档证实。考虑到这项技术（本地 NVMe 缓存对比远程存储集群读取），它在方向上是合理的，但 8 倍这个具体数字反映的是一家客户在特定条件下的生产负载，这些条件可能与其他部署有很大差异。
CoreWeave 尚未披露其当前多机架 Vera Rubin 配置的具体机架数量。「上百块 Rubin GPU」意味着至少两个 NVL72 机架（最少 144 块 GPU），但公告中没有说明集群的实际规模。
现在改变了什么 —— 以及接下来该关注什么
多机架这一里程碑，对那些工作负载已经超出单个 72 GPU 机架能力的 AI 团队最为重要。对于强化学习后训练 —— 策略模型生成轨迹，奖励模型为其打分，梯度在大量同时并行的环境中更新策略 —— 瓶颈一直是能参与同一个同步训练步骤的 GPU 数量。多机架 Vera Rubin 集群为这部分算力池去掉了机架大小的天花板。
对于以高并发服务 DeepSeek R1 等推理模型的大规模推理部署，道理也一样：随着更多 Vera Rubin 机架加入资源池，模型参数中能以完全激活状态保存在 HBM 显存里的比例随之扩大，这直接影响生产部署的每 token 成本和每用户延迟。
值得关注的待定基准，是 CoreWeave 以自己名义提交的 MLPerf Vera Rubin 结果 —— 这将让人们在相同的基准条件下，直接比较 CoreWeave 基于 Vera Rubin 的基础设施栈与 Nebius 以及英伟达的第一方提交。CoreWeave 在 MLPerf v6.1 中的 Blackwell 提交，在 GPT-OSS-120B 和 Llama 2 70B 上展示了领先其他云服务商的单 GPU 吞吐量；这种优化优势能否顺利延伸到多机架规模的 Vera Rubin 上，等那份提交发布后就能看到。
今天的公告和 MLPerf v6.1 都没有回答的更大问题，是使用 Vera Rubin 多机架集群要花多少钱。CoreWeave 尚未公布多机架配置下 Vera Rubin 的每 GPU 小时价格。每兆瓦 token 数提升 10 倍的经济性原则上很有吸引力，但对大多数 AI 团队来说，真正相关的数字是在他们所需的质量和延迟下每百万 token 的成本 —— 而这个数字取决于仍未公布的定价结构。