魔改SGLANG支持7900XTX 双卡TP TTFT <1s 平均TG 80-100! 4并发TG200/sec

Mediali Li

@applejuice 4-bit 量化模型（AWQ、GPTQ 或 AutoRound）的输出速度为 110 token/s，而 FP8 量化可达到约 1500–1600 token/s，从而实现 75 token/s 的输出速度。

applejuice

@Mediali-Li 如果你这个是稠密模型那是真强

Mediali Li

@applejuice 这点速度还快？ 27b w4a16 我双卡5090 去到 8000 prefill，nvfp4得 1.5w+ 2080ti我就挂机做个翻译而已!
Perf_Qwen3.8-27B-QUASAR-NVFP4_c1_2026-09-08_09_38_39.png

applejuice

@Mediali-Li 果然高手在民间

1500prefill 我都感觉很不错了

Mediali Li

@applejuice

不同模型它的输出速度是不同的。

双卡的话prefill 大概15000左右，现在在跑next，我就不测试双卡了。

imbiplaza ASUS

看来我长期被llama 坑惨了。。。速度尽然可以相差3倍之多。。。
我再看看有什么可以捣鼓的，长期在win11 也不是办法

imbiplaza ASUS

@Mediali-Li 没办法的，这个价位只能5070ti 16gb....
在中国还可以选3090。。。
在东南亚都是硬吃amd 的韭菜手段

applejuice

@imbiplaza-ASUS 现在新加坡马来西亚的2手 3090 都比淘宝便宜

想买2手来改水冷玩4张3090 但是难度太高钱要花太多

Mediali Li

还好我可以经常回国，在美国也没啥好买的，不过之前特价倒是入了3张5090 现在派用场了

imbiplaza ASUS

@applejuice
3090神卡来的。。。。卖家不愁顾客

Xiaote

双卡 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 就够，别一上来就双卡。

stormaround

我就一张7900xtx，之前试sglang 跑fp8 双r9700 开mtp，32k ctx会掉到10几tok/s，普通请求40 -50，关mtp 32k也能稳定25左右tok/s，短的也差不多

Mediali Li

@stormaround 这卡 prefill太低了说白了就是性能不行做智能体几乎不能用

terry

@Mediali-Li 你是特么的眼睛长在屁股上吗？我在论坛很少骂人，你特么的是脑子坏了吧，傻逼东西，你看不到数据吗？？？

你要去医院看下眼科再来论坛注册，智障东西。

znx

感谢楼主分享在您帖子的感召下，我已经准备购入第二张显卡了等过两天买好装好也跑跑多并发感觉一下
我的配置是精粤X99D3 看看显卡在PCIE 3.0 16x 下会受到多大的影响

Ben Lee

@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.234s

ROCm 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
MTP3

scheduler 相关：

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 qwen3

MTP：

method: qwen3_5_mtp
num_speculative_tokens: 3

其他：

attention backend: TRITON_ATTN
thinking: false
TP2
INT8 KV
192K context

SGLang 我还是会保留，毕竟 gfx1100 这版性能潜力确实很好。等以后 scheduler / chunked-prefill 这块有更新，我再拿这套 64K + 64K staggered test 回来复测。

terry

@Ben-Lee 兄弟你发帖的时候让AI整理成markdown格式，这么长的帖子这么乱，怎么看？

明风影视mfys

此主題已被删除！

坤坤

我是双卡的，经过测试速度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调用的话非常舒服

坤坤

这个就是用SGLANG部署的

抡锤者

魔改SGLANG支持7900XTX 双卡TP TTFT <1s 平均TG 80-100! 4并发TG200/sec