7 月 21 日 NVIDIA 宣布 Vera Rubin NVL72 量产全面加速，CoreWeave、Google Cloud、Microsoft Azure、Oracle Cloud 的机架已经上线运行；供应链覆盖 30 个国家 350 多家工厂。10 月初 SpaceXAI 又宣布把优化版 Vera Rubin NVL72 搬上第一代 Starmind 卫星。这颗继任者的规格表里，最值得技术人记住的不是 3.6 EFLOPS FP4，而是那 20.7TB 的 HBM4。

规格表读错的方式

官方数据：Vera Rubin NVL72 整机架 20.7TB HBM4、约 1.6PB/s 内存带宽、3600 PFLOPS NVFP4 算力；单颗 Rubin GPU 配 288GB HBM4、19.2TB/s；超芯片（Superchip）配 576GB HBM4、38.5TB/s；NVLink 进入第六代。Micron 的 HBM4 36GB 12-Hi 已在 3 月量产，单栈带宽超过 2.8TB/s。

外行看 FLOPS，内行看容量。原因在于 Agent 负载的瓶颈已经转移。

为什么容量墙先到

过去两年的推理优化，主线是「让每 HBM 字节动得更快」——KV cache 量化、分页注意力、前缀缓存。但当模型越做越大（MoE 总参数逼近万亿）、上下文越拉越长（十万、百万 token）、并发越来越高（一个 Agent 同时挂着十几个工具会话），单卡显存装不下权重加 KV，才是硬约束。

20.7TB 的机架级统一地址空间，意味着两件事：一是巨大 MoE 的全部专家权重可以常驻，不必在 token 生成时从 NVLink 远端反复加载；二是成百上千路并发请求的 KV cache 能落在同一个高带宽池子里，前缀命中后直接复用。算力翻倍只是让排队变短，容量翻倍才是让服务能开张。

对软件栈的连带要求

容量上去了，软件必须跟上：Dynamo 的 prefill/decode 分离、WideEP 专家切分、FP4 权重常驻，都是围绕「把这 20.7TB 用满」设计的。这也是为什么 NVIDIA 反复强调机架是一个完整产品，而不是 72 张卡的拼盘。

判断

Vera Rubin 这一代的信号很清楚：竞争从「单卡跑分」进入「机架级内存经济学」。接下来一两年，谁能把 HBM4 的每字节利用率做高，谁才配谈低成本推理。

对规划机房的团队，这还意味着供电与散热口径要变。整机架液冷成为标配，单机柜功率密度比上一代大幅抬升，老机房的供电与制冷改造预算，往往比 GPU 采购更早成为卡点。

这也解释了为什么供应链新闻比芯片新闻更值得关注：30 个国家三百多家工厂同步爬坡，HBM4、光模块、液冷任一环掉链子，整机架交付就会延期。算力竞争到最后，拼的是整条供应链的成熟度。

去论坛讨论

这篇文章里的观点，欢迎到硅基AGI论坛讨论。按标题搜索：Vera Rubin 架构