7900XTX双卡跑VLLM跑 Qwen3.8 27b实录

[flyer666]

双 RX 7900 XTX（RDNA3）跑 vLLM + Qwen3.8-27B 实录

动机（为什么折腾这个）

今年四月左右看了lcz版主的视频，在家弄了双卡 vLLM 这套主机有一阵了。今天看到lcz视频里提到a卡双卡支持很差，有点小不服，所以贴一下这几天捣鼓的经验。首先说，能跑肯定是能跑，但是短上下文体验远远不如LLaMA.cpp （尤其是mtp聊胜于无），但是如果有agent多并发需求还是可以尝试一下。

起因是之前主力用 llama.cpp：
启动快、跑得稳，但多路并发的缓存重用很差——几个 agent / harness 同时
跑的时候，各自的上下文来回反复预填充，很容易陷入"refill 怪圈"：看起来在
干活，实际大量时间耗在重复 prefill 上，实际体验一般。所以想试试 vLLM 的
前缀缓存（prefix caching）能不能把这摊事理顺。折腾下来发现 vLLM 在 RDNA3
上能跑，但坑是真不少，整理成这篇实录。

先感谢 vLLM 社区这几个让 Qwen 系模型在 RDNA3 上真正能跑的 PR，没有它们
这个帖子不存在：

• vllm-project/vllm#41394 — RDNA3 W4A16 原生 HIP 线性内核（RDNA3W4A16LinearKernel）。
  W4A16 GPTQ 模型在 gfx1100 上流畅推理的基石。没有它只能走 Triton JIT 回退，
  冷启动编译一次能等到怀疑人生。
• vllm-project/vllm#48816 / #47828 — Qwen3.5 MTP drafter BF16 权重加载修复。
  官方 AutoRound GPTQ 仓库把 MTP 张量存成纯 BF16，量化配置却声明 4-bit，
  加载器直接报错。这两个 PR（配合本地把规则改成 -:.*mtp.* 排除）让 MTP
  能正常加载运行。

顺便提了一下，有些大神已经开始搞sglang的7900xtx的支持了，过几天我也试一下：https://github.com/sgl-project/sglang/issues/30599

下面是完整实录。

---

硬件

应版主要求，先上图：

• 主板：ASRock X670E Taichi Carrara（AM5；双卡时 CPU 的 PCIe 4.0 x16 拆成
  两个 PCIe 4.0 x8，每卡约 16 GB/s，对推理完全够用）
• CPU：Ryzen 5 9600X（6C12T）
• 内存：32 GB DDR5
• GPU：2× RX 7900 XTX（gfx1100，24 GB 单卡）
• ROCm 7.14（HIP 7.14.60850）

安装

uv venv --python 3.12 --seed --managed-python
uv pip install vllm --extra-index-url https://wheels.vllm.ai/rocm/ --upgrade

装出来：vllm 0.27.1+rocm723、torch 2.11.0+rocm、triton 3.6.0、
transformers 5.15.1、Python 3.12.13。

最大的坑：amdsmi 引导（不解决这个根本起不来）

ROCm 上如果 torch 是第一个 import amdsmi 的库，torch 的 _amdsmi_cdll_hook
会加载一份冲突的 libamd_smi.so，结果 torch.cuda.device_count() 返回 0
（HIP 明明能看到两张卡），vLLM 直接报 Failed to infer device type。

解法：在 import torch 之前先 import amdsmi。我们写了 serve-bootstrap.py
做这件事，每次都通过它启动 vLLM，原样贴出来：

#!/usr/bin/env python
"""Bootstrap for native vLLM serve on ROCm.

Pre-imports `amdsmi` BEFORE torch so that torch's `_amdsmi_cdll_hook`
(torch/cuda/__init__.py) reuses this already-loaded module instead of loading
a second, conflicting copy of libamd_smi.so. Without the pre-import, amdsmi
reports 0 GPUs after torch loads (ODR violation), torch.cuda.device_count()
returns 0, and vLLM fails platform detection with
"Failed to infer device type".

Usage: serve-bootstrap.py <vllm-subcommand> [args...]
   e.g. serve-bootstrap.py serve --model ... --port 8080
"""
import sys

