又一次巨大的飞跃:Rubin CPX 专用加速器与机架

本文信息来源:semianalysis
全新预填充专用 GPU、机架架构、物料清单、解耦 PD、更高性能与 TCO 比、更低 TCO、GDDR7 与 HBM 市场趋势
Nvidia 宣布推出 Rubin CPX,这是一款专为优化预填充阶段而设计的解决方案,单芯片 Rubin CPX 在计算 FLOPS 上的侧重点远高于内存带宽。这对推理来说是一个颠覆性变化,其重要性仅次于 2024 年 3 月发布的 GB200 NVL72 Oberon 机架级形态。只有针对推理中截然不同的预填充和解码阶段配备专用硬件,分离式服务才能发挥其全部潜力。
因此,Nvidia 与竞争对手在机架系统设计上的差距已扩大到如峡谷般宽广。AMD 和定制芯片竞争者或许在模仿 Nvidia 的 72-GPU 机架级设计上迈出了一小步,但 Nvidia 刚刚又迈出了一大步,再次将竞争对手远远甩在后视镜中。
AMD 和 ASIC 供应商已经在机架级解决方案方面投入了大量资金以追赶竞争对手。尤其是 AMD,一直在不懈努力改进其软件栈,试图缩小与 Nvidia 的差距,但现在所有厂商都必须再次加倍投资,因为他们还需要开发自己的 prefill 芯片,这将进一步延迟他们缩小差距的时间表。随着这一消息的发布,Nvidia 的所有竞争对手都将被迫回到起点,重新调整整个产品路线图,这与当年 Oberon 改变整个行业路线图的情况如出一辙。
Rubin CPX
由于推理过程中的 prefill 阶段往往大量使用计算能力(FLOPS),而对内存带宽的需求较低,因此在配备大量昂贵且带宽极高的 HBM 芯片上运行 prefill 是一种浪费。解决方案是使用一款内存带宽较小、计算能力相对较强的芯片。这就是 Rubin CPX GPU 的用武之地。

Rubin CPX 配备了 20 PFLOPS 的 FP4 密集计算能力,但内存带宽仅为 2TB/s。它还配备了 128GB 的 GDDR7 内存,与 VR200 相比,内存容量更小且成本更低。相比之下,双芯片 R200 芯片提供 33.3 PFLOPS 的 FP4 密集计算能力,以及 288GB 的 HBM 内存,内存带宽高达 20.5 TB/s。

Rubin CPX 的推出将 VR200 机架级服务器家族扩展为三种版本:
- VR200 NVL144:在 18 个计算托盘中分布 72 个 GPU 封装,每个计算托盘包含 4 个 R200 GPU 封装。
- VR200 NVL144 CPX:除 144 个 Rubin CPX GPU 封装外,还包含 72 个逻辑 GPU 封装,分布在 18 个计算托盘中,每个计算托盘配备 4 个 R200 GPU 封装和 8 个 Rubin CPX GPU 封装。
- Vera Rubin CPX 双机架:由两个独立机架组成——一个 VR200 NVL144 机架,以及一个 VR CPX 机架,后者配备 144 个 Rubin CPX GPU,分布在 18 个计算托盘中,每个计算托盘配备 8 个 Rubin CPX GPU。

在本报告中,我们将首先解释迄今为止的背景故事,以及由于内存在推理的预填充阶段和解码阶段中所扮演的不同角色而促使 Rubin CPX 开发的动因。接下来,我们将深入探讨 Rubin CPX 芯片的架构,以及其在机架级解决方案中的部署情况。随后,我们将把焦点从过去和现在转向未来,探讨在解耦推理服务方面的前景,以及今天的发布对其他商用加速器供应商和定制芯片项目未来路线图与竞争力的影响。在本文的最后部分,我们将简要列出两种机架的关键物料清单(BoM),并按主要组件类别进行功耗预算分析。
内存:迄今为止的故事
内存墙一直是人工智能面临的最重要限制。为了将更大的模型加载到加速器中,需要更大的内存容量,而内存带宽则是推理和训练时令牌吞吐量的主要瓶颈。这就是为什么每个 GPU 的高带宽内存(HBM)容量和带宽迅速提升——从 H100 的 80GB 和 3.4TB/s 增加到 GB300 的 288GB 和 8.0TB/s,在不到三年的时间里,内存容量增长了三倍多,带宽提升了约 2.5 倍。
因此,从 Hopper 到 Blackwell,HBM 在加速器物料清单(BOM)中的占比持续上升,如今在 GB300 的封装 BOM 中,HBM 已成为单一占比最大的组件。HBM 对训练和推理都极为重要,但当我们将推理拆分为预填充(prefill)和解码(decode)两个步骤时,HBM 仅在解码步骤中具有较高价值。在计算密集型的预填充阶段,由于其并行特性,KVCache 的生成对带宽的需求要小得多,因此在这一阶段 HBM 的利用率较低。
与其他形式的 DRAM 相比,HBM 因其额外的带宽而价格高昂,而当这种带宽未被充分利用时,HBM 就被“浪费”了。HBM 在物料清单(BOM)中所占比例不断上升,构成了又一道“壁垒”,这正是推动 Rubin CPX GPU 开发的动力所在。

