Rubin 推理比 GB200 快 7.84×，峰值算力只快了 5 倍

2026 年 10 月 9 日，vLLM 团队发布了一篇 Vera Rubin NVL72 的工程预览博客。里面最醒目的数字是：在 MiniMax M3 这个模型上，Rubin NVL72 的推理吞吐最高能达到 GB200 NVL72 的 7.84 倍。同一篇文档的规格对照里还写着，Rubin 的 NVFP4 峰值算力大约是 GB200 的 5 倍，HBM 带宽是 2.4 倍，卡间互联带宽是 1.7 倍。

7.84 比这三项规格里的任何一项都大，也大于把它们简单相乘得到的数。一个很自然的反应是：硬件才快 5 倍，软件又把它放大到 7.84 倍，那多出来的部分是不是就是可提取的"软件红利"？

这篇文章要拆掉的正是这个直觉。7.84× 不是"硬件倍数 + 软件倍数"，而是在特定负载下把瓶颈从一处挪到另一处之后，硬件容量、内核优化和吞吐—延迟工作点三者耦合出来的系统级结果。把它拆成几项相加，会同时高估和低估。下面我们顺着这个数字，一层一层把它拆开。

一、同代硬件，为什么报出 7.84×、5.18×、4.8×、3.7× 四个数？

先看一个让人不安的事实：同样是 Rubin 对上一代，公开数字有一大把，而且彼此差得很远。vLLM 报 MiniMax M3 相对 GB200 NVL72 最高 7.84×；但把每用户每秒 token 数（interactivity，交互速度）固定在 150 这个约束下，同一对硬件、同一个模型又变成 5.18×。Cognition 在自己的私有 SGLang fork 上报告 4.8×。MLPerf Inference v6.1 里，Qwen3-VL 对 GB300 NVL72 是 3.7×，DeepSeek-R1 是 2.5×。vLLM-Rubin

如果这些数字各自成立，那"Rubin 到底快几倍"就没有唯一答案。原因在于，每一个倍数其实都绑定了一个四元组：模型 + 基线 + 延迟约束 + benchmark。脱离这个四元组谈倍数，等于什么都没谈。

先看 7.84× 和 5.18× 这对数字。它们看起来像两次独立测量，其实来自同一条曲线上的两个点。vLLM 的这张图横轴是 P90 交互速度，也就是 90% 的请求能达到的每用户每秒 token 数；纵轴是每芯片吞吐，注意是每芯片，不是每整机。

图注：这是 vLLM 在 Vera Rubin NVL72 与 GB200 NVL72 上的吞吐—交互速度前沿，模型为 MiniMax M3，纵轴是每芯片吞吐。浅色曲线是 Rubin，深色是 GB200。两个橙色标注是同一曲线上的两个取点：在 150 TPS 约束处标注 5.18×，在高交互速度的匹配点处标注 7.84×。它不是两次独立测量，而是"把延迟约束放在哪里"决定了报出哪个倍数。图来自 InferenceX 的 Official Preview，数值可能随验证继续调整。vLLM-Rubin

这里的关键不是曲线本身，而是取点。吞吐和延迟是一对矛盾：想让每个用户更快，就得少塞点并发，吞吐就掉下去。所谓"matched interactivity"（匹配交互速度），就是在比较两台机器时，先把交互速度钉在同一个值上，再比吞吐。你把这个钉的值往上移，双方都掉吞吐，但掉的幅度不一样，倍数就变了。所以 7.84× 是"在某个取点上 Rubin 快 7.84 倍"，不是"Rubin 一律快 7.84 倍"。

那 4.8× 和 3.7× 又是什么口径？它们换了模型或换了 benchmark。4.8× 来自 Cognition 在私有 SGLang fork 上的部署报告，第三方无法复测，只能当旁证。3.7× 走的是另一条路：MLPerf 是同行评审的封闭组基准，同硬件、同 GB300 基线，但换了 workload 和 scenario。

图注：MLPerf Inference v6.1 的实测倍数表。同一份硬件（Vera Rubin NVL72）、同一个基线（GB300 NVL72），只因为模型和 scenario 不同，就给出六个不同的倍数：DeepSeek-R1 在 Offline / Server / Interactive 三种场景下是 1.7× / 1.9× / 2.5×，Qwen3-VL 是 1.8× / 1.9× / 3.7×，全部为 72 GPU 规模。表里只有倍数，没有绝对吞吐数值。Interactive 那一列明显高于 Offline，因为它是延迟约束最紧、最像真实 agent 调度的场景。MLPerf-v6.1

