双 3090 NVLink 跑 Qwen3.8-27B：vLLM + AWQ-INT4 + MTP，工具调用 130 t/s、262K 上下文全开（附完整配置与 8 个踩坑）

starryskyknight

之前发过 Qwen3.6-27B 的实测（双 3090 NVLink，128K 上下文），这次模型换代到 3.8，同时把整套部署重新调了一遍。楼上那篇 7900XTX + llama.cpp Vulkan 写得很好，这篇是它的 NVIDIA 对照版：两条路线都跑到 130 t/s 上下，但方法完全不同。

先讲结论，再讲一个我们绕最久的坑。

1. 先给结论

工作负载	decode 速度（本文实测）
工具调用（JSON 输出）	129.0 – 132.8 t/s
Python 代码生成	126.2 – 127.0 t/s
短 prompt（计数类）	130.3 – 134.7 t/s
中文散文创作	69.5 – 77.3 t/s
prefill（39K token 非重复）	≈1,423 t/s（TTFT 27.4s）
prefill（32K token 重复、cache 命中）	TTFT 1.38s

硬件：2× RTX 3090 24GB + NVLink 桥接（拓扑 NV4）
软件：vLLM 0.27.1（CUDA 路线）
模型：shawnw3i-Huihui-Qwen3.8-27B-abliterated-AWQ-MTP（AWQ-INT4，社群量化版）
上下文：262,144 全开，每卡显存占用约 22.7GB

白话：t/s = 每秒吐几个字；MTP = 用便宜「草稿头」先猜下一步再验证的加速技术，猜得准就快。本文的数字都附测法。

一句话：MTP 方法名用对，速度从 65 直接翻到 130；这篇主要就是讲这件事。

2. 硬件与软件环境

硬件

2× NVIDIA RTX 3090 24GB，NVLink 桥接（nvidia-smi topo -m 显示 NV4，双卡真并行）
P2P 状态 OK（nvidia-smi topo -p2p r）——双卡直连通讯无阻，TP=2 才值得玩
CPU：decode 是 GPU 显存频宽瓶颈、CPU 影响小，但别太老（prefill 和调度会吃到 CPU）

软件

vLLM 0.27.1（pip 安装，独立 venv）
flashinfer（VLLM_USE_FLASHINFER_SAMPLER=1 走 flashinfer 取样器）
CUDA 12.x / PyTorch 对应版本

模型

shawnw3i-Huihui-Qwen3.8-27B-abliterated-AWQ-MTP：社群 AWQ-INT4 量化版，内含 MTP head
同型公开版：shawnw3i/Qwen3.8-27B-AWQ-MTP；基底：huihui-ai/Huihui-Qwen3.8-27B-abliterated
挑它：INT4 ≈ 每卡 18GB 级显存，262K 塞得下，MTP head 完整保留

3. 完整配置（可直接复制）

export VLLM_USE_FLASHINFER_SAMPLER=1
export FLASHINFER_DISABLE_VERSION_CHECK=1
export PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True

python -m vllm.entrypoints.openai.api_server \
  --model /path/to/shawnw3i-Huihui-Qwen3.8-27B-abliterated-AWQ-MTP \
  --served-model-name shawnw3i \
  --host 0.0.0.0 --port 8000 \
  --dtype bfloat16 \
  --quantization awq_marlin \
  --kv-cache-dtype fp8_e4m3 \
  --tensor-parallel-size 2 \
  --max-model-len 262144 \
  --max-num-seqs 1 \
  --max-num-batched-tokens 4096 \
  --gpu-memory-utilization 0.95 \
  --enable-chunked-prefill \
  --block-size 16 \
  --enable-prefix-caching \
  --disable-custom-all-reduce \
  --scheduling-policy priority \
  --speculative-config '{"method":"qwen3_5_mtp","num_speculative_tokens":3}' \
  --reasoning-parser qwen3 \
  --tool-call-parser qwen3_xml \
  --default-chat-template-kwargs '{"enable_thinking": true, "preserve_thinking": true}'

逐行解释关键参数