既然我们已经简要探讨了内存迄今为止所发挥的作用,那么让我们转向今天的发布,详细了解 Rubin CPX 的架构以及其部署的机架级服务器。
带宽与算力差异
每颗 Rubin CPX 芯片将采用传统倒装芯片 BGA 封装的单片 SoC 设计。与使用 HBM 不同,Rubin CPX 将配备 128GB 的 GDDR7 DRAM。从 HBM 转向更便宜的 GDDR7 内存,使得每 GB 成本降低了 50% 以上。
内存速度预计为 32Gbps,配备 512 位总线。这使得每颗 Rubin CPX 的内存带宽达到 2TB/s,而 R200 的内存带宽为 20.5TB/s。值得注意的是,在此次主题演讲中,Nvidia 还确认了常规 Rubin 的带宽有重大升级。R200 的 HBM4 速度已大幅提升至 10Gbps,从而实现每颗 R200 20.5TB/s 的内存带宽,正如我们在此前的加速器与 HBM 模型中所讨论的。这与 R200 最初发布时“仅”具备 13TB/s 内存带宽(6.4Gbps 速度档位)的规格相比有显著提升。我们还在模型中讨论并量化了对 HBM 供应商的影响 。144 颗每颗提供 2.0TB/s 内存带宽的 CPX 芯片与 72 颗每颗提供 20.5TB/s 的 R200 芯片相结合,将实现总系统内存带宽 1.7PB/s。
在计算性能方面,每个 CPX 提供 30 PFLOPs 的稀疏 FP4 计算吞吐量(20 PFLOPs 稠密),相比之下,R200 为 50 PFLOPs 稀疏 FP4(33.3 PFLOPs 稠密)。Rubin CPX 的稠密 PFLOPs 与 R200 一样,遵循稀疏与稠密 3:2 的比例,因为它继承了与 Rubin R200 类似的张量核心架构。相较于 R200 的双芯片设计,CPX 在单个计算芯片上的 FP4 计算吞吐量非常强劲。这种提升很可能来自于减少高精度计算单元,从而增加更多 FP4 ALU。这与 B300 的做法类似,即在保持相同 4NP 工艺节点的情况下,实现比 B200 更高的 FP4 吞吐量。
然而,一如既往,峰值理论 FLOPs 在实际中极难实现。与 Nvidia 其他受功耗限制的 GPU 类似,鉴于我们估计 Rubin CPX 的额定功耗仅约 800W,要持续接近峰值 FLOPs 将非常困难:我们认为其功率密度突破 1W/mm² 并不可行,尤其是在该板卡采用夹层式封装形态的情况下(下文将详细说明)。
不同之处还在于网络。Rubin CPX 没有用于纵向扩展的 NVLink SerDes,而是依赖 PCIe Gen 6 通过横向扩展网络上的 CX-9 NIC 与其他 GPU 通信。这种降低的网络能力完全可以通过实现流水线并行来弥补,我们将在下文讨论。

