Qwen3.6-27B 单卡 3090 推测解码横评：ik_llama 最快，mainline 最稳

一位 r/LocalLLaMA 社区用户近日发布了一组针对 Qwen3.6-27B 在单张 RTX 3090 24GB 上的推测解码（speculative decoding）横评。测试在 Xeon E5-2666v3 + 64GB 内存的机器上完成，覆盖 3 个 llama.cpp 分支、1 个官方主线与 1 款独立服务器引擎 LUCEBOX，对比 MTP、ngram+MTP、DFlash 三类草稿策略，量化版本以 IQ4_KS 与 Q4_K_M 为主。

评测方法与核心指标

测试使用社区 club-3090 仓库的 bench 脚本，并通过 en8wiki 拼接长 prompt 以观察上下文膨胀后的速度衰减。核心指标包括：

• decode_TPS：代码与叙事（narrative）两类文本的解码 token / 秒。
• TTFT：首 token 延迟，反映预填充与草稿模型加载开销。
• VRAM 占用：以 MiB 计。
• 上下文一致性：上下文从 72k 填至 128k 后的生成速度退化幅度。

各引擎实测结果

ik_llama（ubergarm 调优配置）MTP n_max=4：代码 89.2 DP，叙事 63.9 DP（全场最高），TTFT 361ms，VRAM 22304 MiB；长上下文退化 −32.1%，是所有方案中最严重的一档。配置启用 merge-qkv、recurrent checkpoints、cram 32768 等参数。

ik_llama + ngram（ngram+MTP）：将 ngram 草稿（n_max=4, size=16）与 MTP（n_max=3）混合后，代码 87.8 DP，VRAM 20508 MiB，退化 −24.9%。在代码任务上几乎追平纯 MTP 调优版。

ik_llama（标准配置）MTP n_max=2：代码 73.1 DP，叙事 61.7 DP，TTFT 357ms，VRAM 20208 MiB，退化 −24.8%。作为原生 MTP 的基线较为均衡。

mainline llama.cpp MTP n_max=1（Q4_K_M）：代码 64.7 DP，叙事 52.5 DP，TTFT 288ms（全场最低），VRAM 21354 MiB。72k→128k 上下文速度几乎零退化（31.3→31.3），是唯一保持稳定的方案。

Spiritbuun MTP（Q4_K_M，启用 turbo cache 与 flash-attn）：代码 59.7 DP，叙事 45.7 DP，TTFT 294ms，退化 −9%，仅次于 mainline 的稳定性。

beellama DFlash（独立草稿模型 IQ4_XS）：代码 96.8 DP，全场第二；但 TTFT 高达 504ms，首字延迟约为 mainline 的两倍；VRAM 20814 MiB；128k 上下文下仍保持 27.1 DP。

LUCEBOX DFlash（含 TQ3 KV 缓存与 PFlash）：代码 32.6 DP，叙事 32.5 DP，比关闭推测解码还慢，作者怀疑存在环境变量配置问题，未能跑出预期效果。

一致性排名

若以「跨上下文稳定性 + 低 TTFT + 低显存波动」为权重排序：

• mainline llama.cpp MTP：72k→128k 几乎零退化，TTFT 288ms，VRAM 稳定在 ~21GB，无外部草稿模型依赖，被作者评为「最可预测」的方案。
• Spiritbuun MTP：退化仅 −9%，TTFT 294ms，速度略低但非常平稳。
• LUCEBOX DFlash：速度方差小但绝对值低。
• ik_llama 各配置：短上下文峰值最高，但 128k 下速度腰斩明显。

取舍建议

对于追求极限短上下文吞吐的本地玩家，ik_llama 配合 ubergarm 的 IQ4_KS 调优可拿到接近 100 TPS 的代码生成速度，代价是 32% 的长上下文衰减与更高的显存占用；而在意长文档稳定输出、追求「开箱即用」的用户，mainline llama.cpp 的原生 MTP 仍是当前最稳妥的选择。DFlash 路线（beellama）在代码任务上展现了与 MTP 相当的峰值，但额外的草稿模型显著推高 TTFT，尚未构成明显优势。