7900XTX双卡跑VLLM跑 Qwen3.8 27b实录
-
，
T terry 固定了此主题
-
看到终于有人用这个双卡7900xtx了，献上我用了一个多月的vllm吧，直接用这个https://github.com/JartX/vllm perf/rdna3_full_stack 分支的吧！
RDNA3W4A16LinearKernel 这个东西就是这位Jartx老哥提的pr，它还修复了好多7900xtx的kernel，它自己现在就是4卡7900xtx了。现在做的W4A16量化prefill和decode 速度都3090一样的速度了
现在还缺W4A8 W8A8 MXFP4等支持
下面贴一下这个分支的特性，做了很多针对gfx1100 推理关键kernel的修复1. 注意力（KV cache 量化）——优化最重、收益最大 ┌───────────────────┬───────────────────────────────────────────────────────────────────────────────────┬──────────────────────────────────────────────────────────────────────────────┬─────────────────────────────────────────────────┐ │ 优化 │ 内核 │ 门控条件 │ 收益（README 实测） │ ├───────────────────┼───────────────────────────────────────────────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────────┼─────────────────────────────────────────────────┤ │ INT8 prefill │ paged_prefill_attn_rdna3_v2_int8（HIP WMMA） │ --kv-cache-dtype int8_per_token_head + TRITON_ATTN + HS∈{64,128,256} + 纯 │ 3.03ms vs Triton 25ms（8.3×）；整机 1209 vs 727 │ │ │ │ prefill continuation + 无 alibi/swa/sink/softcap │ tok/s（+66%），VRAM −50% │ ├───────────────────┼───────────────────────────────────────────────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────────┼─────────────────────────────────────────────────┤ │ INT8 decode │ pth_decode_int8_rdna3（HIP split-KV，1-wave） │ 同上 + HS==256 + max_query_len≤128 │ decode 主路径 │ ├───────────────────┼───────────────────────────────────────────────────────────────────────────────────┼──────────────────────────────────────────────────────────────────────────────┼─────────────────────────────────────────────────┤ │ INT4 │ paged_prefill_attn_rdna3_v2_int4 + pth_decode_int4_rdna3 + │ int4_per_token_head + HS∈{128,256} │ ~1150 tok/s（+58%），VRAM −75% │ │ prefill/decode │ rht_rotate_inplace_rdna3 + reshape_cache_int4_rdna3（融合 RHT） │ │ │ └───────────────────┴───────────────────────────────────────────────────────────────────────────────────┴──────────────────────────────────────────────────────────────────────────────┴─────────────────────────────────────────────────┘ 关键点：这个阶段与权重量化完全无关，只由 --kv-cache-dtype 决定。 2. W4A16 权重 GEMM（两套 HIP 内核，按对称性分叉） ┌────────────────────────────────────────────────────────────────┬─────────────────────────────────────────────────────────────────┬─────────────────────────────────────────────────────────────────────────────────────────────────────┐ │ 内核 │ 支持的量化 │ 路径 │ ├────────────────────────────────────────────────────────────────┼─────────────────────────────────────────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ gptq_gemm_rdna3 + gptq_gemm_rdna3_wmma（q_gemm_rdna3*.cu，fork │ 对称 int4 = uint4b8（GPTQv1 布局，ExLlama shuffle，存储 zp = │ RDNA3W4A16LinearKernel（优先级第一）；bf16 M≥16 → WMMA（prefill 128×64 主核），M=1 → │ │ 自研） │ 实际 zp − 1） │ 标量快速路径（v_dot2，省 LDS） │ ├────────────────────────────────────────────────────────────────┼─────────────────────────────────────────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ wvSplitK_int4_g（skinny_gemms_int4.cu，移植上游 PR #40977） │ 非对称 int4 = uint4（存储 zp = 实际零点） │ RDNAHybridW4A16LinearKernel；仅 M≤5 且 K·M≤32768 │ ├────────────────────────────────────────────────────────────────┼─────────────────────────────────────────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────┤ │ moe_gptq_gemm_rdna3（moe_q_gemm_rdna3.cu） │ 同 gptq 对称布局 │ MoE 专家 GEMM（KAT-Coder-V2.5 走的就是它） │ └────────────────────────────────────────────────────────────────┴─────────────────────────────────────────────────────────────────┴─────────────────────────────────────────────────────────────────────────────────────────────────────┘特别是它还修复了多卡通信RCCL 和3090一样的延迟了 延迟都能达到20us内了
这位老哥自从用4卡7900xtx 跑了deepseek v4 flash（卸载到内存） 后，最近更新速度降下来了。期望它再接再厉能把v4 flash 搞到30tokens也好呀
-
双卡 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 路径。 -
双卡 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 老老实实带一张卡，就是小主机目前的最优解。