由于总硅含量更低且内存成本更低,Rubin CPX 的生产成本大幅低于 R200。减少总内存容量并采用更低成本的 GDDR7,使得内存成本降低了 5 倍。芯片架构也更加简单,因为避免了使用 HBM,并且仅采用单个光罩尺寸的核心而没有任何 I/O 小芯片,这意味着不需要 CoWoS 封装。作为对比,Rubin CPX 的设计类似于下一代 RTX 5090 或 RTX PRO 6000 Blackwell,因为它们都使用大规模单芯片设计,并配备 512 位宽的 GDDR7 内存接口。由于这些芯片基于消费级 Blackwell GPU 核心,它们的浮点运算能力(FLOPS)仅为配备 HBM 的高端兄弟 B200 的 20%。而 Rubin CPX 的这一比例跃升至 60%,因为它将是一次单独的流片,更接近 R200 计算核心的设计。作为追求单位成本下最大 FLOPS 的尝试——Rubin CPX 无可匹敌。
在本文后面,我们将解析 Rubin CPX 在物料清单(BOM)上的优势,并估算将预填充从 R200 转移到 Rubin CPX 可以节省多少成本。
英伟达 Oberon 机架架构升级:VR NVL144 CPX、VR NVL144、VR CPX
让我们从 Rubin CPX 芯片转向两款将承载 CPX 的全新 Vera Rubin 机架。
去年三月,在 GTC 2024 上,Nvidia 发布了其 Oberon 架构的第一代产品:GB200 NVL72。时隔一年半,第二代 Oberon——GB300 NVL72 即将以量产规模出货。两代产品之间的设计变化和升级非常有限。Oberon 架构的第三代产品 Vera Rubin(VR)成为今天在 AI Infra Summit 上 Ian 演讲的重点。预计在 2026 年推出,距离 Oberon 机架级形态首次亮相不到三年,VR 将在设计和升级方面相比 GB200/GB300 迎来重大变化。
Vera Rubin Oberon 将 Oberon 架构的功率密度推至极限,这需要在供电组件上进行重大升级,并在散热方案设计上作出调整。为了解决在 GB200/GB300 组装中布设飞越电缆的困难,以及托盘内部电缆带来的可靠性问题,选择了无电缆设计。连接 OSFP 插槽与 ConnectX NIC 的电缆已被移除。连接 PCIe 与前端 Bluefield DPU 以及本地 NVMe 存储的电缆也已被移除,其他辅助信号电缆亦同样取消。
Vera Rubin 的主要变化和升级集中在对以下三种 Vera Rubin(VR)计算托盘 SKU 的改进:
- VR NVL144(仅 Rubin)
- VR CPX(仅 Rubin CPX)
- VR NVL144 CPX(同一托盘内包含 Rubin + Rubin CPX)
这三种计算托盘类型是所讨论的三种机架解决方案的基础:
- VR NVL144
- VR NVL144 CPX
- VR NVL144 + VR CPX(双机架)

首个展示的机架是 VR NVL144 CPX。它与 VR NVL144 类似,不同之处在于 VR NVL144 CPX 的 18 个计算托盘中,除了配备 4 块 R200 GPU 和 2 颗 Vera CPU 外,每个计算托盘还额外配备了 8 块 Rubin CPX GPU。
VR NVL144 CPX 机架同样将采用液冷散热,但其功耗预算将大幅提升,约为 370kW,而 VR NVL144 的功耗预算约为 190kW。


另一种部署选项是 Vera Rubin CPX 双机架。顾名思义,该方案允许已经部署了 VR NVL144 机架的客户,随后在数据中心中增加 VR CPX 机架,从而实现用于解耦 PD 推理的专用硬件。VR CPX 不通过 NVLink 连接,因此 VR CPX 机架不包含 NVSwitch 托盘。VR CPX 机架通过可扩展的 InfiniBand 或以太网网络连接到集群,并且可以在方便的物理位置后续添加到集群中——它不必与 VR NVL144 物理相邻。
与 VR NVL144 CPX 相比,双机架方案提供了更高的灵活性,客户可以根据需求设计预填充与解码的比例。此外,并非所有数据中心基础设施都能承受约 370 千瓦的 VR NVL144 CPX。除此之外,与单机架版本相比,双机架方案在故障时的影响范围也更小。

在下表中,我们可以看到在一块计算托盘中塞入了多少计算和网络组件——每个计算托盘共包含 22 颗 Nvidia 芯片(其中 14 颗为 XPU),而每个 VR NVL144 CPX 机架则总计有 396 颗芯片。为了将上述所有组件塞进单个计算托盘,Nvidia 采用了无缆化和模块化设计,并重新设计了计算托盘内部的冷却回路。

