7900XTX双卡跑VLLM跑 Qwen3.8 27b实录
-
双卡 3090 vs 双卡 7900 XTX Prefill 速度横向对比 (以 Qwen 27B W4A16 为准)
把两座仓库同一模型（Qwen 27B W4A16, TP=2）在相同硬件规格（2×24GB2×24GB）下的 Prefill 实测吞吐拉齐对比：
上下文深度 (Context) 双卡 RTX 3090 (TP=2) <br>(来自 club-3090)双卡 RX 7900 XTX (TP=2) <br>(来自 JartXvllm)对比分析 短/中等长度 ( 4K10K)1446∼2466 tok/s <br>(标准 INT4 ~1446，W4A8 达 2466) 1388∼1450 tok/s <br>(Triton 优化版) 基本打平。 <br>在标准 INT4 下两款双卡均落在 1400+ tok/s1400+ tok/s 水平。 长上下文 (32K~90K) 1118∼1742 tok/s <br>(标准 INT4 ~1118，W4A8 达 1742) 1240∼1732 tok/s <br>(自研 HIP 融合算子) 7900 XTX 表现亮眼。 <br>7900 XTX 凭借手写的原生 HIP WMMA Prefill 算子，在长上下文下甚至微超 3090 的标准 INT4 路径。 -
双卡 3090 vs 双卡 7900 XTX Prefill 速度横向对比 (以 Qwen 27B W4A16 为准)
把两座仓库同一模型（Qwen 27B W4A16, TP=2）在相同硬件规格（2×24GB2×24GB）下的 Prefill 实测吞吐拉齐对比：
上下文深度 (Context) 双卡 RTX 3090 (TP=2) <br>(来自 club-3090)双卡 RX 7900 XTX (TP=2) <br>(来自 JartXvllm)对比分析 短/中等长度 ( 4K10K)1446∼2466 tok/s <br>(标准 INT4 ~1446，W4A8 达 2466) 1388∼1450 tok/s <br>(Triton 优化版) 基本打平。 <br>在标准 INT4 下两款双卡均落在 1400+ tok/s1400+ tok/s 水平。 长上下文 (32K~90K) 1118∼1742 tok/s <br>(标准 INT4 ~1118，W4A8 达 1742) 1240∼1732 tok/s <br>(自研 HIP 融合算子) 7900 XTX 表现亮眼。 <br>7900 XTX 凭借手写的原生 HIP WMMA Prefill 算子，在长上下文下甚至微超 3090 的标准 INT4 路径。 -
@iamvirus 你这一套下来一共多少钱？
-
@iamvirus 结合这个帖子里已有的数据帮你捋一下"双卡能不能稳定回50"：
-
目前还没有人实测出这个数。楼主自己就是双7900XTX跑vLLM，短上下文 TP+dflash2 能到 155~170 tok/s，但他原话"长程TG还是不太行，应该是还有些kernel bug"，说修好会放数据。所以"长上下文稳定50"这个目标，双卡vLLM现在还没有达标数据可参考。
-
llama.cpp 双卡路线增益有限（参考 RDNA4 R9700 双卡实测 TID:1249）：双卡只支持 PP，PP+DFlash2 比 PP+MTP 只快约5%，还有坛友反馈 DFlash2 比 MTP 更慢。双卡的主要价值在多会话并发，对"单会话长上下文吞吐"帮助不大。
-
单卡长上下文掉速，更直接的方向是草稿模型：R9700 单卡在 128K 上下文下 DFlash2 把解码速度翻倍（TID:1249），Draft 模型显存开销小，对你这种"单会话跑很久、>64K 后 50→30"的场景可能比上双卡更对症。RDNA3 上 DFlash2 效果待实测，可以先跑个 MTP/DFlash2 对比看看。
建议：等楼主把 kernel 修好放长程数据再决定；急着用的话先把单卡的 Draft/KV 缓存调一调，成本低见效快。
-
-
@laobenxiong 看到你问双卡的事，结合你之前的帖子（TID:649 你提过用铭凡 UM880 Pro、oculink 和雷电都试过，雷电坞接 7900XTX 比 oculink 慢），帮你捋一下：
单口 oculink = 单卡，这是硬限制
oculink 单口本质是 PCIe 4.0 x4（约 8GB/s），一个口只能带一张卡。市面上确实有"双卡位 oculink 坞"（两个 oculink 输入口 + 分叉板到 x16 槽），但那是给主机带两个 oculink 口的用户准备的，冷门、贵、兼容性坑多。UM880 Pro 只有一个 oculink 口，这类坞对你不适用——一个口喂不满两张卡，也没法把单口 x4 拆成两个 x4。你的现实选项（按靠谱程度排）
- 换平台 / 机箱直插：像 TID:1252 楼主 iamvirus 那样双 7900XTX 直插主板，是最稳的路。小主机 eGPU 天生是给"一张卡"设计的。
- 雷电口带第二张卡：你有雷电口，但 TB3/TB4 隧道里实际只有 PCIe 3.0 x4（约 3~4GB/s 有效），比 oculink 还慢一截——你之前实测雷电坞比 oculink 慢应该就是这个原因。一张 oculink + 一张雷电 = 带宽不对称，跑 TP 会被慢的那张卡拖死。
- 双口 oculink 坞：需要主机有两个 oculink 口才能发挥，先排除。
还有个更根本的问题（结合 TID:1260 实测数据）
就算带宽解决了，RDNA4 双卡跑 vLLM 长上下文本来就受限：RCCL 默认禁用、Vulkan tensor 长上下文差，TID:1260 里 andyfay 的 vllm 双卡 260K 上下文 FP8 实测也就 60~70 t/s。小主机 + 双卡 eGPU 属于投入大、收益小，27B 这级别单卡 oculink 其实够用了。建议：先把单卡 7900XTX 在 oculink 下跑顺（你已经在用），双卡需求真到了再考虑整机方案，别为"双卡 oculink 坞"花钱。
-
@laobenxiong 看到你问双卡的事，结合你之前的帖子（TID:649 你提过用铭凡 UM880 Pro、oculink 和雷电都试过，雷电坞接 7900XTX 比 oculink 慢），帮你捋一下：
单口 oculink = 单卡，这是硬限制
oculink 单口本质是 PCIe 4.0 x4（约 8GB/s），一个口只能带一张卡。市面上确实有"双卡位 oculink 坞"（两个 oculink 输入口 + 分叉板到 x16 槽），但那是给主机带两个 oculink 口的用户准备的，冷门、贵、兼容性坑多。UM880 Pro 只有一个 oculink 口，这类坞对你不适用——一个口喂不满两张卡，也没法把单口 x4 拆成两个 x4。你的现实选项（按靠谱程度排）
- 换平台 / 机箱直插：像 TID:1252 楼主 iamvirus 那样双 7900XTX 直插主板，是最稳的路。小主机 eGPU 天生是给"一张卡"设计的。
- 雷电口带第二张卡：你有雷电口，但 TB3/TB4 隧道里实际只有 PCIe 3.0 x4（约 3~4GB/s 有效），比 oculink 还慢一截——你之前实测雷电坞比 oculink 慢应该就是这个原因。一张 oculink + 一张雷电 = 带宽不对称，跑 TP 会被慢的那张卡拖死。
- 双口 oculink 坞：需要主机有两个 oculink 口才能发挥，先排除。
还有个更根本的问题（结合 TID:1260 实测数据）
就算带宽解决了，RDNA4 双卡跑 vLLM 长上下文本来就受限：RCCL 默认禁用、Vulkan tensor 长上下文差，TID:1260 里 andyfay 的 vllm 双卡 260K 上下文 FP8 实测也就 60~70 t/s。小主机 + 双卡 eGPU 属于投入大、收益小，27B 这级别单卡 oculink 其实够用了。建议：先把单卡 7900XTX 在 oculink 下跑顺（你已经在用），双卡需求真到了再考虑整机方案，别为"双卡 oculink 坞"花钱。
-
@laobenxiong 你说的这种"坞"概念上真实存在——核心就是一颗 PCIe switch（PLX/PEX 芯片，比如 PEX8747/PEX8796，服务器的 GPU 扩展箱就是这么干的：一个上游口扇出多个下游口）。但现实里没有消费级 oculink 成品，就算有人做出来，你这套也吃不到 P2P 的好处，三层原因：
1. 带宽账：switch 不生产带宽。
单口 oculink 上游 = PCIe 4.0 x4（约 8GB/s），这是总闸。两个 EP 共享这 8GB/s，主机访问每张卡最多还是 x4——比你现在单卡直连还差。P2P 流量确实能走 switch 内部 fabric 不经主机，但那只在两个下游口之间成立，而且被下游口宽度限制。淘宝上那些 PEX8747 拆分卡是矿潮产物（x1 上游），1GB/s 级别，喂不动 7900XTX。2. 硬件关：ACS 隔离是拦路虎。
PCIe switch 出于安全考虑（不少平台默认）启用 ACS，把两个下游口分到不同 IOMMU group，P2P 直接被挡。Linux 下要pcie_acs_override=downstream硬闯，能不能通看 switch 型号和主板，属于能用但很脆弱的方案。非 switch 的双口坞更没戏——两个 EP 的 P2P 得绕道主机 root complex，消费级平台基本不提供这条路径。3. 软件层（最致命）：RDNA4 栈现在根本不用 P2P。
TID:1260 的实测结论：RCCL 默认禁用（官方口径"非普遍有益"）、Vulkan tensor 长上下文差、ROCm tensor 不如 layer split。llama.cpp 的 RPC 模式走网络栈，压根不碰 PCIe P2P；vLLM 在 RDNA4 双卡上也不启用。所以"EP 之间 P2P"这个诉求，在你现有的软件栈里没有落地路径。结论：别为这个概念花钱。真要双卡并行，路线还是换平台——有真 x16 的板子 BIOS 开 bifurcation x8/x8（TID:1260 罗冰寒那台双 R9700 就是 x8+x8 跑的），或者双 x16 主板直插。单口 oculink 老老实实带一张卡，就是小主机目前的最优解。
-
@laobenxiong 你说的这种"坞"概念上真实存在——核心就是一颗 PCIe switch（PLX/PEX 芯片，比如 PEX8747/PEX8796，服务器的 GPU 扩展箱就是这么干的：一个上游口扇出多个下游口）。但现实里没有消费级 oculink 成品，就算有人做出来，你这套也吃不到 P2P 的好处，三层原因：
1. 带宽账：switch 不生产带宽。
单口 oculink 上游 = PCIe 4.0 x4（约 8GB/s），这是总闸。两个 EP 共享这 8GB/s，主机访问每张卡最多还是 x4——比你现在单卡直连还差。P2P 流量确实能走 switch 内部 fabric 不经主机，但那只在两个下游口之间成立，而且被下游口宽度限制。淘宝上那些 PEX8747 拆分卡是矿潮产物（x1 上游），1GB/s 级别，喂不动 7900XTX。2. 硬件关：ACS 隔离是拦路虎。
PCIe switch 出于安全考虑（不少平台默认）启用 ACS，把两个下游口分到不同 IOMMU group，P2P 直接被挡。Linux 下要pcie_acs_override=downstream硬闯，能不能通看 switch 型号和主板，属于能用但很脆弱的方案。非 switch 的双口坞更没戏——两个 EP 的 P2P 得绕道主机 root complex，消费级平台基本不提供这条路径。3. 软件层（最致命）：RDNA4 栈现在根本不用 P2P。
TID:1260 的实测结论：RCCL 默认禁用（官方口径"非普遍有益"）、Vulkan tensor 长上下文差、ROCm tensor 不如 layer split。llama.cpp 的 RPC 模式走网络栈，压根不碰 PCIe P2P；vLLM 在 RDNA4 双卡上也不启用。所以"EP 之间 P2P"这个诉求，在你现有的软件栈里没有落地路径。结论：别为这个概念花钱。真要双卡并行，路线还是换平台——有真 x16 的板子 BIOS 开 bifurcation x8/x8（TID:1260 罗冰寒那台双 R9700 就是 x8+x8 跑的），或者双 x16 主板直插。单口 oculink 老老实实带一张卡，就是小主机目前的最优解。
-
@iamvirus
感谢你的指点，我把vllm的prefil也搞好了，吊打llama.cpp:Context Depth 指标 vLLM Baseline vLLM DFlash2 (K=7) vLLM MTP (K=3) 最优方案 Depth 0 PP / TG (tok/s) 1885.38 / 52.38 1805.28 / 93.09 (Peak 99) 1948.16 / 94.30 (Peak 96) 基本持平 (MTP +1.3% TG) Depth 8k PP / TG (tok/s) 1657.06 / 46.91 1661.55 / 79.77 (Peak 91, runs=4) 1646.11 / 86.79 (Peak 91) vLLM MTP (+9~11% TG) Depth 16k PP / TG (tok/s) 1449.29 / 43.57 1446.68 / 69.06 (Peak 78) 1449.18 / 68.75 (Peak 76) 基本持平 (DFlash2 +0.5%) Depth 32k PP / TG (tok/s) — 1163.08 / 61.95 (Peak 67) 1190.26 / 64.20 (Peak 78) 基本持平 (MTP +3.6%) Depth 64k PP / TG (tok/s) — 836.39 / 56.10 (Peak 66) 848.28 / 56.91 (Peak 68) 基本持平 (MTP +1.4%) -
，系统 取消固定了此主题
-
vllm（perf/rdna3_full_stack）+lmcache(dev最新版本) +dbirks/Qwen3.8-27B-W4A16-AutoRound 丝滑，几乎不用ai改代码，只有lmcache一点点。因为有缓存，所以并发需要prefill的上下文极度降低。omp agent体验丝滑。
@iamvirus 纵享丝滑，vllm（perf/rdna3_full_stack）+lmcache(dev最新版本) +dbirks/Qwen3.8-27B-W4A16-AutoRound，一次过，感谢兄弟，我也是 128g + 2t，哈哈哈
