-
看来我长期被llama 坑惨了。。。速度尽然可以相差3倍之多。。。
我再看看有什么可以捣鼓的，长期在win11 也不是办法 -
@Mediali-Li 没办法的，这个价位只能5070ti 16gb....
在中国还可以选3090。。。
在东南亚都是硬吃amd 的韭菜手段 -
@Mediali-Li 没办法的，这个价位只能5070ti 16gb....
在中国还可以选3090。。。
在东南亚都是硬吃amd 的韭菜手段@imbiplaza-ASUS 现在新加坡 马来西亚的2手 3090 都比淘宝便宜
想买2手来改水冷玩4张3090 但是难度太高 钱要花太多
-
还好 我可以经常回国，在美国也没啥好买的，不过之前特价倒是入了3张5090 现在派用场了
-
@imbiplaza-ASUS 现在新加坡 马来西亚的2手 3090 都比淘宝便宜
想买2手来改水冷玩4张3090 但是难度太高 钱要花太多
@applejuice
3090神卡来的。。。。卖家不愁顾客 -
双卡 R9700 跑这套 TP 思路可以，但和双 7900XTX 是两码事，别直接类比：
- R9700 32G，双卡就是 64GB 池，容量比 7900XTX 双卡（48G）还大。
- 但带宽和架构不同档：R9700（RDNA4 中端）单卡带宽约 640GB/s，7900XTX（RDNA3 满血）约 960GB/s。TP2 吃的是聚合带宽，所以双 R9700 的 decode 未必跑得赢双 7900XTX，优势在容量和功耗——更省电、温度更友好。
- 一样的前提：RDNA 跑 TP2 必须用 JartX fork（stock vLLM 无官方 RDNA TP）。双 R9700 TP2 的收益主要在「能塞更大模型 + 多并发」，不是「单流更快」。
- 结论：要大模型/多用户并发 → 双 R9700 划算；要单流极限速度 → 双 7900XTX（散热坑大）。日常 27B + ComfyUI，单卡 R9700 就够，别一上来就双卡。
-
我就一张7900xtx，之前试sglang 跑fp8 双r9700 开mtp，32k ctx会掉到10几tok/s，普通请求40 -50，关mtp 32k也能稳定25左右tok/s，短的也差不多
-
，系统 取消固定了此主题
-
我就一张7900xtx，之前试sglang 跑fp8 双r9700 开mtp，32k ctx会掉到10几tok/s，普通请求40 -50，关mtp 32k也能稳定25左右tok/s，短的也差不多
-
@stormaround 这卡 prefill太低了 说白了就是性能不行 做智能体几乎不能用
-
@flyer666 顶礼膜拜flyer666 大神，上次看了您 8/23 发的帖子《双卡 7900 XTX VLLM 跑 Qwen3.8，爽玩 Agent，PP1600 / TG160+（附 MTP / 7900 XTX 全攻略）》之后，我也照着折腾了一套双卡部署。
从之前单卡 llama.cpp Vulkan，到现在双 7900 XTX TP2，体感真的是“一步登天”。不光速度上去了，并发、长上下文、Agent 实际使用体验也完全不是一个级别，确实让我第一次很直观地体会到 1+1 > 2 的感觉。
听老特周末的视频，马上搜到了这个帖子，花了三天时间狠狠折腾了一轮 SGLang，短 benchmark 一度非常惊艳，但真实多 Agent 长上下文用下来踩了一个挺大的坑，也顺手做了一轮比较完整的排查，想把结果发出来给大家参考，也希望有高人能够指点一二。
SGLang 的短 benchmark 确实非常漂亮，C4 aggregate decode 能跑到 200 tok/s 左右，一开始我还挺满意。
但真正拿去跑 Hermes / 多 Agent 以后，体验完全不是一回事：一个长上下文请求开始 prefill，另外一个正在回复的 Agent 会直接“冻住”几十秒。反复优化排查，甚至尝试了最新的RCOM10，问题依旧，表现就是一开始三并发甚至四并发都是飞一般的速度，堪比DSF，但是对话和跑任务几轮后就体会到了明显的卡顿，甚至所有的并发全部卡死（假死，后台排队但是token速度降到10几甚至个位数）。
我后来折腾ChatGPT和DeepSeek做了一系列测试，ChatGPT告诉我基本把问题钉死了。所以目前我的选择很简单：生产切回前一个帖子介绍的vLLM， 目前是Int8 KV 192K上下文三并发，设置65%的压缩阈值，可以做到两个并发跑满，另外一个并发用作本地识图（小上下文）。为什么不用Int4 KV？是因为开满三并发或者四并发的速度体验下降太大，而且测下来Int8反而是速度上的甜点，反正我两个本地推理+1个本地识图服务足够了。
说回到SGLang我踩得坑，我的环境大概是：
2× RX 7900 XTX，TP2
Qwen3.8-27B W4A16 GPTQ
SGLang gfx1100 fork
BF16 KV
192K context
MTP3 / EAGLE
FCFS scheduler
chunked prefill 4096最典型的一组测试
先让 A：64K prefill → 开始正常 decode
等 5 秒，再让 B 加入：64K prefill
结果：
A 最大无 token gap：47.226 秒
B TTFT：49.434 秒
A 的停顿覆盖了 B prefill 时间的 95.5%
waiting=0
KV peak 只有 49.76%也就是说：
不是 KV 不够，也不是请求排队。B 在做 64K prefill 的时候，A 基本整整 47 秒不吐一个 token。
这就完全解释了为什么 benchmark 看着很猛，实际多 Agent 用起来却很“卡”。
三并发更明显：
A 最大停顿：67.736 秒
B 已经开始回复后又停了：18.468 秒
C TTFT：64.945 秒
KV peak 也才 62.22%所以这不是“显存撑爆了”的问题。
我又把几个最可能的原因逐个排了一遍
MTP？
关掉 MTP/EAGLE，其他不动：
MTP3：A gap 47.226s
MTP OFF：A gap 45.051s只改善大约 4.6%。
所以 MTP 不是主因。
chunk 太大？
把：
4096 → 2048
结果：
4096：47.226s
2048：48.913s基本没区别。
ROCm 版本？
这个我也折腾得比较彻底，7.2、7.14、ROCm 10 nightly 都实际跑过。
短 benchmark 里 ROCm 10 hot run 有时候确实快一点，之前 C4 decode 大约能看到几个百分点的优势；7.14 没表现出什么特别明显的好处。
但放到真正有问题的 long-context workload：
ROCm 7.2：A gap 47.226s
ROCm 10 nightly：A gap 54.234sROCm 10 这次反而更慢，因为 64K prefill 本身更慢，结果 A 被“冻住”的时间也跟着变长。
所以至少在我这套环境里：
升级 ROCm 并不能解决这个问题。
它可能改变 prefill/kernel 的原始速度，但没有改变“prefill 期间 concurrent decode 被饿死”这个行为。
网上也有一些很接近的 SGLang issue
我后来查了一圈，发现这个方向并不是完全没人碰到。
比较值得看的有：
SGLang #32549：持续 chunked prefill 时出现 decode starvation，和我的现象最接近。
Discussion #27762：讨论新 prefill 如何严重影响正在运行的 decode，以及如何优先保护 decode。
#35537：chunked-prefill scheduler 里也出现过 starvation / waiting request 长时间得不到调度的问题。
#34676：Hybrid/Mamba 模型的 prefill/cache/scheduler 路径也有相关问题。
#38319：Qwen3.8 + chunked prefill + Radix Cache 还有另外的 race/cache 问题。这些 issue 不一定和我这个 47 秒 stall 是完全同一个 bug，但至少说明 SGLang 最近这一块 scheduler / chunked-prefill / hybrid model 的路径确实还有不少边角问题。
我最后的结论：
我现在比较确定的一点是：短 PP + C4 aggregate tok/s，不能代表真实多 Agent 体验。
以前我测：
PP≈2K
C4数字非常好看。和帖子里的数值基本一致。
但现实是：
A 已经在长上下文里回复
+
B 突然带着 64K/100K 历史进来，然后两边卡几分钟。。。这才是 Agent 的真实 workload。
所以以后我测 serving engine，一定会加这一条：
A: 64K → 开始 decode
5 秒后
B: 64K prefill然后看：A max no-token gap
我的 SGLang 现在实测的结果是：47 秒。就是说我的B会话要等将近一分钟。这还只是64K，大家都知道Hermes启动阶段可能就不止这个数量级了，何况是几轮后上下文滚动到100K+。
所以这一轮的学习，就是这个实测数字对我来说，已经比“C4 200 tok/s”实用得多了。
罗嗦一大圈，最后总结一下：
之前 vLLM 已经连续用了两个星期，和云端大模型搭配着用，整体效果其实已经非常满意了。同样是多 Agent、长上下文的使用方式，vLLM 基本没有出现过这种“一个长 prefill 一进来，另外一路直接冻住几十秒”的情况，日常体感明显更顺。
这段时间在论坛里跟老特和各位高手确实学到了太多东西。7900XTX就是给老特给安利买的。R9700我嫌声音太吵让我给退了然后价格猛涨后悔不迭，然后最近学到单卡 Vulkan 能把本地模型更顺滑得在7900XTX上跑起来，我就已经喜出望外了；看了flyer666大神的帖子马上又买了一张7900XTX组双卡折腾 vLLM、TP2、MTP、长上下文和多并发，才发现这张2022年发布的AMD显卡居然还能玩得这么溜，性价比拉满。
大家可能都比我先知道，SGLang 对 RDNA3 一直算是个“黑洞”，坑不少、但是诱惑大，潜力也摆在那儿。我这次折腾完最大的感受就是：既然现在 vLLM 已经能把双 7900 XTX 跑到这个程度，而且实际 Agent 体验也够稳，确实有点“还要什么自行车”的意思了，先把vLLM用好了，坐等科技日新月异。
备注：不会排版，不知不觉罗列了这么长，卡到这儿的兄弟们您受累了。
附：硬件环境
CPU：AMD AM5 平台 主板：GIGABYTE B850 AI TOP GPU：2 × Radeon RX 7900 XTX 24GB PCIe：CPU 直连 x8/x8 系统内存 64GB PSU：1200W 系统：Ubuntu 24.04 ROCm 主力版本：7.2.3 另外测试过：ROCm 7.14 / ROCm 10 nightly模型
Qwen3.8-27B GPTQ / W4A16
TP2 双卡
context：196608 tokens（192K）
thinking：关闭
主要用途：Hermes / 多 Agent / tool calling / 长上下文并发=========================================
SGLang 参数模型：
--model-path /data/models/Qwen3.8-27B-W4A16-AutoRound-GPTQ
--served-model-name SGLang-27B核心参数：
--tp-size 2
--quantization gptq
--dtype bfloat16
--mamba-ssm-dtype bfloat16--kv-cache-dtype auto
--context-length 196608
--mem-fraction-static 0.94--max-running-requests 4
--max-mamba-cache-size 20--attention-backend triton
--speculative-algorithm EAGLE
--speculative-draft-model-path /data/models/Qwen3.8-27B-W4A16-AutoRound-GPTQ
--speculative-num-steps 3
--speculative-eagle-topk 1
--speculative-num-draft-tokens 4--cuda-graph-bs-decode 1 2 4
--triton-attention-num-kv-splits 16--reasoning-parser qwen3
--tool-call-parser qwen3_coder
--default-chat-template-kwargs '{"enable_thinking": false}'--sleep-on-idle
--trust-remote-code--host 0.0.0.0
--port 8082当前实际：
KV dtype: BF16
KV pool: 265,950 tokens
max running: 4
context: 192K
MTP3scheduler 相关：
schedule_policy = fcfs
chunked_prefill_size = 4096
priority scheduling = off=============================================
vLLM 参数
模型：
--model /data/models/Qwen3.8-27B-Uncensored-GPTQ-MTP
--served-model-name vLLM-27B核心参数：
--tensor-parallel-size 2
--max-model-len 196608
--kv-cache-dtype int8_per_token_head
--max-num-seqs 128
--gpu-memory-utilization 0.95--max-cudagraph-capture-size 128
--enable-auto-tool-choice
--tool-call-parser step3p5
--reasoning-parser qwen3MTP：
method: qwen3_5_mtp
num_speculative_tokens: 3其他：
attention backend: TRITON_ATTN
thinking: false
TP2
INT8 KV
192K contextSGLang 我还是会保留，毕竟 gfx1100 这版性能潜力确实很好。等以后 scheduler / chunked-prefill 这块有更新，我再拿这套 64K + 64K staggered test 回来复测。
-
@flyer666 顶礼膜拜flyer666 大神，上次看了您 8/23 发的帖子《双卡 7900 XTX VLLM 跑 Qwen3.8，爽玩 Agent，PP1600 / TG160+（附 MTP / 7900 XTX 全攻略）》之后，我也照着折腾了一套双卡部署。
从之前单卡 llama.cpp Vulkan，到现在双 7900 XTX TP2，体感真的是“一步登天”。不光速度上去了，并发、长上下文、Agent 实际使用体验也完全不是一个级别，确实让我第一次很直观地体会到 1+1 > 2 的感觉。
听老特周末的视频，马上搜到了这个帖子，花了三天时间狠狠折腾了一轮 SGLang，短 benchmark 一度非常惊艳，但真实多 Agent 长上下文用下来踩了一个挺大的坑，也顺手做了一轮比较完整的排查，想把结果发出来给大家参考，也希望有高人能够指点一二。
SGLang 的短 benchmark 确实非常漂亮，C4 aggregate decode 能跑到 200 tok/s 左右，一开始我还挺满意。
但真正拿去跑 Hermes / 多 Agent 以后，体验完全不是一回事：一个长上下文请求开始 prefill，另外一个正在回复的 Agent 会直接“冻住”几十秒。反复优化排查，甚至尝试了最新的RCOM10，问题依旧，表现就是一开始三并发甚至四并发都是飞一般的速度，堪比DSF，但是对话和跑任务几轮后就体会到了明显的卡顿，甚至所有的并发全部卡死（假死，后台排队但是token速度降到10几甚至个位数）。
我后来折腾ChatGPT和DeepSeek做了一系列测试，ChatGPT告诉我基本把问题钉死了。所以目前我的选择很简单：生产切回前一个帖子介绍的vLLM， 目前是Int8 KV 192K上下文三并发，设置65%的压缩阈值，可以做到两个并发跑满，另外一个并发用作本地识图（小上下文）。为什么不用Int4 KV？是因为开满三并发或者四并发的速度体验下降太大，而且测下来Int8反而是速度上的甜点，反正我两个本地推理+1个本地识图服务足够了。
说回到SGLang我踩得坑，我的环境大概是：
2× RX 7900 XTX，TP2
Qwen3.8-27B W4A16 GPTQ
SGLang gfx1100 fork
BF16 KV
192K context
MTP3 / EAGLE
FCFS scheduler
chunked prefill 4096最典型的一组测试
先让 A：64K prefill → 开始正常 decode
等 5 秒，再让 B 加入：64K prefill
结果：
A 最大无 token gap：47.226 秒
B TTFT：49.434 秒
A 的停顿覆盖了 B prefill 时间的 95.5%
waiting=0
KV peak 只有 49.76%也就是说：
不是 KV 不够，也不是请求排队。B 在做 64K prefill 的时候，A 基本整整 47 秒不吐一个 token。
这就完全解释了为什么 benchmark 看着很猛，实际多 Agent 用起来却很“卡”。
三并发更明显：
A 最大停顿：67.736 秒
B 已经开始回复后又停了：18.468 秒
C TTFT：64.945 秒
KV peak 也才 62.22%所以这不是“显存撑爆了”的问题。
我又把几个最可能的原因逐个排了一遍
MTP？
关掉 MTP/EAGLE，其他不动：
MTP3：A gap 47.226s
MTP OFF：A gap 45.051s只改善大约 4.6%。
所以 MTP 不是主因。
chunk 太大？
把：
4096 → 2048
结果：
4096：47.226s
2048：48.913s基本没区别。
ROCm 版本？
这个我也折腾得比较彻底，7.2、7.14、ROCm 10 nightly 都实际跑过。
短 benchmark 里 ROCm 10 hot run 有时候确实快一点，之前 C4 decode 大约能看到几个百分点的优势；7.14 没表现出什么特别明显的好处。
但放到真正有问题的 long-context workload：
ROCm 7.2：A gap 47.226s
ROCm 10 nightly：A gap 54.234sROCm 10 这次反而更慢，因为 64K prefill 本身更慢，结果 A 被“冻住”的时间也跟着变长。
所以至少在我这套环境里：
升级 ROCm 并不能解决这个问题。
它可能改变 prefill/kernel 的原始速度，但没有改变“prefill 期间 concurrent decode 被饿死”这个行为。
网上也有一些很接近的 SGLang issue
我后来查了一圈，发现这个方向并不是完全没人碰到。
比较值得看的有：
SGLang #32549：持续 chunked prefill 时出现 decode starvation，和我的现象最接近。
Discussion #27762：讨论新 prefill 如何严重影响正在运行的 decode，以及如何优先保护 decode。
#35537：chunked-prefill scheduler 里也出现过 starvation / waiting request 长时间得不到调度的问题。
#34676：Hybrid/Mamba 模型的 prefill/cache/scheduler 路径也有相关问题。
#38319：Qwen3.8 + chunked prefill + Radix Cache 还有另外的 race/cache 问题。这些 issue 不一定和我这个 47 秒 stall 是完全同一个 bug，但至少说明 SGLang 最近这一块 scheduler / chunked-prefill / hybrid model 的路径确实还有不少边角问题。
我最后的结论：
我现在比较确定的一点是：短 PP + C4 aggregate tok/s，不能代表真实多 Agent 体验。
以前我测：
PP≈2K
C4数字非常好看。和帖子里的数值基本一致。
但现实是：
A 已经在长上下文里回复
+
B 突然带着 64K/100K 历史进来，然后两边卡几分钟。。。这才是 Agent 的真实 workload。
所以以后我测 serving engine，一定会加这一条：
A: 64K → 开始 decode
5 秒后
B: 64K prefill然后看：A max no-token gap
我的 SGLang 现在实测的结果是：47 秒。就是说我的B会话要等将近一分钟。这还只是64K，大家都知道Hermes启动阶段可能就不止这个数量级了，何况是几轮后上下文滚动到100K+。
所以这一轮的学习，就是这个实测数字对我来说，已经比“C4 200 tok/s”实用得多了。
罗嗦一大圈，最后总结一下：
之前 vLLM 已经连续用了两个星期，和云端大模型搭配着用，整体效果其实已经非常满意了。同样是多 Agent、长上下文的使用方式，vLLM 基本没有出现过这种“一个长 prefill 一进来，另外一路直接冻住几十秒”的情况，日常体感明显更顺。
这段时间在论坛里跟老特和各位高手确实学到了太多东西。7900XTX就是给老特给安利买的。R9700我嫌声音太吵让我给退了然后价格猛涨后悔不迭，然后最近学到单卡 Vulkan 能把本地模型更顺滑得在7900XTX上跑起来，我就已经喜出望外了；看了flyer666大神的帖子马上又买了一张7900XTX组双卡折腾 vLLM、TP2、MTP、长上下文和多并发，才发现这张2022年发布的AMD显卡居然还能玩得这么溜，性价比拉满。
大家可能都比我先知道，SGLang 对 RDNA3 一直算是个“黑洞”，坑不少、但是诱惑大，潜力也摆在那儿。我这次折腾完最大的感受就是：既然现在 vLLM 已经能把双 7900 XTX 跑到这个程度，而且实际 Agent 体验也够稳，确实有点“还要什么自行车”的意思了，先把vLLM用好了，坐等科技日新月异。
备注：不会排版，不知不觉罗列了这么长，卡到这儿的兄弟们您受累了。
附：硬件环境
CPU：AMD AM5 平台 主板：GIGABYTE B850 AI TOP GPU：2 × Radeon RX 7900 XTX 24GB PCIe：CPU 直连 x8/x8 系统内存 64GB PSU：1200W 系统：Ubuntu 24.04 ROCm 主力版本：7.2.3 另外测试过：ROCm 7.14 / ROCm 10 nightly模型
Qwen3.8-27B GPTQ / W4A16
TP2 双卡
context：196608 tokens（192K）
thinking：关闭
主要用途：Hermes / 多 Agent / tool calling / 长上下文并发=========================================
SGLang 参数模型：
--model-path /data/models/Qwen3.8-27B-W4A16-AutoRound-GPTQ
--served-model-name SGLang-27B核心参数：
--tp-size 2
--quantization gptq
--dtype bfloat16
--mamba-ssm-dtype bfloat16--kv-cache-dtype auto
--context-length 196608
--mem-fraction-static 0.94--max-running-requests 4
--max-mamba-cache-size 20--attention-backend triton
--speculative-algorithm EAGLE
--speculative-draft-model-path /data/models/Qwen3.8-27B-W4A16-AutoRound-GPTQ
--speculative-num-steps 3
--speculative-eagle-topk 1
--speculative-num-draft-tokens 4--cuda-graph-bs-decode 1 2 4
--triton-attention-num-kv-splits 16--reasoning-parser qwen3
--tool-call-parser qwen3_coder
--default-chat-template-kwargs '{"enable_thinking": false}'--sleep-on-idle
--trust-remote-code--host 0.0.0.0
--port 8082当前实际：
KV dtype: BF16
KV pool: 265,950 tokens
max running: 4
context: 192K
MTP3scheduler 相关：
schedule_policy = fcfs
chunked_prefill_size = 4096
priority scheduling = off=============================================
vLLM 参数
模型：
--model /data/models/Qwen3.8-27B-Uncensored-GPTQ-MTP
--served-model-name vLLM-27B核心参数：
--tensor-parallel-size 2
--max-model-len 196608
--kv-cache-dtype int8_per_token_head
--max-num-seqs 128
--gpu-memory-utilization 0.95--max-cudagraph-capture-size 128
--enable-auto-tool-choice
--tool-call-parser step3p5
--reasoning-parser qwen3MTP：
method: qwen3_5_mtp
num_speculative_tokens: 3其他：
attention backend: TRITON_ATTN
thinking: false
TP2
INT8 KV
192K contextSGLang 我还是会保留，毕竟 gfx1100 这版性能潜力确实很好。等以后 scheduler / chunked-prefill 这块有更新，我再拿这套 64K + 64K staggered test 回来复测。
-
-
我是双卡的，经过测试速度vllm满意多了，
这是30k左右上下文的速度 [2026-09-09 19:50:38 TP0] Decode batch, #running-req: 1, #full token: 33103, full token usage: 0.14, mamba num: 4, mamba usage: 0.20, accept len: 2.77, accept rate: 0.59, cuda graph: True, gen throughput (token/s): 60.85, #queue-req: 0 [2026-09-09 19:50:39 TP0] Decode batch, #running-req: 1, #full token: 33215, full token usage: 0.14, mamba num: 4, mamba usage: 0.20, accept len: 2.85, accept rate: 0.62, cuda graph: True, gen throughput (token/s): 62.58, #queue-req: 0 [2026-09-09 19:50:41 TP0] Decode batch, #running-req: 1, #full token: 33332, full token usage: 0.14, mamba num: 4, mamba usage: 0.20, accept len: 2.88, accept rate: 0.62, cuda graph: True, gen throughput (token/s): 62.95, #queue-req: 0 [2026-09-09 19:50:43 TP0] Decode batch, #running-req: 1, #full token: 33434, full token usage: 0.14, mamba num: 4, mamba usage: 0.20, accept len: 2.55, accept rate: 0.52, cuda graph: True, gen throughput (token/s): 55.82, #queue-req: 0 [2026-09-09 19:50:45 TP0] Decode batch, #running-req: 1, #full token: 33542, full token usage: 0.14, mamba num: 4, mamba usage: 0.20, accept len: 2.73, accept rate: 0.57, cuda graph: True, gen throughput (token/s): 59.54, #queue-req: 0 [2026-09-09 19:50:47 TP0] Decode batch, #running-req: 1, #full token: 33665, full token usage: 0.14, mamba num: 4, mamba usage: 0.20, accept len: 3.10, accept rate: 0.70, cuda graph: True, gen throughput (token/s): 66.78, #queue-req: 0 [2026-09-09 19:50:49 TP0] Decode batch, #running-req: 1, #full token: 33810, full token usage: 0.14, mamba num: 4, mamba usage: 0.20, accept len: 3.62, accept rate: 0.88, cuda graph: True, gen throughput (token/s): 79.26, #queue-req: 0 [2026-09-09 19:50:50 TP0] Decode batch, #running-req: 1, #full token: 33943, full token usage: 0.14, mamba num: 4, mamba usage: 0.20, accept len: 3.33, accept rate: 0.78, cuda graph: True, gen throughput (token/s): 72.62, #queue-req: 0 [2026-09-09 19:50:52 TP0] Decode batch, #running-req: 1, #full token: 34081, full token usage: 0.14, mamba num: 4, mamba usage: 0.20, accept len: 3.38, accept rate: 0.79, cuda graph: True, gen throughput (token/s): 73.58, #queue-req: 0 [2026-09-09 19:50:54 TP0] Decode batch, #running-req: 1, #full token: 34213, full token usage: 0.14, mamba num: 4, mamba usage: 0.20, accept len: 3.38, accept rate: 0.79, cuda graph: True, gen throughput (token/s): 73.63, #queue-req: 0 [2026-09-09 19:50:56 TP0] Decode batch, #running-req: 1, #full token: 34358, full token usage: 0.14, mamba num: 4, mamba usage: 0.20, accept len: 3.62, accept rate: 0.88, cuda graph: True, gen throughput (token/s): 79.04, #queue-req: 0 [2026-09-09 19:50:58 TP0] Decode batch, #running-req: 1, #full token: 34485, full token usage: 0.14, mamba num: 4, mamba usage: 0.20, accept len: 3.12, accept rate: 0.71, cuda graph: True, gen throughput (token/s): 68.08, #queue-req: 0这是64k上下文左右的 [2026-09-09 19:59:43 TP0] Decode batch, #running-req: 1, #full token: 67798, full token usage: 0.28, mamba num: 4, mamba usage: 0.20, accept len: 3.40, accept rate: 0.80, cuda graph: True, gen throughput (token/s): 62.86, #queue-req: 0 [2026-09-09 19:59:45 TP0] Decode batch, #running-req: 1, #full token: 67933, full token usage: 0.28, mamba num: 4, mamba usage: 0.20, accept len: 3.38, accept rate: 0.79, cuda graph: True, gen throughput (token/s): 62.37, #queue-req: 0 [2026-09-09 19:59:47 TP0] Decode batch, #running-req: 1, #full token: 68056, full token usage: 0.28, mamba num: 4, mamba usage: 0.20, accept len: 3.08, accept rate: 0.69, cuda graph: True, gen throughput (token/s): 56.86, #queue-req: 0 [2026-09-09 19:59:49 TP0] Decode batch, #running-req: 1, #full token: 68170, full token usage: 0.28, mamba num: 4, mamba usage: 0.20, accept len: 2.92, accept rate: 0.64, cuda graph: True, gen throughput (token/s): 53.99, #queue-req: 0 [2026-09-09 19:59:52 TP0] Decode batch, #running-req: 1, #full token: 68298, full token usage: 0.28, mamba num: 4, mamba usage: 0.20, accept len: 3.20, accept rate: 0.73, cuda graph: True, gen throughput (token/s): 59.00, #queue-req: 0 [2026-09-09 19:59:54 TP0] Decode batch, #running-req: 1, #full token: 68418, full token usage: 0.28, mamba num: 4, mamba usage: 0.20, accept len: 3.00, accept rate: 0.67, cuda graph: True, gen throughput (token/s): 55.36, #queue-req: 0 [2026-09-09 19:59:56 TP0] Decode batch, #running-req: 1, #full token: 68532, full token usage: 0.28, mamba num: 4, mamba usage: 0.20, accept len: 2.77, accept rate: 0.59, cuda graph: True, gen throughput (token/s): 51.23, #queue-req: 0 [2026-09-09 19:59:58 TP0] Decode batch, #running-req: 1, #full token: 68636, full token usage: 0.28, mamba num: 4, mamba usage: 0.20, accept len: 2.60, accept rate: 0.53, cuda graph: True, gen throughput (token/s): 47.93, #queue-req: 0 [2026-09-09 20:00:00 TP0] Decode batch, #running-req: 1, #full token: 68729, full token usage: 0.28, mamba num: 4, mamba usage: 0.20, accept len: 2.35, accept rate: 0.45, cuda graph: True, gen throughput (token/s): 43.04, #queue-req: 0 [2026-09-09 20:00:02 TP0] Decode batch, #running-req: 1, #full token: 68822, full token usage: 0.28, mamba num: 4, mamba usage: 0.20, accept len: 2.30, accept rate: 0.43, cuda graph: True, gen throughput (token/s): 42.36, #queue-req: 0 [2026-09-09 20:00:05 TP0] Decode batch, #running-req: 1, #full token: 68901, full token usage: 0.28, mamba num: 4, mamba usage: 0.20, accept len: 2.05, accept rate: 0.35, cuda graph: True, gen throughput (token/s): 37.75, #queue-req: 0 [2026-09-09 20:00:07 TP0] Decode batch, #running-req: 1, #full token: 69001, full token usage: 0.28, mamba num: 4, mamba usage: 0.20, accept len: 2.48, accept rate: 0.49, cuda graph: True, gen throughput (token/s): 45.58, #queue-req: 0 [2026-09-09 20:00:09 TP0] Decode batch, #running-req: 1, #full token: 69130, full token usage: 0.28, mamba num: 4, mamba usage: 0.20, accept len: 3.25, accept rate: 0.75, cuda graph: True, gen throughput (token/s): 59.83, #queue-req: 0 [2026-09-09 20:00:11 TP0] Decode batch, #running-req: 1, #full token: 69247, full token usage: 0.28, mamba num: 4, mamba usage: 0.20, accept len: 2.85, accept rate: 0.62, cuda graph: True, gen throughput (token/s): 52.28, #queue-req: 0使用codex和用dsh和hermes调用的话非常舒服
-
我是双卡的，经过测试速度vllm满意多了，
这是30k左右上下文的速度 [2026-09-09 19:50:38 TP0] Decode batch, #running-req: 1, #full token: 33103, full token usage: 0.14, mamba num: 4, mamba usage: 0.20, accept len: 2.77, accept rate: 0.59, cuda graph: True, gen throughput (token/s): 60.85, #queue-req: 0 [2026-09-09 19:50:39 TP0] Decode batch, #running-req: 1, #full token: 33215, full token usage: 0.14, mamba num: 4, mamba usage: 0.20, accept len: 2.85, accept rate: 0.62, cuda graph: True, gen throughput (token/s): 62.58, #queue-req: 0 [2026-09-09 19:50:41 TP0] Decode batch, #running-req: 1, #full token: 33332, full token usage: 0.14, mamba num: 4, mamba usage: 0.20, accept len: 2.88, accept rate: 0.62, cuda graph: True, gen throughput (token/s): 62.95, #queue-req: 0 [2026-09-09 19:50:43 TP0] Decode batch, #running-req: 1, #full token: 33434, full token usage: 0.14, mamba num: 4, mamba usage: 0.20, accept len: 2.55, accept rate: 0.52, cuda graph: True, gen throughput (token/s): 55.82, #queue-req: 0 [2026-09-09 19:50:45 TP0] Decode batch, #running-req: 1, #full token: 33542, full token usage: 0.14, mamba num: 4, mamba usage: 0.20, accept len: 2.73, accept rate: 0.57, cuda graph: True, gen throughput (token/s): 59.54, #queue-req: 0 [2026-09-09 19:50:47 TP0] Decode batch, #running-req: 1, #full token: 33665, full token usage: 0.14, mamba num: 4, mamba usage: 0.20, accept len: 3.10, accept rate: 0.70, cuda graph: True, gen throughput (token/s): 66.78, #queue-req: 0 [2026-09-09 19:50:49 TP0] Decode batch, #running-req: 1, #full token: 33810, full token usage: 0.14, mamba num: 4, mamba usage: 0.20, accept len: 3.62, accept rate: 0.88, cuda graph: True, gen throughput (token/s): 79.26, #queue-req: 0 [2026-09-09 19:50:50 TP0] Decode batch, #running-req: 1, #full token: 33943, full token usage: 0.14, mamba num: 4, mamba usage: 0.20, accept len: 3.33, accept rate: 0.78, cuda graph: True, gen throughput (token/s): 72.62, #queue-req: 0 [2026-09-09 19:50:52 TP0] Decode batch, #running-req: 1, #full token: 34081, full token usage: 0.14, mamba num: 4, mamba usage: 0.20, accept len: 3.38, accept rate: 0.79, cuda graph: True, gen throughput (token/s): 73.58, #queue-req: 0 [2026-09-09 19:50:54 TP0] Decode batch, #running-req: 1, #full token: 34213, full token usage: 0.14, mamba num: 4, mamba usage: 0.20, accept len: 3.38, accept rate: 0.79, cuda graph: True, gen throughput (token/s): 73.63, #queue-req: 0 [2026-09-09 19:50:56 TP0] Decode batch, #running-req: 1, #full token: 34358, full token usage: 0.14, mamba num: 4, mamba usage: 0.20, accept len: 3.62, accept rate: 0.88, cuda graph: True, gen throughput (token/s): 79.04, #queue-req: 0 [2026-09-09 19:50:58 TP0] Decode batch, #running-req: 1, #full token: 34485, full token usage: 0.14, mamba num: 4, mamba usage: 0.20, accept len: 3.12, accept rate: 0.71, cuda graph: True, gen throughput (token/s): 68.08, #queue-req: 0这是64k上下文左右的 [2026-09-09 19:59:43 TP0] Decode batch, #running-req: 1, #full token: 67798, full token usage: 0.28, mamba num: 4, mamba usage: 0.20, accept len: 3.40, accept rate: 0.80, cuda graph: True, gen throughput (token/s): 62.86, #queue-req: 0 [2026-09-09 19:59:45 TP0] Decode batch, #running-req: 1, #full token: 67933, full token usage: 0.28, mamba num: 4, mamba usage: 0.20, accept len: 3.38, accept rate: 0.79, cuda graph: True, gen throughput (token/s): 62.37, #queue-req: 0 [2026-09-09 19:59:47 TP0] Decode batch, #running-req: 1, #full token: 68056, full token usage: 0.28, mamba num: 4, mamba usage: 0.20, accept len: 3.08, accept rate: 0.69, cuda graph: True, gen throughput (token/s): 56.86, #queue-req: 0 [2026-09-09 19:59:49 TP0] Decode batch, #running-req: 1, #full token: 68170, full token usage: 0.28, mamba num: 4, mamba usage: 0.20, accept len: 2.92, accept rate: 0.64, cuda graph: True, gen throughput (token/s): 53.99, #queue-req: 0 [2026-09-09 19:59:52 TP0] Decode batch, #running-req: 1, #full token: 68298, full token usage: 0.28, mamba num: 4, mamba usage: 0.20, accept len: 3.20, accept rate: 0.73, cuda graph: True, gen throughput (token/s): 59.00, #queue-req: 0 [2026-09-09 19:59:54 TP0] Decode batch, #running-req: 1, #full token: 68418, full token usage: 0.28, mamba num: 4, mamba usage: 0.20, accept len: 3.00, accept rate: 0.67, cuda graph: True, gen throughput (token/s): 55.36, #queue-req: 0 [2026-09-09 19:59:56 TP0] Decode batch, #running-req: 1, #full token: 68532, full token usage: 0.28, mamba num: 4, mamba usage: 0.20, accept len: 2.77, accept rate: 0.59, cuda graph: True, gen throughput (token/s): 51.23, #queue-req: 0 [2026-09-09 19:59:58 TP0] Decode batch, #running-req: 1, #full token: 68636, full token usage: 0.28, mamba num: 4, mamba usage: 0.20, accept len: 2.60, accept rate: 0.53, cuda graph: True, gen throughput (token/s): 47.93, #queue-req: 0 [2026-09-09 20:00:00 TP0] Decode batch, #running-req: 1, #full token: 68729, full token usage: 0.28, mamba num: 4, mamba usage: 0.20, accept len: 2.35, accept rate: 0.45, cuda graph: True, gen throughput (token/s): 43.04, #queue-req: 0 [2026-09-09 20:00:02 TP0] Decode batch, #running-req: 1, #full token: 68822, full token usage: 0.28, mamba num: 4, mamba usage: 0.20, accept len: 2.30, accept rate: 0.43, cuda graph: True, gen throughput (token/s): 42.36, #queue-req: 0 [2026-09-09 20:00:05 TP0] Decode batch, #running-req: 1, #full token: 68901, full token usage: 0.28, mamba num: 4, mamba usage: 0.20, accept len: 2.05, accept rate: 0.35, cuda graph: True, gen throughput (token/s): 37.75, #queue-req: 0 [2026-09-09 20:00:07 TP0] Decode batch, #running-req: 1, #full token: 69001, full token usage: 0.28, mamba num: 4, mamba usage: 0.20, accept len: 2.48, accept rate: 0.49, cuda graph: True, gen throughput (token/s): 45.58, #queue-req: 0 [2026-09-09 20:00:09 TP0] Decode batch, #running-req: 1, #full token: 69130, full token usage: 0.28, mamba num: 4, mamba usage: 0.20, accept len: 3.25, accept rate: 0.75, cuda graph: True, gen throughput (token/s): 59.83, #queue-req: 0 [2026-09-09 20:00:11 TP0] Decode batch, #running-req: 1, #full token: 69247, full token usage: 0.28, mamba num: 4, mamba usage: 0.20, accept len: 2.85, accept rate: 0.62, cuda graph: True, gen throughput (token/s): 52.28, #queue-req: 0使用codex和用dsh和hermes调用的话非常舒服
-
@flyer666 顶礼膜拜flyer666 大神，上次看了您 8/23 发的帖子《双卡 7900 XTX VLLM 跑 Qwen3.8，爽玩 Agent，PP1600 / TG160+（附 MTP / 7900 XTX 全攻略）》之后，我也照着折腾了一套双卡部署。
从之前单卡 llama.cpp Vulkan，到现在双 7900 XTX TP2，体感真的是“一步登天”。不光速度上去了，并发、长上下文、Agent 实际使用体验也完全不是一个级别，确实让我第一次很直观地体会到 1+1 > 2 的感觉。
听老特周末的视频，马上搜到了这个帖子，花了三天时间狠狠折腾了一轮 SGLang，短 benchmark 一度非常惊艳，但真实多 Agent 长上下文用下来踩了一个挺大的坑，也顺手做了一轮比较完整的排查，想把结果发出来给大家参考，也希望有高人能够指点一二。
SGLang 的短 benchmark 确实非常漂亮，C4 aggregate decode 能跑到 200 tok/s 左右，一开始我还挺满意。
但真正拿去跑 Hermes / 多 Agent 以后，体验完全不是一回事：一个长上下文请求开始 prefill，另外一个正在回复的 Agent 会直接“冻住”几十秒。反复优化排查，甚至尝试了最新的RCOM10，问题依旧，表现就是一开始三并发甚至四并发都是飞一般的速度，堪比DSF，但是对话和跑任务几轮后就体会到了明显的卡顿，甚至所有的并发全部卡死（假死，后台排队但是token速度降到10几甚至个位数）。
我后来折腾ChatGPT和DeepSeek做了一系列测试，ChatGPT告诉我基本把问题钉死了。所以目前我的选择很简单：生产切回前一个帖子介绍的vLLM， 目前是Int8 KV 192K上下文三并发，设置65%的压缩阈值，可以做到两个并发跑满，另外一个并发用作本地识图（小上下文）。为什么不用Int4 KV？是因为开满三并发或者四并发的速度体验下降太大，而且测下来Int8反而是速度上的甜点，反正我两个本地推理+1个本地识图服务足够了。
说回到SGLang我踩得坑，我的环境大概是：
2× RX 7900 XTX，TP2
Qwen3.8-27B W4A16 GPTQ
SGLang gfx1100 fork
BF16 KV
192K context
MTP3 / EAGLE
FCFS scheduler
chunked prefill 4096最典型的一组测试
先让 A：64K prefill → 开始正常 decode
等 5 秒，再让 B 加入：64K prefill
结果：
A 最大无 token gap：47.226 秒
B TTFT：49.434 秒
A 的停顿覆盖了 B prefill 时间的 95.5%
waiting=0
KV peak 只有 49.76%也就是说：
不是 KV 不够，也不是请求排队。B 在做 64K prefill 的时候，A 基本整整 47 秒不吐一个 token。
这就完全解释了为什么 benchmark 看着很猛，实际多 Agent 用起来却很“卡”。
三并发更明显：
A 最大停顿：67.736 秒
B 已经开始回复后又停了：18.468 秒
C TTFT：64.945 秒
KV peak 也才 62.22%所以这不是“显存撑爆了”的问题。
我又把几个最可能的原因逐个排了一遍
MTP？
关掉 MTP/EAGLE，其他不动：
MTP3：A gap 47.226s
MTP OFF：A gap 45.051s只改善大约 4.6%。
所以 MTP 不是主因。
chunk 太大？
把：
4096 → 2048
结果：
4096：47.226s
2048：48.913s基本没区别。
ROCm 版本？
这个我也折腾得比较彻底，7.2、7.14、ROCm 10 nightly 都实际跑过。
短 benchmark 里 ROCm 10 hot run 有时候确实快一点，之前 C4 decode 大约能看到几个百分点的优势；7.14 没表现出什么特别明显的好处。
但放到真正有问题的 long-context workload：
ROCm 7.2：A gap 47.226s
ROCm 10 nightly：A gap 54.234sROCm 10 这次反而更慢，因为 64K prefill 本身更慢，结果 A 被“冻住”的时间也跟着变长。
所以至少在我这套环境里：
升级 ROCm 并不能解决这个问题。
它可能改变 prefill/kernel 的原始速度，但没有改变“prefill 期间 concurrent decode 被饿死”这个行为。
网上也有一些很接近的 SGLang issue
我后来查了一圈，发现这个方向并不是完全没人碰到。
比较值得看的有：
SGLang #32549：持续 chunked prefill 时出现 decode starvation，和我的现象最接近。
Discussion #27762：讨论新 prefill 如何严重影响正在运行的 decode，以及如何优先保护 decode。
#35537：chunked-prefill scheduler 里也出现过 starvation / waiting request 长时间得不到调度的问题。
#34676：Hybrid/Mamba 模型的 prefill/cache/scheduler 路径也有相关问题。
#38319：Qwen3.8 + chunked prefill + Radix Cache 还有另外的 race/cache 问题。这些 issue 不一定和我这个 47 秒 stall 是完全同一个 bug，但至少说明 SGLang 最近这一块 scheduler / chunked-prefill / hybrid model 的路径确实还有不少边角问题。
我最后的结论：
我现在比较确定的一点是：短 PP + C4 aggregate tok/s，不能代表真实多 Agent 体验。
以前我测：
PP≈2K
C4数字非常好看。和帖子里的数值基本一致。
但现实是：
A 已经在长上下文里回复
+
B 突然带着 64K/100K 历史进来，然后两边卡几分钟。。。这才是 Agent 的真实 workload。
所以以后我测 serving engine，一定会加这一条：
A: 64K → 开始 decode
5 秒后
B: 64K prefill然后看：A max no-token gap
我的 SGLang 现在实测的结果是：47 秒。就是说我的B会话要等将近一分钟。这还只是64K，大家都知道Hermes启动阶段可能就不止这个数量级了，何况是几轮后上下文滚动到100K+。
所以这一轮的学习，就是这个实测数字对我来说，已经比“C4 200 tok/s”实用得多了。
罗嗦一大圈，最后总结一下：
之前 vLLM 已经连续用了两个星期，和云端大模型搭配着用，整体效果其实已经非常满意了。同样是多 Agent、长上下文的使用方式，vLLM 基本没有出现过这种“一个长 prefill 一进来，另外一路直接冻住几十秒”的情况，日常体感明显更顺。
这段时间在论坛里跟老特和各位高手确实学到了太多东西。7900XTX就是给老特给安利买的。R9700我嫌声音太吵让我给退了然后价格猛涨后悔不迭，然后最近学到单卡 Vulkan 能把本地模型更顺滑得在7900XTX上跑起来，我就已经喜出望外了；看了flyer666大神的帖子马上又买了一张7900XTX组双卡折腾 vLLM、TP2、MTP、长上下文和多并发，才发现这张2022年发布的AMD显卡居然还能玩得这么溜，性价比拉满。
大家可能都比我先知道，SGLang 对 RDNA3 一直算是个“黑洞”，坑不少、但是诱惑大，潜力也摆在那儿。我这次折腾完最大的感受就是：既然现在 vLLM 已经能把双 7900 XTX 跑到这个程度，而且实际 Agent 体验也够稳，确实有点“还要什么自行车”的意思了，先把vLLM用好了，坐等科技日新月异。
备注：不会排版，不知不觉罗列了这么长，卡到这儿的兄弟们您受累了。
附：硬件环境
CPU：AMD AM5 平台 主板：GIGABYTE B850 AI TOP GPU：2 × Radeon RX 7900 XTX 24GB PCIe：CPU 直连 x8/x8 系统内存 64GB PSU：1200W 系统：Ubuntu 24.04 ROCm 主力版本：7.2.3 另外测试过：ROCm 7.14 / ROCm 10 nightly模型
Qwen3.8-27B GPTQ / W4A16
TP2 双卡
context：196608 tokens（192K）
thinking：关闭
主要用途：Hermes / 多 Agent / tool calling / 长上下文并发=========================================
SGLang 参数模型：
--model-path /data/models/Qwen3.8-27B-W4A16-AutoRound-GPTQ
--served-model-name SGLang-27B核心参数：
--tp-size 2
--quantization gptq
--dtype bfloat16
--mamba-ssm-dtype bfloat16--kv-cache-dtype auto
--context-length 196608
--mem-fraction-static 0.94--max-running-requests 4
--max-mamba-cache-size 20--attention-backend triton
--speculative-algorithm EAGLE
--speculative-draft-model-path /data/models/Qwen3.8-27B-W4A16-AutoRound-GPTQ
--speculative-num-steps 3
--speculative-eagle-topk 1
--speculative-num-draft-tokens 4--cuda-graph-bs-decode 1 2 4
--triton-attention-num-kv-splits 16--reasoning-parser qwen3
--tool-call-parser qwen3_coder
--default-chat-template-kwargs '{"enable_thinking": false}'--sleep-on-idle
--trust-remote-code--host 0.0.0.0
--port 8082当前实际：
KV dtype: BF16
KV pool: 265,950 tokens
max running: 4
context: 192K
MTP3scheduler 相关：
schedule_policy = fcfs
chunked_prefill_size = 4096
priority scheduling = off=============================================
vLLM 参数
模型：
--model /data/models/Qwen3.8-27B-Uncensored-GPTQ-MTP
--served-model-name vLLM-27B核心参数：
--tensor-parallel-size 2
--max-model-len 196608
--kv-cache-dtype int8_per_token_head
--max-num-seqs 128
--gpu-memory-utilization 0.95--max-cudagraph-capture-size 128
--enable-auto-tool-choice
--tool-call-parser step3p5
--reasoning-parser qwen3MTP：
method: qwen3_5_mtp
num_speculative_tokens: 3其他：
attention backend: TRITON_ATTN
thinking: false
TP2
INT8 KV
192K contextSGLang 我还是会保留，毕竟 gfx1100 这版性能潜力确实很好。等以后 scheduler / chunked-prefill 这块有更新，我再拿这套 64K + 64K staggered test 回来复测。
@Ben-Lee 哈哈 我一般本地最多同时开俩session，prefill结束后基本就是轮流进行短prefill + decode ，所以体感还好。
你那种现象我估计有几种原因：
- 超长prefill并发估计是触及了7900xtx的算力瓶颈，估计上r9700会好很多 （pp 2500+)。
- bf16的kv cache token池子太小（~192k），很容易触发radix cache eviction，你看看加几条内存上hicache会不会好一些。按理说都是hermes agent，前缀命中应该概率很高。如果是完全是fresh prefill，估计vllm比较适合你。
-
今天 SGLang 双卡部署的总结（已去掉 IP 等敏感信息，去掉原帖内容）：
═══════════════════════════════════════════
一、最后结果
═══════════════════════════════════════════- SGLang 双卡 TP=2 在本平台不可行，方向正式关闭。
卡点不是软件：ROCm 7.14 + torch 2.11 + SGLang 魔改 fork（gfx1100-support）全部装通，编译过、import 过、模型加载过，死在最后一关——双卡通信（hipDeviceCanAccessPeer = NO）。 - 根因是平台硬伤，不是配置问题：
Intel X99 双路主板的 root complex 没有 GPU 间 P2P 路由能力，两卡分属两个独立 root port、两个 IOMMU group，数据只能经 CPU 内存中转，实测跨卡 3.1~6.9 GB/s（正常 TP 平台是 32~900 GB/s，差 10~300 倍）。 - 环境已全部还原并验证（实测确认）：
- 两台推理 VM（GPU0/GPU1）恢复单卡直通，均 running
- 两台 llama-server 的 /v1/models 均正常返回 qwen3.8-27b
- 双卡回到 vfio-pci，双卡测试 VM 的直通配置已清空
- 双卡均设 onboot=1，宿主重启后自动恢复
- 配置备份保留在宿主 /root/gpu_restore_102103_20260909_2054
═══════════════════════════════════════════
二、硬件平台
═══════════════════════════════════════════
- 宿主：pve001，华南 X99-T8D 双路主板，2× E5-2696v3（Haswell-EP，PCIe 3.0），PVE 9.2.6
- GPU：2× RX 7900 XTX（gfx1100/RDNA3，24GB），每卡经板载 Navi10 交换芯片挂到独立 root port
- 测试载体：
- VM104：Ubuntu 24.04.4，双卡 vfio 直通
- LXC 200：宿主原生 amdgpu 驱动（模拟裸机条件）
- VM102/103：还原后各持一卡，llama.cpp Vulkan
═══════════════════════════════════════════
三、问题链（踩坑顺序，后人照这个避）
═══════════════════════════════════════════
阶段 0：装环境（9/7~9/8）
- ROCm 版本坑：fork 要求 ROCm 7.14，但官方常用源的 ubuntu2404 目录里只有 10.0，7.14 的正确源是 repo.amd.com 的 multi-arch 目录，包名带版本后缀。
- torch wheel 下载坑：pytorch.org 断流；AMD manylinux 源是 flat 目录不是 pip 索引，pip --index-url 会报 No matching distribution，必须 curl 直接下 wheel 再本地装。
- fork 源码 bug：moe_q_gemm_rdna3.cu 里 half2 z_h[4] 在 ROCm 7.14 clang 下编译失败，须改成 z_h[4][2]；且必须改 .cu 源文件（.hip 是 hipify 产物会被覆盖）；不能把该文件从构建里剔除（链接期 undefined symbol）。
- CUDA 污染坑：pip editable install 会顺手拉 CUDA 版 torch 覆盖 ROCm 版，装完必须 force-reinstall 回 rocm wheel 并卸载 nvidia 相关包。
- PVE 双卡直通坑：两卡共用同名 romfile 会报 duplicate fw_cfg file name，必须复制一份异名 rom。
阶段 1：P2P 验证（9/9 上午） - VM 内实测：hipDeviceCanAccessPeer 双向 NO，rocm-smi topo 矩阵 False/False → VM 直通路径判死。
- 怀疑是虚拟化层问题（vfio 不做 peer DMA、guest 看到的是伪造拓扑），决定验证"裸机能不能通"。
阶段 2：裸机/LXC 路径（9/9 中午） - 新问题——卡锁死：vfio→amdgpu 热切换测试中，卡 2 进入 D3hot 无法唤醒，PCI reset 都阻塞，内核多进程卡在 SMU 通信上，只能重启宿主恢复。（教训：换驱动要冷启动，别热切）
- 建 LXC 走宿主原生 amdgpu（最接近裸机）：实测 hipDeviceCanAccessPeer 依然 NO，KFD 的 p2p_links 目录为空，跨卡 memcpy 3.1 GB/s（纯主机中转）。
- 结论钉死：虚拟化不是原因，Intel X99 root complex 不给 GPU 间 P2P/原子路由。BIOS 也无开关可解（Above 4G 已开，唯一前提已满足，剩下是硬件能力问题）。
阶段 3：收尾（9/9 下午~晚上） - 还原：双卡回 vfio，VM102/103 恢复单卡直通 + onboot=1，VM104 清 hostpci，重启宿主，验证 API 恢复。
═══════════════════════════════════════════
四、给后来人的五条血泪教训
═══════════════════════════════════════════ - 双卡 TP 先查硬件再装软件：5 分钟命令（hipDeviceCanAccessPeer + lspci IOMMU group）能救几十小时的装环境时间。这次是反着来的，白折腾。
- 双路主板（X99/EPYC 双路）跨 CPU socket 的双卡没有 P2P，结构性不可行。
- 即便两卡挪到同一 CPU 下，只要挂在两个独立 root port、不同 IOMMU group，照样没有 P2P。今天特意做了这个验证——白费。
- Intel 消费/工作站平台（X99/Z270 等）无 GPU P2P 成功先例；成功案例全是 AMD 单路平台（原生 peer 路由）或 PLX 交换卡拓扑。
- 看 PCIe 速率以 root port 侧为准：GPU 端点 lspci 显示 16GT/s x16 是卡内 switch 那段，真实槽速是 root port 的 Gen3（8GT/s），两头看结论完全不同。
- SGLang 双卡 TP=2 在本平台不可行，方向正式关闭。
-
今天 SGLang 双卡部署的总结（已去掉 IP 等敏感信息，去掉原帖内容）：
═══════════════════════════════════════════
一、最后结果
═══════════════════════════════════════════- SGLang 双卡 TP=2 在本平台不可行，方向正式关闭。
卡点不是软件：ROCm 7.14 + torch 2.11 + SGLang 魔改 fork（gfx1100-support）全部装通，编译过、import 过、模型加载过，死在最后一关——双卡通信（hipDeviceCanAccessPeer = NO）。 - 根因是平台硬伤，不是配置问题：
Intel X99 双路主板的 root complex 没有 GPU 间 P2P 路由能力，两卡分属两个独立 root port、两个 IOMMU group，数据只能经 CPU 内存中转，实测跨卡 3.1~6.9 GB/s（正常 TP 平台是 32~900 GB/s，差 10~300 倍）。 - 环境已全部还原并验证（实测确认）：
- 两台推理 VM（GPU0/GPU1）恢复单卡直通，均 running
- 两台 llama-server 的 /v1/models 均正常返回 qwen3.8-27b
- 双卡回到 vfio-pci，双卡测试 VM 的直通配置已清空
- 双卡均设 onboot=1，宿主重启后自动恢复
- 配置备份保留在宿主 /root/gpu_restore_102103_20260909_2054
═══════════════════════════════════════════
二、硬件平台
═══════════════════════════════════════════
- 宿主：pve001，华南 X99-T8D 双路主板，2× E5-2696v3（Haswell-EP，PCIe 3.0），PVE 9.2.6
- GPU：2× RX 7900 XTX（gfx1100/RDNA3，24GB），每卡经板载 Navi10 交换芯片挂到独立 root port
- 测试载体：
- VM104：Ubuntu 24.04.4，双卡 vfio 直通
- LXC 200：宿主原生 amdgpu 驱动（模拟裸机条件）
- VM102/103：还原后各持一卡，llama.cpp Vulkan
═══════════════════════════════════════════
三、问题链（踩坑顺序，后人照这个避）
═══════════════════════════════════════════
阶段 0：装环境（9/7~9/8）
- ROCm 版本坑：fork 要求 ROCm 7.14，但官方常用源的 ubuntu2404 目录里只有 10.0，7.14 的正确源是 repo.amd.com 的 multi-arch 目录，包名带版本后缀。
- torch wheel 下载坑：pytorch.org 断流；AMD manylinux 源是 flat 目录不是 pip 索引，pip --index-url 会报 No matching distribution，必须 curl 直接下 wheel 再本地装。
- fork 源码 bug：moe_q_gemm_rdna3.cu 里 half2 z_h[4] 在 ROCm 7.14 clang 下编译失败，须改成 z_h[4][2]；且必须改 .cu 源文件（.hip 是 hipify 产物会被覆盖）；不能把该文件从构建里剔除（链接期 undefined symbol）。
- CUDA 污染坑：pip editable install 会顺手拉 CUDA 版 torch 覆盖 ROCm 版，装完必须 force-reinstall 回 rocm wheel 并卸载 nvidia 相关包。
- PVE 双卡直通坑：两卡共用同名 romfile 会报 duplicate fw_cfg file name，必须复制一份异名 rom。
阶段 1：P2P 验证（9/9 上午） - VM 内实测：hipDeviceCanAccessPeer 双向 NO，rocm-smi topo 矩阵 False/False → VM 直通路径判死。
- 怀疑是虚拟化层问题（vfio 不做 peer DMA、guest 看到的是伪造拓扑），决定验证"裸机能不能通"。
阶段 2：裸机/LXC 路径（9/9 中午） - 新问题——卡锁死：vfio→amdgpu 热切换测试中，卡 2 进入 D3hot 无法唤醒，PCI reset 都阻塞，内核多进程卡在 SMU 通信上，只能重启宿主恢复。（教训：换驱动要冷启动，别热切）
- 建 LXC 走宿主原生 amdgpu（最接近裸机）：实测 hipDeviceCanAccessPeer 依然 NO，KFD 的 p2p_links 目录为空，跨卡 memcpy 3.1 GB/s（纯主机中转）。
- 结论钉死：虚拟化不是原因，Intel X99 root complex 不给 GPU 间 P2P/原子路由。BIOS 也无开关可解（Above 4G 已开，唯一前提已满足，剩下是硬件能力问题）。
阶段 3：收尾（9/9 下午~晚上） - 还原：双卡回 vfio，VM102/103 恢复单卡直通 + onboot=1，VM104 清 hostpci，重启宿主，验证 API 恢复。
═══════════════════════════════════════════
四、给后来人的五条血泪教训
═══════════════════════════════════════════ - 双卡 TP 先查硬件再装软件：5 分钟命令（hipDeviceCanAccessPeer + lspci IOMMU group）能救几十小时的装环境时间。这次是反着来的，白折腾。
- 双路主板（X99/EPYC 双路）跨 CPU socket 的双卡没有 P2P，结构性不可行。
- 即便两卡挪到同一 CPU 下，只要挂在两个独立 root port、不同 IOMMU group，照样没有 P2P。今天特意做了这个验证——白费。
- Intel 消费/工作站平台（X99/Z270 等）无 GPU P2P 成功先例；成功案例全是 AMD 单路平台（原生 peer 路由）或 PLX 交换卡拓扑。
- 看 PCIe 速率以 root port 侧为准：GPU 端点 lspci 显示 16GT/s x16 是卡内 switch 那段，真实槽速是 root port 的 Gen3（8GT/s），两头看结论完全不同。
- SGLang 双卡 TP=2 在本平台不可行，方向正式关闭。