NVL144 CPX 在计算托盘机箱的后半部分将保持与 GB200/GB300 类似的计算板布局。显著的不同在于,内存部分采用了可插拔的 SOCAMM DRAM 模块,而非焊接的 LPDDR5X,这些内存由 CPU 驱动。VR NVL144 CPX 与 GB200/GB300 之间的大部分差异,集中在机箱前半部分,即位于主处理器主板(“HPM”)计算板下方的区域,该主板在 Blackwell 代中也被称为 “Bianca” 板。
在前部,VR NVL144 CPX 的设计是模块化的,由 7 个子卡模块组成。
- 机箱两侧各放置了四个子卡模块。每侧有两块子卡上下堆叠。这四块子卡每块都包含两个 800G CX-9 网卡、一个 1.6T OSFP 插槽、一个 E1.S SSD NVMe 模块,以及两个 Rubin CPX。
- 机箱中部的一块子卡(下方示意图的中下位置)安装了 Bluefield-4 模块,该模块包含一个 Grace CPU 和一个 CX-9 网卡。
- 堆叠在 Bluefield-4 模块上方的另一块子卡安装了电源分配板(PDB)。PDB 负责将从机箱后部母排连接器输入的 48-54V 电压降至 12-13.5V。
- 最后一块子卡要小得多,位于 Bluefield-4 模块的右侧。它更为纤薄,内部集成了实用管理模块,其中包含 BMC、HMC、DC-SCM 以及管理 I/O 等组件。





我们估算 Rubin CPX 芯片的 TDP 约为 800W,但如果将包含 GDDR7 内存的整个模块计算在内,总功耗将上升至 880W。为了给计算托盘前端的 7,040W Rubin CPX 模块降温,机箱前端的散热方式必须从风冷升级为液冷。
为此,NVIDIA 重新采用了其 2009 年 GTX 295 的设计。Rubin CPX 和 CX9 子卡采用夹层式布局,中间共享一个液冷冷板。



在 PCB 的外侧,热管和散热片将每个对壳式 GDDR7 内存模块背面的热量传导至主冷板。通过充分利用 1U 托盘的高度并在冷板的两侧安装 GPU,将容纳这些 GPU 所需的计算托盘面积减半,从而实现最高密度。

VR NVL144 CPX 的另一项关键设计变更是采用了无缆设计。正如我们在 《PCB 超级周期核心研究报告》 以及近期关于 Amphenol 人工智能内容的核心研究报告中所讨论的,这一设计有两个原因。首先,飞越电缆在组装过程中容易受损,存在多个潜在故障点。其次,VR NVL144 CPX 的高密度设计根本没有空间布设电缆。
那么,信号是如何在没有电缆的情况下传输的呢?答案很简单:来自 HPM(Bianca)板的信号通过 Amphenol 的 Paladin 板对板连接器离开主板。这一点在我们最近关于 Amphenol AI 内容的文章中有更详细的讨论。随后,信号通过位于机箱中部的 PCB 中板进行传输。在 PCB 中板的另一侧,子卡通过另一组 Paladin 板对板连接器与 PCB 中板相连。


为适应这种无缆设计,HPM(Bianca)板上部的 CX-9 NIC 从机箱后半部分移至前半部分,如下图所示。对于 GB200/GB300,GPU/CPU 与 CX-7/8 之间的 PCIe 信号距离比 CX-7/8 与 OSFP 插槽之间的以太网/InfiniBand 信号距离更短。
此前——需要将计算托盘后半部分的 NIC 发出的 200G 以太网/InfiniBand 信号传输到计算托盘前部的 OSFP 插槽时,由于 PCB 在 200Gbit/s(单向)每通道下的信号损耗过高,必须使用飞线电缆。
但由于现在 NIC 更靠近 OSFP 插槽,较低速率的每通道 PCIe Gen6 信号(每通道单向 64Gbit/s)需要传输更长的距离,这种连接现在可以通过 PCB 进行布线。尽管在 PCB 上传输 PCIe Gen6 信号仍具挑战性,但通过升级 PCB 材料,仍然可以实现良好的信号完整性。


为了更好地维护,子卡也被设计成模块化结构。每个子卡模块都可以在子卡模块槽中自由滑入和滑出。在计算托盘内部,还配备了专门为此设计的内部导轨套件。
下面我们展示了不同 Vera Rubin 计算托盘 SKU 内部信号的走向,以及 VR Rubin SKU 的计算托盘拓扑结构。这些图表的一个亮点是,CX-9 在实现 Rubin CPX 和横向扩展连接中发挥了关键作用,因为它同时也是一款集成的 PCIe 交换机。






