在一张卡上读作 mem_busy；拿 H200、B300、PRO 6000 和第二张 H100 检验，并对照一份在跑数据之前就写下的预测
Qwen3-8B 做一步解码，单卡内存控制器有 87 % 的时间处于忙碌；换成 gemma-4-26B-A4B，这个数字是 38 %。只要在一张卡上读出这个值，就能预测两者之中谁更能从更快的卡、第二张卡或更快的显存中获益，谁又会在更慢的显存上承受更大损失。这些预测成立的硬件，此前甚至从未做过实测。但它说不出差出多少。一份在数据之前写下的预测把这件事记录在案。
本仓库此前的所有推算，都基于办公桌下的两张 Radeon 以及 Colab 提供的有限算力。这次租机为解码和预填充阶梯补充了六种机器配置（H100、H200、B300、RTX PRO 6000、两张 H100 和两张 PRO 6000），并在集合通信上补充了八种配置。整轮实测产出 586 次阶梯测量与 385 个集合通信格，0 个错误，并首次将上下文长度推进至 32 000 token 以上。测试首先设立了两个平台对照：在同一平台上租用的 A100 和 L4，复现 Colab 已入库数据行的偏差仅为 0.07 % 与 0.9 %，这让我们能够放心地将后续所有比值都视为显卡本身的差异。
结论是一个计数器。在 campaign-2026-09-02d 中，单卡上的内存控制器忙碌比例（mem_busy）决定了第二张 Radeon 能带来多少提升：在 bf16 8B 模型上该值为 90 %，加速比为 1.70×；在 w4a16 12B 上该值为 56 %，加速比为 1.20×。此前这只是单台机器上的五个格子。如今，这个计数器成功给五种场景的测试结果排出了相同次序：一种在这一对卡上，另外四种以单张 H100 为基线。这四种场景包括 H200、B300、PRO 6000（由于显存更慢，收益方向相反），以及通过 NVLink 连接的第二张 H100；对于读取显存最少的模型，其提升仅有 2.9 %。然而，它无法预测幅度。在运行 H200 测试前，我们预先提交了一份预测。实测结果表明两端的相对顺序完全正确，但实际跨度几乎是预测值的两倍。在受限于显存的一端，性能增益甚至超过了显存时钟频率之比本身，而这是所用模型公式无论如何也推算不出的。它能排序，不能定量，记录在案的结果正是如此。
互连线路并不是决定性的主轴，如今这一点已经得到了实测验证。在八种配置中，集合通信在带宽端的跨度高达 62×，而延迟端仅相差 3.2×。batch-1 解码每次仅归约单行数据，因此落在延迟端。NVLink 在双卡时能带来 20 % 的提升，在四卡时提升则达 171 %。测试还引出了另外三项发现：四张显卡在未指定任何启动参数的情况下自动选择了三种不同的 attention 后端；租金 $7.10/h 的 B300 在 MoE 模型上不敌 $3.95/h 的 H100，但在 8B 模型上却胜出 66 %；在上下文长度超过 32 000 token 后，真正使解码曲线趋于平缓的是有界的 attention 窗口而非循环状态，这推翻了运行前写入 runner 的预期。
下文涉及的所有比值，均以 Modal 上租用的显卡数据除以八月份在 Colab 上实测的 A100 或 L4。跨平台对比的前提是两个环境的表现保持一致。为了直接检验这一假设，我们在 Modal 上租用了同型号的两张卡，在相同的模型、上下文预算以及 Colab 采用的阶梯档位下重新运行。
gemma-4-12B 在一张 A100-SXM4-80GB 上四个档位的解码：Colab 于 2026-08-29 与 2026-08-30，
Modal 于 2026-09-03。Modal 这次在每一档都落在 Colab 第二次的 0.07 % 之内，比 Colab 自己两次会话
之间还要近。这个区间不是看了答案之后定的：那四行 Colab 数据从八月起就已入库。L4 对照在一张不进入任何结论的卡上说了
同样的话：32 000 处 25.29 tok/s，对 Colab 的 25.07 与 25.17。
指标 mem_busy_pct 记录的是采样中内存控制器处于忙碌状态的时间比例。每台机器上都由同一个采样器统一读取该指标（见 harness/telemetry.py：Radeon 上读取 amdgpu 的 mem_busy_percent，CUDA 卡上读取 NVML 的 utilization.memory）。它代表的是忙碌比例而非实际达到的有效带宽；测试套件 harness 将两个平台上的实际带宽均标记为缺失，并阐释了具体原因。在 2026-09-02 那天，仅凭在单张 Radeon 上测量两个模型的该指标，就成功推断出了第二张卡的价值。接下来的五种场景旨在对这一排序规律进行检验：每种场景保持模型固定，并对比计数器取值区间两端的表现：
mem_busy。这一对卡自己的场景是 2026-09-02d，它的两个模型是 bf16 的 8B 和 w4a16 的 12B —— 那场 campaign
跑的就是它们；四种租机场景比较的是 H100 自身区间的两端，87 % 的 Qwen3-8B 和 38 % 的 MoE。
在每一种场景里，吃显存重的那一端离 1.0 都比吃算力重的那一端更远，不论场景往哪个方向走 —— 包括显存更慢的 PRO 6000，
在那上面从更多带宽赚得最多的模型，也在更少带宽上亏得最多。最后一行读两遍：mem_busy 38 % 时，
NVLink 上的第二张 H100 值 2.9 %。
五种场景下的排序在真正做出有效预测之前，终究只是一种相关性。H200 提供了最纯粹的检验场景：它与 H100 拥有相同的计算能力、700 W 功耗上限以及 SM 时钟频率上限，区别仅仅在于显存更快。如果一步解码有比例为 f 的时间在等待显存，其余时间用于其他开销，那么将显存速度提升至 r 倍后的理论加速比即为 1 / ((1 − f) + f / r)。这里的 f 取单张 H100 基线上的 mem_busy。比值 r 则直接取自两张卡实测的最高显存时钟频率：2 619 对 3 201 MHz，计算得 1.222，而非采信本仓库未曾独立验证过的厂商标称带宽。这六项预测在实际运行之前均已提交入库。
gemma-4-31B 用 2 000，因为它在 H200 上 500 档的两轮相差 13 %。
两端的次序是对的，而且分得很开。跨度不对：实测 0.210 对预测的 0.114，而且
Qwen3-8B 的 1.254× 超过了 r 本身 —— 对任何 f ≤ 1，那个公式都给不出这个值，
所以错的是 f 而不是 r，而且不是差一个常数倍。这个计数器能排序，不能定量。一个独立的旁证说明机制是对的、只是算术不对：H200 上六个模型的 mem_busy
全都低于 H100，没有一个交叉 —— 更快的显存做同样的活，让控制器忙碌的时间更短，这正是模型说应该发生的事，
而它不是拟合出来的。
关于 a100 的那篇文章在第 9 节中曾断言，第二张 Radeon 的带宽开销主要耗费在互连上。但在 allreduce-2026-09-02 这一 campaign 中，通过在这一对卡上的直接测量推翻了该结论。在 CUDA Graph 回放机制下，每次集合通信仅需 16.6–21.5 µs，大约相当于单步解码的十分之一耗时。第二张卡把一个模型提到 1.70×，另一个只有 1.20×，两者付出的通信开销完全一样。在七种 NVIDIA 配置上开展的同等横扫，为推翻此前结论提供了扎实的机制解释。
Qwen3-8B 的一行）处的 t_graph_us：一个 token，即一步解码；
以及 16 384 个 token，即一次预填充。所有 NVIDIA 运行都是 NCCL 2.29.7，Radeon 上是 RCCL 2.27.7，同一个脚本。
八种配置上带宽端跨 62×，延迟端跨 3.2×；只看双卡，延迟端跨
1.5×，对面仍是同样的 62×。batch-1 解码归约的是一行，落在延迟端 —— 在那里一对 B300 只比这一对
Radeon 快 1.2×，而在另一端快 62×。这就是第二张卡的价值跟着内存控制器走、而不跟着互连走的原因：互连的
区间是真实的，推理从来不曾进入它。NVLink 是为第四张卡准备的。加上第三、第四张卡，H100 一步解码变成
×1.22、带宽端 ×1.30；PCIe 上没有 NVLink 的 PRO 6000 是 ×2.71 与 ×2.99。没有 NVLink 的两张卡比有的贵
20 %；四张卡贵 171 %。而四张 H200 与四张 H100 在两端都吻合在 1 % 之内，所以第 3 节里 H200 阶梯上的优势
没有一分是从线路上来的。
同样的 vLLM 版本，同样的命令行，整轮横扫中未传入任何指定后端的参数。runner 直接从每份 serve 日志中解析实际启用的后端，而不是轻信静态配置表，这也是各后端分歧得以暴露的唯一原因。由于 vLLM 0.28 并未提供显式指定解码器后端的参数（检查安装包可知，attention_backend 仅存在于 config/speculative.py 中），因此无法构建对照组来将显卡硬件与 GPU 内核的影响隔离开来。
Qwen3-8B 上比 $3.95/h 的 H100 快
66 %，在 gemma-4-12B 上快 4 %，在 gemma-4-26B-A4B 上输了
—— 次序与计数器的一样，因为 B300 的优势是带宽，而 MoE 读得最少。按美元算它三个都输。B300 还换了 attention 后端，
所以它那一列里机器和后端一起在动；价格是 Modal 在 2026-09-03 的价目表，是本页上仅有的手打数字。
在此轮横扫之前，本仓库的所有测量阶梯均止步于 32 000 token；此次测试中，H100 将五个模型成功推进到了 128 000。运行之前，已将一份预测写入 runner 中。参测模型采用了三种截然不同的 attention 设计：gemma-4 读取的 KV cache 随长度无界增长；Qwen3.8-27B 维护的循环状态则完全不随长度增长；而 Muse-Glimmer-30B 借助 2 048 token 的滑动窗口计算 attention，开销先随长度增长随后固定。据此，先前的预测认为 Muse-Glimmer 的表现将介于两者之间。
Muse-Glimmer-30B
在 128 000 处只丢掉 500 token 速率的 4.8 %；hybrid SSM 丢掉 21.8 %，
和稠密 31B 的 22.0 % 一样远。带循环状态的模型不是平的那个。让曲线变平的是有界的 attention 窗口，不是固定大小的状态
—— SSM 仍然带着开销随深度增长的 attention 层。同样的次序出现在一个独立的量上：32 000 处从 A100 换到这张 H100，
对 Muse-Glimmer 值 1.36×，对 SSM 值 1.45×，对三个 gemma 模型值 1.90–2.16×。一个混淆因素，
而且它反着结论走：Muse-Glimmer 是唯一一个 W4A16 内核随机器变化的模型 —— Hopper 上是 Machete，别处是 Marlin —— 而
Machete 在 Hopper 上是两者中更快的那个。
局限性在第 3 节中显而易见。公式 1 / ((1 − f) + f / r) 以单卡测得的 f 代入，将实际跨度低估了一半，且完全无法推算出受限于显存的一端。这背后存在两种可能：要么有效带宽比高于显存时钟比（厂商标称数字给出 1.43，若以此代入，该公式又会全面高估每一行）；要么 H200 与 H100 之间存在此前预测时忽略的其他硬件差异。当前测试无法对这两种因素做出解耦。
图 6 中的 B300 数据列以及所有 gemma-4 的对比，均混杂了显卡硬件与后端实现的双重影响。由于 vLLM 0.28 无法固定解码器后端，这项对照未做实测。
gemma-4-26B-A4B 无法在 TP=4 下运行，报错为：CompressedTensors WNA16 MoE with static group scales requires the MoE intermediate size per tensor-parallel partition to be divisible by group_size (32)。这是 checkpoint 本身的结构约束，并非重试不足所致。其余四个模型在 TP=4 下的测试，以及 Muse-Glimmer 在租用的这一对卡上的 TP=2 测试，则受限于预算未予采购。
mem_busy 反映的是忙碌时间占比：某一速率下的 87 % 与另一速率下的 87 % 绝不能划等号，且两个平台上均缺少实际达到的带宽数据。计数器可以在机器间迁移，但其分母基数却无法随之带走。此外，它本质上横跨了两个不同的驱动指标：Radeon 上的 amdgpu mem_busy_percent 与 CUDA 上的 NVML utilization.memory。同一个采样器读取出的同一对模型，在两端分别测得 90/56 与 87/53，这只能说明两个计数器的度量特性相近，但绝非严谨的证明。
H200、B300、PRO 6000 以及第二张 H100 的数据行，除以的都是单次 H100 会话的测量值，因此该会话若存在任何系统偏差，会导致这四行数据发生同向偏移。平台对照将该会话与 Colab 的差异严格限定在 0.07 % 之内，而这一对卡则是在另一套物理机器上完成测试。因此，这五种场景整体上构成了对这一对卡实测发现的一次独立检验，而非五次。
租用卡上有二十三个预填充格子未通过可重复性筛选，全部集中在 500 至 2 000 token 之间，对应冷启动阶段的头几次请求。解码也有两个格子没过，都在 H200 上：gemma-4-26B-A4B 的 1 000 档与 gemma-4-31B 的 500 档。上文的所有结论均不依赖这些格子。
全部材料。各 campaign 目录、runner、serve 日志以及集合通信扫描均开源在 benchmarks/cuda-modal/。预测与追加的裁决见 cuda-h200/campaign-2026-09-03/PREDICTION.md。除已注明的两项价目表价格外，文中的每一个数字均由 verify_doc_figures.py 从已入库的数据行中重新计算得出。
该计数器本身，以及在这一对卡上促成此项测试的五个格子，详见 另一篇文章的第 9 节。