DeepSeek V4 Flash 在 Strix Halo 上的投机解码实测

Reddit 用户 Responsible_Pain3278 在 r/LocalLLaMA 发布了对 DeepSeek-V4-Flash-0731 模型在 Strix Halo 设备上的投机解码（speculative decoding）实测数据。经过一周的对比测试，作者发现 n_max=3 是综合最优配置，可获得约 28.5 tok/s 的平均解码速度，相对无草案基线提升 1.39 倍。

测试硬件与模型设置

测试平台为搭载 128 GB 统一内存的 Strix Halo 迷你 PC，系统为 Ubuntu。目标模型使用 Unsloth 的 UD-IQ3_XXS 量化方案，注意力层保留 Q6 精度，权重约 96 GB；在 264k 上下文、无上下文量化的情况下，进程占用约 114 GB 内存。

无草案基线测试在 64k 上下文下进行，预填充速度为 200–220 tok/s，解码速度稳定在 20–22 tok/s（取 20.48 tok/s 作为基准）。

草案模型与采样设置

作者对比了两种 DSpark 草案模型：

• Q8_0 量化版本，文件大小 10.15 GB
• 自制的 Q2_K_S 量化版本，文件大小 6.45 GB

测试覆盖 n_max 从 2 到 7 的所有取值，每种配置在 7 类提示上各跑 5 轮。所有测试统一采用 temp 0.9、top_p 0.95、min_p 0.01 的采样参数，开启思维链（reasoning_effort=low）。为隔离草案模型本身的效果，测试期间关闭了 ngram-mod。

关键结论：n_max=3 综合最优

综合两类草案模型的平均结果：

• n_max=3 达到峰值 28.5 tok/s，为无草案基线的 1.39 倍
• Q2 与 Q8 草案表现几乎一致，各项配置差距均在 1–3% 以内，因此体积更小的 6.45 GB Q2 文件更具实用价值
• n_max=5–7 仅在「重复」类高接受率任务上有收益，其他任务上多余的草案 token 多被拒绝，反而拖慢速度

按任务类别统计的「最佳 n_max / 平均速度 / 加速比」：

• 代码 — n_max=3 — 28.99 tok/s — 1.42×
• JSON — n_max=3 — 28.59 tok/s — 1.40×
• 数学 — n_max=3 — 31.22 tok/s — 1.52×
• 对话 — n_max=3 — 25.48 tok/s — 1.24×
• 翻译 — n_max=2 — 25.09 tok/s — 1.22×
• 散文 — n_max=2 — 23.38 tok/s — 1.14×
• 重复 — n_max=5 — 40.17 tok/s — 1.96×

各 n_max 整体表现一览：

• n_max=2：27.12 tok/s，1.32×，接受率 0.69
• n_max=3：28.50 tok/s，1.39×，接受率 0.60
• n_max=4：27.73 tok/s，1.35×，接受率 0.52
• n_max=5–7：约 26.4–26.5 tok/s，1.29×，接受率约 0.45

实际使用建议

作者特别指出，测试提示集偏向投机解码擅长的任务（重复、数学、代码），且实际填充的上下文仅约 32k。因此 28.5 tok/s 这一数字不应被视作混合聊天/编程场景下的承诺值，更现实的预估为 22–28 tok/s。

作者日常部署使用 128k 上下文、ngram-mod 叠加草案模型、思维链设为 max，并表示「如果你已经在 Strix Halo 上跑 Flash 0731，从 --spec-draft-n-max 3 和 Q2 草案开始即可」。

部署相关资源

测试使用的是 llama.cpp 的 strix-halo-llamacpp 分支，包含 FA、MoE-prefill 修复以及集成的 Mesa、Vulkan/HIP 支持，上游仍是 llama.cpp。相关资源如下：

• 基座权重：deepseek-ai/DeepSeek-V4-Flash-0731
• GGUF：unsloth/DeepSeek-V4-Flash-0731-GGUF
• 草案模型：Lynxpda/DeepSeek-V4-Flash-0731-DSpark-Drafter-Q2_K_S-GGUF