巨大的飞跃:解耦式推理服务
今天发布的 Rubin CPX 对推理来说是一个颠覆性改变,其重要性仅次于首次发布的 GB200 NVL72 Oberon 机架级形态。只有在针对推理中截然不同的两个阶段——预填充(prefill)和解码(decode)——配备专用硬件,解耦式推理服务才能真正实现。
在本节中,我们将解释从传统推理服务到使用统一硬件的解耦式推理服务的演变过程,并最终分析配备专用硬件的解耦式推理服务。我们将展示使用统一硬件进行解耦式推理服务会造成多大的浪费。一旦专用推理硬件普及,使用统一硬件就会像用风钻去拍死一只虫子一样荒谬。
正如我们在文章前面提到的,Rubin CPX 的发布将迫使 Nvidia 的竞争对手重新审视并调整他们的路线图。如果他们不推出自己的预填充专用芯片,就意味着要让客户使用低效的系统,这将注定这些客户在代币经济市场中处于劣势。
处理一个 LLM 请求包括两个阶段:预填充阶段和解码阶段。在预填充阶段,LLM 根据用户提示生成第一个 token。该阶段影响首个 token 生成时间(TTFT),通常受计算能力限制,内存带宽利用率不足。另一方面,解码阶段在从 KV 缓存加载先前 token 的同时生成新 token。该阶段影响每个输出 token 的生成时间(TPOT),始终受内存限制,计算资源利用率不足。


在下图中,我们看到一个示例,展示了在同一系统上进行预填充(prefill)和解码(decode)时,内存带宽与 FLOPS 利用率之间的权衡。预填充单个 token 所需的 FLOPS 会随着输入序列长度线性增长。解码所需的 FLOPS 也会随着系统中的用户数量(即批处理大小)和序列长度而变化。
较短的输入序列长度可能无法充分利用推理系统可用的 FLOPS,此时系统输出将受限于将参数加载到芯片内存的速度——这取决于内存带宽。随着输入序列长度的增加,工作负载最终会增长到占满推理系统的全部 FLOPS,此时工作负载将受限于系统总 FLOPS。在下图右半部分,我们展示了当序列长度超过 32k 时,FLOPS 利用率达到 100%,而内存带宽利用率则下降。

因此我们可以看到,当一个节点执行预填充(prefill)占比很高的工作负载——无论是长序列长度还是大批量大小时,内存带宽都未被充分利用。正如上一节所提到的,过去几年中芯片物料清单(Chip BOM)中分配给内存的比例不断增加,这最终导致了非常昂贵的资源闲置!
低效还源于这样一个事实:预填充阶段和解码阶段的工作负载特性本质上差异极大,当它们并发处理时,预填充请求和解码请求总是会相互干扰性能。为平衡两者,有许多优化方法——例如在预填充计算中加入决策,以确保请求长度相对均匀,从而提高利用率,但这些方法总是伴随着权衡。另一种方法是将预填充和解码阶段完全分离,但如果优先解码阶段,那么预填充就必须等待——导致首个 token 的生成时间变长。反之,如果优先预填充,解码阶段就会被迫等待,token 间延迟会变慢,因为此时内存带宽又未被充分利用。
初步尝试:使用相同硬件实现解耦的预填充与解码
首要的解决方案是实施解耦式服务,首先通过将预填充(prefill)和解码(decode)请求分别路由到不同的计算单元来应对干扰,从而更容易分析性能。这一方法的好处在于能够更好地管理服务水平协议(SLA),而这些协议往往关注每位用户每秒的特定令牌数。然而,这其中也有一些问题。这种完全解耦似乎只在特定的输入/输出序列长度比例以及较长的解码长度下才能取得显著效果,而在其他场景中收益并不理想。此外,这种解耦仍然存在“规模不匹配”的问题,即纯预填充操作几乎总是会严重低利用内存带宽。
在下面的示例中,我们展示了当 R200 仅用于预填充时,其内存带宽几乎不会被大量使用。随着序列长度的增加以及对可用 FLOPS 的更高效利用,内存带宽的使用率会变得越来越低——实际上是在浪费非常昂贵的 HBM 内存。

下一步:在专用硬件上实现解耦的预填充与解码——Rubin CPX 登场
由于预填充本质上会导致内存带宽资源的利用率不足,一种减少浪费的方法是减少内存的容量和成本。Rubin CPX 正是采取了这种方法,使用了数量更少、成本更低的 GDDR7 内存。
在下面的示例中,我们展示了当 R200 仅用于预填充时,其内存带宽几乎没有被大量使用。相比之下,Rubin CPX 在相对较短的输入长度下实际上利用了更高比例的内存带宽,而在我们认为是典型的输入长度下,其利用率会进一步下降。

确实,我们强调这并不是为了效率而追求效率本身——而是对利润有着巨大的影响!在下表中,我们提供了一个示例,用于比较 R200 GPU 和 Rubin CPX GPU 的内存带宽利用率。在这种情况下,两者的内存带宽利用率都非常低,但不同之处在于,Rubin CPX GPU 至少浪费的是数量更少、成本更低的内存。对于 R200,我们看到在运行与 CPX 完全相同的预填充工作负载时,会导致每小时 0.90 美元的总拥有成本浪费!

