两张 Radeon 上的解码速率与预填充扩展；对照单卡、A100 和 L4 实测
给 batch-1 解码再加上第二张消费级卡，只带来 1.11× 到 1.23×。在 prefill 上，同一张卡把 32 K 提示的处理时间从 40.1 秒降到 21.5 秒，收益达到 1.87×。两项实测在同一天跑在同样两张卡上，变化的只是交给它们的任务。
这篇文章原先只问了一个问题：两张消费级卡对一张 A100 表现如何。这个问题实际上捆绑了三个独立议题。把每张卡单独拿出来测，才能将它们拆开：单张消费级卡对比数据中心卡值多少，第二张消费级卡能补上什么，最后才是这一对卡合起来能跑出多少。
第二张卡在解码上增益很小。在十一个深度和两个模型上，它只带来 1.11× 到 1.23×。此后测得的每步 all-reduce 表明通信并非瓶颈，它只占单步时间的大约九分之一。在同一台机器上，承担同样集合通信开销的 Qwen3-8B 却能从第二张卡获得 1.70×。拖住这两个模型的并不是互连带宽，第 9 节给出了真正的原因。而在 prefill 上，同一张卡按实际耗时快 1.56× 到 1.87×，因为注意力计算的并行完全不需要通信。
prefill 包含两个行为不同的项。按 T(S) = a + bS + cS² 拟合，在稠密的 12B 模型上，A100 对比单张 7900 XT 在 b 项上领先 3.3×，在 c 项上领先 6.7×。注意力的扩展差距是算力差距的两倍。而在 4B 激活参数缩减了算力项的混合专家模型上，两个差距重合在 5.75× 与 5.71×。数据中心芯片也并非在所有维度上都更快：L4 在 b 项上甚至慢于消费级 7900 XT（0.90×），仅在 c 项上领先 3.0×。数据中心与消费级从来不是单一维度的比较。
将双卡组合对照单张 A100 评估是第三步，这回到了本文最初的起点。在不开启投机解码时，A100 在阶梯全部十一个深度上均保持 1.30× 到 1.46× 的领先。这一差距全程保持平稳，与最初四个单次实测点所暗示的 U 形走势完全不同。
共有四种机器配置参与比较：单张 RX 7900 XT、两张卡配置在 TP=2、单张 A100-SXM4-80GB 以及单张 L4。受限于三种硬件架构，并非每个模型都能在所有机器上运行；其中两处缺失是显存装不下，不是漏测。gemma-4-26B-A4B 在单张 7900 XT 上只测到 12 000 token：在 19.98 GiB 的显卡上驻留 16.96 GiB 权重后，即便显存利用率设为 0.95，也仅剩下 0.93 GiB 用于 KV 缓存，而扩展到 32 K 则需要大约 0.97。此外，gemma-4-31B-it 完全没有单卡数据行，因为 22 GB 的权重无法装入 20 GB 的显卡，双卡是这台机器运行该模型的唯一方式。31B 仅在第三步引入，此前未在任何位置出现。
31B 这一步保持了原始配置：使用 checkpoint gemma-4-31B-it-qat-w4a16-ct、batch 1 以及 greedy 采样。两个平台均在 TRITON_ATTN 注意力后端上运行。该模型不规则的 head 维度导致在 FA4 不可用时只能强制退回 Triton，无论对 gfx1100 还是 A100 均是如此。
prefill 取自曲线拟合，而非照搬单点数字。孤立的 prefill tok/s 无法说明问题，因为提示扩展呈现非线性特征：针对 S 个 token 的提示，首 token 生成时间遵循 T(S) = a + bS + cS²。两台主要对比机器在一项上相差三倍，在另一项上则相差近七倍。下文的拟合结果由 `build_prefill.fits()` 生成，与 prefill.jsonl --fits 所汇报的完全一致，且仅在达到图表标准的档位上进行。常数项 a 虽然参与了拟合，但从未被引用：同一配置在两场相隔的 campaign 之间从 9.8 ms 漂移到 99.8 ms，当前这套阶梯无法对其进行定量。
先剥离张量并行：在单张 7900 XT、单张 A100 与单张 L4 上，使用相同的阶梯测试两个模型。A100 全程保持领先，领先幅度因模型而异，并随上下文深度增加而收窄。L4 则全程落后。
L4 是一张在当前任务下输给消费级卡的数据中心卡。在两个模型和所有上下文深度下，它的表现仅相当于单张 7900 XT 的 0.54× 到 0.68×。它展现出的特性是平缓：在 32 K 深度下它保留了 500-token 解码速率的 89 %，而 A100 仅保留 62 %。这种稳定性源于显存带宽较低的小型芯片架构，并不构成优势。该比较表明「数据中心」并非性能档位的代名词，而下一张图才是 L4 发挥价值的场景。
第二张 7900 XT 构成了图 1 中最为平缓的曲线。在稠密模型的十一个深度上，它仅带来 1.13× 到 1.23× 的收益；而在混合专家模型的七个深度上，收益仅为 1.11× 到 1.12×。这种扩展甚至不是单调的：在 12B 模型上，加速比在 6 000 token 处达到 1.23× 的峰值，随后在 32 K 下滑落至 1.13×。
batch 1 解码单步耗时极短且受显存带宽限制。切分模型权重使每张 GPU 读取的字节数减半，这就是全部的性能来源。随后每一步都以一次 all-reduce 结束，其延迟并不随切分而降低。本页面原先由此断定：第二张卡在带宽上的增益大半被通信线路消耗。实测表明线路通信仅占单步耗时的大约九分之一，在 12B 上为 16.70 里的 1.85 ms，并且同一台机器上的另一模型在承担相同集合通信开销的同时，第二张卡能够获得 1.70×。集合通信延迟可被准确测量，但并非主要瓶颈，详见第 9 节。
prefill 则相反，而测试对象依然是同样两张卡。提示阶段的注意力计算跨 head 并行且完全无须通信，同时足够长的提示使单步开销被稀释至舍入误差的程度。对两组测试配置进行拟合，并在各自达到的最深档位上合并各项：在稠密模型上，32 K 时用时由 40.1 秒缩减至 21.5 秒，收益为 1.87×；在混合专家模型上，12 K 时用时由 6.21 秒缩减至 3.99 秒，收益为 1.56×。同样的硬件与同一天的测试，增益却达到了解码阶段的四到七倍。
线性项 b 代表 GEMM 吞吐，即机器执行矩阵乘法的速率。二次项 c 衡量注意力计算随提示长度增加而恶化的程度。单一的 prefill tok/s 指标仅代表特定提示长度下两者的加权均值，该权重随提示深度不断改变。将两项分开拟合后，相同的机器展现出了相反的动态特性：
b 的单位是每 token 提示的微秒，
c 是每 token 平方的纳秒；两者都来自 build_prefill.fits()，
只在 chart-grade 档位上拟合，画出来的每一组 r² ≥ 0.9999。常数项拟合了但不画，
因为这套阶梯测不了它。由此可以得出三个结论，任何一条都无法被笼统地归结为一个均值：
在稠密模型上，A100 的注意力优势相当于其算力优势的两倍：6.67× 对比 3.29×。无论 7900 XT 在 prefill 阶段的主要瓶颈是什么，乘法器本身都不是核心原因。
在混合专家模型上，两个差距重合在一起，分别为 5.71× 与 5.75×。该模型每个 token 仅激活其 26B 参数中的 4B，导致 GEMM 项在两台机器上均维持在极低水平，两者之间的比值已无法反映矩阵乘法的吞吐差异。
L4 在 b 项上慢于消费级卡，在 c 项上则领先三倍。实测表现为 0.90× 与 3.01×。这解释了为何它在 32 K 提示上比 7900 XT 快 1.58× 却在短提示下落后：两条性能曲线发生交叉，使得 prefill 的优劣完全取决于提示长度。相比之下，第二张卡在 b 项上带来 1.44–1.48× 的提升，在 c 项上带来 1.91–2.22× 的提升，对二次项的改善幅度高于线性项，与前文测得的墙钟耗时一致。
C-31B-tp2 对 2026-08-30 的 A100 阶梯，取自
benchmarks/decode.jsonl。
点线与短虚线是 2026-08-29 那一对，它是唯一同时跑了两组投机配置的会话；
它的 Radeon 一侧带着三个 A100 一侧没有的补丁，所以它画在这里是为了说明 MTP 的代价，
而不是为了给出差距的大小。
「2026-08-26 的探针」那个开关会加上这篇文章最初依据的四个单次点 —— k=1、每格一轮，
最深那格是 Radeon 的 32K 对 A100 的 30K，因为那是那一侧当时能跑到的最长一档。
它的 U 形是四个点的形状，而它背后的两套阶梯都没有 U。
性能差距平稳保持在约 1.4×。两端均运行未经修改的原版代码且不带补丁时，A100 在 500 档领先 1.36×，到 32K 是 1.44×。在十一个对齐的深度档位上，这一差距全程保持平缓。早先测得的 U 形曲线是缺乏对照的四个离散点造成的假象；当前数据每格均取两轮均值，证实差距全程平稳。
这一领先幅度反映了投机解码给 A100 带来的代价。投机解码必须基于 2026-08-29 的测试组进行评估，因为只有该会话同时在两台机器上运行了两种测试配置。同时其 Radeon 一端应用了三个 A100 一侧没有的补丁，因此其相对差值比基准水平更具参考价值。在未启用投机时，该会话显示 A100 领先 1.30× 到 1.46×，接近上文的原版阶梯。开启 MTP 后领先优势消失：500 档仅为 0.88×，2K 至 8K 区间持平，到 32K 也仅有 1.08×。这并非因为 Radeon 变快，而是 A100 在投机解码上付出了更高代价。原因也不在于草稿质量：它的接受长度实际上是两者中更好的一方，单步达到 1.92–2.07 个 token，而 Radeon 为 1.46–1.53。它亏在成本上：在它上面单次投机步耗时相当于普通解码步的 2.40–2.57×，而同样一步在 Radeon 上仅需 1.35–1.39×。在 batch 1 下，双卡组合在单步内存在充裕的闲置算力，而单卡缺乏这种算力余量，使得生成并验证四个 token 的固定开销在既有负载中所占比例高得多。两项数据分别位于 benchmarks/campaign-2026-08-29/ 与 benchmarks/cuda-a100/campaign-2026-08-29/。
所谓的 U 形曲线仅由四个数据点构成。开启探针后该曲线确实呈现：1 K 时为 1.48×，在 16 K 时降至 1.14×，随后在 32 K 回升至 1.87×，正是这些数值构成了本文的原标题。然而同样的测试在两台机器上按每格两轮取均值后，呈现出的却是一条 1.36× 到 1.44× 的平直走势。早先看似极小值的 16 K 点不过是单次运行中的孤立数据格，且其最深的数据邻居对比的是两个完全不同的深度。该形态未能在复现测试中维持；原始数据点仍保留在页面上。
prefill 维度的实测数据现已补齐。在 2026-08-30 之前，该对比中 A100 一侧始终缺乏有效的 prefill 数据：早先测量解码的会话开启了 prefix caching，而测试阶梯的每个档位均为下一档的前缀，导致重复 token 被错误计为零开销从而未能满足可重复性标准。在关闭缓存并在两个系统上针对五个模型重新测量后，prefill 揭示了解码过程中无法观察到的运行动态：
c 到 19 而 b 只到 4 —— 因为要比的是同一项之内。
分组依据是 vLLM 在 A100 上选的后端，五个模型都有记录，并且与旁边那份 serve log 核对过；
Radeon 一侧五个里记录了三个，没有留下日志的那几场 campaign 写的是 null 而不是一个猜测。2026-09-02 更改：31B 和 Qwen3.8 两对里 Radeon 一侧的数据原先来自 2026-08-29 那场，当时两张卡中的一张训练在
PCIe 3.0 x8 而非 x16（宿主机开机日志有记录；客户机的 sysfs 看不到），而链路一窄就动 b，
那正是这张图要拆的两项之一。一次重启把宽度恢复了，两组在同一个容器、同样的 serve 参数下重新跑了一遍：
31B 的 b 从 868.7 降到 722.6，Qwen3.8 从 846.2 降到
758.5，所以这里 31B 那根柱子不再是 2.31×，而是 1.92×。
画出来的就是这两次。12B 和 26B 两对来自 2026-08-24，在 x16 上。 算力项并不关心执行路径上使用的是哪种 kernel，而注意力项几乎完全取决于此。在全部五个模型上，A100 在 b 项上领先 1.92× 到 4.00×，不同 kernel 实现之间的分布区间彼此重叠。但在 c 项上，两者完全分化：在 A100 与 Radeon 同样采用 Triton unified-attention 家族的三个模型上，领先优势为 2.99× 到 3.10×；而在它通过 FlashAttention 提供服务的两个模型上，优势跃升至 11.94× 和 19.01×。
五个模型之间的差异不仅限于 kernel，因此前述表现仅属于相关性。而在同一台机器、同一天及同一个模型内部，这一效应得到了直接验证。在这组显卡上，Qwen3.8-27B 默认被路由至 ROCM_ATTN，但可以通过指定 flag 固定为 TRITON_ATTN。在固定后端后，其 c 项耗时为 17.27 ns/token²，A100 领先 11.94×；保持默认时，其 c 项为 4.46，A100 领先 3.08×。仅需一个 flag 且无须任何补丁，「A100 在长提示词上领先多少」的答案便发生了 3.87× 的转移。该 flag 直到 2026-08-30 之前一直被本仓库视作「零代价」；它在 32 K 深度换取了 1.15× 的解码增益，却付出了如此代价。
这丝毫没有削弱 A100 的地位：它在每个模型及两项指标上均保持领先。但这表明，关于「数据中心卡到底快多少」的单一数字并不是这两张卡本身的属性：在二次项上，它主要取决于两端各自最终采用了哪种注意力 kernel，而在当前硬件配置下，这由一张路由表和一个命令行 flag 决定。
原版 vLLM 在投机解码时陷入的 2D 注意力路径，会为每个 KV head 启动一个 workgroup。当前模型包含 16 个 head。单卡上单个 rank 可以处理全部 head；而在双卡切分下，每个 rank 仅分到八个。本就饥饿的执行路径因并行切分而遭受加倍的饥饿，这直接体现在保留率数据中：
(total_num_q_blocks, num_kv_heads)：workgroup 数是 KV head
怎么切的性质，不是厂商的性质。同一次塌陷、同一个 kernel，在两张卡上大约翻倍。
MTP 草稿模型仅有四层，因此额外的单次前向传播开销很小。真正昂贵之处在于，每个草稿步依然是一个完整的执行步。在 TP=2 配置下，无论评估的模型规模如何，每一步都需要承受基准 all-reduce 延迟下限，实测在 31B 上达到 2.30 ms，且不随草稿模型深度改变。因此，投机解码在双卡上不如在单卡上划算。
splitkv-31b-stock.json，
那边是后端矩阵里被强制默认的那一列 —— 而且都是单次运行。
这里比的是收益，不是速率本身。
标称带宽比值假定两端均能达到理论峰值带宽，但实际上双方均未能做到。根据七月份 campaign 重新计算实测带宽，即解码速率乘以每张 GPU 每 token 搬运的权重字节数并除以 800 GB/s，本对比涉及的模型仅达到标称值的 63 %：
benchmarks/results.jsonl 在 500 token 上下文、TP=2 下的值，
每张 GPU 每 token 的字节数取自
benchmarks.md §3。
两个效应都真实可见：同样的量化下更大的模型实到更高，而 BF16 那个还要更高。
A100 那边没有测过对应的数字，
所以图 3 里的对比在那一侧是对着标称上限，在这一侧是对着实到值。
2026-09-02 补记：这里每一根柱子都是推算的 —— tok/s 乘以 checkpoint 大小，
假设一个解码步把每个权重字节都从显存读一遍。在 A100-SXM4-40GB 上用硬件计数器实测，
一个解码步在 gemma-4-12B 上读了 checkpoint 的 81.6 %、在 gemma-4-31B
上读了 85.6 %，所以那边的推算高估了 17–23 %。gfx1100 上测不了 —— VFIO 客户机的计数器读零 ——
所以这些柱子只能当作上界。基准测试全部在 batch 1 下运行。未进行实测的批量吞吐属于另一个工作区间；一旦解码脱离显存带宽受限状态，第二张卡的 1.1× 提升及本页其他结论均不再适用。prefill 虽然经过实测，但仅覆盖两个形状项：常数项 a 虽经拟合但从不引用，因其在相隔一个月的两场 campaign 中于同一配置下从 9.8 ms 漂移至 99.8 ms，在另一配置下甚至出现负值。因此足够短的提示超出了当前拟合所能描述的范围。
31B 在当前机器上缺失且无法获得单卡数据：模型权重为 22 GB，而显存仅有 20 GB。分析的前两步依赖其余模型完成，31B 仅在必须双卡运行的第三步介入。
图 7 仅展示 Radeon 平台，对应另一平台的数据未做实测。图 3 标注的 1.27× 仅为官方标称规格的比值，代表纯带宽差异所能解释的性能上限，而非任何一方经过实测对照的理论预测。
两端各自运行原生软件栈的不同 vLLM 版本，且测试跨越了会话方差未量化的租赁 Colab 虚拟机。测试中 A100 与 L4 均仅使用单张显卡完成单次测量，无法将芯片架构特性与特定硬件实例的影响剥离开来。
图 3 的实线基于两端未经修改的原版代码展开对比。2026-08-29 的测试组未做补丁对齐：Radeon 端运行了 vllm#45916、window block-skip 与 vllm#45450；而 A100 非投机端省略了全部三个补丁，投机端仅运行 vllm#45450。在缺乏同时覆盖两组的原版测试情况下，MTP 开销必须从相对差值而非绝对水平中解读。投机配置本身完全对齐：由 verify_doc_figures.py 断言，两端 serve 日志均记录了指向相同 assistant checkpoint 的 SpeculativeConfig(method='mtp', …, num_spec_tokens=3)。
本页原先说：batch 1 单步解码时间极短，固定的 all-reduce 延迟吞噬了第二张卡贡献的大半带宽，而且这里没有给任何一次 all-reduce 计过时。现在完成实测后，数据并不支持这一判断。在 HIP graph 回放模式下（serve 日志记录为 cudagraph_mode FULL_AND_PIECEWISE 与 Capturing CUDA graphs (decode, FULL)，即解码真正运行的机制），batch 1 形状下一次 all-reduce 是
16.6 到 21.5 µs。按 2 × 层数 + 1 次集合通信计算（于 2026-09-03 清点：每层两次加一次 embedding），通信耗时仅占 12B 一步 16.70 ms 里的 1.85 ms，约九分之一。
而且同一台机器上，Qwen3-8B 的第二张卡在解码上值 1.70×，
12B 只值 1.185×，两者单步集合通信开销相差在 0.6 ms 以内。若通信线路吞噬了带宽，8B 便无法达到 1.70×。拖住它的并不是通信线路。减去理想减半耗时与实测集合通信开销，12B 还剩 4.96 ms 无法解释，8B 只剩 0.66 ms。（2026-09-02 得出解答：此前的假设存在缺陷。）原先的分析假设显存带宽构成瓶颈；然而在单卡上 8B 让内存控制器达到 90 % 忙碌，而 12B 仅有 56 %。在全部五个数据格中，扩展收益完全与该计数器相吻合（campaign-2026-09-02d）。12B 的 4.96 ms 并非不知所踪的时间损耗，而是零假设模型对一个半闲置的内存控制器做出了错误估计。该计数器此后在四种租赁 NVIDIA 配置下成功对高带宽显存、双卡扩展以及降级显卡的价值做出了排序，相关分析见独立专文。
原论断中关于注意力机制的半句依然成立：注意力计算在无须通信的前提下实现并行，上述 prefill 数据充分证实了这一点。而此前依据拟合截距对集合通信进行定量评估的三项结论依然处于撤回状态：相关量在当前阶梯上无法定量，且被小 49 到 63 倍的直接实测数据所推翻。实测数据已在仓库中归档，运行时库由 /proc/self/maps 直接读取确定而非依据版本常量。
README.md 所公布的结果。2026-08-29 测试组因作为评估投机解码的唯一依据而予以保留，并已明确标明其包含的补丁。
README.md 中引用了 38 % 的实测带宽，将 12B 的指标与达到 62.8 % 的 31B 混淆。相关数据已就地更正并标注日期，全部三个显存带宽利用率数据现均由 verify_doc_figures.py 直接从 campaign 日志中重新计算得出。
数据。基准测试记录保存在：Radeon 数据见 benchmarks/speculative-decoding/，A100 运行记录与移植日志见 benchmarks/cuda-a100/45450-validation/，图 7 对应记录见 benchmarks/results.jsonl。本页所有图表均由 verify_doc_figures.py 直接重算得出。
两套软件栈为何均需补丁才具备可比性，详见上一篇文章。