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

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

1. 先给结论

• 硬件：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}'

逐行解释关键参数

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

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

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

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

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

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

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

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

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

差距接近一倍，参数一个字没改。 原因和 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 倍

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

两点心得：

1. prefill 别用短 prompt 测——固定开销会量出荒谬数字，用 ≥2K token。
2. 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 前后差）：

• 接受率衰减非常平缓（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 专属）

1. MTP 方法名：qwen3_5_mtp ≠ qwen3_next_mtp，用错静默失效（第 4 节）。第一大坑
2. torch_compile_cache 污染：换过模型后残留 compile cache 会让新模型 segfault，换模型必清
3. alias 名称匹配：--served-model-name 要和呼叫端 100% 一致，否则 404 → fallback 跑去别的模型
4. 同时只跑一个 instance：双卡 48GB，两个 27B instance 直接 OOM。单 instance 铁律
5. AWQ + torch compile 会死 worker：AWQ 别开 compile（VLLM_TORCH_COMPILE_LEVEL=0）
6. thinking 吃 decode 预算：本表所有数字都含 thinking token。关掉会更高，但 agent 场景思考品质重要
7. 262K 不是免费的：context 全开代表长对话 prefill 线性上升（27.4s），日常无感因为 prefix caching 挡前面
8. --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 时期）的对比

说明：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」，同款硬件跑同一模型的公开结果，把我们摆进去是这样：

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