你的情况：4×R9700 每卡 32G，跑 27B FP8 本来就是正解，tensor 并行下每卡权重才 7G，KV 余量很足。4bit 的真正意义是"用质量换容量/并发"——想每卡独立跑一个实例、或把上下文拉得极长时再降不迟。如果当前 FP8 已经跑顺了，没必要为省显存降级。

[實測] R9700 (gfx1201) 雙卡別再試 vLLM tensor-parallel — 附四卡該怎麼配

看到有人問四卡要怎麼處理,先把我們踩過的坑跟數字放上來,省下你重走一遍。

TL;DR

• vLLM TP/PP 在 gfx1201 VM上跑不起來,裸機也一樣,不是你設定錯
• 就算修好,卡越多越慢 —— 有人 8 卡 TP=8 跑到 3.9 tok/s,輸我們 2 卡的 16
• 四卡的正解是四個獨立實例,不是把一個模型切四份

症狀

雙 R9700,--tensor-parallel-size 2:

NCCL error: unhandled cuda error
HIP failure 'the operation cannot be performed in the present state'
  at .../rccl/build/hipify/src/enqueue.cc:1926

關鍵細節:ncclCommInitRank 是成功的(tuning index 7 有對到 gfx1201),
死在後面實際 kernel enqueue。所以不是「認不到卡」或「拓樸不通」。

試過但沒用的(全部同一個死法)

#	配方	結果
1	kyuz0 image + P2P 全開,不加任何 disable
2	官方 vllm-openai-rocm:v0.20.2 + NCCL_PROTO=Simple
3	NCCL_P2P_DISABLE=1 + NCCL_SHM_DISABLE=0 + HSA_ENABLE_SDMA=0 + HSA_FORCE_FINE_GRAIN_PCIE=1
4	上述 + guest kernel iommu=pt

跟 image 版本、傳輸方式(P2P/SHM)、SDMA、fine-grain、IOMMU 全部無關。

這不是虛擬化造成的

Puget Systems 的裸機實測明確寫:

stock vLLM cannot serve a model across two R9700s in either multi-GPU mode

TP 和 PP 都不行 —— vLLM v1 引擎不管哪種平行模式,distributed init
都會做一次 RCCL all-reduce。

最貴的一課:修好 P2P 沒有用

我們花了不少工夫把 VM passthrough 的 ReBAR 修好
(BAR0 從 256MB resize 到 32GB + OVMF X-PciMmio64Mb 加大 MMIO 窗口)。
修完之後 rocm-smi --showtopo 確認兩卡 PCIE 直連,
RCCL log 也看得到 via P2P/IPC + Connected all rings。

然後 TP=2 死在同一行 enqueue.cc。

P2P/ReBAR 修復是必要但不充分:它讓 RCCL 通道建立成功了,
但過不了 collective kernel launch。

(ReBAR 對 llama.cpp 是純加分,卡間傳輸現在走直連 —— 那部分值得修。)

數字:為什麼「卡越多越慢」

同一顆 Qwen3.8-27B,llama.cpp + Vulkan,ReBAR 已修復:

單卡(模型裝得下)

雙卡 split-mode 對照(llama-bench)

llama.cpp 自己也有 TP 型的切法,三種都能跑,但 layer 全面最快 ——
PCIe x8 的卡間延遲吃掉了 TP 的並行收益。

八卡 TP=8(Level1Techs,裸機 Gen5 x16,自製修補 RCCL 2.30.4)

~3.9 tok/s

43 層 × 86 次同步點被 PCIe 延遲拖垮。他們的硬體條件(裸機直插)
比我們的 VM passthrough 好,8 張卡還是打不過我們 2 張的 16.4。

把三組放在一起

在這個硬體上,layer split 勝過 tensor parallel 是物理規律,不是軟體沒調好。
而「不切」又勝過「切」—— 差了 4 倍。

所以四卡該怎麼配?

先問一句:你的模型放得進單張 32GB 嗎?

放得下 → 四個獨立實例,不要切

card0  llama-server  instance A ─┐
card1  llama-server  instance B ─┤
card2  llama-server  instance C ─┼─→ 前面掛一個 OpenAI 相容閘道做負載平衡
card3  llama-server  instance D ─┘

• 每個實例都是滿速 ~65 tok/s
• 四個併發槽,聚合吞吐 ~260 tok/s
• 一張卡掛掉只損失 1/4,不是整組死
• 完全不碰 RCCL

我們兩卡就是這樣跑的(前面掛 LiteLLM 做別名與 key 管理),
Qwen3.8-27B Q4_K_XL 只有 16.4 GiB,單卡綽綽有餘。

放不下 → 用剛好夠的卡數做 layer-split,不是全部下去

一個 60GB 的模型,用 2 張 layer-split,剩下 2 張跑第二個實例 ——
不要 4 張切一份。每多一張卡就多一組同步點,而收益是零。

# llama.cpp,不經 RCCL
llama-server -m model.gguf --split-mode layer -ngl 99 ...
# 預設就會自動分卡,不需要 tensor-split

真的非要 vLLM TP 不可 → 兩條路,都不推薦

1. GPU 改裸機直跑(VM passthrough 這條已確認無解)
2. 自己編譯修補版 RCCL 2.30.4
   (修掉 TP≥2 觸發的 DDA IPC 初始化路徑問題,官方 nightly 沒這個補丁)
   配 NCCL_P2P_DISABLE=1 + NCCL_SHM_DISABLE=0
   —— 注意是保留 SHM,跟多數人試的「兩個都關」相反

