Qwen3.8-27B 在 RTX 3090 上的推理优化：DFlash2 + 查找增强投机解码

社区开发者 syv-ai 在 RTX 3090 消费级显卡上对 Qwen3 系列 27B 级别混合架构模型（作者将其命名为 Qwen3.8-27B）的推理引擎进行了又一轮重大迭代。更新后默认采样下单请求吞吐约 138 tps，64 并发约 942 tps；最关键的是长对话中的第二轮耗时从约 23 秒降至约 1 秒。代码已开源，并提供 W4A16 量化版本的 DFlash2 drafter 与 fast-variant 张量。

本轮性能数据

单请求默认采样：约 138 tps（此前约 124 tps）
64 并发：约 942 tps（同一软硬件复测）
长对话第二轮：约 1 秒（此前约 23 秒）
质量指标全程不变：困惑度 8.09，GSM8K 96.5%

注：作者说明其 RTX 3090 受限于 250W 功耗上限。

新增 DFlash2 块级投机解码

Inclusion AI 发布了针对该模型的 DFlash2 块级 drafter（5 层，一次非自回归前向预测 7 个 token，并配路径选择器）。由于 vLLM 的支持仍是未合并的 PR，作者将其回移植到 0.27.1，并修复了一处真实缺陷：0.27.1 缓存的是经过温度调整的 draft logits，而 main 分支缓存的是原始 logits，因此在 0 < T ≠ 1 的情况下 verify 步骤会使用错误的提案分布。修复后单步接受 token 数从 2.8 提升到 3.3。

drafter 被重新量化为 W4A16：

bf16 版本：3.85 GB，在 24 GB 显卡上是净损失（106 tps）
使用 drafter 自身在真实流量上采集的 Hessian 做 GPTQ int4：1.19 GB，无贪心接受率损失

通过 python fetch_dflash2.py 即可下载。

查找增强投机（Lookup-augmented drafting）

作者提出的原创思路。块级 drafter 视野为 2048 token，但长上下文助手的大量输出其实是复述提示中的内容——引用文档、重复指令、改写段落而保留代码。这些 token 原样存在于 prompt 中，位于其视野之外。

具体做法是新增一个 Triton 内核，在请求自身的 token 历史中扫描最近 6–12 个已生成 token 的最后一次出现，并把后续内容直接作为提案：

「复现每条指令」类工作：+29% tokens/step，吞吐从 105 → 131 tps
普通对话：+5%
每步额外开销约 0.075 ms
始终精确；贪心路径不读取 draft 分布，采样位置获得一个点质量 q，是 rejection sampler 合法的提案

混合模型前缀缓存

vLLM 对 mamba/GDN 混合模型默认关闭前缀缓存，因此每次对话轮次都会重新 prefill 整段对话。开启 --mamba-cache-mode align 后，循环状态从最后一个缓存块边界恢复：

24k token 文档，第二轮：23 秒 → 0.85–1.35 秒，输出 token 级别一致
批量场景：64 个请求共享 5820 token 系统提示：222 秒 → 16.9 秒（中位延迟 95 秒 → 8 秒）
额外占用约 14–16% 的 KV 池

64k 上下文与显存优化

启用 DFlash2 后需要修复分配器：vLLM 按最小层桶对混合模型的 KV 组进行尺寸估算，drafter 的 5 个滑动窗口层会把目标模型的 16 个注意力层 padding 到 20、48 个 GDN 层 padding 到 50，相当于每 token 多用 25% 显存。改为对窗口组做 padding 后：105 → 78 KB per token。

此外，作者让 V2 runner 的 CUDA-graph 显存显式化：上游返回 0，导致约 1.2 GB 静默叠加在用户设定的 --gpu-memory-utilization 之外。

工程化与容器化

Docker：docker compose --profile single up -d 启动，镜像锁定 0.27.1 + 所有补丁
prepare 步骤负责下载并重新量化模型
verify.sh 在构建时运行

适用边界

DFlash2 最适合 1–4 并发用户；每个请求预留 8 个循环状态槽位，因此 8+ 并发时 MTP 反而更快。drafter 的 2048 token 窗口也意味着在长上下文自由生成场景中，MTP 仍略占优。两种模式之间仅相差一个环境变量。