Qwen3.8-27B 开源刚满一周，社区讨论的热点已经悄悄换了一茬。上周大家还在问"我的显卡能不能跑"，这周知乎和小红书上被收藏最多的帖子，都变成了同一类：为什么你的 Qwen3.8-27B 比我的快。有人用 4090D 跑 Q8_0，MTP 开关不开只有 30 tok/s，开了提速约 50%。小红书也有人在 24G 显卡上，llama-server 稳定只有 35.88 t/s，而 Ollama 里同一个模型能跑 41 t/s。知乎
我把最近三天（8 月 19 日—21 日）各平台晒出来的实测翻了一遍，结论相当一致：这个模型的速度差距，通常不是硬件拉开的，而是几个不起眼的开关。这篇把社区这周验证过的三条加速路径整理在一起，外加一个比提速更值得先查的"假加速"坑。
一、免费提速：把模型自带的 MTP 投机解码打开
Qwen3.8-27B 内置了一层 MTP（Multi-Token Prediction）投机解码：一次草拟多个 token 再统一验证，猜对省时间，猜错退回正常生成，输出质量不变。有位用户用 AMD 7900 XTX 24G 跑 llama-server 做日常推理，觉得 35.88 t/s 还行，直到发现 Ollama 里同一个模型快 15%。他把 Ollama 启动的进程参数拉出来一看，发现是 Ollama 默认悄悄开启了 MTP 投机解码。把这组参数搬回自己的 llama-server 后，最好成绩到了 47 t/s，日志里能看到 MTP 的接受率：一次草拟 4 个 token，平均接受 3.96 个，接近完美命中。知乎
嫌手动折腾的，也可以直接抄社区的现成作业。一位 16G 显存用户晒出了自己的完整启动参数，MTP 投机解码、KV cache 量化、128K 上下文一次配齐，照搬即可。小红书
二、硬核提速：DFlash2 草稿模型开源，专门给 27B 做的
8 月 20 日，Inco AI 团队开源了面向 Qwen3.8-27B 的投机解码草稿模型 Qwen3.8-27B-DFlash2：1.92B 参数、约 3.85GB，沿用一次前向传播并行预测整块 token 的设计。知乎原理不复杂：小模型先一次"猜"出一整块 token，大模型再统一验证，猜对保留、猜错丢弃。
官方给出的数字相当能打：单张 H200、SGLang、并发 1 的条件下，配合该草稿模型的输出吞吐达到自回归解码的 2.7—3.4 倍；五个基准上平均接受长度 4.80，高于 Qwen3.8 原生 MTP 的 4.28 和社区 DSpark 草稿模型的 3.62，而且解码结果无损。知乎
社区实测也跟上了。MacBook Pro（M5 Pro、48GB）上，llama.cpp 跑 Q4_K_M 主模型加 DFlash2 Q4_K_M 草稿，约 16K 上下文能到 14.52 token/s；在约 1K、16K、32K 上下文下的草稿接受率分别约 46%、58%、51%，而且和 Q6_K 主模型相比，Q4 组合解码更快、内存占用还少约 5GiB。知乎对 Mac 用户来说，这是眼下真能用的加速路径。
三、设置提速：量化和缓存里的水分
不碰投机解码，设置本身也有不少可挤的空间：
一位 16G 显存用户在 AMD 9070 上选了 unsloth 的 IQ3_S 量化版，质量和速度平衡最好，128K 上下文占显存 14.5GB 左右，跑出了稳定 40+ token/s。小红书这基本是 16G 卡的天花板配置。
一位 3090 Ti 用户花了一两天，把官方 4-bit 量化版（17.74GB）在 LM Studio 里的输出速度，从 20—30 tps 优化到 50—60 tps。知乎他还发现解码速度对上下文长度不敏感，10K 上下文只比裸测慢约 10%，长对话不会让速度断崖式下跌。
显存够大的话，KV cache 开 q8_0 量化，显存减半且实测不掉速，这是 48G 卡塞下 200K 上下文的关键。小红书
上面 16G 配置跑起来的速度效果，在 llama.cpp 日志里长这样，decode 速度稳定在 38—45 t/s：
四、比提速更要紧：先查自己是不是"假加速"
这是横向对比这周实测后，我们觉得最容易被忽略的一个坑：加速开关开了，不等于加速真的生效了。一位 Mac 用户的实测是个典型：当前版本的 oMLX 无法加载 DFlash2 草稿权重，识别到配置后自动回退为普通引擎，你以为开了加速，其实一直在裸跑自回归。知乎换句话说，性能之外还有"加速到底有没有真的启用"这个工程问题，对只想装好就用的用户，这种兼容性成本本身就是风险。
自查方法很简单：看日志。MTP 的接受率、DFlash2 的接受长度都会打印在推理日志里，这些数字缺失或异常低，说明加速根本没生效，该查的是参数、版本和权重格式是否匹配，而不是怀疑自己的显卡。
还有两种"看起来慢"，容易和加速混为一谈。一种是思考过度：这个模型默认思考档位是最高的 xhigh，不传参数一道题能想近一万 token，又慢又烧额度。小红书网传的 enable_thinking 字段和 /no_think 后缀全部无效，正确姿势是用 OpenAI 标准字段 reasoning_effort，日常任务压到 none 或 medium 就好。
另一种是首字等待（TTFT），这是 prefill 阶段的问题，投机解码只帮得上解码、帮不上 prefill：Mac 上 16K 上下文要等 42.7—69.4 秒才出第一个字，到了约 32K，最短也要 96.79 秒才开始生成。知乎所以如果你的主力场景是长文档 RAG 或 agent 工作流，加速方向应该是 KV cache 复用和前缀缓存，而不是换草稿模型；顺带一提，请求中途取消会让前缀缓存失效，下次全量重读。小红书
五、不同人怎么办
24G N 卡（3090/4090）：官方 4-bit 或 Q4_K_M 加 MTP 参数，是当前最稳的路子；跑稳之后再考虑 DFlash2，注意显存余量。
16G 显存：IQ3_S 加 vulkan 后端，KV cache 开 q4_0，先稳稳跑住 40 tok/s 再谈别的。
AMD 卡：直接用 vulkan，有用户反馈 9070 用 ROCm 经常卡死，vulkan 非常丝滑。小红书
Mac：llama.cpp 加 DFlash2 可用，oMLX 目前会静默回退；另外别把笔记本当长上下文主力机，首字等待几十秒是常态。
纯 API 用户：这篇与你们无关，本地加速是有卡玩家的快乐。
最后留两个观察信号：DFlash2 在 llama.cpp、oMLX 这些后端里的适配进度，和你自己日志里的接受率数字。这个模型的加速生态还在快速演化，本文结论的有效期先到 8 月 21 日为止。