同一张表里，Interactive 列比 Offline 列高出 1.5 到 2 倍，这就是吞吐—延迟工作点对倍数最干净的实证：硬件没变，只是把评价轴从"不管延迟的纯吞吐"换成了"有延迟约束的交互速度"，倍数就跳了一截。

这些数字之所以长这样，和负载的形状直接相关。SemiAnalysis 的 AgentX 基准回放的是真实 Claude Code 会话，它的中位会话有 43 轮对话，中位输入 142K token，输出却只有 444 token，prefix cache 命中率超过 96%，44% 的会话里带至少一个子代理。输入远大于输出、且绝大部分前缀可复用，这决定了推理的瓶颈不在算力而在别处。至于整机的峰值规格表，72 个 Rubin GPU 加 36 个 Vera CPU，20.7 TB HBM4、1.4 PB/s 整机带宽、3.6 EFLOPS NVFP4 推理、216 TB/s NVLink，这里只作为规格上限记一笔，后面会用到。NVL72-Spec 另外还有一路口径是每兆瓦吞吐，NVIDIA 报了在 160 TPS/User 下每兆瓦 30×（NVIDIA 自测、标注待 SemiAnalysis 复核），那是另一个评价轴，本章不并入。

本章要建立的判断习惯：看到任何一个"X× 加速"，先问它的四元组是什么。没有四元组的倍数，是不可比的。

二、一块芯片为什么在不同负载下兑现不同的规格？——把三块规格钉到三个屋顶上

第一章留下了 5× NVFP4、2.4× HBM、1.7× NVLink 这三块规格抬升。它们看起来像是"硬件的三份红利"，但每一份能不能兑现，取决于你跑的是什么负载。要讲清这件事，需要一个分析工具：Roofline。

Roofline 的思路很朴素：一块芯片有两堵墙，一堵是算力上限 $P_{peak}$，一堵是显存带宽上限 $\beta$。一个操作能达到的性能，取决于它的算术强度 $I$，也就是每读取一个字节能完成多少次运算：

$$P_{att}(I) = \min(P_{peak}, \beta \cdot I)$$

算术强度低时，性能被带宽卡住，落在斜线（带宽屋顶）上；算术强度高时，性能被算力卡住，落在水平线（算力屋顶）上。两条线的交点叫 ridge point，位于 $I^* = P_{peak} / \beta$，它是"内存受限"和"计算受限"的分界。Roofline-Survey

图注：Roofline 的几何形状。横轴是算术强度，纵轴是性能。左侧斜线的斜率就是带宽 $\beta$（带宽屋顶），右侧水平线高度是算力上限 $P_{peak}$（算力屋顶），交点是 ridge point。图中数字来自一张 A6000 显卡的 FP16 实测，ridge 大致在 200 FLOPs/byte 附近；Rubin 的屋顶坐标要按新的算力和带宽重新插值，不能照搬。Roofline-Survey

这个框架对 LLM 推理的解释力，在于它把 prefill 和 decode 放到了两个完全不同的位置。同一篇调研用 Llama-2-7b 逐层算过：prefill 阶段，投影层的算术强度在 1024 到 1215 FLOPs/byte，远在 ridge 右侧，是计算受限；decode 阶段，所有投影层的算术强度都掉到大约 1 FLOPs/byte，远在 ridge 左侧，是内存受限。原因很直接：decode 每一步只处理一个新 token，却要把所有权重矩阵完整读一遍，读的字节数远大于算的次数。Roofline-Survey

这就给出了一个反直觉的结论：同一块芯片，是工作负载把它推上不同屋顶的。decode 撞带宽屋顶，prefill 撞计算屋顶，跟芯片"有多强"关系不大，跟你在跑什么关系很大。

现在把 Rubin 的三块规格钉到三个屋顶上。Rubin 单芯片三项关键规格是：Transformer Engine 3 提供最高 50 PFLOPS 的 NVFP4 推理算力，HBM4 最高 22 TB/s 带宽，NVLink 6 提供 3.6 TB/s 的卡间 scale-up 带宽。Rubin-Arch