Rubin CPX 提供了更大的内存容量,但其“位”质量较低,因为使用的是 GDDR7,其每 GB 成本不到 HBM 的一半。 从内存供应商的角度来看,GDDR7 的利润率更低,因为它在技术上要求较低,竞争更多(例如三星也能供应)。
这意味着,使用 CPX 系统会降低 HBM 在整个系统内容中的占比。每花费 1 美元在 VR200 NVL144 CPX 或 VR CPX 机架上,与将同样的 1 美元花在独立的 VR200 NVL144 机架相比,花在 HBM 上的比例会更低。在其他条件相同的情况下,假设 AI 系统的支出总额固定,那么每花费 1 美元所需的 HBM 需求将会下降。
为何不进一步减少内存?
许多读者无疑会对减少 HBM 支出感到兴奋,并会想:为何不进一步削减系统中的内存容量?如果典型的预填充序列长度意味着内存利用率只有低两位数甚至个位数——为何不将内存容量减少到原来的 1/10?这是否意味着 HBM 需求乃至整体内存需求的衰退?

然而,技术领域的情况并非如此简单。Rubin CPX 的作用是降低预填充和令牌的成本。令牌成本降低会增加需求,这也意味着对解码的需求会随之上升。与许多其他降低成本的技术创新一样,需求的增长通常会远远抵消成本的下降,从而使整体市场规模(以美元计)反而更大。
GDDR7 需求还带来了额外的供应链影响。RTX Pro 6000 同样采用 GDDR7,但速度较低,为 28Gbps。Nvidia 为 RTX Pro 机型下了大量供应链订单,最初计划是在 H20 出口许可证重新发放之前,将其作为 H20 的替代品销售给中国。这些订单主要下给了三星,因为三星有能力满足这类突发的大额订单。SK 海力士和美光则无法满足这一需求,因为它们的晶圆产能被包括 HBM 在内的其他订单占用。由于三星能够提供具有竞争力的 GDDR7,三星同样可能从 Rubin CPX 中受益。
更多关于预填充流水线并行:Rubin CPX 分离式预填充的一个有趣优势
在前一部分中,我们概述了 Rubin CPX 如何减少内存浪费,而 Rubin CPX 放弃使用诸如 NVLink 等高速扩展网络能力解决方案,则是另一项重要的节省。Rubin CPX 的芯片外 I/O 仅限于 16 条 PCIe Gen6 通道,单向带宽约为 1Tbit/s,而 R200 的 NVLink 则为 14.4Tbit/s。即便是针对现代 MoE 前沿 LLMs,这样的 I/O 也足以执行预填充操作。
例如,DeepSeek V3 在使用 NVFP4 数字格式运行时,需要 335GB 的内存容量来加载所有模型权重——这超过了单个 CPX 芯片 128GB 的内存容量。可以通过使用流水线并行(Pipeline Parallelism,简称“PP”)来解决这一问题,即将模型的多个层分布在不同的 GPU 上。在 PP 中,每个 GPU 按顺序处理 token,并将激活值传递到流水线的下一阶段。
PP 的缺点是 token 需要依次在多个 GPU 之间传递,从而因阶段间通信产生延迟。重要的一点是,PP 往往能在每个 GPU 上实现比专家并行(Expert Parallelism,简称“EP”)更高的 token 吞吐量,但代价是 PP 的首个 token 输出时间(TTFT)比 EP 更长。PP 之所以能实现更高的 tok/s/gpu 吞吐量,是因为 EP 涉及全互连(all-to-all)集合操作,通信开销较大,而 PP 仅需进行简单的发送和接收操作。
因此,对于流水线并行推理来说,更简单的通信需求意味着预填充几乎不会占满通信链路——这意味着无需配置昂贵的高速扩展网络。与 HBM 类似,这是另一个可以节省成本的领域,通过剥离在仅预填充操作中未被使用的又一层设备,避免系统所有者在总拥有成本(TCO)上的浪费。
在下表中,我们展示了在使用 PP8 或 PP4 并行方案时,DeepSeek 的预填充每个 token 的消息大小为 7KB。如果我们将 PCIe Gen6 x16 通道的 I/O 完全饱和传输消息,这意味着我们最多可以传输(并因此处理)每秒 1830 万个 token。这就是通信瓶颈。
在计算瓶颈的情境下,我们看到预填充每个 token 的 FLOP 为 0.074 TFLOP。因此,如果我们将 Rubin CPX 的稠密 FP4 吞吐量 19,800 PFLOPS 除以 0.074 TFLOP,就得到最大 token 吞吐量为每秒 26.76 万个。
这远低于通信瓶颈,甚至无法充分利用普通的 PCIe Gen6 I/O,更不用说带宽是 PCIe Gen6 16 通道 14 倍以上的 NVLink 了。
我们估算,NVLink 扩展(包括 NVSwitch 和背板)对终端系统拥有者的总成本约为每块 GPU 8,000 美元——这仅占每块 GPU 集群总成本的 10% 多一点。这是 Rubin CPX 为终端用户带来显著节省的另一面。