但看上面那張表:修好之後大概率比 llama.cpp 慢。 工程成本換來更慢的東西。

追蹤中

ROCm/rocm-systems#5480
—— 標題就是「RCCL deadlock during vLLM TP=2 inference on dual R9700 (gfx1201/RDNA4)」,
同代 Ryzen X3D + 2× R9700,跟我們幾乎同一台機器。

查證時狀態:Open,已指派 @tcgu-amd,無官方回應/時程。
確認是 RCCL 2.27.3 → 2.27.7 之間的回歸性 bug。
回報者自己試 NCCL_P2P_DISABLE=1 無效
(跟 Level1Techs 8 卡帖裡有效的 workaround 不同 —— 那是另一組版本組合,不能直接套)。

要問雙卡/四卡 vLLM TP 有沒有進展,先去看 #5480 狀態變了沒。

觀察名單:SGLang

有人在裸機雙 R9700 跑通 TP=2
(mattbucci/2x-R9700-RDNA4-GFX1201-sglang-inference
—— SGLang v0.5.16 + 69 個自製 patch + RCCL 2.27.7 釘版)。

裸機 only,而且 TP=2 重啟會間歇 RCCL coredump(作者自己掛 watchdog),
不適合當常駐後端。他的高速主要來自 MoE 模型(A3B 每 token 只動約 3B 參數);
dense 27B 在 gfx1201 填不滿 CU 是他親測結論 —— 跟我們的實測一致。

環境:PVE + VM passthrough,2× AMD Radeon AI PRO R9700 (gfx1201),
ROCm 7.14,llama.cpp + Vulkan (kyuz0/amd-r9700-toolboxes:vulkan-radv)。

1. 为什么 3.6 换 3.8 明显变慢（架构原因，不是参数）
Qwen3.8-27B 是 hybrid Mamba+Attention：只有 16 层 attention 需要缓存 KV，其余是 mamba state。prefix caching 在这类模型上有已知坑（零命中/白算），等于 Hermes 每回合整包重发上下文时 prefill 全量重算，缓存基本白开；3.6 是纯 attention，cache 还能命中一段。所以"3.6 还行、3.8 拉胯"大概率不是调参能救的，是模型架构对 agent 重 prefill 场景更不友好。

2. 两个数先查

• curl localhost:8000/metrics | grep num_preemptions_total——只要在涨，就是 180K 长上下文把 KV 池挤爆被踢重算，把 --max-model-len 砍到 65536/98304、--max-num-seqs 降到 8-12（楼上已说，我同意）。
• fp8 是否真生效：看 vLLM 启动日志有没有 FP8 kernel 选择（gfx1201 的 FP8 走 AITER/半官方路径，不对会静默回退 BF16，权重和 KV 白翻倍）。

3. Flash-Next：别上，更别为它加卡
Flash-Next 176B，FP8 权重就要 ~176GB，4 卡 128G、加第 5 卡 160G 都装不下；只能跑 IQ4_XS ~100GB 的量化。但你这场景是 agent 多用户、每回合 3-6 万 token 重 prefill，176B 的 prefill 比 27B 慢一个数量级，加卡只会更惨。27B 就是这个负载的甜点；真想提质量，试 35B 级模型更实际。

4. 并发才是多人变慢的主开关
24 个 seq 槽对 agent"占坑型"会话太多：5 个同事的飞书会话能占满长上下文坑位互相挤。降到 8-12 之外，飞书接入端也限制同时活跃的会话数，比调 vLLM 参数立竿见影。

改完把一轮 Hermes 的实际 prompt 长度（日志里的 input tokens）贴出来，能帮你把 KV 预算算死。

再叠一层：你 --max-model-len 180000 是预分配，不是弹性。这模型是 hybrid-attention，只有 16 层缓存 KV，FP8 约 32KiB/token，180000×24≈134GiB，超过你 4×32=128GiB 的池子。长上下文一挤，vLLM 就 preemption（踢出去重算），这就是掉到个位数的直接原因。

按影响改几个：

1. --max-model-len 降到 65536 或 98304 就够，别 180000。KV 启动时就分配好，调低等于把池子腾给并发。
2. 日志里num_preemptions_total在涨就把--max-num-seqs降到 8-12。agent 会话是占坑的，不是快查询。
3. --max-num-batched-tokens 24576 偏大偏吞吐，多人求快降到 8192-16384。
4. --enable-prefix-caching先关掉量一次。hybrid 模型的 prefix cache 有已知坑（零命中/白算），agent 最需要它却常不中用。
5. MTP 你 94% accept 说明能跑，但多人吞吐帮助有限，反而多一层 verify，可关可留。
6. 确认下你 vllm-openai-rocm:latest 是不是真原生 FP8，还是偷偷反量化回 FP32。是的话加 VLLM_ROCM_USE_AITER=0 跑，顺便 python3 -c "import aiter.ops.triton.utils.arch_info as a; a._ARCH_TO_DEVICE['gfx1201']='MI350X'"。

量测看 curl localhost:8000/metrics | grep -E "num_preemptions_total|spec_decode_num_accepted_tokens_total"，改一处重启对照。把一轮 Hermes 的 prompt 长度贴出来更好判断。