import amdsmi  # noqa: F401  -- must be imported before torch

from vllm.entrypoints.cli.main import main

if __name__ == "__main__":
    sys.exit(main())

用法：

python serve-bootstrap.py serve --model <model_dir> --port 8080 ...其它参数

启动（当前生产：非 MTP，fp8 KV，TP2）

export HSA_OVERRIDE_GFX_VERSION=11.0.0
export HSA_ENABLE_IPC_MODE_LEGACY=0
export FLASH_ATTENTION_TRITON_AMD_ENABLE=TRUE
export VLLM_ROCM_USE_AITER=1
export HSA_FORCE_FINE_GRAIN_AMDGPU=1
export VLLM_ENGINE_READY_TIMEOUT_S=1800
export VLLM_ENGINE_ITERATION_TIMEOUT_S=1800
export VLLM_EXECUTE_MODEL_TIMEOUT_SECONDS=1800

python serve-bootstrap.py serve \
  --model ~/Documents/vllm-serving/qwen3.8-27b-mtp-fixed \
  --tensor-parallel-size 2 \
  --host 0.0.0.0 --port 8080 \
  --kv-cache-dtype fp8 \
  --max-model-len 262144 \
  --max-num-seqs 8 \
  --max-num-batched-tokens 2048 \
  --attention-backend TRITON_ATTN \
  --enable-prefix-caching --enable-chunked-prefill \
  --performance-mode interactivity

几个为什么：

• --kv-cache-dtype fp8：跑 MTP 时是必须的（模型 FP16，drafter 的
  context_attention_fwd 在 bf16 KV 下会报 fp16 × bf16 dot 断言）。但非
  MTP + TRITON_ATTN 下 bf16 KV 实测完全可用（0/16k 上下文 64.7/50.8 tok/s，
  与 fp8 相当甚至略好）。用 fp8 的实际理由是 KV 内存减半——--max-model-len 262144 下 bf16 KV 会很吃显存。
• **--max-num-seqs 8 单人使用 大部分harness都够了
• 超时别设超过 1800：设成 3600000 会撑爆 zmq int32，vLLM 陷入重启死循环。
• 启动后先 warmup：第一批请求会吃 Triton JIT 编译的卡顿，脚本里发个
  "hi" 请求把 JIT 吃掉。

想开 MTP？怎么改、以及为什么我们没开

MTP（多 token 预测投机解码）在短上下文确实能白嫖提速（pp=32 时 +32%）。
想开的话，在上面那个命令基础上改三处：

# 1) 加投机解码配置（spec=3 实测最优，1/2 不够摊成本，4 过犹不及）
  --speculative-config '{"method":"mtp","num_speculative_tokens":3}' \
# 2) performance-mode 必须换成 throughput（interactivity 会触发
#    MTP drafter 的 inductor 编译 bug）
  --performance-mode throughput \
# 3) KV 缓存保持 fp8（MTP 下 bf16 KV 必崩：drafter 的 context_attention_fwd
#    会报 fp16 x bf16 dot 断言）
  --kv-cache-dtype fp8 \

前提是模型检查点已经打过 MTP 量化规则补丁（见"踩坑速览"第 1 条）。

但我们最终默认没开 MTP，原因就一句话：长上下文惨不忍睹。

• MTP 的 drafter 每步都要把整个 KV 缓存重新 attention 一遍，上下文越
  长越慢：pp=2048 时已经变成负收益（46.2 vs 51.2 tok/s）；到 16k 深度直接
  崩到 13.8 tok/s，同期非 MTP 还有 45.7。
• 我们的主要场景是跑 agent / harness，上下文只会越滚越长，MTP 属于开局
  猛、后面拖后腿，所以干脆默认关掉。短对话 / 数学 / 代码类任务想开就开，
  收益 +32% ~ +13%。

所以当前生产是非 MTP + fp8 KV，深度表现反而更稳。

性能速览

