第二张 AMD 显卡该怎么用？一次 128K Agent 双卡推理实测
-
三、哪条路线更快？
前面讲了这么多硬件、切分比例和通信方式，到这里终于该看成绩了。
不过，在公布结果之前，还需要补上最后两个会出现在表格里的名字，那就是 MTP 和 DFlash2 。
它们都属于投机解码方案。简单来说，就是先尝试一次预测多个候选token，再由主模型统一验证，如果候选token被接受，主模型就不必严格按照一次一个token的方式向前生成。两者的区别在于MTP使用模型自身携带的多token预测能力，不需要额外加载独立草稿模型。而DFlash2需要加载一个额外的草稿模型，由草稿模型提出候选，再交给主模型验证。
经过兼容性测试后，最终形成了三条可以实际运行的路线：
路线 多卡模式 投机方式 定位 TP + MTP Tensor Split + RCCL 模型内置MTP 双卡性能路线 PP + MTP Layer Split 模型内置MTP 简单、省显存的PP路线 PP + DFlash2 Layer Split 外部DFlash2 Q4草稿 PP下追求更高解码性能 PS：至于TP + DFlash2，它会在当前llama.cpp的分片输出权重与GET_ROWS路径上失败，因此没有进入正式性能对照。这个问题会在后文单独说明。
为了尽量减少变量，我重新进行了一轮对照，保持以下条件一致：
项目 条件 主模型 Qwen3.8-27B HauhauCS-Aggressive Q6_K_P 双卡比例 R9700 / RX 9070 = 65/35 上下文容量 163840 tokens 主模型KV Cache FP16 mmproj 加载相同的BF16视觉投影 并发 parallel=1R9700功耗上限 210W RX 9070功耗上限 200W 采样 temperature=0，seed=123TP路线 TP + RCCL + MTP， n-max=3PP路线 PP + DFlash2 Q4_K_M， n-max=4测试时，每个端点都尽量保持输入内容、输出长度和缓存状态一致。我选择了四种更接近日常Agent使用方式的负载。
第一种是96-token短输入，并强制生成512个token。这里的96是96个token，不是96K。它主要考察短输入、持续生成时的Decode能力，Prefill数字只作为记录，不适合拿来判断长提示吞吐。
第二种是从零载入129481个token，再生成256个token。它模拟缓存完全失效、服务重启或者上下文压缩后重新载入完整历史的情况。
第三种是命中128965个token的长前缀缓存，只追加1547个新token，再生成256个token。它最接近日常Agent完成一次工具调用后，把新结果追加到既有上下文中的场景。
第四种是在命中129996个token之后，一次性追加31413个token，再生成256个token。它模拟工具突然返回大量日志、源码或文档的突发情况。
TP + MTP与PP + DFlash2结果：
测试场景 路线 Prefill Decode 总墙钟时间 96输入 + 512输出 TP + MTP 225.823 t/s 44.901 t/s 11.813秒 96输入 + 512输出 PP + DFlash2 206.037 t/s 42.116 t/s 12.606秒 129481冷输入 + 256输出 TP + MTP 397.916 t/s 33.610 t/s 333.067秒 129481冷输入 + 256输出 PP + DFlash2 269.625 t/s 24.424 t/s 490.752秒 命中128965，追加1547 + 256输出 TP + MTP 226.741 t/s 36.621 t/s 13.872秒 命中128965，追加1547 + 256输出 PP + DFlash2 159.674 t/s 22.839 t/s 20.938秒 命中129996，追加31413 + 256输出 TP + MTP 221.005 t/s 34.119 t/s 149.716秒 命中129996，追加31413 + 256输出 PP + DFlash2 147.937 t/s 22.997 t/s 223.533秒 TP + MTP相对PP + DFlash2的领先幅度：
测试场景 Prefill领先 Decode领先 总墙钟缩短 96-token短输入、长生成 9.60% 6.61% 6.29% 129K冷重建 47.58% 37.61% 32.13% 129K高命中、追加约1.5K 42.00% 60.34% 33.75% 约130K高命中、突发约31K 49.39% 48.36% 33.02% 结果比我最初预期的更加明确。
在96-token短输入中，两条路线的差距并不大。TP + MTP的总时间只缩短了6.29%，说明当输入很短、主要时间用于持续生成时，两种投机方案都能获得比较接近的效果，但进入真正的长上下文之后，差距迅速拉开。
在129K冷启动中，TP + MTP将总时间从490.752秒缩短到333.067秒；在高缓存命中、只追加约1.5K的情况下，总时间从20.938秒缩短到13.872秒；面对约31K的突发追加，总时间也从223.533秒缩短到149.716秒。
三种长上下文工况的最终结果非常接近，TP + MTP都把总时间缩短了大约32%到34%，这也推翻了我在测试前的一个重要预期。
我原本认为，PP通信更少，应该更擅长完整吞入长提示。TP则主要在深上下文Decode中占优。但严格复测表明，在这套具有真实P2P、启用RCCL的R9700 + RX 9070平台上，TP不仅提高了Decode，也显著提高了129K冷启动和长上下文追加时的Prefill。换句话说，TP + MTP并不是只在某一个指标上跑出了更漂亮的数字，而是在三种最接近真实128K Agent的工作负载中，都取得了更短的端到端等待时间。
因此，这轮测试给出的第一个核心结论是：
在当前硬件、模型和软件构建下，TP + RCCL + MTP是这套双卡系统的默认性能路线。
不过，这张表同时留下了另一个很有意思的问题，PP + DFlash2在部分测试中拥有更高的草稿接受率和更长的连续接受长度，按直觉似乎应该生成得更快，但最终却没有赢得端到端速度。
为什么接受了更多候选token，反而还是更慢？
这就是下一部分需要回答的问题。
-
四、接受率≠速度。
投机解码最容易让人产生误解的指标，就是接受率。
从原理上看，草稿模型一次提出多个候选token，主模型验证后接受得越多，理论上就越能减少逐token前向计算。因此，看到更高的接受率和更长的连续接受长度时，我们很自然地会认为它应该更快，但实际速度并不只由接受率决定。
一次投机解码所消耗的时间，包含以下几个部分：
草稿模型生成候选token -> 主模型批量验证候选 -> 接受或者拒绝候选并更新KV Cache -> 多卡之间完成模型计算和数据同步 -> 采样器选择最终输出。
所以更准确的理解应该是：
实际速度 ≈ 每轮最终接受的有效token ÷ 草稿生成、主模型验证、跨卡同步和采样的总耗时
这就好像是一个公式，接受率只能反映分子的一部分，却没有告诉我们为了获得这些候选，系统在分母上付出了多少成本。
DFlash2接受率更高，却没有赢下对照实验
在96-token短输入中，PP + DFlash2的接受率为57.96%，平均连续接受长度为3.32，TP + MTP的接受率只有48.24%，平均连续接受长度为2.44。
单看这两个数字，DFlash2明显更漂亮，但最终Decode速度却是TP + MTP：44.901 t/s 而 PP + DFlash2：42.116 t/s。TP + MTP仍然更快，端到端时间也从12.606秒缩短到了11.813秒。
在129K冷启动测试中，同样的现象更加明显：
路线 接受率 平均接受长度 Decode TP + MTP 52.88% 2.58 33.610 t/s PP + DFlash2 57.28% 3.27 24.424 t/s PP + DFlash2接受了更多候选，平均连续接受长度也更高，但Decode仍然明显落后。
DFlash2提高了PP的投机效率，但它无法消除PP本身的串行分层路径。对于每一个需要主模型验证的token，数据仍然要依次经过R9700与RX 9070负责的模型阶段。相反，TP + MTP虽然接受率不一定更高，但两张显卡能够同时参与同一层的主模型计算。在真实P2P与RCCL都能够工作的情况下，主模型基础路径上的优势，最终超过了DFlash2在接受率上的领先。
所以这张主对照表能够证明“TP + MTP比PP + DFlash2更快”，却还不能单独证明“MTP这种投机算法比DFlash2更好”，如果要把多卡模式和投机算法拆开，就必须让它们在相同的PP环境中再比一次。
MTP与DFlash2的差距其实很小
为了只比较两种投机方案，我又补充了一轮PP内部对照，结果如下：
测试场景 PP + MTP PP + DFlash2 端到端结果 96输入 + 512输出 267.90 prefill / 39.70 decode / 13.30秒 206.04 prefill / 42.12 decode / 12.61秒 DFlash2快5.22% 129K输入 + 256输出 260.32 prefill / 23.81 decode / 508.14秒 269.62 prefill / 24.42 decode / 490.75秒 DFlash2快3.42% 命中约129K，追加1547 + 256输出 149.12 prefill / 25.17 decode / 20.59秒 159.67 prefill / 22.84 decode / 20.94秒 MTP快1.65% 命中约130K，追加31413 + 256输出 140.30 prefill / 21.77 decode / 235.71秒 147.94 prefill / 23.00 decode / 223.53秒 DFlash2快5.17% DFlash2在四项测试中三项领先，但它的领先幅度并不大，基本集中在3%到5%。
唯一由MTP获胜的，是高缓存命中后只追加约1.5K的Agent工况。这里PP + MTP的Prefill低于DFlash2，但深上下文Decode达到25.17 t/s，高于DFlash2的22.84 t/s，最终以20.59秒对20.94秒小幅获胜。
这组结果说明，两种投机方案并不存在数量级上的差距。
DFlash2通常能够获得更长的连续接受长度，在多数PP工况中略快，MTP则不需要加载外部草稿模型，在部分深上下文增量生成中也可能取得更好的Decode表现。
因此，主对照中TP + MTP领先32%到34%，主要原因并不是MTP在投机算法上全面击败了DFlash2，而是TP主模型计算路径本身取得了明显优势。
MTP更省显存，也更容易部署
两种PP投机方案在显存分配上有差异。
路线 R9700显存占用 RX 9070显存占用 PP + MTP 约25.0GB 约12.9GB PP + DFlash2 Q4 约26.7GB 约11.7GB DFlash2需要把额外草稿模型放在R9700上，因此比MTP多占用大约1.7GB主卡显存。它还需要单独下载草稿文件，并使用支持DFlash2的实验性llama.cpp构建。
MTP则直接使用模型内部能力，不需要额外草稿文件，也为R9700留下了更多显存余量。
所以，如果PP只是TP不可用时的兼容降级路线，我更倾向于把MTP作为默认选择。如果愿意为多数工况大约3%到5%的提升，增加约1.7GB显存占用和一套额外草稿依赖，再考虑启用DFlash2会更合理。
为什么没有TP + DFlash2？
既然TP的主模型路径更快，而DFlash2在PP中又能获得不错的投机效果，一个很自然的想法就是：
能不能把它们组合起来，使用TP + DFlash2？
我确实进行了尝试，但很可惜当前版本无法正常运行。
DFlash2的候选选择器需要从主模型的输出权重中取出指定token对应的行，也就是执行GET_ROWS。在TP模式下，这张输出权重表已经被切分到两张显卡上，当前llama.cpp的多卡后端还不能在这条路径中，正确完成跨分片取行与结果聚合。
最终表现为split axis、shared tensor或者backend ownership相关错误，缺少DFlash2候选选择器面对分片输出权重时的完整语义。
所以至少在当前构建中，DFlash2只能留在PP路径上。
-
五、RCCL究竟带来了多少提升？
前面提到，RCCL是对跨卡Reduce路径的一次优化。
这次测试分别在4K短上下文和128K长上下文下，对启用与关闭RCCL进行了严格对照。
4K上下文：Prefill提升约9%
TP构建 Prefill Decode 不使用RCCL 1183.30 t/s 28.53 t/s 使用RCCL 1291.31 t/s 29.18 t/s 提升 9.13% 2.27% 在4K测试中，RCCL带来的Prefill提升比较明显，从1183.30 t/s提高到1291.31 t/s，增幅约为9.13%，Decode也有所提高，但幅度只有2.27%。
这说明RCCL确实优化了TP的跨卡通信，但跨卡归约并不是Decode中的唯一成本。即使通信变得更高效，模型计算、显存访问和采样等部分仍然不会因此消失。
128K上下文：收益收敛到约2%
TP构建 Append Prefill Deep Decode 不使用RCCL 266.89 t/s 19.28 t/s 使用RCCL 273.24 t/s 19.55 t/s 提升 2.38% 1.44% 第二组测试在已有约128K上下文的情况下，继续追加约1K新输入并生成输出。
到了128K，RCCL带来的提升明显缩小，增量Prefill从266.89 t/s提高到273.24 t/s，提升2.38%；Deep Decode从19.28 t/s提高到19.55 t/s，提升1.44%。
我更倾向于把这种变化理解为瓶颈占比发生了转移。
在4K工况下，跨卡通信和同步在总耗时中占有相对明显的比例，因此优化归约路径能够直接反映到Prefill速度上。随着上下文增长到128K，Attention和KV Cache访问开始消耗更多时间，跨卡通信即使变快，在整个任务中的占比也随之下降。
RCCL仍然有效，只是它能够优化的那部分，已经不再是主要矛盾，所以，对这套平台来说，RCCL值得作为TP的默认构建选项，这份收益不算惊人，但方向稳定，而且没有在本次测试中观察到明显负作用。既然决定使用TP，就没有理由主动放弃它。
-
六、我应该怎样部署？
经过前面的测试之后，我并不打算为每一种任务都准备一套完全不同的启动参数。
理论上，针对冷启动、缓存追加、短输入生成和大段突发内容分别切换Llama的启动配置，或许能够再挤出一点性能，但在实际工作中，频繁重启服务、修改参数和重新建立缓存，本身也会带来额外成本。
所以我更需要的是一条能够覆盖大多数128K Agent任务的默认路线，所以我选择了，TP + RCCL + MTP。
核心配置为：
HIP_VISIBLE_DEVICES=1,0 --split-mode tensor --tensor-split 65,35 --ctx-size 163840 --parallel 1 --cache-type-k f16 --cache-type-v f16 --flash-attn on --fit off MTP n-max=3这选择163840作为分配容量，并不意味着日常任务一定要把上下文用到160K，我的实际目标仍然是把主要工作上下文长度控制在128K附近，额外留下大约32K空间，用于工具突然返回大量日志、源码或者文档。这样既能避免上下文刚到128K就立刻触发裁剪，也能为Agent完成当前步骤留下足够余量。
-
结论：第二张显卡究竟值不值得？
回到最开始的问题，那就是这套AMD平台究竟值不值得继续折腾多卡？
我的答案是：
值得，但需要清楚自己得到的是什么。
RX 9070并没有让R9700的性能简单翻倍。这套同架构异规格双卡仍然受到显存容量不对称、计算能力差异和PCIe通信的限制。TP需要快卡等待慢卡，PP又无法自动提高单流生成速度，额外的驱动、构建和参数维护也都是真实存在的成本。
但第二张显卡同样不只是增加了16GB显存，在严格同条件测试中，TP + RCCL + MTP把129K启动、高缓存命中追加和31K突发追加三种长上下文任务的总等待时间缩短了大约32%到34%。
对于一次十几秒的短对话，这种差距可能不算久，但对于一个持续运行数小时、不断搜索、编译、测试和调用工具的Agent任务，每一轮节省下来的几秒或者几分钟，最终都会累积成可以真实感受到的工作效率。
这也是这次实验给我最重要的答案：
双卡没有让本地模型突然变成另一种级别的产品，但它确实让一个已经能够完成工作的模型，变得更适合持续工作。
RX 9070也完成了它作为“测试卡”的任务。
它证明了这张B850主板可以实现PCIe 5.0 x8/x8和双向P2P，证明了ROCm上的TP与RCCL能够在消费级平台上获得实际收益，也暴露了DFlash2在TP分片权重路径中的兼容问题。更重要的是，它让我在真正购买第二张R9700之前，先用相对有限的成本看清了多卡能够带来什么，又需要付出什么。
如果未来升级到双R9700，两张卡拥有相同的显存容量和计算规模，切分与同步应该会比现在更加自然。
至于这篇文章本身，如果后来有人在相似的平台上尝试AMD双卡，能够因为这些记录少走一点弯路，那么这次折腾就已经超过了它最初的意义。
-
补充：R9700 单卡Q8 KV、无 mmproj 的 DFlash2 验证
刚准备睡觉发现还落了单卡的性能测试，这里补上。
GPU: R9700 单卡，210W PPT 上限 主模型: HauhauCS-Aggressive Q6_K_P 配置上下文: 163840 主 KV: Q8_0 / Q8_0 草稿 KV: Q8_0 / Q8_0 草稿: DFlash2 Q4_K_M，n-max=4 mmproj: 不加载 parallel: 1 Flash Attention: on配置 R9700 VRAM GTT CPU offload Q6_K_P + Q8 KV，无投机 28.6GB 约 8MB 无 Q6_K_P + Q8 KV + DFlash2 Q4 30.7GB 约 8MB 无 512-token A/B
相同 96-token 代码 Agent 提示、temperature 0、seed 123、强制生成 512 token：
指标 无投机 DFlash2 Q4 差异 Prefill 335.81 t/s 272.85 t/s 仅 96 token，绝对差 66ms Decode 21.01 t/s 42.01 t/s +99.93% Decode time 24.321 s 12.165 s -49.98% 总墙钟 24.613 s 12.523 s -49.12% Draft accepted/generated — 357/615 58.05% 平均接受长度 — 3.32 — 在短输入、持续生成的工况中，DFlash2 几乎把 R9700 单卡速度翻倍，属于明确收益。
129K 输入后的深上下文 A/B
相同 129,481-token Agent 工具历史、256 输出 token、temperature 0、seed 123：
指标 无投机 DFlash2 Q4 差异 Full prefill 277.266 t/s 275.524 t/s -0.63% Prefill time 466.992 s 469.944 s +2.951 s Deep decode 13.814 t/s 20.538 t/s +48.68% Decode time / 256 18.460 s 12.416 s -6.044 s 总墙钟 485.536 s 482.445 s -3.091 s / -0.64% Draft accepted/generated — 176/312 56.41% 平均接受长度 — 3.26 — 单卡 MTP 与 DFlash2 Q4
为补齐投机算法之间的直接比较，又以完全相同的 R9700 单卡、210W、Q6_K_P、Q8 主/草稿 KV、163840 上下文、不加载 mmproj、
parallel=1、temperature 0、seed 123 条件补测了模型内置 MTP（n-max=3）。每个端点前均重新启动服务，129K 工况为cache_n=0的完整冷输入。DFlash2 使用前述同条件 Q4_K_M、n-max=4数据。工况 MTP DFlash2 Q4 端到端结果 96 输入 + 512 输出，Prefill 267.432 t/s 272.850 t/s DFlash2 高 2.03% 96 输入 + 512 输出，Decode 38.210 t/s 42.010 t/s DFlash2 高 9.95% 96 输入 + 512 输出，总墙钟 13.869 s 12.523 s DFlash2 缩短 9.71% 129K 输入 + 256 输出，Prefill 266.561 t/s 275.524 t/s DFlash2 高 3.36% 129K 长度 Decode 20.962 t/s 20.538 t/s MTP 高 2.06% 129K 输入 + 256 输出，总墙钟 497.994 s 482.445 s DFlash2 缩短 3.12% 工况 路线 接受率 平均接受长度 96 输入 + 512 输出 MTP 59.24%（327/552） 2.78 96 输入 + 512 输出 DFlash2 Q4 58.05%（357/615） 3.32 129K 输入 + 256 输出 MTP 60.52%（164/271） 2.80 129K 输入 + 256 输出 DFlash2 Q4 56.41%（176/312） 3.26 MTP 的 token 接受率略高，但连续接受长度更短，不能只凭接受率判断端到端速度。短生成由 DFlash2 明显胜出。129K 深度 decode 则由 MTP 小胜约 2%，但 DFlash2 更快的冷 prefill 仍令整项任务缩短约 3.1%。两者的进程 VRAM 都约 30.6～30.7GB，MTP 在 129K 满载时 AMD-SMI 总显存达到约 32.26/32.62GB，只剩约 0.36GB 设备级余量。
-
，
T terry 固定了此主题
-
，系统 取消固定了此主题
-
其实没必要纠结pcie5.0x8拆分 ， 直接买 pcie 4*16 的主板即可，可能会更便宜
-
-
最近不够了，看看我也可以买一张7900xtx 来玩一下
-
，T terry 引用了 此主题
