之前发过 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 节未测清单还有很多可以挖——有更优的配置直接打脸我们也没关系，那就是发这篇文的目的。
