7900XTX 四种双卡方案实测
-
双 7900XTX 上 B760M：硬件情况、两种卡对比、四种双卡方案实测
机器
- 板 U：B760M（DDR4），CPU 是 RPL ES，P 核 5.0 / E 核 4.0，内存 64G DDR4-2666
- 卡：蓝宝石 PULSE 7900XTX + 一张涡轮公版 7900XTX
- 电源 1000W，双卡满载整机峰值 636W，够用
插槽拓扑：PULSE 走 CPU 的 x16（Gen4 x16 满速，实测 27.7GB/s），涡轮走 PCH 的 x4（Gen3 x4，实测 3.6GB/s）。两张卡挂在不同的 root 口下面，没有 P2P，跨卡流量都走内存弹跳。
两张卡本体对比（同配置同 prompt 实测）
同一颗 die（0x744c / gfx1100），裸算力一个水平（8GB sum 454 vs 460 GB/s，GEMM 同速），差别全在 VBIOS：
PULSE（老卡） 涡轮（新卡） 负载实际 sclk 2677 MHz 2137 MHz 显存 mclk 1249 MHz 1249 MHz 功耗墙 / 实测均值 303W / 290W（peak 314） 257W / 203W（peak 219） 满载温度 52-55°C 53-55°C decode（生产配置，256tok） 63.9 t/s 52.2 t/s（-18%） prefill（2K） 790 t/s 605 t/s（-23%） 每瓦 decode 0.205 tok/W 0.235 tok/W（反高 15%） 涡轮跑 203W 离自己的 257W 墙还远，说明不是功耗受限，是 VBIOS 频率表出厂就低。两张卡 cap_max 都是 350W，但 RDNA3 在 Linux 下没有 pp_od_clk_voltage，频率表拉不动，写大功耗墙也没用（它根本没顶到）。所以这 -18% 是永久的，好在温度能效都健康，当副卡完全合格。
TP2 的坑（PCH 平台必看）
vLLM 开
--tensor-parallel-size 2直接hipErrorInvalidState (401)，而且错误永远跟着 PCH 那张卡走。排查到底发现是硬件+驱动叠加：
- RCCL 2.30.4 的 kernel 被 device-link 无条件挂了 hidden hostcall buffer，hostcall 门铃就是 PCIe 原子写
- lspci 看 AtomicOp Completer：CPU 口
00:01.0全部+，PCH 口00:1c.0全部-（Routing- 32bit- 64bit- 128bitCAS-），这些是只读硬件位，setpci 没救 - 于是 amdgpu 在 PCH 卡上禁 atomics，HIP 运行时直接拒发 kernel → 401
修法用的是 rocm-systems#11277 这个未合并 PR 的思路：装载期标记 hostcall 不可满足，
HIP_HOSTCALL_ALLOW_MISSING=1时放行为 null buffer。kernel 真去执行 hostcall 才会 fault，而 RCCL 热路径从不 printf，所以安全（PR 作者和本机双重验证过）。自己编了一份 clr，几个坑：ROCM_KPACK_ENABLED=ON必须开，不开 torch 的 kernel 全 SIGSEGV- TheRock wheel 的 torch 按绝对路径加载 SDK 库，LD_LIBRARY_PATH 换不动运行时 → 用 docker 单文件 bind-mount 直接盖掉 wheel 里的
libamdhip64.so - 容器里 apt 基本残废，GL/X11/zstd 头文件直接从 ubuntu pool 下 deb 解压出个 prefix 传给 cmake
弄完 torchrun 双卡 allreduce 通过，TP2 一次点火成功。
四种方案实测
统一口径：2K token 随机词表 prompt × 强制生成 256 token，E2E 聚合 tok/s。随机词表对投机解码是 worst case，数字看相对差距比看绝对值有意义。llama.cpp 并发下它自报的 predicted_per_second 会虚高（报过 600+），只信 tokens/wall。
模型：Qwen3.8 27B（llama.cpp 用 UD-Q4_K_S；vLLM 用 W4A16 GPTQ）；Strata 部分是 Flash-Next IQ3_XXS。
并发 A 双实例副本 B vLLM TP2 B+MTP3 C llama.cpp 切层 D Strata 层切 1 59.4 / 46.1 29.6 46.7 32.4 80.5* 2 64.6 56.3 — 32.0 — 4 53.3 97.0 50.3 30.5 53.8 8 58.1 118.3 — 30.5 ≈N4（串行队列） *A 那格 59.4/46.1 = 两张卡各自实例单发各一个；D 是 Flash-Next IQ3_XXS 不是 27B，只看趋势。
A 双实例副本：每卡一个 llama.cpp，带全套投机。单请求延迟全场最好，N=2 之后排队，聚合封顶 58-65。隔离干净，这是日常默认形态。
B TP2：并发近线性，N=8 的 118 是副本天花板的两倍。代价：要补丁运行时（上面的配方）。MTP3 投机对单请求 +58%（29.6→46.7），但 N=4 反而 97→50，投机和连续批处理不对付，按场景开。
C llama.cpp 切层：
--device Vulkan1,Vulkan2 --tensor-split 1,1能跑，但 30-32 永平线。原因是每个 decode 步都要把另一半层的结果从 PCH x4 拉回来，每 token 一次跨卡同步，这块板上就是自残。数据放这就是让大家别踩。D Strata 层切：官方 docs/MULTI_GPU.md 的流水线层切，跟 C 完全不是一回事——token 每个验证窗只跨卡一次（几百 KB pinned RAM），x4/x1 槽官方明文能用，实测 PCH 卡拿一半层照常工作。两点经验：
- 必须
STRATA_SPLIT_OVERLAP=1。不开的话层切 decode 倒退（官方 2×XTX 数据 53 vs 单卡 70），开了和单卡持平。本机：单卡 79.7 vs 层切 80.5，零损失。 - 收益全在 prefill 和容量：9.6K prompt 900→1100 t/s（+21%），双卡专家缓存 22577/24576 对约 99.8% 驻留（单卡 96-97%）。
--batch多会话模式试了，聚合没涨还把单流砍半，没必要。并发它还是一问一答的串行队列，跟 TP2 没得比。
长上下文
TP2 大 prompt 冷填是另一个量级：130K token 冷填 77 秒（1684 t/s）；单卡副本 186K 深度实测 620 秒（300 t/s），速率差 5.6 倍。128K 和 160K 的三针大海捞针全过。160K 深度 fresh prefill 会掉到 359 t/s，可复现，还没调好（批长和 attention backend 待试），先如实报。
结论
- 日常用双实例副本：隔离、延迟最好、零额外依赖。第二张卡最大的实际收益就是它——两个会话各占一张卡互不打架，外加副卡常驻 60-90 t/s 的第二实例。
- 多并发或者大 prompt 冷填，TP2 按需点火：聚合 2 倍、冷填 5.6 倍。PCH 平台的 atomics 修复照上面配方走一遍就能用。
- llama.cpp 切层在这类板子（CPU x16 + PCH x4）上是负优化，数据就是 30 一条横线。
- Strata 玩家：层切可以用，前提 SPLIT_OVERLAP，收益在 prefill 和专家驻留，别指望并发。
- 单会话速度双卡救不了，天花板就是单卡。预算有限又只想加单流速度的，省下钱。
- 涡轮版/公版涡轮当副卡合适：便宜，能效还高 15%，接受 -18% 就行。
附：复现要点
vLLM TP2 关键参数：
--tensor-parallel-size 2 --disable-custom-all-reduce --dtype bfloat16 NCCL_P2P_DISABLE=1 HSA_ENABLE_SDMA=0 NCCL_PROTO=Simple HIP_HOSTCALL_ALLOW_MISSING=1 # 补丁运行时配套无 P2P 平台 allreduce 走 host transport，Simple 协议实测优于 auto。Strata 层切配置就三行：
"gpu": [0,1]+"layer_split": "auto"+ 环境变量STRATA_SPLIT_OVERLAP=1，卡序不用管，引擎自动把快卡放末级（head+draft 在快卡上）。欢迎交流，尤其是同样 PCH 口插卡想走 TP2 的，atomics 这个坑应该不止我碰到。
一句话：双7900xtx没啥明显收益
-
-
-
1，SGLang 双卡TP提升明显。论坛有详细部署方案，也经过抄作业的人实际验证。
2，Strata你的双卡方案，是串行分层，论坛不是有其他人的TP方案吗？他的数据是有提升，还挺多的。
3，双卡没有明显收益，即便从显存角度来看，也不太可能，是不是部署的问题？关于双7900 XTX测试的更正与补充
感谢指出问题。原帖是10月23日早期测试的总结，“双卡没有明显收益”“单会话双卡救不了”的表述过于绝对，我更正。它只能代表当时本机的特定配置，不能作为双7900 XTX或整个框架的结论。10月24日至26日的后续测试已经测到了明确收益。
1. SGLang TP2确实有收益
后续用SGLang TP2＋DFlash测同一份长输入，先读文档、再携带完整历史写代码和续写：
场景 单卡llama.cpp 双卡SGLang TP2＋DFlash 三轮总耗时减少 32K输入，三轮总耗时 63.78秒 50.13秒 21.4% 64K输入，三轮总耗时 140.88秒 106.27秒 24.6% 其中32K写代码/续写的生成速度是69.36/77.08→106.33/126.82 tok/s，说明单请求生成也有提升，原帖的概括不成立。
但这组是整套部署方案对比：llama.cpp用GGUF Q4_K_S与q4 KV，SGLang用GPTQ W4A16与BF16 KV，还叠加了DFlash，不能把提升全部归给第二张卡。同SGLang单卡DFlash短代码约93–96，双卡约104–105 tok/s；单卡该配置的实际KV容量仅允许992输入，32K请求被拒，因此双卡还有明确的容量收益。后续遇到过验证核、缓存和长输入临时显存问题，调整后部分场景通过，也还有未解决的稳定性/调度问题。
2. Strata需要区分层切、流水与双副本
我原帖的Strata数据主要是早期层切配置，不能代表全部双卡方案。后续开启
--pipeline-windows 2、调整卡顺序和预填参数后，在Flash-Next IQ3_XXS上测得：场景 单旧卡 双卡层切＋流水 零复用短代码生成，实际输出均512 token 92.49 tok/s 125.76 tok/s 同一119906-token冷输入，原生prefill 3049.5 tok/s 3484.9 tok/s 上述冷输入首字 39.40秒 34.49秒 双卡代码生成约快36%，120K首字等待少12.5%。但16K、32K冷输入仍有双卡更慢的情况，不能把生成速度与冷输入总耗时混为一谈。这些是后续调参数据，不是本轮两张卡原厂默认性能对照。
关于论坛的另一套方案，我重新核对了2318的介绍与其引用的2317原帖。2317作者明确写的是“双单卡replicas”，没有采用传统TP2或layer split：每卡独立引擎/KV/MTP，共享主机RAM中的专家arena，由服务分配请求。因此它的双流约160 tok/s是并发聚合成绩，不是一个请求在双卡上的速度。它的收益有效，只是与层切流水属于不同路线。
本机早期普通双副本也跑出过约110–117 tok/s双路聚合；后续新版共享arena双副本尝试两次启动失败，报
verify: copy stream create failed，还没有完整复现上述方案。不能把未跑通写成方案无效，也不能直接认定扩内存就能解决。3. 并发和显存收益应单独列
后续llama.cpp四请求测试，每请求实际输出512 token，整批吞吐按总输出除总墙钟：已调参旧卡单独运行，代码107.6、中文77.4 tok/s；两卡独立副本为190.9、130.4，分别提升77.4%和68.5%。这是明确的双卡并发收益。
两张24GB也不等于任何框架都能获得完整48GB可用池：TP/层切可分担部分权重，但仍有重复缓冲和缓存开销；独立副本则主要增加并发服务能力。对Strata这种专家分层存储的模型，第二张卡还能增加专家驻留、减少主存或CPU回退。这些价值不能用短输入单请求生成速度一项否定。
因此修正结论为：双7900 XTX有明确的并发、容量和部分单请求加速收益；原帖暴露的是本机早期部署及比较口径的局限，不能泛化为双卡无用。 SGLang TP2、Strata流水层切和双副本应按相同模型、输入、输出及并发分别比较。
-
关于双7900 XTX测试的更正与补充
感谢指出问题。原帖是10月23日早期测试的总结，“双卡没有明显收益”“单会话双卡救不了”的表述过于绝对，我更正。它只能代表当时本机的特定配置，不能作为双7900 XTX或整个框架的结论。10月24日至26日的后续测试已经测到了明确收益。
1. SGLang TP2确实有收益
后续用SGLang TP2＋DFlash测同一份长输入，先读文档、再携带完整历史写代码和续写：
场景 单卡llama.cpp 双卡SGLang TP2＋DFlash 三轮总耗时减少 32K输入，三轮总耗时 63.78秒 50.13秒 21.4% 64K输入，三轮总耗时 140.88秒 106.27秒 24.6% 其中32K写代码/续写的生成速度是69.36/77.08→106.33/126.82 tok/s，说明单请求生成也有提升，原帖的概括不成立。
但这组是整套部署方案对比：llama.cpp用GGUF Q4_K_S与q4 KV，SGLang用GPTQ W4A16与BF16 KV，还叠加了DFlash，不能把提升全部归给第二张卡。同SGLang单卡DFlash短代码约93–96，双卡约104–105 tok/s；单卡该配置的实际KV容量仅允许992输入，32K请求被拒，因此双卡还有明确的容量收益。后续遇到过验证核、缓存和长输入临时显存问题，调整后部分场景通过，也还有未解决的稳定性/调度问题。
2. Strata需要区分层切、流水与双副本
我原帖的Strata数据主要是早期层切配置，不能代表全部双卡方案。后续开启
--pipeline-windows 2、调整卡顺序和预填参数后，在Flash-Next IQ3_XXS上测得：场景 单旧卡 双卡层切＋流水 零复用短代码生成，实际输出均512 token 92.49 tok/s 125.76 tok/s 同一119906-token冷输入，原生prefill 3049.5 tok/s 3484.9 tok/s 上述冷输入首字 39.40秒 34.49秒 双卡代码生成约快36%，120K首字等待少12.5%。但16K、32K冷输入仍有双卡更慢的情况，不能把生成速度与冷输入总耗时混为一谈。这些是后续调参数据，不是本轮两张卡原厂默认性能对照。
关于论坛的另一套方案，我重新核对了2318的介绍与其引用的2317原帖。2317作者明确写的是“双单卡replicas”，没有采用传统TP2或layer split：每卡独立引擎/KV/MTP，共享主机RAM中的专家arena，由服务分配请求。因此它的双流约160 tok/s是并发聚合成绩，不是一个请求在双卡上的速度。它的收益有效，只是与层切流水属于不同路线。
本机早期普通双副本也跑出过约110–117 tok/s双路聚合；后续新版共享arena双副本尝试两次启动失败，报
verify: copy stream create failed，还没有完整复现上述方案。不能把未跑通写成方案无效，也不能直接认定扩内存就能解决。3. 并发和显存收益应单独列
后续llama.cpp四请求测试，每请求实际输出512 token，整批吞吐按总输出除总墙钟：已调参旧卡单独运行，代码107.6、中文77.4 tok/s；两卡独立副本为190.9、130.4，分别提升77.4%和68.5%。这是明确的双卡并发收益。
两张24GB也不等于任何框架都能获得完整48GB可用池：TP/层切可分担部分权重，但仍有重复缓冲和缓存开销；独立副本则主要增加并发服务能力。对Strata这种专家分层存储的模型，第二张卡还能增加专家驻留、减少主存或CPU回退。这些价值不能用短输入单请求生成速度一项否定。
因此修正结论为：双7900 XTX有明确的并发、容量和部分单请求加速收益；原帖暴露的是本机早期部署及比较口径的局限，不能泛化为双卡无用。 SGLang TP2、Strata流水层切和双副本应按相同模型、输入、输出及并发分别比较。