然而,尝试在低速网络连接下使用专家并行(Expert Parallelism)将导致延迟问题和瓶颈。通信需求会随着 top_k 与层数的乘积而扩展。DeepSeek V3 的 top_k 为 8,层数为 61,因此粗略计算表明,与流水线并行(PP)相比,使用专家并行(EP)会使通信需求增加约 488 倍。
关于扩展性与黄氏定律的另一点
今天的讨论聚焦于使用 NVFP4 数字格式进行推理的指标。事实上,推理服务提供商一直通过采用精度越来越低的数字格式,不断提升吞吐量。然而——一旦我们进入 FP4 阶段——可挖掘的潜力将开始枯竭。
稀疏性被视为提升吞吐量的另一种手段,这也是为什么大多数营销规格和演示文稿会以稀疏 TFLOPS 为单位进行宣传的关键原因。然而,稀疏性至今尚未真正兑现其承诺的收益——远未达到其声称的 2 倍提升。
今天的发布还为 Rubin 引入了稀疏性。这种稀疏方案不同于 Hopper 和 Ampere 所采用的 2:4 结构化稀疏,也不同于 Blackwell 的 4:8 成对结构化稀疏。我们希望 Rubin 稀疏性能够带来实质性的吞吐量提升,并让黄氏定律继续奏效!
硬件专用解耦式推理的弊端
尽管预填充专用芯片的出现令人振奋,但我们还未达到理想境界,硬件专用的解耦式推理同样存在弊端。随着服务商的工作负载和模型不断变化,能够调整预填充与解码实例比例(PD 比例)至关重要。
定制芯片的下一步是什么?
最佳的 PD 比例受多种因素影响,包括模型架构、SLA、网络带宽等。然而,Vera Rubin NVL144 CPX 的一个主要劣势在于,它的 Rubin 和 Rubin CPX 芯片数量及比例是固定的,这使得在需要调整 PD 比例时灵活性较差。
Nvidia 在芯片演进上的敏捷性正迅速改变竞争格局。就在竞争对手在性能或架构上接近持平之际,Nvidia 又会在另一个维度上进化其产品。我们来探讨一下 Rubin CPX GPU 的广泛采用可能会如何影响竞争方案。
Google TPU
TPU 的 3D Torus 扩展网络具有独特优势,可支持最大 9,216 个 TPU 的 Pod 规模。这是业内最大的集群规模,同时每个加速器的扩展网络成本却是最低之一。这使其能够支持非常广泛的并行方案,而其他较小规模的集群可能无法实现。
话虽如此,谷歌若能开发一款仅用于预填充的芯片,将有助于继续保持其在内部工作负载上的性能与成本优势。他们拥有足够的内部工作负载来产生核心需求,从而推动并资助仅用于预填充芯片的研发,而这类芯片未来也可对外销售。
谷歌独特的拓扑结构意味着,在某些推理系统配置和模型中,其性能甚至可能超过部分英伟达系统。
AWS Trainium3 Max NVL72、AWS EFA 网卡以及 Meta MTIAv4 SUE72
来自那些拥有内部工作负载、但正在追求模仿 NVL72 机架外形设计的供应商的系统构成了另一类。这些供应商同样拥有内部工作负载,可以用来推动仅预填充芯片的开发,而为了与英伟达 VR200 NVL144 CPX 保持同步,他们最好这样做。
例如,一款与 Trainium3 Teton-3 Max NL72(配备 72 个逻辑 GPU,并具备与 VR200 NVL144 相同的全互连扩展规模)配合使用的仅预填充芯片,可以依托 Anthropic 的需求进行协同设计,并在其推理工作负载中获得采用。
由于 AWS 的 1U 计算托盘已经高度集成,内部紧密排列着 4 个大型 Rubin GPU 封装和 8 个 CPX GPU 封装,导致没有空间在计算托盘中添加 AWS 定制的 EFA NIC,因此其 VR 144 CPX 将面临重大的上市时间挑战。Amazon 不想使用 ConnectX-9。AWS 非常钟爱 EFA!
我们认为,他们将继续使用 EFA,并通过将 EFA NIC 拆分为仅包含 EFA NIC 的外挂机架,并使用外部 PCIe AEC 电缆连接 VR 144 CPX 机架与该 EFA NIC 外挂机架,从而克服这一挑战。此外,由于他们不会使用集成 PCIe 交换机的 ConnectX-9 NIC,因此还需要使用 Astera Labs 的专用 PCIe 交换机,将 Vera CPU、本地 NVMe、Rubin CPX GPU 以及通往外挂机架中 EFA NIC 的外部 PCIe AEC 电缆连接起来。
MTIAv4 的 SUE72(配备 72 个逻辑 GPU,具备与 VR200 NVL144 相同的全互连扩展规模)设计同样可以依托 Meta 内部推理工作负载。即便是像 OpenAI 携手 Broadcom 推出的新兴设计,也有望参与竞争,因为它们将以 Frontier Models 为目标进行协同设计,并以内部工作负载作为支撑。
尽管享有内部需求的优势,MTIAv3 因其仅有 16 个 GPU 的小规模集群而被排除在此类别之外。它实际上现在需要开发仅用于预填充的芯片,才能有机会与即将推出的 Nvidia 系统实现性能持平。
AMD MI400 系列 UALoE72 和 MI500 UAL256
然而,随着 Rubin CPX GPU 的发布,AMD 的回归战略看起来既不迅速也不激进,AMD 将再次陷入追赶 Nvidia 的局面。AMD 原本凭借机架级 MI400 有望迎头赶上,但 Nvidia 再次提高了门槛。
AMD 与上述厂商的关键区别在于,AMD 缺乏强大的内部工作负载,无法为又一个仅为追赶而进行的芯片开发项目提供收入和需求的支撑。
今年早些时候,AMD 在其“Advancing AI”活动中引起轰动,首次亮相了 MI400 72 GPU 机架级系统。 我们当时的分析指出,MI400 在 FP4 FLOPS 方面的总体拥有成本可能低于 VR200 NVL144 系统——同时提供 19.8TB/s 的内存带宽,而 VR200 NVL144 最初宣传的内存带宽为 13.0TB/s。
Nvidia 的 VR200 NVL144 如今通过向供应商要求更高速的分档,宣传其每个逻辑 GPU 的内存带宽约为 20.5TB/s。VR200 的内存带宽如今在更少的 HBM 封装下已与 AMD MI400 持平。

