教你在消费级NVIDIA显卡上最优运行通义千问3.8 27B

我会教你如何在最优配置下运行 Qwen 3.8 27B Dense。如果你有 RTX 3090、4090 或 5090，现在就能在桌面上拥有前沿级 AI。该模型免费、开源，采用 Apache 2.0 协议。但默认配置并非最优。

社区花了最初24小时从模型里挖出了真正可用的配置，现在只需要几个参数，就能把「能运行」变成「运行正确」。我会逐个讲解每个参数，以及它为什么需要存在。

最重要的那个参数。
--spec-type draft-mtp
Qwen 直接把一个 draft head 训练进了权重里。一个附加的小模块会猜测接下来的几个 token，大模型一次过检查所有猜测，每一个被接受的猜测都是免费 token。

这个 head 已经包含在你下载的 GGUF 文件里了。你不需要额外下载 drafter，也不需要编译任何东西。有人在凌晨2点从服务器日志里发现了未被使用的张量，尝试构建 draft 文件，结果发现根本没什么需要构建的。只需要一个参数就能连接已经存在的内容（这个发现来自 sudoingX，他做了AB对照，在日出前就开源了探测工具）。

深度上限。这个 head 正好只有一层。设置n=4会直接崩溃。
--spec-draft-n-max 2
n=2是最佳点，n=3就是天花板了。模型只有一个 MTP 层，所以把 draft 深度推到4或5会让 head 崩溃，开始输出垃圾 token。人们在 Spark 上碰到了这个问题，记录了完整的梯度：n=1 提速1.75倍，n=2 提速2.37倍，n=3 提速2.85倍，n=4 根本不可用。请遵守这个上限。

内存相关参数。MTP 自带额外内存开销。
--cache-type-k q8_0 --cache-type-v q8_0 --spec-draft-type-k q8_0 --spec-draft-type-v q8_0 -np 1

三个参数，同一个目标：让模型能塞进24GB显存。KV缓存是模型存储对话的运行内存，也是长上下文下占满你显存的元凶。q8_0能把它的体积减半，且没有可见的质量损失。

第二行参数对 draft head 自己的缓存做了同样的事，它默认是全精度，会偷偷吃掉2GB显存。把并行槽位设置为1意味着请求会排队，而不是预留第二个缓存池。单卡单任务，所有内容都能装下（AJ 就是在3090上跑这套配置）。

质量参数。超过100K上下文后模型会变笨，这就是修复方法。
--kv-cache-dtype bfloat16

量化缓存能节省内存，但会降低长上下文下的推理质量。有人全天测试了超过一半上下文窗口的场景，发现这个全精度修复带来了天差地别的提升。只有轻微的每秒token数损失，换来了真实的质量提升。如果你的会话都很短，可以跳过这个参数。如果你需要超过100K上下文，一定要加。

会催生「这个量化版坏了」报错的陷阱。
--jinja

Qwen 3.8 自带它自己的聊天模板。不加这个参数加载模型，就没有可靠的标记区分用户输入结束和模型回答开始。会出现两种失败情况：模型会一直说，超过停止标记，或者输出截断的回答，还会丢失多轮对话之间的上下文。两种情况看起来都像是量化版坏了，但其实问题不在量化版。

现在好几个打包版本都带了修正后的模板文件，因为官方模板在多轮之间会嵌套空的思考块。

如果你拥有50系显卡或是 Spark，这里是 Blackwell 路线。用 NVFP4 而不是 GGUF。

MTP 参数对应写成 --speculative-config '{"method":"mtp","num_speculative_tokens":3}“，上限规则不变。FP8 KV 缓存能让你的上下文窗口翻倍（完整的1M token会话大约需要32GB缓存）。

最初24小时里人们记录了两个坑：原版 vLLM 无法在 Spark 上加载这个模型的 MTP 架构，你需要社区的 GB10 构建版。而且 FP8 KV 在 Spark 上需要特定的注意力后端，默认后端会静默无法服务。把推理深度设置为 medium，否则它会在每一次回复都用最大深度思考。默认是 xhigh，会浪费你的token。

这些内容没有一个来自模型卡。每一个都来自某人的服务器日志、凌晨两点的测试会话，或是成对基准测试。改好这些参数之后，来社区表格告诉我们你的卡跑出来什么结果。在这条推文的评论里留下你的参数和你的技术验证来源👇

完整设置：
24GB显存路线（3090 / 4090 / 5090），llama.cpp，Q4_K_M：
llama-server -m Qwen3.8-27B-Q4_K_M.gguf \
-ngl 999 -fa on --jinja \
-np 1 -t 12 \
--spec-default --spec-type draft-mtp \
--spec-draft-n-max 2 \
--spec-draft-type-k q8_0 --spec-draft-type-v q8_0 \
--cache-type-k q8_0 --cache-type-v q8_0 \
--temperature 1.0 --top_p 0.95 --top_k 30 \
--min_p 0.0 --presence_penalty 0.0

- 添加 --spec-draft-n-max 2 来固定深度（AJ的命令依赖默认值；2是实测最佳点，3是硬性天花板，4会让head崩溃）

- 把推理深度设置为 medium（默认的xhigh会浪费token）

- 需要超过100K上下文：把缓存参数改成 --cache-type-k f16 --cache-type-v f16。全精度KV，轻微速度损失，质量保持稳定（这是mmike87的修复，量化缓存会降低长上下文推理能力）

Blackwell 路线（50系 / DGX Spark），vLLM，NVFP4：
vllm serve unsloth/Qwen3.8-27B-NVFP4 \
--max-model-len 262144 \
--kv-cache-dtype fp8 \
--gpu-memory-utilization 0.90 \
--enable-auto-tool-choice --tool-call-parser hermes \
--speculative-config ”{"method":"mtp","num_speculative_tokens":3}'

- Spark 用户：原版 vLLM 无法在 GB10 上加载这个模型的 MTP 架构，请使用固定的社区构建版（keys的仓库做了镜像）

- FP8 KV 在 Spark 上需要 triton_attn，默认注意力后端无法服务它

- 96GB显卡（RTX 6000 PRO）：无头运行把显存利用率降到0.80，接显示器用降到0.75，否则会在CUDA图捕获时OOM

社区来源（本文每一个参数都可以追溯到发现者）：
MTP 参数 + 深度上限 - sudoingX:
- sudoingX 仓库（参数、启动命令、调优扫描、探测、社区表格）
- keys/drowzeys MTP 深度梯度（n=1 1.75x / n=2 2.37x / n=3 2.85x / n=4 崩溃，只有一个MTP层）
- keys 首次运行帖子

内存三件套（适配24GB）- AJ的完整3090运行命令：
- AJ的原始解码速度帖子
- MTP KV缓存开销 + draft缓存参数（社区议题帖）

长上下文bf16 KV - mmike87（「100k+ 模型变笨」，量化KV，全精度修复，「天差地别」）

模板陷阱 - PurpleDoubled（GGUF 尺寸、KV技巧、--jinja失败模式、修正模板）

Blackwell / Spark 路线 - Mia的仓库（MTP n=2，FP8 KV，1M ctx，显存利用率警告）
- Mia的帖子