场景	数字
非 MTP 并发 8	272 tok/s（ns=8）
非 MTP 单流短上下文	52–64 tok/s
16k 深度解码（非 MTP）	~48 tok/s
32k 深度解码（非 MTP）	~42 tok/s
冷 prefill 1k / 16k / 32k	1757 / 955 / 623 tok/s
MTP 短上下文（pp=32）	+32%（70.2 vs 53.2）
MTP 16k 深度	13.8 tok/s（崩了，别用）

踩坑速览（详情都在这篇里的链接和注释里）

1. 本地 model config 改动：MTP 的量化规则从 +: 改成 -:（可复现）。
   HF 官方 Vishva007/Qwen3.8-27B-W4A16-AutoRound-GPTQ 的 config.json /
   quantization_config.json 里 dynamic 有 98 条规则，其中 MTP 是两条
   正向包含：+:.*mtp.* 和 +:.*mtp\.fc.*（按 4-bit 处理 MTP）。
   我们本地（qwen3.8-27b-mtp-fixed/，连同 HF cache 快照里的 config）把它
   改成 97 条：删掉两条 +:，加一条 -:.*mtp.* 排除。其余 96 条
   linear_attn 规则及所有字段零差异。

   为什么这么改：model_extra_tensors.safetensors 里 15 个 MTP 张量其实是
   纯 BF16（实测 dtype 全为 bfloat16），不是 4-bit。+: 规则会让 GPTQ
   加载器要求 MTP 提供 qweight，直接报
   ValueError: no module or parameter named 'layers.0.mlp.down_proj.weight'；
   改成 -: 排除后，vLLM 的 qwen3_5_mtp.py 检测到排除规则自动让 MTP 走
   非量化（BF16）加载（对应
   #48816 /
   #47828 的修复路径）。
   注意 mtp-fixed 目录里 config 两件是实体文件，权重文件是软链指向
   HF 缓存。

2. MTP 只适合短上下文：dense drafter 每步要整上下文 attention，深度一
   上去直接崩。数学/代码类 +32%~+13%，创意写作是负收益。深度任务用非 MTP。

3. AITER attention 别选：--attention-backend ROCM_AITER_UNIFIED_ATTN
   在这套环境上（amd_aiter 0.1.19 + gfx1100）会无声卡死，import aiter
   直接死锁，严重时把 amdgpu 驱动搞挂，只能重启机器。

4. 为什么 llama.cpp MTP 深度给力而 vLLM 不行：内核效率问题。vLLM 的
   Triton attention 在 16k 上下文每行 query 要 24–27 ms，llama.cpp 的 ggml
   FA 只要 4–5 ms。MTP 就是把这整上下文的行数乘了倍，vLLM 自然崩。

5. #45916 的 split-KV 我们试过：它改的 kernel_paged_attention_2d 在这
   套栈上根本不会执行（dense 解码走 GDN 融合的 kernel_unified_attention），
   属于改了用不上，已回滚。

6. 改过 wheel 后务必清编译缓存：rm -rf ~/.cache/vllm/torch_compile_cache，
   否则各种灵异现象（性能骤降、MTP inductor 报错）。

结语

双 7900 XTX 跑 vLLM 是完全可行的，当前非 MTP 配置在短上下文有 52–64 tok/s
单流、并发可到 270+ tok/s，深度解码也稳。MTP 想深度用就得上 llama.cpp。
有同样硬件配置的朋友欢迎交流。

[fcme]

勇气可嘉！我在R9700上面折腾过，体验不太好，太慢了，可能vLLM对7900XTX的支持更好些吧。我当时折腾下来是PP速度大概是llamacpp的一半，TP直接个位数，几乎没法用

[flyer666]

你的经验我也有过，rdna只能用W4A16量化的模型，其他模型均无pre compiled kernel 奇慢无比。你可以和试试我这个量化模型

[terry]

@fcme 你看老哥的数字，也就是玩具，32k上下文能干嘛，完全没有意义，不如跑两个单独的模型。
但是我相信老哥折腾下，能拿出更好的体验方案，最好是接入Agent测试下。

[flyer666]

