Qwen3.8 27B 加速 9.5 倍,75 tok/s 是怎么跑出来的

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

Qwen3.8 27B 加速 9.5 倍,75 tok/s 是怎么跑出来的

本文来源: 大模型前线观察(公众号:大模型前线观察)
原文链接: https://mp.weixin.qq.com/s/t806IBzEBI7JMc73waohCQ
发布时间: 2026-08-18 08:36

Qwen3.8 27B 加速 9.5 倍,75 tok/s 是怎么跑出来的

作者: 大模型前线观察  发布时间: 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 ,加速效果实测

DSpark 无损加速,三台机器实测

先看最狠的一组。开发者 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 ,流畅度靠前缀缓存,三者全是开源的,你现在就能在自己桌上复现。

觉得有启发?点个「在看」,转发给朋友。

关注本号,持续追踪大模型前沿动态。


本文转载自微信公众号「大模型前线观察」,仅供学习交流使用。

觉得内容不错?我要

打赏杯咖啡或蜜雪冰城吧
微信扫一扫
微信赞赏码
支付宝扫一扫
支付宝赞赏码
评论 暂无评论
请登录后参与评论