继前帖 Vibe爆改VLLM Kernel 支持我的双卡TP 之后，我也是过上了多并发跑qwen3.8的好日子，可是没过几天就发现了新毛病：虽然VLLM的Paged attention缓存容量效率都不错，但是它是每~1600token进行前缀缓存，在长上下文中往往不如llama.cpp（完全缓存命中），总要等个1-10秒才吐字，这时候就想起来老特安利的SGLANG，调研一番后发现官方支持基本没有，比VLLM还烂。但是它和VLLM底层都用的是Pytorch，转念一想把对应的VLLM kernel port过来不就完事了？

正好这个周末GLM大赦天下无限token，打开ZCode直接开干！

下面贴repo，找个称手的LLM API和harness即可一键重现复制：
https://github.com/StevenChenSE/sglang/tree/gfx1100-support#chinese

这里面唯一的遗憾就是折腾了两天也没法支持fp8 kv cache，双卡4路并发的情况下bf16缓存只能开到192k上下文。

下来扔几个实测数据吧，整体上来说SGLANG的超短上下文爆发力不如VLLM，在数学题比VLLM 130tok/s低大概30%。此外在agent工作流中，整体表现远远超过VLLM:

双路并发平均150-200tok/sec

deepseek harness编程实测：

实测在hermes & deepseek harness中，90%情况下ttft都在<1s，80k上下文之前TG在80-100之间波动，丝滑程度远超llama.cpp & vllm，接下来唯一的缺憾就是等下单的32g ddr5内存（肉痛啊喂）快到货尽快上hicache了，下个周末有空看看dflash效果如何。

以下数据为LLM生成。

1. 标准化上下文深度衰减测试 (llama-benchy)

标准 Prompt Prefill ($PP=2048$) 与 Token Generation ($TG=128$), 并发数 = 1

上下文深度	SGLang MTP-3 (本分支)	vLLM MTP-3 基线	vLLM DFlash2 基线	对比 vLLM MTP-3 优势
Depth 0	97.1 tok/s	88.6 tok/s	71.1 tok/s	+9.6%
Depth 4,096	97.3 tok/s	83.3 tok/s	68.4 tok/s	+16.8%
Depth 8,192	91.5 tok/s	93.3 tok/s	71.8 tok/s	-1.9%
Depth 16,384	95.7 tok/s	75.9 tok/s	62.2 tok/s	+26.1%
速度留存率 (16k / 0k)	98.5%	85.7%	87.5%	长文本衰减极低

2. 真实 120k Agent 多轮会话回放（16 轮离散交互）

采样自真实 120k 长文本 Agent 对话（332 $\to$ 120,443 tokens），启用 Radix 前缀缓存

评估指标	SGLang MTP-3 (本分支)	vLLM MTP-3	vLLM DFlash2	提升幅度
平均生成速度 (Mean TG)	87.89 tok/s	63.50 tok/s	67.96 tok/s	提速 +38.4%
中位数速度 (Median TG)	85.97 tok/s	61.52 tok/s	67.16 tok/s	提速 +39.7%
抖动率 (CV Jitter %)	12.92%	45.34%	36.56%	平稳度提升 3.5 倍
最差轮次保底速度	66.71 tok/s	16.94 tok/s	32.94 tok/s	最低速度提升 4 倍

3. 数学思维链推理测试 (GSM8K & MATH-500)

Greedy 贪婪采样，temperature = 0.0，max_tokens = 1024

数据集用例	生成 Token 数量	首字延迟 (TTFT)	Prefill 速度	生成速度 (TG)	准确率
GSM8K #1	48	0.169s	533.5 tok/s	98.9 tok/s	100% 正确
GSM8K #2	196	0.180s	626.9 tok/s	116.2 tok/s	100% 正确
MATH-500 #1	169	0.149s	556.4 tok/s	114.7 tok/s	100% 正确
MATH-500 #2	212	0.137s	533.3 tok/s	111.2 tok/s	100% 正确
综合平均	—	0.159s	562.5 tok/s	110.3 tok/s	100% 正确

4. 多并发吞吐实测 ($c=4$)

使用 llama-benchy 进行多并发请求压测 ($PP=2048, TG=128$, Depth 0)

推理服务引擎	并发数	Prefill 总吞吐 (PP)	生成总吞吐 (TG)	峰值生成吞吐	运行稳定性与说明
SGLang MTP-3 (本分支)	c = 4	1,974.5 tok/s	147.5 tok/s	206.0 tok/s	100% 稳定运行，Decode CUDA 图与 MTP-3 正常工作
vLLM Baseline (无投机)	c = 4	1,891.1 tok/s	83.1 tok/s	180.0 tok/s	原生稳定，但解码速度较低
vLLM DFlash2	c = 4	1,693.2 tok/s	75.9 tok/s	188.0 tok/s	投机开销导致多并发总 TG 吞吐反而低于 Baseline
llama.cpp (MTP)	c = 4	636.3 tok/s	50.1 tok/s	—	受限于插槽并发队列瓶颈 (-np 2)