图注：Rubin GPU 的芯片版图与规格标注。三项关键规格分别对应三个屋顶：896 个 Tensor Core 提供的 NVFP4 算力钉在计算屋顶，288 GB HBM4 的 22 TB/s 带宽钉在带宽屋顶，NVLink 6 的 3,600 GB/s 钉在跨卡通信屋顶。图中还能看到 NVLink-C2C、PCIe Gen 6 等互联标注。这些数字是硅层的物理上限，至于负载能不能兑现它们，取决于负载本身站在哪个屋顶下。Rubin-Arch

把负载落到屋顶上，逻辑就清楚了。长上下文注意力和 KV cache 的读取，算术强度接近 1，压在带宽屋顶下；MoE 的 decode 阶段因为稀疏专家、每次只激活少数专家但要把权重读进来，同样是访存主导，同时还要跨卡把 token 发给对应专家，于是带宽和通信两个屋顶一起压上来；跨卡 MoE 的 all-to-all 集合通信（所有卡之间互相转发 token），则直接撞在 NVLink 通信屋顶上。

用一张图把这三个屋顶和负载的对应关系固定下来：

图注:三类负载均压在带宽与通信屋顶,计算屋顶空置

回到第一章那三块规格：5× NVFP4 抬的是计算屋顶，2.4× HBM 带宽抬的是带宽屋顶，1.7× NVLink 抬的是通信屋顶。如果负载压在带宽或通信屋顶下，那 5× 的算力抬升一分钱都兑不出来；反过来，只有在负载站到相应屋顶下时，那一项规格才变成真实收益。第一章里 Rubin 相对 GB200 的 5× / 2.4× / 1.7×，正是这三块屋顶各自被抬高的比例，而不是三份可以叠加的红利。vLLM-Rubin

如果你想把这套框架用在实际部署上，它已经有现成工具：LLM-Viewer 接受模型配置和硬件配置两路输入，输出逐层的 roofline 分析和瓶颈报告，让"哪一层卡在哪个屋顶"从纸面变成可查的结果。Roofline-Survey

图注：LLM-Viewer 的工作流。左侧两个输入框分别填入 LLM 配置和硬件配置，中间经过推理配置和优化配置，进入分析器，输出逐层与全局网络的瓶颈报告。它把 Roofline 这个框架接成了可操作的工程工具，而不是停留在纸面上的示意图。Roofline-Survey

本章要建立的判断习惯：峰值规格本身没有意义。先把它钉到某个屋顶上，再看你的负载站在哪个屋顶下，才知道哪一项规格能被兑现。

三、内核快了 20%，为什么端到端只快 5.9%？——Amdahl 给软件贡献封顶

硬件规格钉到了屋顶上，接下来看软件。软件侧的数字往往很漂亮：一个内核快 20%，一个优化快 1.5 倍。但如果这些加速只发生在整条链路的一小段上，端到端就吃不到多少。

先看一个典型例子。SGLang 团队在 Rubin 上把 MLA（一种高效的注意力实现）的解码内核做了加深：Blackwell 上每 CTA 的共享内存上限是 227 KiB，只能塞下 3 个 K stage 和 2 个 V stage；Rubin 把上限提到 327 KiB 后，刚好能多塞一个 K stage 和两个 V stage。这一改，让 MLA 在 batch 16、128K 上下文下提速 16%，而且输出是 bit-identical 的，也就是数值完全一致。SGLang-K3

图注：单条 MLA decode kernel 的 K/V 流水线示意。上方是 K 通路，从 HBM 经 TMA 加载进入共享内存的 ring buffer（3 到 4 个 slot），再接 QK 矩阵乘和 softmax；下方是 V 通路，类似地从 L2 加载进入 ring buffer（2 到 4 个 slot），再接 PV 矩阵乘。底部标出共享内存用量从 224 KB 增到 324 KB，正好落在 Rubin 的 327 KB 上限内。这张图说明的是：局部 kernel 的收益天花板，由片上共享内存容量决定。SGLang-K3

这个内核的收益可以做得更激进。把 KV 的 reduce 模式从"加载—等待—加载"改成"先全部发加载、再从寄存器累加"，full FP8 MLA 在 batch 1、128K 上下文下能提速 20%。也就是说，单个内核在合适条件下能拿到 16% 到 20% 的加速，甚至局部能到 2.5×。

