Qwen3.8 27B 加速 9.5 倍,75 tok/s 是怎么跑出来的
本文来源: 大模型前线观察(公众号:大模型前线观察)
原文链接: https://mp.weixin.qq.com/s/t806IBzEBI7JMc73waohCQ
发布时间: 2026-08-18 08:36

作者: 大模型前线观察 发布时间: 2026-08-18 08:36
Qwen3.8-27B 火是真火,两天 100 万下载、 500 个社区量化版本。但稠密模型的痛也是真的:每生成一个 token , 27B 参数要全部过一遍,单流十几 tok/s 是常态。
耐不住社区能人还是多,有人把它跑到了单流 75 tok/s 。相比最原始的 7.88 tok/s ,快了 9.5 倍,而且一个字不改。
这中间差出来的,是一整套「推理侧工程」。核心就是 DSpark 。
DSpark 是什么,凭什么无损加速
DSpark 出自 z-lab 的 DFlash 生态,本质是推测解码( Speculative Decoding ),论文 arXiv:2602.06036 。
传统自回归模型一次前向预测一个 token ,再把结果喂回去继续。推测解码的思路是:用一个 1.36B 的小草稿模型先快速「猜」出一串 token ,再由主模型批量验证,猜对了就白赚,猜错了重来。这样把「一个一个想」变成「先打草稿再批量确认」。
DFlash 的关键改进是用块扩散( Block Diffusion ),让草稿模型一次 forward 并行吐出一整块草稿。 DSpark 又加了两招:
•目标模型辅助特征:草稿模型从大模型第 4 、 16 、 28 、 40 、 52 层偷隐状态,等于「知道」大模型在想什么,猜得更准
•置信度头:动态决定每步投机多少个 token ,拿得准多猜,拿不准少猜
最关键的是无损。主模型验证每一个 drafted token ,输出和原始模型完全一致,不是拿质量换速度。
从 7.88 到 75 tok/s ,加速效果实测

先看最狠的一组。开发者 0xBakeer 在单台 DGX Spark ( GB10 , 128GB 统一内存, 273GB/s )上做了完整调优:
•原始基线只有 7.88 tok/s
•调优后单流冲到 75 tok/s,提升约 9.5 倍
•16 路并发时聚合吞吐 256 tok/s
他给了一个明确的排序:投机解码 > 前缀缓存 > 量化。投机解码加前缀缓存一共贡献了 7.4 倍,而且完全不改模型输出;量化只贡献 1.6 倍,还改变了模型知识。
其他几组实测也印证了这条路:
•MegaCube( 128GB 统一内存, SGLang ):原生 NVFP4 12.51 tok/s ,加 DSpark 后 38.16 tok/s , 3.05 倍,第二天复测偏差不到 2%
•苹果 M4 Pro 48GB( mlx-dspark ): 8-bit 从 8.3 到 20.3 tok/s , 2.45 倍,数学任务 3 倍、代码 3.18 倍。 8-bit 加草稿模型甚至打败了纯 4-bit
•MTP 路线( qwen38-mtp 项目): RTX 4090 从 47.7 到 76.3 tok/s , RTX A6000 从 26.7 到 52.5 , AMD RX 7900 XTX 从 30.7 到 43.9 。项目两天 21 个贡献者、 27 组配置
这些数字有个共同点:加速几乎全来自解码策略,不靠砍精度。
三大加速杠杆,顺序别搞反
这是最容易被忽略、也最重要的一层。很多人的第一反应是「量化」,其实方向错了。
第一,投机解码。 提高一次主模型 forward 能产生的有效 token 数。这是收益最大的一项,而且无损。
第二,前缀缓存。 对 Agent 、 RAG 、 Coding 这类大量共享上下文的场景,前缀缓存能带来 14 到 22 倍的 prefill 加速。但有个坑:它常常因为框架的默认值被静默关闭,你以为开着,其实没开。
第三,量化。 它是唯一会改变模型输出、也唯一在高负载下收益归零的手段。 0xBakeer 的实测很扎心: 4bit 在单请求上快 27%,到了 16 并发只剩 0.2%。 k 值也是一样, k=14 单请求更快,却能让 FP8 的 8 并发吞吐下降 43%。
所以正确的顺序是:先穷尽解码策略(投机解码 + 前缀缓存),再考虑量化。别一上来就砍精度。
部署,一条命令跑起来
0xBakeer 给了一份能在 DGX Spark 上复现 75 tok/s 的 vLLM 配置,草稿模型用社区 RadixArk 提供的 1.36B DSpark draft :
vllm serve Qwen/Qwen3.8-27B-FP8 \
--max-model-len 262144 \
--gpu-memory-utilization 0.85 \
--max-num-batched-tokens 16384 \
--enable-prefix-caching \
--reasoning-parser qwen3 --tool-call-parser qwen3_xml \
--speculative-config '{"method":"dspark", "model":"RadixArk/Qwen3.8-27B-DSpark", "num_speculative_tokens":7, "draft_sample_method":"probabilistic"}'注意两个关键参数:--enable-prefix-caching 显式打开前缀缓存(它常被静默关掉),以及 --speculative-config 里的 dspark 方法。
SGLang 用户走对应的 DSpark 参数:
python -m sglang.launch_server \
--model-path Qwen/Qwen3.8-27B-FP8 \
--speculative-algorithm DSPARK \
--speculative-draft-model-path RadixArk/Qwen3.8-27B-DSpark \
--trust-remote-code
苹果芯片一条命令装完 mlx-dspark ,自带 OpenAI 兼容接口和 Anthropic Messages API ,能直接给 Claude Code 当本地后端:
pip install mlx-dspark什么时候别用,几个坑
DSpark 不是万能加速器,有几个实打实的坑。
草稿接受率随任务漂移。 0xBakeer 测出来:编辑已有代码时草稿接受率 99%,写全新代码时只剩 29%。同一个配置,两种场景一胜一负。格式化文本(代码补全、 JSON )命中率高,自由创作命中率低。
单请求和并发的结论会反转。 很多公开数据是单点测量,但配置的优劣排序在单请求和 16 并发之间可能完全反过来。真要用,得在自己的真实负载上测。
统一内存设备和 CUDA 大卡结论不同。 Mac 、 DGX Spark 、 MegaCube 这类统一内存设备上, DSpark 的 3 到 9 倍加速基本能吃满;纯 CUDA 大卡上 MTP 的接受率可能更高,未必非 DSpark 不可。
值不值得上
值得,尤其是统一内存设备的用户。
Qwen3.8-27B 本身已经是「够聪明 + 本地能跑」的甜点模型, DSpark 解决的是最后一块短板:速度。 75 tok/s 意味着一个 500 token 的回答 7 秒出完,体感已经和云端 API 差不多,而这一切发生在本地,不花 API 钱、数据不出门。
真正值得记住的不是某个数字,是那个排序:投机解码 > 前缀缓存 > 量化。多数人优化本地模型第一反应是砍精度,但真正的大头在解码策略。这一条想明白,能少走很多弯路。
模型能力靠 Qwen3.8 的分数说话,速度靠 DSpark ,流畅度靠前缀缓存,三者全是开源的,你现在就能在自己桌上复现。
觉得有启发?点个「在看」,转发给朋友。
关注本号,持续追踪大模型前沿动态。
本文转载自微信公众号「大模型前线观察」,仅供学习交流使用。
觉得内容不错?我要