参数	为什么是这个值
`--quantization awq_marlin`	Ampere（30 系）跑 Marlin kernel 比原生 AWQ 快；INT4 让 262K 塞得进 24GB×2
`--kv-cache-dtype fp8_e4m3`	KV cache 量化，省下的显存全拿去开上下文
`--max-model-len 262144`	模型原生上限全开。开太大启动时直接 OOM 或 silent 降级
`--max-num-seqs 1`	单请求独占双卡——agent 场景（一次一使用者）最佳解
`--max-num-batched-tokens 4096`	chunked prefill 块大小，太大 TTFT 升、太小吞吐降
`--enable-prefix-caching`	agent 神技：每轮 system prompt + 工具 schema 完全相同，radix cache 直接命中。对齐实测：相同 16K prompt 连发，TTFT 7.24s → 0.87s（8.3×，见第 6 节）
`--disable-custom-all-reduce`	这行不能拔。我们 A/B 实测：拔掉（改用 vLLM 自订 allreduce，`nvidia-smi topo -p2p r` 显示 P2P OK）→ CUDA graph capture 阶段 worker 无声崩溃，systemd 重启循环连崩 3 次；加回 → 稳定 130 t/s。GeForce 的 NVLink P2P 对 vLLM CUSTOM AR 不稳，NCCL 才是稳路。细节见踩坑 #8
`--speculative-config '{"method":"qwen3_5_mtp","num_speculative_tokens":3}'`	全文最重要的参数，见第 4 节
`--reasoning-parser qwen3` + enable_thinking	保留思考模式（agent 场景值回票价）
`--tool-call-parser qwen3_xml`	工具呼叫解析，vLLM 原生 structured output
`--default-chat-template-kwargs '{"enable_thinking": true, "preserve_thinking": true}'`	开思考链＋保留思考 token。注意：这是 chat template 的 kwargs，不是独立旗标
`VLLM_USE_FLASHINFER_SAMPLER=1`	flashinfer 取样比默认快
`FLASHINFER_DISABLE_VERSION_CHECK=1`	flashinfer-cubin 与 python 打包版本号不一致的官方认可绕行

4. 全文核心：MTP 方法名用错 = MTP 从头到尾没启动

这是我们绕最久、也最想救人的坑。

vLLM 的 MTP 方法名是按模型架构世代分的：

方法名	适用架构
`qwen3_5_mtp`	Qwen3.5 / Qwen3.6 / Qwen3.8 共用（vLLM Recipes 官网明载）
`qwen3_next_mtp`	Qwen3-Next 专用，别的型号用了直接无效

我们一开始写成 qwen3_next_mtp，vLLM 不报错、不警告，静默当成普通推理跑——速度一直卡在 65 t/s 上下，还以为「这模型就这样」。这比报错更危险：报错你会去查，静默你会以为这就是天花板。

三种方式确认 MTP 有没有真的启动：

启动日志找 speculative 相关行（有没有载入 MTP head）
看 index.json 的 weight_map 里有没有 mtp tensors
终极判据：速度——有 MTP 130 t/s vs 无 MTP ~65 t/s，差一倍，不可能认错

官方参考：vLLM Recipes — Qwen3.8-27B（明文：MTP head 拼法 qwen3_5_mtp）

5. 为什么论坛的数字差两倍

同一台机器、同一组参数，只换测试题目：

题目	decode
中文散文创作（600 tok）	69.5 – 77.3 t/s
Python 代码生成	126.2 – 127.0 t/s
工具调用 JSON	129.0 – 132.8 t/s

差距接近一倍，参数一个字没改。 原因和 7900XTX 那篇说的一样：MTP 的速度取决于草稿猜得准不准。创作类文本下一步几乎不可预测，接受率砍半，速度腰斩。

所以「双 3090 跑 Qwen3.8 有几 t/s」没有标准答案——先问「跑什么题目」。 我们日常是 Hermes agent（工具调用＋长 system prompt），130 t/s 就是真实体感；写小说的人体感会是 70。

测法（照抄可复现）：/v1/chat/completions，max_tokens=600，每型跑 3 次、3 次全报，decode = completion_tokens / 耗时。工具调用三次原始值：129.0 / 130.1 / 132.8（中位数 130.1）——标题的 130 取中位数，不是单次峰值。题目原文：

计数：「Count from 1 to 100, one number per line.」
代码：「Write a Python function that implements quicksort with comments. Code only, no explanation.」
中文散文：「写一篇关于东京夏天的游记，连续写不要停」（temperature 0.7）
工具调用：「Output only a JSON object describing an API call to get weather for Tokyo」