多并发核心结论：此前在 ROCm 平台上，vLLM 的投机解码在多并发下普遍面临崩溃或负优化（DFlash2 吞吐不如普通非投机模型，原生 MTP 则直接非法地址异常）。而 SGLang 依靠 Wave32 对齐的 Triton 解码图和独立的 Mamba 状态缓冲，在 4 并发下展现出 147.5 tok/s 的总生成吞吐，比 vLLM 基线高出 +77.5%，比 vLLM DFlash2 高出 +94.4%。

这个周末在家用dsh疯狂pua白嫖来的美国豆包（gemini3.7-flash），用stock vllm 神奇的拉起来了 (Qwen3.8-27B-W4A16-AutoRound-GPTQ)[https://huggingface.co/Vishva007/Qwen3.8-27B-W4A16-AutoRound-GPTQ] 后 pp 1200 tg 50 无mtp后始终不太满意，继续调优，不得不说amd整vllm真是坑，尤其是7900xtx这种连fp8/AITER支持都没有的老架构，各种奇怪的数值溢出退化层出不穷，但好在最终全部搞定。顺便感谢论坛里的大神@iamvirus 的介绍https://github.com/JartX/vllm ，帮我把pp直接暴拉到几乎翻倍。

最后说下体验吧，vllm下开8路并发，llama.cpp下tensor parallel 和Hermes agent对话便秘的感觉（900pp 50tg)完全没了，两个agent同时可以30-40 tg跑毫无压力，三个对话也可以勉强运行，单流70-80tok/s和很多在线api差不多，唯一的问题就是qwen3.8 thinking又臭又长，和在线api实际体验还是慢不少。考虑到这两张卡入的时候加起来不到1万，能跑到现在这个水平很满意了。

我的机器是大体配置是一块终端华擎主板+32g ddr5+amd 9600x，可以做pcie4*8拆分给两张卡