如果 MI400 的 FP4 有效密集 FLOPS(即微基准测试实际能提供的性能,而非宣传的吞吐量)与 VR200 NVL144 持平或更低,那么 AMD 实际上将比 Nvidia 晚一步进入市场,并且推出的是 VR200 NVL144 的翻版。与此同时,Nvidia 将再次领先,因为 VR200 CPX NVL144 在长上下文长度下能提供更高的每 TCO 性能。AMD 将不得不再次等到 2027 年才能追赶上来。
然而,我们认为 AMD 仍处于战时状态,现在需要开辟另一条战线,在开发机架级系统和改进软件的同时,参与仅限预填充硅芯片的战斗,才能有机会在 2027 年前追上 Nvidia。
英伟达
最后——为什么英伟达只停留在推出一款专注于预填充的芯片上,而不推出一款专注于解码的芯片呢?到目前为止,英伟达只发布了预填充专用芯片,而解码步骤仍由现有的 R200 芯片承担,而不是推出一款专门的解码 SKU。
一款专注于解码的芯片将与预填充芯片完全相反:计算能力较弱,但内存带宽极高。这款芯片看起来会像 R200,但不需要那么多计算单元。理想情况下,通过保持 I/O 小芯片的尺寸,可以同时保留内存和封装外 I/O 的带宽,但主计算芯片与 I/O 芯片相接的边缘可以缩小,同时保持每条边可容纳 2 个 HBM 位置的设计。这样可以得到一个更小的计算芯片。
此外,通过大量削减 SM 单元功能并显著提高参数良率,还可以进一步节省成本,同时在功率传输和热管理方面降低 TDP,从而减少相关成本。这与预填充芯片的情况正好相反,后者在保持 HBM 数量不变的同时,削减了系统其他部分,从而使 HBM 在物料清单中的占比回升。