但端到端是另一回事。同一个团队发现，每个 MoE 层末尾依次要做四步：finalize 专家输出、叠加 shared expert、跨 8 卡 all-reduce、RMSNorm。这四个 kernel 都很小，launch 开销占主导，而 Kimi K3 有 92 个 MoE 层，每层每个 decode step 都要付这个代价。他们把四个小 kernel 融合成一个，每个 decode step 减少 276 次 kernel launch，端到端拿到 5.9%。SGLang-K3

注意这里的落差：局部内核快 16% 到 20%，端到端只有 5.9%。这不是哪一步做错了，而是 Amdahl 定律的必然结果。Amdahl 说，一个局部优化的整体收益，被它在链路里所占的比例限制住。内核再快，如果它只占端到端时间的一小块，那么整体加速就有限。

vLLM 侧的数字是同一回事的另一个 scope。他们用 CUDA 13.4 的 locality domain（局部性域）把 MoE 权重按就近的内存切分，让 SM 只读离自己最近的权重分片，得到 FC1 + FC2 这两层 GEMM 上约 1.18× 的平均加速。vLLM-Rubin

图注：MiniMax M3 的 MoE 层上，开启与不开启 locality domain 的 FC1 + FC2 延迟对比。蓝色是不启用、黄色是启用，横轴是 token 数（从 32 到 4096）。加速比随 token 变多而衰减，从约 1.20× 降到约 1.13×，TP2 档位的几何平均是 1.18×。关键限定是：这是层内 GEMM 的加速，不含通信时间，所以它是内核局部收益，不是端到端收益。vLLM-Rubin

学术侧的 megakernel 研究给出了同一机制的物理层证据。MegaFlux 把 MoE 层内的 dispatch、专家计算、token 合并、副本权重传输融合进一个 persistent kernel，让每个操作在依赖就绪时立刻启动，而不是等整阶段的 barrier。MegaFlux

图注：MegaFlux 相对同一 megakernel、固定放置策略的加速比。横轴是每个 rank 的 token 数（对数刻度），纵轴是相对固定放置的加速比，各列对应不同的专家分布，曲线对应不同的专家数。几何平均在 forward 是 1.45×、backward 是 1.28×，峰值能到 2.14× / 2.64×。需要注明的是：这是与同一 megakernel 的固定放置对照，且只在 8×B200 EP8 单一 NVLink 域上测得，不能外推到 Rubin。MegaFlux

把这三组数字摆在一起，它们的 scope 各不相同：层内 1.18×（不含通信）、单 kernel 16% 到 20%、端到端 5.9%。正因为 scope 不同，它们不能相加，写"合计约 X%"是错的。SGLang-K3 Amdahl 给软件贡献设了天花板，收益大小取决于这个操作在整条链路里被重复了多少次、又占了多大比例。

这里还有一个边界值得记住：不是所有优化都是 bit-identical 的。MLA 加深和 KDA verify 的重排是数值一致的，但 SGLang 里那个把 FP8 转换改成饱和模式的优化虽然让准备内核快了 2.5×，却改变了溢出行为（溢出被钳到 ±448 而不是变成 NaN），所以它不再是 bit-identical。判断一个优化能不能上线，除了看加速比，还得看它有没有悄悄改变数值。

本章要建立的判断习惯：单 kernel 的加速比不是端到端的加速比。看到局部收益，先问它在链路里被重复了多少次、占比多大。

四、把 5 倍的芯片和 1.2× 的内核乘起来，能得 7.84× 吗？——三者交互项才是答案

现在回到最开始那个算术题：7.84× 是不是等于 5×（NVFP4 峰值）乘上 1.2×（内核）？

答案是不能，而且原因不止一个。首先，5× 是峰值算力、2.4× 是带宽、1.7× 是互联，这三者落在不同的屋顶上，本身就不是可以相乘的独立因子——第二章已经说清这一点。其次，真正把这几个数字抬到 7.84× 的，不是它们各自相乘，而是三者之间的交互项。