先秀一下具体数值吧，首先短上下文dflash2是绝对的王者，吞吐和单流都比mtp2高至少30%：(只测到8个并发，更高没测过，因为对我来说没啥实用价值），以下是0上下文测出的数据：

并发路数 (Concurrency)	DFlash2 聚合吞吐 (Aggregate TG)	DFlash2 单路速率 (Per-Req TG)	MTP3 聚合吞吐 (Aggregate TG)	MTP3 单路速率 (Per-Req TG)	平均首字延迟 (TTFT)
c = 1	113.25 tok/s	112.36 tok/s	111.41 tok/s	110.54 tok/s	178 ms
c = 2	152.25 tok/s	77.49 tok/s	175.35 tok/s	88.94 tok/s	245 ms
c = 3	177.60 tok/s	71.17 tok/s	204.84 tok/s	70.14 tok/s	350 ms
c = 4	190.95 tok/s	56.45 tok/s	228.10 tok/s	67.44 tok/s	419 ms
c = 5	211.76 tok/s	52.13 tok/s	254.79 tok/s	52.41 tok/s	490 ms
c = 6	218.84 tok/s	44.23 tok/s	300.53 tok/s	51.73 tok/s	596 ms
c = 7	249.90 tok/s	39.18 tok/s	289.66 tok/s	44.11 tok/s	703 ms
c = 8	379.85 tok/s 🏆	50.18 tok/s	339.59 tok/s	43.74 tok/s	770 ms

下面祭出dflash2论文中的最优workload（解数学题），可以看到150tok/s，实测有的题能到180tok/s，懒得找了

长上下文8k+ mtp和dflash就逐渐打平，但是mtp发挥往往比较稳定（tg随上下文稳定下降），dflash经常一会50 一会80随生成内容而跳，一般来说在80k上下，单流基本能在50-70之间，160k以上会一起退化到30. 以下是我用一个真实的dsh的session 文件 (80k context)一步步重放测出来的数值：

考虑到dflash占用了宝贵的显存，目前稳定跑还是切回了mtp，实测慢不了多少，kv的提升是实实在在的。

下面直接上教程，我把vllm简单fork一下把改动放进了一个单独的branch：https://github.com/StevenChenSE/vllm/tree/feat/dflash-perf-opt 找个能扛事的在线llm api和称手的harness让他照着这个README.md来搞，注意目前我这个是裸机跑的，所以你得让手动编译一下kernel，但也不是太复杂，就找harness自己搞就行。

好不容易放假了，我又开始鼓捣我的本地硬件了，最近X上Strata比较火，昨天正好支持了AMD 7900xtx，简单跑了一下支持最高精度的IQ3_S，基本上tg跑到了55，但是prefill才700多，差点意思，于是指挥deepseek v4.1把vllm上的专用wmma kernel搬过来，效果立竿见影，pp能到1300+左右。

啥也不说，先放PR:https://github.com/Niko1221/Strata/pull/260 找个趁手的Agent帮你部署一下就好了。

简单谈几个可能会被忽视的小细节：

1. 这个引擎的专家基本都在RAM缓存，支持CPU/GPU混合计算，所以会看到一个奇怪现象：段上下文的pp/tg比长上下文的pp低，这主要是VRAM caching构建中的摩擦成本，所以这模型越用越快也是有点意思。刚开始随机跟它对话的话tg大概40左右，用dsh加一个9k的prompt居然tg到了50，考虑到这是个80GB+模型，这个引擎也算是agent圣体了。
   下面是一个dsh 120k session的 tg随context下降的图表：
   

2. pp阶段主要瓶颈是pcie带宽，我本来是双卡7900xtx pcie48 拆分，把另一张卡关机拔了重启后主显卡自动获得pcie416，pp自动涨了+30%，tg也涨了10%。另外可以看到12GB 的5070 tg和24g的7900xtx一样，主要是因为人家是pcie5*16，估计未来R9700支持之后速度会更快，当然要搭配更贵的PCIE5主板和内存。

最后API server的拉起命令:

cd path/to/Strata
HIP_VISIBLE_DEVICES=0 PYTHONUNBUFFERED=1 \
  ~/.config/strata/venv/bin/python -m serve.server \
    --engine strata --config /home/jianwei/.config/strata/serve.json --port 8080

serve.json

{
  "exe": "/path/to/Strata/build-hip/strata-hip",
  "cwd": "/path/to/Strata",
  "args": [
    "--pack",
    "/path/to/Strata-data/packs/iq3_s",
    "--native",
    "/path/to/Strata-data/models/IQ3_S/Qwen3.8-Flash-Next-GSQ-RCO-IQ3_S-00001-of-00002.gguf",
    "--ple-gguf",
    "/path/to/Strata-data/models/IQ3_S/Qwen3.8-Flash-Next-GSQ-RCO-IQ3_S-00002-of-00002.gguf",
    "--expert-profile",
    "/path/to/Strata/data/expert-profile.bin",
    "--expert-cache",
    "auto",
    "--prefill",
    "2048",
    "--spec",
    "2",
    "--spec-min-p",
    "0.5",
    "--adapt-every",
    "2",
    "--pcie-frac",
    "0.30",
    "--kv",
    "int8",
    "--max-context",
    "262144",
    "--mtp",
    "/path/to/Strata-data/models/IQ3_S/mtp/rt"
  ],
  "tokenizer": "/path/to/Strata-data/packs/iq3_s/tokenizer",
  "model_name": "Qwen3.8-Flash-Next",
  "host": "0.0.0.0",
  "port": 8080
}

最后一两张截图：

这几天折腾了好一阵单卡strata，终于调优到了理想水平(pp1800, tg60-90)之后，略感空虚，整了点活，水一篇哈哈。

TDLR：单卡内存够的情况下，在视觉相关任务上（前端、客户端开发），strata生成质量明显高于27b，无脑选择IQ3_S。

量化更激进的模型跑的更快，但实际执行任务的时间更长，原因包括雷霆大思考流口水，不断返工等等，不值得为了点pp/tg的提升。此外，量化的确牺牲了不少模型对事物的认知和细节，具体可以从下文的报告里看到。

本地模型 vs 在线模型：鹈鹕骑自行车 SVG 生成评测

评测日期： 2026-10-04
测试方式： DeepSeek Harness (DSH) agent，同一句 prompt：Generate an SVG of a pelican riding a bicycle.
硬件： AMD Radeon RX 7900 XTX 24 GB (gfx1100/RDNA3)，Ryzen 5 9600X (6C/12T)，92 GiB RAM

本文回答两个问题：

1. 本地模型比在线模型差了些什么？可用性如何？
2. 更 aggressive 的量化损失了什么？

---

1. 结论

问题一：本地模型差了"速度"，但没差"质量"

本地模型在质量上不落后。 IQ3_S（7.9 KB）产出的鹈鹕在解剖准确性上优于两个在线模型中的阿里官方，仅次于 DeepSeek v4.1-flash。三者在"能否画出正确的鹈鹕骑自行车"这一核心判据上处于同一档。

差距集中在延迟和吞吐，且分布不均：

维度	本地最优	在线最优	差距
冷启动 TTFT	7,643 ms	807 ms	9.5×
预热 TTFT	411 ms	750 ms	本地反超 1.8×
decode 吞吐	88 tok/s	279 tok/s	3.2×
短 prompt prefill	1,195 tok/s	不可比（缓存）	—

关键发现：预热之后，本地模型的 TTFT 反而比在线更快（411 ms vs 750 ms），因为本地没有网络往返。真正输的只有 decode 吞吐（约 1/3.2）和冷启动的首次加载。

可用性判断：

• 交互式使用：可用。 预热 TTFT 0.4–0.8 s、decode 44–88 tok/s，与在线模型的体验差距主要在长输出的生成速度上（等 30 s vs 等 10 s 量级），而非响应手感。
• 冷启动：唯一的硬伤。 首次请求需 7.6–9.8 s，之后不再出现。
• 质量：完全可用。 本地模型产出与在线旗舰同档，且本轮没有任何一个模型出现明显错误。

问题二：更 aggressive 的量化，损失的主要是"推理节制性"

IQ3_S → IQ3_XXS 是同一模型的两次量化，构成直接对照组。体积只小 10%，但行为差异显著：

指标	IQ3_S	IQ3_XXS	变化
权重体积	~79 GB	~71 GB	−10%
decode 吞吐	71.8 tok/s	88.0 tok/s	+23%
短 prompt prefill	1,044 tok/s	1,195 tok/s	+14%
冷启动 TTFT	8,745 ms	7,643 ms	−13%
全程 output token	23,814	65,175	+174%
thinking 占比	51.6%	64.3%	+12.7 pt
SVG 自纠正编辑	2 次	4 次	+2
SVG 渲染验证	6 次	11 次	+5

量化省下 10% 的体积，换来 14–23% 的速度提升 —— 但代价是推理变得不节制： IQ3_XXS 输出了 2.7 倍的 token，其中 thinking 占比升到 64.3%。它单独产出的 41,921 个 thinking token 比 IQ3_S 的全部输出（23,814）还多 76%。

净效果是负的： IQ3_XXS 的 turn 1 端到端耗时 741.5 s，是 IQ3_S（307.5 s）的 2.4 倍。速度提升被过度推理完全吃掉。

产出质量没有损失 —— 两者同级，IQ3_XXS 的打磨次数甚至更多（自纠正 4 次 vs 2 次、渲染验证 11 次 vs 6 次），说明它更愿意反复迭代，但多花的成本没有转化为可见的质量收益。

这是单次运行的观察，n=1。 "IQ3_XXS 更啰嗦"可能是量化导致的系统性行为偏移，也可能是本次采样偶然。要确认需要多次重复实验。

---

2. 被测模型

#	模型	部署	量化	HuggingFace 仓库 / 权重	artifact
1	Qwen3.8-Flash-Next	本地 Strata (HIP/gfx1100)	IQ3_S	ISTA-DASLab/…-GSQ-RCO-GGUF @ 2a55d759<br>…IQ3_S-00001/00002-of-00002.gguf	/tmp/local_iq3/
2	Qwen3.8-Flash-Next	本地 Strata (HIP/gfx1100)	IQ3_XXS	同上仓库 @ 2a55d759<br>…IQ3_XXS-00001/00002-of-00002.gguf	/tmp/iq3_xxs/
3	Unsloth Qwen3.8-27B	本地 llama.cpp	UD-Q4_K_S（14.3 GiB）	unsloth/Qwen3.8-27B-GGUF @ 14370d1b	/tmp/27b/
4	阿里官方 qwen3.8-flash	在线 API	—	阿里云百炼 qwen3.8-flash	/tmp/qwen-official/
5	DeepSeek v4.1-flash	在线 API	—	deepseek-official / deepseek-flash（1M ctx）	/tmp/deepseekv41/

模型 1/2 是同一模型的不同量化，构成本文问题二的对照组。

---

3. 问题一：本地 vs 在线

3.1 延迟

冷启动本地慢 3–4 倍，预热后本地反超。 本地三个模型的预热 TTFT（411–787 ms）全部优于阿里官方（2,083 ms），27B 甚至优于 DeepSeek（411 vs 750 ms）。原因是本地无网络往返，而在线模型每次请求都要跑完整 RTT。

本地模型的冷启动降幅达 11–24 倍，说明主要成本是首次加载（expert cache 预热、首个 verify window 建立），而非推理本身。在线模型冷/预热差异仅 1.1–1.2 倍，因其服务端始终处于热态。

3.2 吞吐

decode 是本地唯一稳定落后的维度：44–88 tok/s vs 在线 105–279 tok/s。差距比 prefill 小得多，且对交互体验的影响主要是长输出时的等待时长。但是考虑到一个27G的本地显卡可以达到阿里官方API 70%的速度，可以说并不差了。

prefill 无法公平比较： 两个在线模型的首步输入分别有 98% 和 86% 命中服务端缓存，其 TTFT 反映缓存读取而非计算。三个本地模型无缓存命中，是真实 prefill：

模型	prefill	说明
IQ3_S	1,044 tok/s	真实（短 prompt）
IQ3_XXS	1,195 tok/s	真实（短 prompt）
27B Q4_K_S	991 tok/s	真实（短 prompt）
阿里官方	️ 不可比	98% 缓存命中
DeepSeek v4.1	️ 不可比	86% 缓存命中

长 prompt（33K 全新）下本地可达 1,856–1,980 tok/s，为短 prompt 值的 1.8–2.0 倍。

3.3 质量

五个 artifact 并排对比（上排为本地模型，下排为在线模型；按各自原生画布尺寸渲染）：

模型	字节	元素	<path>	transform	可访问性
IQ3_S 本地	7,936	89	37	3
IQ3_XXS 本地	8,214	86	28	0
27B Q4_K_S 本地	6,244	86	13	1
阿里官方	12,292	120	56	10
DeepSeek v4.1	8,924	90	20	9

所有 artifact 按各自原生画布尺寸渲染（IQ3_XXS 640×480，其余 800×600），不作缩放比较。

目视评估：

• IQ3_S（本地） — 毫无疑义本地最优，自行车细节准确，翅膀扶车把，但没有掌握前后遮盖关系。
• IQ3_XXS（本地） — 细节明显更少，似乎掌握了鹈鹕嘴的特征，但也没画合上，勉强及格。
• 27B Q4_K_S（本地） — 干净克制、构图居中、带文字标题。<path> 仅 13 个，细节最少，脚与脚踏关系含糊。勉强能算“鸟骑自行车”吧。
• 阿里官方（在线） — 全场最强，细节最丰富：戴头盔、红围巾、远山、云、虚线柏油路、扬尘。缺点：整了些莫名其妙的，帽子红领巾之类，属实是自行发挥了。
• DeepSeek v4.1（在线） — 可能是deepseek搞多模态比较晚，训练预料不够的原因，细节偏简单，比27b稍强，勉强跟iq3_xxs坐一桌。

3.4 token 构成

模型	turn 1 耗时	step 数	工具调用	全程 input	全程 output
IQ3_S 本地	307.5 s	19	21	16,755	23,814
IQ3_XXS 本地	741.5 s	34	36	17,365	65,175
27B Q4_K_S 本地	202.2 s	8	8	11,144	8,993
阿里官方	489.5 s	23	27	81,170	43,491
DeepSeek v4.1	56.4 s	15	17	6,073	11,986

端到端耗时由输出长度主导，而非速度。 本地最慢的 IQ3_XXS 不是因为卡慢，而是因为它写了 2.7 倍的 token。

---

4. 问题二：量化的损失

4.1 IQ3_S vs IQ3_XXS：同模型对照

指标	IQ3_S	IQ3_XXS	解读
权重体积	~79 GB	~71 GB	省 10%
decode	71.8 tok/s	88.0 tok/s	快 23%
prefill（短）	1,044 tok/s	1,195 tok/s	快 14%
冷启动 TTFT	8,745 ms	7,643 ms	快 13%
全程 output	23,814	65,175	多 174%
thinking 占比	51.6%	64.3%	高 12.7 pt
自纠正编辑	2	4	更多打磨
渲染验证	6	11	更多打磨
turn 1 端到端	307.5 s	741.5 s	慢 2.4×

4.2 三个层次的损失

第一层：推理节制性（最严重）。 IQ3_XXS 输出的 thinking token（41,921）超过 IQ3_S 的全部输出（23,814）达 76%。量化后的模型似乎更难"想够了就停"。这是本轮量化最明确的损失。

第二层：端到端效率（由第一层导致）。 速度提升 14–23%，但输出量增加 174%，净结果是端到端慢 2.5 倍。单看 tok/s 会得出完全错误的结论。

第三层：产出质量（无明显损失）。 两个 artifact 同级，IQ3_XXS 细节甚至略多。量化没有损害产出质量 —— 至少在这个任务上、这一次运行中。

4.3 交叉印证：27B Q4_K_S

另一个 aggressive 量化样本（27B 的 4-bit 版）不支持"量化必然导致啰嗦"：

指标	IQ3_XXS	27B Q4_K_S
量化等级	IQ3_XXS（更激进）	UD-Q4_K_S
全程 output	65,175	8,993
thinking 占比	64.3%	54.9%
自纠正编辑	4	0
turn 1 耗时	741.5 s	202.2 s

27B Q4 输出最少、几乎不反复打磨（0 次编辑、4 次渲染），一次成型且质量合格。说明"量化导致过度推理"与具体模型/量化方案相关，不是普遍规律。

4.4 对部署的含义

• 不要只看 tok/s 选量化。 IQ3_XXS 每 token 更快，但完成同一任务总耗时是 2.5 倍。
• 10% 的体积换 14–23% 的速度，性价比一般。 24 GB 卡装得下 IQ3_S 时，没必要退到 IQ3_XXS。
• 量化损失的是"行为"而非"能力"。 模型仍然会画鹈鹕，只是话变多了。

---

5. 局限

1. n=1。 每模型单次运行，无法区分系统性行为与采样偶然。§4 关于"量化导致啰嗦"的结论尤其需要重复验证。
2. 各会话不可严格横向比较 —— prompt 长度、工具次数、输出长度、并发状况均不同；本地三个模型共享同一张 GPU。
3. thinking token 为派生指标 —— 会话按 reasoning/text/tool-call 分类存储字符数，token 占比由各模型实测字符/token 比（中位 2.38–2.98）换算，非直接测量。
4. 本地 prefill 与本次会话无一一对应 —— 1,856/1,980 tok/s 为同配置独立实测值。
5. 在线模型 prefill 不可比 —— 缓存命中率 86–98%。
6. TTFT 含首 token 固定开销，不等于纯 prefill 时间。

周中被老特翻了牌子哈哈哈，所以周六早早爬起来水一篇续写前帖：

给梁圣冲了30块，狠狠地搞了一下dflash2的优化，现在基本差不多满意了，pp变化不大，但是tg比mtp提速了25%左右，还是很爽的。

运行方式和之前一样, pull一下之前的代码：https://github.com/StevenChenSE/sglang/blob/gfx1100-support/README.zh-CN.md
找你最爱的LLM agent harness 重新build一下SGLANG 引擎和kernel，下载对应的dflash2 drafter:

• 推荐这个：https://huggingface.co/syvai/Qwen3.8-27B-DFlash2-W4A16 节省~2GB显存，实测速度和精度没有损失
• 原版也可以：https://huggingface.co/incoai/Qwen3.8-27B-DFlash2

Disclailmer: 标题所说速度是仅仅在极短上下文，特定workload下有效，中等长度prompt (16k-32k)的decode速度大概在90-150tok/s之间。
先秀一下：

做数学题：（200-220）

写代码：（180-250tok/s)