6. prefill 实测 + prefix caching 的 8.3 倍

测试	TTFT	说明
39K 非重复文本（cache 不命中）	27.4s → prefill ≈ 1,423 t/s	冷启动基准
16K 非重复文本，第一次（对照组）	7.24s	对齐对照
16K 完全相同 prompt，第二次（cache 命中）	0.87s	加速 8.3×

注：早期试过「同一行重复 4000 次」的病态 prompt，TTFT 1.38s ≈ 20×——但那是 cache 的极端上限、不是真实场景，本文只采用上表 token 数对齐的 8.3×。

两点心得：

prefill 别用短 prompt 测——固定开销会量出荒谬数字，用 ≥2K token。
agent 场景 prefix caching 是白送的性能：agent 每一轮的 system prompt + 工具 schema + 对话历史都是逐字相同的前缀，radix cache 全中，第二轮起 TTFT 压到 1 秒内（上表 0.87s 就是真实模式）。vLLM 官方对「低并发延迟敏感」建议关它配 MTP-1，但那是「每次 prompt 都不一样」的批次服务；agent 对话反而 cache 全中，实测保留才快。

6.5 MTP 接受率衰减 + 功耗实测

有人问「MTP 在长上下文会不会失效」——我们直接量了三点（测法：/metrics 的 spec_decode_num_accepted_tokens_total ÷ spec_decode_num_draft_tokens_total 前后差）：

上下文长度	MTP 接受率	decode（同题目）	TTFT
~2K token	51.9%	99.5 t/s	1.0s
~36K token	48.4%	90.0 t/s	17.6s
~139K token	47.4%	75.7 t/s	99.1s

接受率衰减非常平缓（51.9→47.4%），MTP 到 139K 上下文还稳得住，这是我们敢把 262K 全开的信心来源
decode 速度随上下文下降（99.5→75.7）主要是 KV cache 读取变大，属正常物理
三个草稿位置的累计接受率：第 1 个 71%、第 2 个 49%、第 3 个 37%——想调 num_speculative_tokens 的可以先看这组：猜 2 个性价比最高（71%+49% 都会用到）

功耗（nvidia-smi 实测，双卡 350W 上限）：

空载：每卡 ~17-19W
满载（prefill 与 decode 阶段皆是）：每卡 ~347W，双卡峰值 ~695W
换算：116-130 t/s ÷ 695W ≈ 0.18 t/s/W（写作任务约 0.11）——想算电费的楼友自己乘电价

7. 踩坑记录（8 个，vLLM/CUDA 专属）

MTP 方法名：qwen3_5_mtp ≠ qwen3_next_mtp，用错静默失效（第 4 节）。第一大坑
torch_compile_cache 污染：换过模型后残留 compile cache 会让新模型 segfault，换模型必清
alias 名称匹配：--served-model-name 要和呼叫端 100% 一致，否则 404 → fallback 跑去别的模型
同时只跑一个 instance：双卡 48GB，两个 27B instance 直接 OOM。单 instance 铁律
AWQ + torch compile 会死 worker：AWQ 别开 compile（VLLM_TORCH_COMPILE_LEVEL=0）
thinking 吃 decode 预算：本表所有数字都含 thinking token。关掉会更高，但 agent 场景思考品质重要
262K 不是免费的：context 全开代表长对话 prefill 线性上升（27.4s），日常无感因为 prefix caching 挡前面
--disable-custom-all-reduce 不能拔（本周 A/B 实测）：想说 nvidia-smi topo -p2p r 都 OK 了，不如拔了让 vLLM 用 CUSTOM allreduce——结果 CUDA graph capture 阶段 worker 无声崩溃（log 停在 warmup、无错误输出），systemd 重启循环连崩 3 次；加回 flag 走 NCCL → 稳定。教训：GeForce 的 NVLink P2P ≠ vLLM CUSTOM AR 可用；「拔掉理论上更快」实测是「拔掉直接死」

8. 和旧贴文（Qwen3.6 时期）的对比

	之前（Qwen3.6-27B）	现在（Qwen3.8-27B）
量化	GPTQ Marlin INT4	AWQ Marlin INT4
加速	无 MTP	MTP ×3 正确启用
工具调用	~67 t/s	129-132.8 t/s
上下文	262K（已全开）	262K（维持）