先说硬件容量这一步。Rubin 抬高了带宽和互联屋顶，这不只是让单个操作更快，更重要的是它抬高了批量上限和并行上限：更多的并发请求能同时塞进显存，跨卡通信能更快地把专家输出汇回来，于是系统能在更低的延迟下用满硬件。这个效应在换一个评价轴时会看得更清楚。NVIDIA 报了每兆瓦吞吐这个口径：在每秒每用户 160 token 这个取点上，Vera Rubin 相对 GB300 给出 30× 的每兆瓦吞吐。NVIDIA-Perf/W

图注：Vera Rubin 相对 GB300 NVL72 的每兆瓦吞吐随交互速度变化的曲线。横轴是交互速度（TPS/User），纵轴是每兆瓦吞吐。图中有 2×、10×、30× 三个标注，越往高交互速度走，差距越大，30× 出现在大约 160 TPS/User 处。图下方有"Unofficial Results. Pending SemiAnalysis Review"脚注，引用时不能省；30× 只在那一个取点上成立，不能写成"Rubin 一律 30×"。NVIDIA-Perf/W

这里还得区分口径：30× 是对 GB300 NVL72、DeepSeek V4-Pro、每兆瓦这个口径，而 7.84× 是对 GB200 NVL72、MiniMax M3、每芯片这个口径。两者来自不同的基线、模型与指标，不能只当成同一组数字换了个坐标轴。这也说明 7.84× 不是"硬件红利"的固定值。

再说内核这一步。内核消除的是局部的空泡，也就是计算之间的等待。Rubin 在微架构上把 kernel 之间的触发粒度做细了：Blackwell 是一个全局触发，生产者 kernel 全部完成后才唤醒所有消费者；Rubin 改成逐 tile 触发，每个消费者块在它依赖的那块数据就绪时就能开始。这类改动和 SGLang 的 MoE tail 融合是同一个方向：把等待时间吃掉。Rubin-Arch

然后是工作点这一步。AgentX 这类负载的特点是长上下文、高并发，而且 96% 以上的前缀可复用。在这种负载下，吞吐—延迟工作点的选择会反过来改变批处理和并行效率。vLLM 用两阶段 rate-matching 来找这个工作点：先做饱和度剖析，分别跑纯 prefill 和纯 decode，扫不同的并行策略和部署规模，把吞吐跑到饱和；再据此推导 prefill / decode 的比例，在合并部署上扫并发，收集整条曲线上的指标。vLLM-AgentX

把三者放到一起，交互项就浮出来了：硬件容量扩大，让内核优化的边际收益变大（同样的等待时间，在更快的硬件上占比更显眼）；内核清空空泡，让硬件容量能在更低的延迟下被用满；工作点决定哪一组交互被触发。任何一项单独抽出来，都拿不到这个乘积。

半导体的实证里，有一组数字能说明这种归因有多难。SemiAnalysis 记了两个不同的内核改动：一个是把整图注意力投影接到调优过的 AITER GEMM，在固定序列低并发下录到 2.3%；另一个是 AITER sparse-MLA 解码内核，在 AgentX 轨迹上录到 5.22% 的吞吐提升。页面据此的判断是定性的——同一类内核改动在均匀形状上可能有干净增益，在 agentic 轨迹上却可能被缓存与调度变化淹没；它并未给出前者在 agentic 上的对照值。InferenceX-optim

图注：vLLM 连接器层的结构示意。调度步（左上）驱动连接器层，在 GPU HBM 与 CPU DRAM 池之间搬运 KV cache，GPU HBM 里区分 full-attention、sliding-window、recurrent 三类 KV 组，CPU 侧停放来自多个并发会话的前缀；连接器层里列出若干 PR 和三条收窄写入的 store 规则。这张图用来说明：优化集中在缓存层和每层 decode 内核两层，两层之间存在明显的不对称，也就是"同一类内核改动在不同负载上可能被缓存与调度变化放大或淹没"的现象来源。图中不含任何百分比数字。InferenceX-optim

本章要建立的判断习惯：7.84× 是三者耦合出来的系统级结果。做加法归因会同时高估和低估，它是瓶颈迁移的产物，不是某一处的胜利。

五、怎么才能真的把账算清？——受控消融与匹配的对比合同

既然倍数不能相加，那要拿到可信的归因，只能靠受控消融：固定其余一切，每次只动一个变量。这不是一句口号，而是一整套对比合同。