普通问答(英文）：(90-120 token/s)

普通问答(中文）：(70-90 token/s)

最后贴一下benchmark测试：

实测性能基准对比

全部基准均在双卡 RX 7900 XTX (TP=2) 实机测试，运行 Qwen3.8-27B-W4A16 模型。
SGLang DFlash2 列于 2026-09-11 在当前构建上刷新（65b16b3df7，Prefill 第 1–5 轮
迭代 + 热 L2 Autotune 修复；llama-benchy 0.4.0，--no-cache 全新提示词，
每个深度取 3 次运行均值）；数学与 120k 回放为单次运行。MTP-3 列与 c=4 取自
2026-09-09 套件（较早构建）。
vLLM 基线列为早期实测数据，如需精确对比请使用相同工具版本重新压测。
上方 DFlash2 列运行 W4A16 草稿模型（自 2026-09-08 起经 zz-w4a16-draft.conf
systemd drop-in 成为生产默认；KV 容量增至 214,284 tokens）。同日同构建的 bf16
草稿模型对照实测为：数学 181.0 tok/s / 120k 回放均值 119.3 tok/s / 深度均值
114.3 tok/s（池容量 189,172）——全面等于或低于 W4A16 列，故维持 W4A16。
第 5 节保留 2026-09-10 的 W4A16 原始验证记录及其取代的 bf16 列。

1. 标准化上下文深度衰减测试 (llama-benchy)

标准 Prompt Prefill ($PP=2048$) 与 Token Generation ($TG=128$), 并发数 = 1

上下文深度	SGLang MTP-3 (本分支)	SGLang DFlash2 (本分支)	vLLM MTP-3 基线	vLLM DFlash2 基线
Depth 0	93.6 tok/s	128.3 tok/s	88.6 tok/s	71.1 tok/s
Depth 4,096	90.1 tok/s	136.7 tok/s	83.3 tok/s	68.4 tok/s
Depth 8,192	85.9 tok/s	112.8 tok/s	93.3 tok/s	71.8 tok/s
Depth 16,384	78.2 tok/s	108.8 tok/s	75.9 tok/s	62.2 tok/s
速度留存率 (16k / 0k)	83.6%	84.8%	85.7%	87.5%

MTP-3 对比 vLLM MTP-3：+5.6 / +8.2 / −7.9 / +3.0%（2026-09-09 构建）。DFlash2 于 2026-09-11 刷新：深度 0 绝对速度较 09-09 读数 +19%（128.3 对 107.9），16k 深度 +3.5%（108.8 对 105.1）；留存率比值读数偏低仅因深度 0 基线涨幅大于深上下文点位（本机单次采样波动约 ±15 tok/s，4k 点位恰逢波峰）。DFlash2 对比 vLLM DFlash2：+80.5 / +99.9 / +57.1 / +74.9%。

2. 真实 120k Agent 多轮会话回放（16 轮离散交互）

采样自真实 120k 长文本 Agent 对话（332 $\to$ 120,443 tokens），启用 Radix 前缀缓存

评估指标	SGLang MTP-3 (本分支)	SGLang DFlash2 (本分支)	vLLM MTP-3	vLLM DFlash2
平均生成速度 (Mean TG)	89.46 tok/s	118.7 tok/s	63.50 tok/s	67.96 tok/s
中位数速度 (Median TG)	88.38 tok/s	112.8 tok/s	61.52 tok/s	67.16 tok/s
抖动率 (CV Jitter %)	11.74%	23.6%	45.34%	36.56%
最差轮次保底速度	72.88 tok/s	56.9 tok/s	16.94 tok/s	32.94 tok/s

MTP-3：较 vLLM MTP-3 平均提速 +40.9%、平稳度 3.9 倍、保底速度 4.3 倍（2026-09-09 构建）。DFlash2 于 2026-09-11 刷新：较 vLLM DFlash2 平均提速 +74.7%（118.7 对 67.96），平稳度 1.5 倍，保底速度较 09-09 读数 40.6 提升 40% 至 56.9。注意事项：最后一轮 120k 的前缀缓存命中降至 32%（09-09 启动约 93%），导致该轮 TTFT 膨胀至约 91 秒（TG 仍保持 56.9 tok/s）——当前显存池布局下 120k 前缀树驻留比例下降。

3. 数学思维链推理测试 (GSM8K & MATH-500)

Greedy 贪婪采样，temperature = 0.0，max_tokens = 1024

数据集用例	生成 Token 数量	首字延迟 (TTFT)	Prefill 速度	生成速度 (TG)	准确率
GSM8K #1	48	0.128s	701.6 tok/s	97.3 tok/s	100% 正确
GSM8K #2	196	0.139s	814.8 tok/s	115.5 tok/s	100% 正确
MATH-500 #1	201	0.137s	605.5 tok/s	120.8 tok/s	100% 正确
MATH-500 #2	212	0.128s	568.2 tok/s	110.9 tok/s	100% 正确
综合平均	—	0.133s	672.5 tok/s	113.9 tok/s	100% 正确

SGLang DFlash2（同一测试套件，2026-09-11 刷新）：

数据集用例	生成 Token 数量	首字延迟 (TTFT)	Prefill 速度	生成速度 (TG)	准确率
GSM8K #1	63	0.134s	1510.5 tok/s	144.2 tok/s	✗（答 96，正确为 72）
GSM8K #2	200	0.144s	1567.5 tok/s	208.9 tok/s	✓
MATH-500 #1	195	0.133s	1475.7 tok/s	224.0 tok/s	✓
MATH-500 #2	182	0.131s	1414.7 tok/s	195.6 tok/s	✓
综合平均	—	0.136s	1492.1 tok/s	193.2 tok/s	75%（3/4）

DFlash2 数学生成速度较 09-09 读数快约 70%（193.2 对 166.0 tok/s；两次套件运行复现
193.15 / 193.62），TTFT 在更长提示词下保持平稳，但 GSM8K #1 在贪婪采样下仍会失误
（答 96，正确 72）——这是其窗口式草稿路径在量化稠密 GEMM 上的已知权衡；MTP-3 四题全对。

4. 多并发吞吐实测 ($c=4$)

使用 llama-benchy 进行多并发请求压测 ($PP=2048, TG=128$, Depth 0)

推理服务引擎	并发数	Prefill 总吞吐 (PP)	生成总吞吐 (TG)	峰值生成吞吐	运行稳定性与说明
SGLang MTP-3 (本分支)	c = 4	1,357.4 tok/s	78.5 tok/s	118.0 tok/s	100% 稳定运行，Decode CUDA 图与 MTP-3 正常工作
SGLang DFlash2 (本分支)	c = 4	1,275.5 tok/s	92.1 tok/s	146.0 tok/s	100% 稳定运行，单次采样
vLLM Baseline (无投机)	c = 4	1,891.1 tok/s	83.1 tok/s	180.0 tok/s	原生稳定，但解码速度较低
vLLM DFlash2	c = 4	1,693.2 tok/s	75.9 tok/s	188.0 tok/s	投机开销导致多并发总 TG 吞吐反而低于 Baseline
llama.cpp (MTP)	c = 4	636.3 tok/s	50.1 tok/s	—	受限于插槽并发队列瓶颈 (-np 2)

多并发核心结论：SGLang 两套推测解码在 RDNA3 上 4 并发均保持 100% 稳定——无非法显存访问、无图捕获失败（vLLM 原生 MTP-3 在 batch > 1 时仍会崩溃）。DFlash2 以 92.1 tok/s 总生成吞吐领先（较 vLLM 无投机基线 +10.8%，较 vLLM DFlash2 +21.3%），峰值 146 tok/s；MTP-3 为 78.5 tok/s。vLLM 基线列为旧版 llama-benchy 实测，引用精确跨引擎对比前请用 0.4.0 重新压测基线。

5. W4A16 草稿模型（syvai/Qwen3.8-27B-DFlash2-W4A16，融合 KV）

2026-09-10，同一硬件与 llama-benchy 0.4.0。深度曲线与 120k 回放在无外部流量的
隔离端口实测；数学、c=4、深上下文与多模态取自 2026-09-09 套件（顺序 KV 路径——
准确率与该路径无关，融合 KV 仅影响草稿上下文 KV 构建）。

深度曲线（PP=2048/TG=128，c=1；两次运行取平均，16k 为三次采样均值）：

指标	bf16 草稿模型（2026-09-09）	W4A16 草稿模型（融合 KV）
Depth 0	107.9 tok/s	118.9 tok/s
Depth 4,096	96.8 tok/s	98.9 tok/s
Depth 8,192	97.7 tok/s	95.9 tok/s
Depth 16,384	105.1 tok/s	98.0 tok/s
速度留存率 (16k / 0k)	97.4%	82.4%

本机单次采样 TG 波动约 ±15 tok/s（深度 0 的背靠背采样分别读得 101.7 与 136.1），解读单点数据时请保留该误差量级。在同一隔离端口关闭融合 KV 后，16k 均值降至 88.1 tok/s——融合 KV 在深度场景带来约 +11% 收益，并将与 bf16 草稿模型的 16k 留存率差距基本抹平。

120k Agentic 会话回放（两次运行，融合 KV）：平均 88.6 tok/s、中位数
82.8 tok/s、CV 25.3%、最差轮次 52.5 tok/s——2026-09-09 的 bf16 草稿
模型为 83.8 / 79.8 / 23.0% / 40.6；2026-09-11 单次复测中 bf16 / W4A16 的均值
分别为 119.3 / 125.5 tok/s。平均速度持平或略优。

数学思维链（greedy，单次运行）：3/4 正确——与 bf16 草稿模型出现 相同的
GSM8K #1 失误（答 96，正确 72），量化草稿模型未带来额外精度损失。平均 TG
148.9 tok/s（63 token 的 GSM8K #1 短答案拉低均值至 54.0 tok/s；其余三题
为 155–200 tok/s）。

深上下文扩展（单次运行，10k→160k TG）：78.4 / 117.3 / 90.4 / 86.1 / 60.1 /
39.0 tok/s——约 80k 之后 TG 开始衰减，与该窗口式草稿家族的长上下文行为一致。

c=4 多并发： 总 TG 89.3 tok/s、峰值 121 tok/s、PP 1,266 tok/s、
100% 稳定（bf16 草稿模型：92.1 / 146.0 / 1,275.5）。

多模态矩阵： 单图 / 多图与多轮交错工作负载均无循环 / 格式缺陷。

这个 哈哈，淘宝100块的架子，无敌散热，就是孩子大了得保护一下

双 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。
有同样硬件配置的朋友欢迎交流。

@terry 哈哈哈 这周在搞一个更好玩的project: 把qwen3.8 flash next 从我的这台机器上拉起来，等搞完再看看。

fp8 kv cache估计是不太行，主要是sglang架构问题和7900xtx的硬件支持导致的，我试了几次，就算拉起来16k的prefill就会掉到200几乎不可用，vllm的page attention没这个问题，可以跑fp8 kv （参考我最早的帖子）

@terry 我三月看你的视频买了一个新卡，一个咸鱼商家二手卡，加起来才10000块...

有点意思，看来这个strata不太挑显卡，但是要发挥最高潜能，对机器整体素质要求不低。
我这边贡献个数据点：9600x 6核，96g ddr5 3600 （带宽比你的稍低），pcie4*16 （是你的两倍），跑更大的iq3_s时候pp1600-2000，decode 60-80。
看起来你这个setup 要是换个pcie4的板子还有提升空间

@terry

我主板是x670e的华擎板子，大概1500左右，可以PCIE4 * 8倒不是特别贵，主要是ddr5内存太贵，我年初看你视频买的内存当时32g单条2500,现在最便宜的都3500了，如果有pcie3*16的洋垃圾的话性价比高一点。。。

教程就是那个repo readme，deepseek v4 flash/glm5.3级别的基本都应该可以配好，等我周末有空打磨一下看看能不能打包整成个docker吧。

@terry 【淘宝】https://e.tb.cn/h.8mjotDyGvc4vpj5?tk=70jlTVq0sg9 CZ005 「超算AI训练开放式X99双路EATX主板4卡机箱双电源显卡机架4K435」
点击链接直接打开 或者 淘宝搜索直接打开

@terry 哈哈哈 谢谢老特翻牌子，周末一定搞！

@iamvirus 你这个TG多少？

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

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

@X一棵树 我只有D5，欢迎贡献d4的数据点。

D5和D4区别只在hicache上，如果不用内存kv cache 基本都一样，推理速度除了卡就是主板的pcie带宽了

Hi 我的repo 更新了dflash2的解决方案，你可以试试，我这边比mtp双卡平均提速10-20%

@Ben-Lee 哈哈 这不是放假在家 闲下来整活来着