@terry 描述不清楚，可以跑256k context,只是128k以上tg就调到25token/s了

[iamvirus]

看到终于有人用这个双卡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也好呀

[iamvirus]

双卡 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]

https://github.com/sgl-project/sglang/issues/30599 这个我都跟踪好久了，不要去浪费时间，sglang没有大神用gfx1100

[flyer666]

@iamvirus 你这个TG多少？

我今天试了一下双卡tp dflash2, tg最高到了155 ~ 170.1 tok/s，但是长程TG还是不太行，应该是还有些kernel bug。等我搞好了一起放出来

[坤坤]

妙哇，终于有人测了，我最近就一直纠结要不要再弄一张7900xtx来测试，我原本设想就是单卡输出速度能在50左右，上下文超过64k就降速到30，如果双卡的话是不是就能稳定回50

[坤坤]

老哥你看能不能测试下，我现在就是用单卡跑dsh在辅助我处理工作的事情，但是单会话久了后就降速到30tok/s，慢了一倍

[terry]

@iamvirus 出家人不打诳语，真这么好用？我都想弄一个玩玩。

[Quanta Magic]

@iamvirus 你这一套下来一共多少钱？

[Xiaote]

@iamvirus 结合这个帖子里已有的数据帮你捋一下"双卡能不能稳定回50"：

1. 目前还没有人实测出这个数。楼主自己就是双7900XTX跑vLLM，短上下文 TP+dflash2 能到 155~170 tok/s，但他原话"长程TG还是不太行，应该是还有些kernel bug"，说修好会放数据。所以"长上下文稳定50"这个目标，双卡vLLM现在还没有达标数据可参考。

2. llama.cpp 双卡路线增益有限（参考 RDNA4 R9700 双卡实测 TID:1249）：双卡只支持 PP，PP+DFlash2 比 PP+MTP 只快约5%，还有坛友反馈 DFlash2 比 MTP 更慢。双卡的主要价值在多会话并发，对"单会话长上下文吞吐"帮助不大。

3. 单卡长上下文掉速，更直接的方向是草稿模型：R9700 单卡在 128K 上下文下 DFlash2 把解码速度翻倍（TID:1249），Draft 模型显存开销小，对你这种"单会话跑很久、>64K 后 50→30"的场景可能比上双卡更对症。RDNA3 上 DFlash2 效果待实测，可以先跑个 MTP/DFlash2 对比看看。

建议：等楼主把 kernel 修好放长程数据再决定；急着用的话先把单卡的 Draft/KV 缓存调一调，成本低见效快。

[applejuice]

此主題已被删除！

[laobenxiong]

早就想试试双卡...可是只有一个oculink, 咋办? 有没有双卡的oculink显卡坞...

[good lee]

不好意思我是小白 问个蠢一点的问题，我这使用量 ，本地部署能省多少钱？本地部署能不能作为生产力

[Xiaote]

@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。

你的现实选项（按靠谱程度排）

1. 换平台 / 机箱直插：像 TID:1252 楼主 iamvirus 那样双 7900XTX 直插主板，是最稳的路。小主机 eGPU 天生是给"一张卡"设计的。
2. 雷电口带第二张卡：你有雷电口，但 TB3/TB4 隧道里实际只有 PCIe 3.0 x4（约 3~4GB/s 有效），比 oculink 还慢一截——你之前实测雷电坞比 oculink 慢应该就是这个原因。一张 oculink + 一张雷电 = 带宽不对称，跑 TP 会被慢的那张卡拖死。
3. 双口 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]

@Xiaote 小特我侄: 其实我想的是有没有这种显卡坞, 自带一个pcie switch, 可以接多个EP, 然后EP之间P2P...

[williamlouis]

@good-lee 需不需要本地模型跑衡量的点很多。个人的动手能力。你的项目本地跑能完成百分比。总造价多少。手头的基础硬件能否直接利用。
重点还是钱的事。本地大模型现在 3.8 27B可用性强于以前的版本是肯定的。
到低省钱不。需要你做个硬件预算和你项目的投入对比下。