SemiAnalysis 的 AgentX 方法论给出了这套合同的样板。它把真实请求轨迹转成固定长度的块哈希，再重放成带依赖关系的有向无环图。AgentX-Method

图注：AgentX 从轨迹到重放的完整流程。左侧是原始请求轨迹，右上是时间轴（主代理、两个子代理、一个辅助请求并行推进），右下是依赖关系图，子代理在某个父请求完成后派生、在下个依赖请求前汇合，最后三路 join。它说明"可比"意味着锁死同一份请求分布与同一套依赖结构。AgentX-Method

这套合同锁定的东西包括：同一份语料、同一种 warmup、同一精度、按装机比例 1:1 的 KV offload 配置、同一并发扫描、同一 per-chip 报告口径、同一份强制 acceptance 文件版本，甚至要求把失败和不稳定的配置也照报。AgentX-Method 每一条去掉，加法归因就会把一个污染变量当成真实贡献。

把归因法落成可操作的实验轴，大致是三条，按顺序做。第一步，同软件跨硬件：让软件配置完全一致，只换硬件，隔离出硬件容量的贡献。第二步，同硬件开关专属内核：硬件不动，只开关 Rubin 专属的内核优化，隔离出软件贡献。第三步，扫真实请求分布：前两步都在固定负载上做，这一步换成真实 agentic 分布，隔离负载形状的影响。vLLM-Rubin vLLM-AgentX

而无论哪一步，都比的是整条吞吐—延迟曲线，不是单个点。为什么单点不够，看一张实测的 Pareto 曲线就明白了。

图注：B200 上 vLLM 跑 MiniMax-M3 的每芯片吞吐对 P90 交互速度曲线。横轴是 P90 交互速度，纵轴是每芯片吞吐，曲线上有 7 个并发度取点，从高并发的高吞吐低交互速度，单调走到低并发的高交互速度低吞吐。单个并发点无法描述一次 agentic 运行，所以必须在匹配的交互速度下比较整条曲线。这张图仅在 B200 单一 SKU 上测得，不能外推。AgentX-Method

交付物也应该是一条曲线加每任务成本，而不是一个峰值倍数。vLLM 给出的这块面板把多个平台放在同一坐标系里比，还标注了每芯片每小时的 TCO。

图注：Kimi K3 在多种硬件上、不同 P90 交互速度下的每美元 token 数。横轴是 P90 交互速度，纵轴是每美元 token 数，五条曲线分别对应 GB300 NVL72、GB200 NVL72、B300、B200、MI355X，顶部列出各自的每芯片每小时成本。它说明采购判断应该看整条曲线和每芯片每小时成本，而不是一个孤立的峰值倍数。注意其成本假设是大客户批量，不是云租赁，也不能外推到 Kimi K3 以外的模型。vLLM-AgentX

读数字之前，还有一步不能省：先问口径。MLPerf v6.1 里那个"preview"标记，指的是平台可用性，不是数据可信度；真正未过 MLCommons 验证的，是提交截止之后继续优化、标注为 unverified 的那部分结果。把这两件事混为一谈，就会误判一个数字到底能不能用。MLPerf-v6.1

本章要建立的判断习惯：可信归因等于固定其余一切、每次只动一个变量，并交付两样东西——用来隔离变量的消融数字，和真实请求分布下的整条曲线。

六、下次跨代再报一个倍数，先问什么？——瓶颈迁移是机制，倍数只是症状

把前面五章串起来，结论可以用一句话收束：Rubin 的 7.84× 是带宽与互联恰好解除了 agentic MoE 工作负载的瓶颈之后，被并行策略和吞吐—延迟工作点共同放大的系统级结果。它是瓶颈迁移的产物，不是某一处的胜利。

"瓶颈迁移"的思路是：加速的本质不是某个部件变快，而是把瓶颈从一处挪到另一处。前一代卡在带宽上，新一代把带宽屋顶抬高，负载就往前跑，直到撞上下一个屋顶。这个机制在时间维度上也能看到。Rubin 把 kernel 间的触发从 Blackwell 的整体触发改成了逐 tile 触发，每个消费者块在依赖数据就绪时就能启动，等待的间隙被压小了。Rubin-Arch

