Blackwell 与 Rubin:从路线图到训推优化
一句话结论:Blackwell 和 Rubin 的硬件特性,直接决定了软件侧该往哪优化。双 die + 微缩放低精度 → FP8/FP4 成为训练推理主线;NVLink 大域 → 机架成为标准部署单元;HBM 带宽与算力的不对称 → prefill/decode 分离与专用 SKU(Rubin CPX)出现。 看清这三对因果,比记住任何单个规格数字都有用。
本文对照 NVIDIA 官方白皮书、产品页、GTC 主题演讲与相关论文逐条核对过数字。核对中发现原稿有七处需要更正,其中一处是时效性问题——NVIDIA 在 2026 年下半年下调了 Rubin 的多个规格,已在文中以 ⚠️ 标注。
一、全局视角:NVIDIA 数据中心 GPU 路线图
NVIDIA 的数据中心架构以科学家姓氏命名,并且已经从两年一代切换到一年一代。
| 架构 | 上市时间 | 代表产品 | 关键规格特征 |
|---|---|---|---|
| Ampere | 2020 | A100 | 第一代 MIG、BF16/TF32 |
| Hopper | 2022(H100)/ 2023(H200) | H100 / H200 | 第一代 Transformer Engine、FP8、NVLink 4 |
| Blackwell | 2024(B200/GB200)/ 2025(B300/GB300) | B200、GB200 NVL72、B300 | 双 die、NVFP4、NVLink 5、HBM3e |
| Rubin | 2026 | Vera Rubin NVL72、Rubin CPX | HBM4、NVLink 6 |
| Rubin Ultra | 2027(规划) | VR300 | 100 PFLOPS FP4、1TB HBM4e(规格见 §3.5) |
| Feynman | 2028(规划) | — | Rosa CPU、NVLink 8、自定义 HBM |
⚠️ 更正两处年份:H200 是 2023 年发布,不是 2022(Hopper 代的 2022 指 H100);B300 / Blackwell Ultra 是 2025 年发布,不是 2024。
「一年一代」这个说法有明确官方依据:黄仁勋在 2024 年 5 月财报电话会上表示 Blackwell 之后仍会保持一年一次的更新节奏,并在 Computex 2024 主题演讲中公开展示了年度架构路线图。此前是两年一代(Ampere 2020 → Hopper 2022 → Blackwell 2024)。
二、Blackwell:为万亿参数模型而生的「双 die + 机架级」
相对 Hopper 的跨越主要在四个维度。
2.1 计算层:双 die 合封 + 微缩放低精度
每颗 Blackwell 由两块 reticle 极限的 die 通过 NV-HBI(NVIDIA High-Bandwidth Interface)拼成「逻辑上的单 GPU」。官方白皮书原文:
The two dies are connected and unified with a single 10 terabyte-per-second (TB/s) chip-to-chip NVIDIA High-Bandwidth Interface (NV-HBI), providing one fully coherent chip.
总晶体管 2080 亿(官方口径:“Built with 208 billion transistors, more than 2.5x the amount of transistors in NVIDIA Hopper GPUs”)。
⚠️ 更正:原稿写「总晶体管 208B(每 die 104B)」。104B/die 在 NVIDIA 官方文本中查无实据——官方只给 208B 总量与「两颗 reticle 极限 die」。104B 是 208/2 的二手推算,引用时宜标注为推算值。
两颗 die 共享完全一致的 L2、内存访问完全一致(官方:“Full coherence: Shared L2 cache with fully coherent memory accesses”),对 CUDA 程序员呈现为单一设备。
补充一句边界:「完全透明」是官方口径,但跨 die 的 NV-HBI 交互并非零成本。有微基准论文指出其测试"primarily exercised single-die behavior",跨 die 延迟仍是待研究的开放问题。做极限性能优化时不能默认跨 die 免费。
2.2 微缩放:4bit 能进生产的关键
第五代 Tensor Core 引入 NVFP4 / MXFP8 微缩放格式——分组浮点,每组元素共享一个 scaling factor。这里有两个数字必须分清:
| 格式 | block size | scale 类型 |
|---|---|---|
| NVFP4 | 16 | E4M3 |
| MXFP4 / MXFP8 / MXFP6 / MXINT8 | 32 | E8M0(幂次) |
⚠️ 更正(这条影响论证):原稿写「NVFP4/MXFP8 微缩放格式,即每 16 个元素共享一个 scaling factor」。MXFP8 的 block size 是 32,不是 16——NVIDIA 官方格式表写得很明确(
MXFP8 | E5M2/E4M3 | 8 | 32 | E8M0)。只有 NVFP4 是 16。
为什么这个区别重要?因为「4bit 能用于生产」的论证正建立在 block 变小的基础上。NVIDIA 官方博客原文:
By reducing the block size from 32 to 16 elements compared to MXFP4, NVFP4 minimizes the influence of outliers and enables more precise scaling. This finer granularity reduces quantization error and improves overall model accuracy.
注意对比对象是 MXFP4(block 32),不是 MXFP8。NVIDIA 的 JAX/MaxText 量化实验给了个具体量级:8B 模型 1T token 训练中,MXFP4 需要多约 36% 的 token 才能追平 NVFP4 的最终 loss。
2.3 互联层:NVLink 5 + NVSwitch
单卡 NVLink 5 双向 1.8 TB/s(Hopper 的 2 倍)。72 卡 NVL72 机架内通过 NVLink Switch 形成 130 TB/s 的全域带宽,让 72 颗 GPU 表现得像一颗巨型 GPU。
GB200 Superchip 则用 NVLink-C2C(900 GB/s) 把两颗 Blackwell GPU 与一颗 Grace CPU 直连成超级芯片。
⚠️ 更正一处容量口径:原稿写 Superchip「HBM3e 达 384GB / 16 TB/s」。官方产品页现列 372 GB(= 2×186 GB 可用容量);384 GB 是 2×192 GB 的物理口径。16 TB/s 带宽属实。两者需注明口径差异。
2.4 内存与系统层
GB200 NVL72 = 72 GPU + 36 Grace CPU + 全液冷。
⚠️ 更正(这处是重复计数):原稿写「13.5 TB GPU 显存 + 30 TB 系统总内存」。实际官方是 13.4 TB HBM3e,而那个 30 TB 是 NVIDIA 所说的 “fast memory”,= 13.4 TB GPU HBM + 17 TB CPU LPDDR5X 之和——它不是一个独立于 GPU 显存的「系统内存」。两者并列写会重复计算。
两个性能宣称的基线不同,别混:
| 宣称 | 倍数 | 基线 |
|---|---|---|
| 万亿参数模型实时推理 | 30× | H100 |
| MoE 架构 | 10× | H200(HGX H200) |
⚠️ 更正:原稿把两个都算成对 H100。30× 确实是对 H100(官方:“up to a 30x performance increase compared to the same number of NVIDIA H100 Tensor Core GPUs”);但 10× MoE 的基线是 HGX H200,NVIDIA 的 MoE 专文写得很明确。
2.5 专用引擎
- 第二代 Transformer Engine:为 FP8 / FP6 / NVFP4 优化,自动处理分块、动态缩放与低比特矩阵乘;
- 800 GB/s 硬件解压引擎;
- 业界首个支持 TEE-I/O 的机密计算 GPU。
三、Rubin:延续 Blackwell 体系,物理层大跃迁
Rubin 基本继承 Blackwell 的「微缩放低精度 + NVLink 大域」框架,在物理层做了一次跃迁。
3.1 核心规格
| 项 | 规格 |
|---|---|
| 晶体管 / 封装 | 3360 亿,2 die 合封,NV-HBI 互连 |
| 制程 | 台积电 N3(业界一致报道为 N3P + CoWoS-L) |
| SM / Tensor Core | 224 个 SM、896 个 Tensor Core |
| 显存 | 288 GB HBM4 |
| 显存带宽 | 19.2 TB/s(发布时为 22 TB/s,见 §3.4) |
| 算力 | 50 PFLOPS NVFP4 推理(sparse)/ 35 PFLOPS NVFP4 训练(dense) |
| 互联 | NVLink 6,每 GPU 双向 3 TB/s |
| CPU | Vera CPU,88 个 NVIDIA 自研 Olympus 核(Arm 兼容),176 线程 |
⚠️ 更正两处:
- 50 / 35 PFLOPS 必须区分 sparse 与 dense。官方产品页脚注写明:推理 50 PFLOPS 是 sparse specification,训练 35 PFLOPS 是 dense specification。原稿没区分。
- Vera CPU 的核是 NVIDIA 自研的 “Olympus” 核(官方:“NVIDIA-designed Olympus cores… full Arm compatibility”),不是泛指的「88 个 ARM 核」。写「Arm 兼容的自研核」更准确。
3.2 Vera Rubin NVL72
72 Rubin GPU + 36 Vera CPU,全液冷(进风温度 45°C),机架级 3.6 EFLOPS NVFP4 推理(sparse)/ 2.5 EFLOPS 训练(dense)。
引入 Intelligent Power Smoothing with energy storage(智能电源平滑 + 储能)来吸收推理负载的功率尖峰——官方称相比上代电源平滑技术降低约 10% 功耗、把 50ms 尺度的峰值功率削掉约 20%。这是「推理负载功率波动」被硬件化应对的一个信号。
3.3 Rubin CPX:为超长上下文 prefill 而生
Rubin CPX 是 Rubin 家族里一个定位特殊的 SKU:
- 128 GB GDDR7(不是 HBM4)、单片 monolithic die;
- 30 PFLOPS NVFP4;
- 定位是长上下文(prefill / context 阶段)推理,走「算力密度 / 成本密度」取向,而非 HBM 带宽取向。
Vera Rubin NVL144 CPX 把两相硬件混合:144 张 Rubin CPX + 144 张 Rubin + 36 颗 Vera CPU,单机架 8 EFLOPS NVFP4(官方称较 GB300 NVL72 提升 7.5 倍),配 100 TB 高速内存、1.7 PB/s 内存带宽,专门面向百万 token 级代码生成与视频生成。
注意:这个 SKU 的存在本身就是第 5.3 节那个「prefill/decode 硬件分离」论点的物理证据——NVIDIA 不是在软件层做分离,而是直接做了两种 GPU。
3.4 ⚠️ 时效性提醒:Rubin 的规格在 2026 下半年被下调
这是原稿最需要更新的一处。 NVIDIA 在 2026 年 9—11 月把 Vera Rubin 的多个发布指标下调为量产规格:
| 项 | 发布值(GTC 2026) | 量产规格(产品页现列) |
|---|---|---|
| HBM4 带宽 | 22 TB/s | 19.2 TB/s |
| NVLink 6 每 GPU | 3.6 TB/s | 3 TB/s |
| NVL72 机架 NVLink 总带宽 | 260 TB/s | 216 TB/s |
NVIDIA 对媒体的解释是:早期公布的数字属于 “preliminary architectural targets”,量产规格才是最终交付值。
写硬件文章时这是个通用教训:发布会的架构目标与产品页的量产规格是两套数字,中间可能隔好几个月才对齐。引用时务必看产品页的当前值,而不是主题演讲幻灯片。
3.5 Rubin Ultra 与 Feynman
Rubin Ultra(2027,规划):原官方路线图是四颗 reticle 尺寸核心、100 PFLOPS FP4、1 TB HBM4e(16 接口)、NVL576、约 600 kW。但 2026 年有多家媒体(TrendForce / Tom’s Hardware 系)报道 NVIDIA 取消了 4-die 设计、改回 2-die(原因是 CoWoS-L 的翘曲与成本问题)。
⚠️ 这一改动未经 NVIDIA 官方确认,属媒体消息。本文标注为「原规划 4 die,2026 年有报道称改为 2 die」,请以最终发布为准。
Feynman(约 2028):目前只有路线图方向——搭配 Rosa CPU、NVLink 8(带 co-packaged optics)、自定义 HBM,以及 LP40 系统内存。注意 LP40 是系统内存,和「GPU 用自定义 HBM」是两个不同部件,原稿把「LP40/自定义 HBM」并写容易混淆。该代尚无任何容量或性能数字。
四、训练侧:围绕低精度与互联的系统级优化
硬件能力需要软件栈配合才能兑现。
4.1 FP8 训练已进入生产实践
Transformer Engine 的 recipe 不止三种:
| Recipe | 说明 |
|---|---|
DelayedScaling |
延迟缩放,最经典的 FP8 方案 |
Float8CurrentScaling |
当前张量缩放 |
Float8BlockScaling |
分块缩放,对应 DeepSeek-V3 |
MXFP8BlockScaling |
MXFP8 分块 |
NVFP4BlockScaling |
NVFP4 分块 |
⚠️ 更正:原稿只列了三种(漏了
MXFP8BlockScaling)。DeepSeek-V3 对应Float8BlockScaling属实——TE 文档原文:“inspired by the quantization scheme used to train the DeepSeek-v3 model, the first open-source large-scale LLM trained entirely in FP8 precision”(block size 128)。
关于「FP8 相比 BF16 提升 30—40%」:
⚠️ 更正归因:「微软/Meta/Google 已用 FP8 训练、提升 30—40%」这个说法出自二手技术博客,不是 NVIDIA 官方口径。NVIDIA 自己的 NeMo 基准(H100,current-scaling)给的是:Llama 3 8B ≈1.30×、70B 1.43×、405B 1.53×;DGX B200 上 MXFP8 是 1.28—1.37×。区间大致落在 28—53%,比「30—40%」更宽,且 NVIDIA 未点名那三家公司。建议引用官方基准。
4.2 MXFP8 预训练配方
NVIDIA 论文《Recipes for Pre-training LLMs with MXFP8》(arXiv:2506.08027)给出了一个明确结论:
MXFP8-E4M3 datatype and a specific number conversion algorithm result in training sessions that match those carried out in BF16.
这个「特定的数值转换算法」指的是缩放因子向上取整到正无穷(区别于 OCP v1 规范的向下取整)。结论是:MXFP8 配合正确的取整方向,可以做到与 BF16 训练精度对齐——因为 Blackwell 的微缩放让更窄的数据类型也保住了动态范围。
4.3 FP4 训练仍在探索期
推理侧 FP4 已经可用,训练侧还没有:
- SageAttention3(arXiv:2505.11594)的结论是:“8-bit attention achieves lossless performance in fine-tuning tasks but exhibits slower convergence in pretraining tasks”——微调无损,预训练收敛更慢;
- MXFP4 训练发散有明确出处:论文 Hardware-Aware FP4 FlashAttention-4(arXiv:2609.04105)原文——“every tested MXFP4 probability/value training trajectory diverges”。
⚠️ 两处更正:
- 「FA4 提出把前向量化直接传入反向、在 GB200 上让 8B 模型单卡更新提速 1.14×、报告 MXFP4 发散」——这组结论出自 arXiv:2609.04105(Hardware-Aware FP4 FlashAttention-4),不是 FA4 主论文(arXiv:2603.05451),属张冠李戴。1.14× / GB200 / 8B / MXFP4 发散本身都是真的。
- 原文是「前向量化(quantization)直接传入反向」,不是「前向量化(vectorization)」——原稿把 quantization 译成了「向量化」。
结论:FP4 目前主要用于推理权重,FP4 训练要等更成熟的数值方案。
4.4 并行策略围绕 NVLink 大域重设计
NVLink 5/6 + NVSwitch 让 72 卡进入同一通信域,张量并行可以扩展到 8 卡乃至更多;流水线/专家并行的带宽也大幅受益。
⚠️ 更正一处概念:原稿写「72 卡共享内存语义(NVLS, NVLink Shared Memory)」。NVLS 的官方含义是 NVLink SHARP(Scalable Hierarchical Aggregation and Reduction Protocol,网内集合通信卸载),不是 “NVLink Shared Memory”。NCCL 文档原文:“NVLS (stands for NVLink SHARP)”、“NVLS and NVLSTree enable NVLink SHARP offload”。它做的是把 all-reduce 等集合通信卸载到交换机里做,这恰恰是「72 卡像一颗 GPU」的机制之一——但名字和含义都得改。
长上下文训练则普遍叠加序列并行/上下文并行与 FlashAttention 系 kernel。
五、推理侧:低精度量化、专用 kernel 与 prefill/decode 分离
5.1 NVFP4 量化与部署管线
生产路径是 NVIDIA ModelOpt 做 PTQ 校准 → TensorRT-LLM 原生构建 NVFP4 引擎。
⚠️ 更正一处版本:TRT-LLM 0.17.0 首加 NVFP4(Release Notes:“Added NVFP4 Gemm support for Llama and Mixtral models”)属实;但RTX Pro 6000 的支持到 0.20.0 才加上,不是 0.17。GB200 早期是 “not fully supported”,后续版本才完整支持。
vLLM 也支持 FP4:
⚠️ 更正一处表述:原稿写「MoE 走 FlashInfer FP4 kernel,dense 走 llm-compressor 量化」。前半句属实(vLLM 有
flashinfer_fp4_moe模块);但后半句不严谨——llm-compressor 是离线量化 checkpoint 的工具,不是 dense 专属的运行时内核。vLLM 同时支持 LLM Compressor 与 Model Optimizer 两种量化格式,与 dense/MoE 不是一一对应的。
FP4 相比 BF16 省一半权重显存、翻倍有效带宽,直接推高单卡可服务的模型规模。
5.2 专用 attention kernel
- FlashAttention-3 针对 Hopper 优化,Blackwell 上进一步结合 FP8/FP4;
- SageAttention3 用微缩放 FP4 做 attention,在 RTX 5090 上达到 1038 TOPS,相对 RTX 5090 上最快的 FlashAttention 提速 5×,论文 Figure 1 用 HunyuanVideo 演示了端到端提速。
⚠️ 更正:原稿写「2× 级 kernel 提速」。官方论文写的是 5×(“1038 TOPS on RTX5090, which is a 5x speedup over the fastest FlashAttention on RTX5090”)。
关于「同一 B200 跑不同 kernel 差距巨大」的那组数字:
⚠️ 这条建议直接删掉。 原稿写「同一 B200 跑 GPT-OSS-20B FP4:SGLang 1262 TFLOPS、FlashInfer CuteDSL 1225 TFLOPS、vLLM 1117 TFLOPS」。这组数字只出现在一篇无引用的第三方聚合文里,且原文根本没提 GPT-OSS-20B(只写「三个 MoE 后端 / Blackwell B200」)。NVIDIA、vLLM、SGLang、FlashInfer 的官方资料都没有这组数。
论点(kernel 工程决定实际吞吐)本身是对的,但不该用查不到来源的数字来支撑。想讲这个论点,可以引用各框架自己的官方 benchmark 页面。
5.3 Prefill/decode 分离与长上下文
prefill 是算力受限(FLOPS 打满),decode 是带宽受限(不停从 HBM 抓权重与 KV cache)——两者的硬件需求相反。
NVIDIA 的应对是把两相硬件分开:GDDR7 的 Rubin CPX 打 prefill,HBM4 的 Rubin 打 decode,在长 prompt 下同时改善 TTFT 与 TPS(见 §3.3 的 NVL144 CPX)。
配套手段还有投机解码、KV cache 压缩,以及把 KV cache 卸载到 host 内存。
⚠️ 更正:原稿写「MXFP8 KV cache 压缩」。主流框架的 KV cache 量化类型里没有 MXFP8——TRT-LLM 只有 FP8/NVFP4,SGLang 有 fp8/nvfp4/fp4_mx_block16,vLLM 只有 FP8。MXFP8 是用在权重/激活 GEMM 上的,不是 KV cache 格式。
「KV cache 溢出到 CPU 内存」属实(NVIDIA Dynamo KVBM 的内存层级含 pinned host memory,TRT-LLM 有 host cache offload);在 Grace 系统上这块 host 内存就是 Grace CPU 内存——但官方没有把这个组合命名为一个独立特性,表述时宜按机制描述而非当成产品名。
六、三对因果:硬件特性如何决定优化方向
把整条线收束成三对因果:
第一对:双 die + 微缩放 FP4/FP8 → 低精度训练与推理成为主线。
FP4 让单位带宽算力翻倍,但动态范围窄,所以必须做 microscaling(NVFP4 的 16 元素块 + E4M3 scale)+ 专门的 Transformer Engine recipe。这也解释了为什么 MXFP8 的 block 是 32 而 NVFP4 是 16——为了精度,NVIDIA 在 NVFP4 上多付了 scale 存储的代价。
第二对:NVLink 5/6 + NVSwitch 大域 → 机架级大模型成为标准部署单元。
万亿参数推理不再靠单卡硬扛,而是 72 GPU 作为一个统一计算域。NVLS(NVLink SHARP)把集合通信卸载进交换机,是「72 卡像一颗 GPU」的关键机制之一。张量并行跨 8 卡以上因此成为常态。
第三对:HBM 带宽提升 + 算力/带宽不对称 → prefill/decode 分离与专用 SKU 出现。
Rubin CPX 就是把这一不对称硬件化的产物——软件侧的分离式 serving,对应到硬件侧就是两种不同内存子系统的 GPU。
七、生态与动手路径
目前 Blackwell 上最成熟的组合:
| 层 | 组件 |
|---|---|
| 训练 | Transformer Engine(FP8 / MXFP8 recipe) |
| 推理 | TensorRT-LLM / vLLM / SGLang(NVFP4) |
| kernel | FlashAttention-3/4、SageAttention、FlashInfer |
Rubin 沿用同一软件栈,主要新增 HBM4 / NVLink 6 的带宽红利与 Rubin CPX 的专用形态。
最直接的动手路径:
- 训练侧在 Transformer Engine 里切到 MXFP8 recipe(论文已验证可与 BF16 精度对齐);
- 推理侧用 ModelOpt 做 NVFP4 PTQ;
- 交给 TRT-LLM 或 vLLM / SGLang 起 serve。
这三步就能吃到 Blackwell/Rubin 的绝大部分红利——剩下的差距在 kernel 工程,那是另一个战场(见姊妹篇)。
相关阅读
- GPU 微架构:从晶体管到一次 GEMM 的完整数据流——本文的姊妹篇,拆到 SM 内部与 GEMM 数据流,解释这些规格数字在硬件上意味着什么
- 从 LLM 到具身:注意力架构、VLA 世界模型与云 Infra 全景调研——架构侧的演进全景
- 一文搞懂 AI 推理部署算子融合——TensorRT 系的软件栈落点
- Speculator as a Service:大模型推理架构的解耦演进——投机解码与推理架构解耦
- AI Infra 全景复盘:GPU 性能、分布式训练与调度层深潜——并行策略与性能剖析
核实说明:本文规格数字逐条核对自 NVIDIA 官方来源——Blackwell 架构技术简报 V2.1、Blackwell Ultra Datasheet、Vera Rubin NVL72 与 GB200/GB300 产品页、GTC 2026 主题演讲逐字稿、NVIDIA 开发者博客、Transformer Engine 源码与文档、TensorRT-LLM Release Notes、NCCL 文档。论文结论核对自 arXiv:2506.08027(MXFP8 配方)、2505.11594(SageAttention3)、2609.04105(FP4 FlashAttention-4)。
原稿的更正汇总:年份(H200 2023 / B300 2025)、MXFP8 的 block size(32 非 16)、GB200 内存口径(13.4 TB 且 30 TB 是合计值)、Superchip HBM(372 GB 官方口径)、10× MoE 的基线(H200 非 H100)、Vera CPU 核名(Olympus)、NVLS 释义(NVLink SHARP 非 Shared Memory)、SageAttention3 提速(5× 非 2×)、Transformer Engine recipe 数量(5 种非 3 种)、TRT-LLM 版本(RTX Pro 6000 在 0.20)、MXFP8 KV cache(不存在)、FA4 结论归属、以及 Rubin 三个规格的下调(22→19.2 TB/s、3.6→3 TB/s、260→216 TB/s)。另有一组查无一手来源的 benchmark 数字已删除。