说明：67 是「上一代 GPTQ 的基准」，65 是「这一代 MTP 踩坑时的速度」，两者接近纯属巧合；130 才是修正后的真实水准。从 67/65 到 130，几乎全部来自 MTP 修正——这也再次证明第 4 节那个坑有多贵。（7 t/s 与 67 t/s 数字出自旧贴 topic/322 实测原文）

9. 社群对照（同双 3090 硬件的公开数据）

Reddit r/LocalLLaMA 有一串「Optimized Dual 3090 Qwen3.8 Quant」，同款硬件跑同一模型的公开结果，把我们摆进去是这样：

来源	配置	decode @8K/1 stream
jbro1985	INT8-W8A16、无 NVLink（Oculink x4）、TP2	59.7 t/s（接受率 53-57%）
Schlopper	INT8-W8A16、max-num-seqs 6	87 t/s（2 streams 平均，接受率 77%）
本文	AWQ-INT4、NVLink NV4、max-num-seqs 1	129-134 t/s

社群当时的判断（jbro1985 原话大意）：「3.8 比 3.6 慢主要是权重读取频宽（14.7 vs 9.4 GiB/卡），等 3.8-INT4 出来就会追回来」——本文 129-134 正是这个预言的实证：INT4 不只省显存，权重频宽砍半直接反映在 decode 速度。

10. 诚实揭露：未测项目

并发多请求（我们是 max-num-seqs=1 单使用者）
其他量化格式（GPTQ/FBGEMM 没在同模型重测）
长上下文「大海捞针」品质（262K 极限注意力品质）
num_speculative_tokens（1/2/3/4）完整扫描（沿用 3 就没再扫）
~~--disable-custom-all-reduce 的 A/B~~ 已测：见踩坑 #8（拔掉=崩溃循环，保留=稳定）
接受率衰减已测三点（§6.5），但 139K→262K 尾段还没量

11. 下一步想做

MTP num_speculative_tokens 完整扫描
开 thinking vs 关 thinking 的速度/品质对照
长上下文针测

有问题直接在楼里问，参数哪一行看不懂、或想照抄但显存对不上，都可以聊。第 10 节未测清单还有很多可以挖——有更优的配置直接打脸我们也没关系，那就是发这篇文的目的。

Xiaote

@starryskyknight 先赞一个，这组数据把 MTP 的脾气测得很清楚。你 65→130 的翻倍和散文档 69-77 的「不翻倍」，是同一个机制的两面：MTP 吃的是草稿头猜得准不准，跟任务难易无关，跟输出 token 的熵有关。

工具调用/JSON 输出是低熵文本：键名、schema、括号引号全是模板化的，草稿头一猜一个准，验证批量通过。130/65 = 2.0×，等效每步多接受约 1 个草稿 token（MTP-3 下平均接受数 ≈ 1）。
中文散文是高熵自由文本：下一个 token 可能性极多，草稿头命中率趋近 0，验证几乎全废 → 69-77 基本贴着无 MTP 基线（65），只剩 1.06-1.19× 的残值。
你开了 enable_thinking，思考链部分同样基本吃不到 MTP 红利（推理 token 也是高熵），真正翻倍的是结构化输出段。所以 agent 场景（工具调用 + 前缀缓存）正好是 MTP 的主场——你的 262K + radix 命中 TTFT 27.4s→1.38s 就是完整闭环。

另外 --disable-custom-all-reduce 那条很值钱：GeForce NVLink 上 vLLM 的 CUSTOM AR 在 CUDA graph 捕获阶段崩是已知坑，NCCL 路线稳。你 A/B 实测出来的「拔掉就崩、加回就 130」比任何 issue 帖都有说服力，值得去 vLLM repo 提一个带 nvidia-smi topo -p2p r 输出的 issue。

想验证接受率的话，跑一组 num_speculative_tokens=1 的工具调用对照就行：草稿链短时每步命中率会明显更高（长链后面几步的命中率是递减的），接受率曲线一下子就出来了。

stxpnet

大赞，我的模型不是这个，但我让GLM抄作业，吸取你的亮点，晚点实测一下

starryskyknight

@stxpnet 欢迎前辈一起讨论我觉得一起讨论优化才会越来越好

抡锤者