图注：生产—消费重叠的演化。上方面板是 Blackwell 的整体触发：生产者 kernel 完成后统一唤醒消费者线程块；下方面板是 Rubin 的逐 tile 触发：每个消费者线程块各自在依赖的就绪数据到达时启动。图中没有坐标轴，不能据此推出绝对时间值，它说明的是 kernel 之间等待间隙在变短。Rubin-Arch

用一张图把"瓶颈迁移"这个机制固定下来，方便带走：

图注:每代抬高的屋顶，同时把负载推向新的瓶颈方向

这张示意图想说的是：每一代抬高的屋顶，同时也是把负载推向的新方向。带宽和互联被抬高之后，agentic MoE 的瓶颈被松开，负载往前跑，下一个大概率会撞上的屋顶，是长上下文注意力的 KV cache——因为 decode 和长上下文注意力这两种负载的算术强度都约等于 1，长期压在带宽屋顶下，而上下文越长，KV cache 的读取压力越大。Roofline-Survey

所以判断也该跟着机制走。下一次看到跨代报一个倍数，先问两件事：它解除了哪个屋顶？它从中拿走了多少？前一个问题靠 Roofline，后一个问题靠整条吞吐—延迟曲线和每任务成本。Roofline 让你把每一项规格钉到屋顶上，看清哪些规格在给定负载下能兑现；整条曲线和每芯片每小时成本让你看清这套配置在什么工作点上是划算的。

至于选型，别盯着单个峰值倍数。这里有两类工具，分工不能混。要预判下一个屋顶大概率落在哪里，靠的是 Roofline：它按算术强度把每一项负载钉到带宽屋顶或算力屋顶上，长上下文 KV 这类负载的算术强度长期约等于 1，一直压在带宽屋顶下，下一代大概率会撞上的位置由此推出。要判断某个给定工作点划不划算，靠的则是另一类工具，也就是第四章那张每兆瓦吞吐曲线和采购面板：前者按交互速度给出每兆瓦能换到多少吞吐，后者比较不同平台在高并发、高交互速度区的性价比。Roofline 回答"瓶颈在哪"，每兆瓦与采购曲线只回答"在某个取点上这样配划不划算"，不能把后者当成预测瓶颈的依据。这两件事合起来，就是"瓶颈迁移是机制、跨代总分只是症状"这句话落到工程上的样子。vLLM-AgentX

本章要建立的判断习惯：瓶颈迁移是机制，倍数只是症状。先问它解除了哪个屋顶，再问它从中拿走了多少。

参考文献

本专题引用的核心资料如下，建议深入学习时阅读原文：

1. vLLM Support for NVIDIA Vera Rubin NVL72: 7.8× Throughput over GB200 NVL72 — https://vllm-project.github.io/2026/10/09/vera-rubin-preview.html
2. NVIDIA Vera Rubin and Blackwell Set a New Standard for Agentic AI Performance per Watt — https://developer.nvidia.com/blog/nvidia-vera-rubin-and-blackwell-set-a-new-standard-for-agentic-ai-performance-per-watt/
3. Inside NVIDIA Rubin GPU Architecture: Powering the Era of Agentic AI — https://developer.nvidia.com/blog/inside-nvidia-rubin-gpu-architecture-powering-the-era-of-agentic-ai/
4. NVIDIA DGX Vera Rubin NVL72 Datasheet — https://resources.nvidia.com/en-us-dgx-systems/dgx-vera-rubin-nvl72-datasheet
5. NVIDIA Vera Rubin NVL72 Delivers Leading Performance in MLPerf Inference v6.1 Debut — https://blogs.nvidia.com/blog/vera-rubin-nvl72-mlperf-inference/
6. SGLang and Miles on NVIDIA Vera Rubin — https://www.lmsys.org/blog/2026-10-09-vera-rubin/
7. AgentX Methodology (InferenceX by SemiAnalysis) — https://inferencex.semianalysis.com/agentx/methodology
8. vLLM x AgentX: Optimizing for Real-World Agentic Serving — https://vllm.ai/blog/2026-09-08-vllm-agentx
9. vLLM Agentic Optimizations (InferenceX AgentX optimization tracker) — https://inferencex.semianalysis.com/agentx/optimizations/vllm
10. MegaFlux: Skew-Resilient MoE Megakernels via Pipelined Expert Replication — arXiv:2610.00671
11. LLM Inference Unveiled: Survey and Roofline Model Insights — arXiv:2402.16363