硬件：AMD RX 7900 XTX 24GB（gfx1100）/ Ryzen 9 7950X3D 16C32T（100W）/ 48GB DDR5（单通道）/ Windows 11 25H2
用途：本地代码 / agent 生成，验证主线 draft-dspark / draft-dflash 投机解码在本机是否可用
后端：llama.cpp Vulkan（官方 b10295 win-vulkan 免编译包）
模型：Qwen3.6-27B i1 Fable / Huihui / HauhauCS + satgeze DSpark / zeeksa DFlash 草稿；Qwen3.6-35B-A3B MoE

TL;DR

主线 llama.cpp 已原生支持 DSpark（PR #25173）、DFlash（PR #22105）与 MTP，Windows 直接可用。

n_max=4 甜点在 dense / MoE / 小模型全部复现。27B + DFlash 峰值接近 100 t/s（Huihui ~100，裸跑 42 的 2.4x）。
跨目标加速比 2.2x 与匹配目标一致；绝对速度由裸跑基线决定，匹配目标并不会自动更快。
核心变量是 --spec-draft-n-max：按 PR 作者"=block_size"的规则（DSpark 15 / DFlash 16）在本机是负优化，设为 n_max=4（约等于平均接受长度）后全面翻盘。
代码场景 DFlash 与 MTP 打平（~74 vs ~73 t/s），均远优于 DSpark；DSpark 长上下文不可用：代码下接受率崩到 ~2%，64k 以上又因草稿 3.7GB 过大显存溢出。
长上下文 128k 可行：DFlash 42~46 / MTP 42~43 t/s，接受率 0.68-0.75 不崩，速度约为短上下文一半，prefill 104k 需 ~5 分钟。

Agent/代码生成的最佳选择

27B dense（i1 Fable 或 Huihui）+ DFlash n_max=4 ≈ 91~100 t/s：代码能力强（27B dense 是代码主力），投机无损输出质量。
匹配权重下 MTP 略胜 DFlash 只出现在 HauhauCS（约 94 vs 85），i1 上两者打平；i1+DFlash 跨目标仍 91~100，是绝对速度最高，见结果总览。
35B-A3B 虽 183 t/s（DSpark n_max=4 均值，区间 170~190）但代码力弱于 27B dense，只在不在乎代码质量的高吞吐或对话场景用。
9B coder 本贴未测试，不下结论；可参考社区数据：Q4 量化在 RTX 3080 Ti 上 MTP 也有约 25% 提升，需按机器实测。

范围说明：短上下文测速在 8192 上下文下完成；65536 / 81920 / 131072 长上下文已实测（35B MTP/DFlash、27B MTP/DFlash），见「长上下文可行性」一节。

背景：DSpark / DFlash、匹配 vs 跨目标、MTP

DSpark / DFlash

• DSpark（PR #25173，2026-07-28 合并）：block-diffusion 草稿 + Markov head，草稿一次生成一块 token。
• DFlash（PR #22105，2026-06-28 合并）：block-diffusion 草稿，无 Markov head，草稿更轻。

两者都是 llama.cpp 主线的投机草稿方案，后端无关的 ggml 图实现，Vulkan 可直接跑，与 Lucebox 那种只能 CUDA/HIP 的引擎不同。

匹配 vs 跨目标

草稿基于同一基座（Qwen3.6-27B base）训练，目标模型是基座上的社区 finetune：Huihui 为 abliterated 去审查版，i1 Fable 为 Fable-Fusion 的 i1 量化，HauhauCS-Aggressive（下称 HauhauCS）为另一权重链。DFlash 草稿来自 zeeksa，DSpark 草稿来自 satgeze。

• 匹配目标：草稿与目标同发布者同权重链。zeeksa 的 HauhauCS-Aggressive + 配套 DFlash。
• 跨目标：草稿配其他发布者的 finetune。zeeksa DFlash 配 Huihui / i1 Fable。

草稿只要求与目标同架构、同分词器，猜错会被目标否决，因此同一份草稿可配任意同架构 finetune，无需重训。但 finetune 与基座偏差越大草稿越猜不准，接受率下降、加速比缩水。跨 finetune 可用，加速比需实测，不保证与匹配目标持平。

MTP（对照方案）

MTP（多 token 预测，草稿头长在目标模型内部）由 --spec-type draft-mtp 启动，代表是 Unsloth 的 MTP 版模型。好处是几乎零额外显存、天然同源。

受控对比结果（同权重，n_max=4）：

• 27B HauhauCS Q4_K_P：MTP 84.6~99.8（均值~94）t/s vs DFlash 78~89.5（均值~85）t/s vs DSpark 64~80（均值~74）t/s，MTP 反超 DFlash 约 10%、反超 DSpark 约 27%。
• 27B i1 Fable Q4_K_S：MTP 83.8~91.9（均值~88.5）t/s vs DFlash 89.6~91.7（均值~91）t/s vs DSpark 76.7 t/s，MTP 与 DFlash 打平略低，均高于 DSpark。
• 35B-A3B MoE：DFlash 196~237 t/s vs MTP 204~226 t/s vs DSpark 170~190 t/s，DFlash 与 MTP 相当，均反超 DSpark ~17%。

MTP 反超 DFlash/DSpark 的幅度随目标而变，非固定规律；主因仍是 MTP 草稿头与目标同源匹配更好、接受率更高（i1 上接受率 0.60-0.70 与 DFlash 0.61-0.74 相当，故无优势）。

关键发现：n_max=15 负优化，n_max=4~5 是甜点

实测数据（同一服务器，仅改 --spec-draft-n-max，其余参数固定）

基于 27B i1 Fable + DSpark（satgeze 草稿，block-15）

真实代码 prompt 复核（n_max=4）：76.7 t/s，接受率 0.587，用代码类任务而非"你好"类高可预测短句，结论稳健。

为什么 n_max 大反而慢（机制）

1. target verify 每次验证整块草稿，这是 27B 目标的主导成本。
   n_max=15 时 15 个 token 只被接受 ~4 个，73% 的验证工作量浪费在被拒绝的 token 上；
   n_max=4 时 ~4 个接受 3.4 个，浪费趋近于零。
2. 接受率沿 block 衰减（PR #25173 作者原话 "acceptance decays along the block"）：
   位置越深越难预测，n_max=15 把低接受率的尾部（8~15）也扩散出来，全是白算。
3. 每条规则都有适用范围：PR 作者"n_max=block_size"是 CUDA 规则（草稿近免费、verify 极快）；
   本机（Windows Vulkan + 7900 XTX）应设 n_max ≈ 平均接受长度（4~5）。

n_max=4 甜点在多架构复现

• 35B-A3B MoE（fast 目标）：n_max=8 负优化（108 t/s）、n_max=4 反超裸跑（183 t/s 为 DSpark 均值，区间 170~190），MTP（n_max=4）更达 204~226 t/s。
• 27B Huihui / i1 / HauhauCS（慢目标）：n_max=4 收益最大（2.2~2.4x）。
• 0.8B（超快目标）：即便 n_max=4 也净降速，目标太快、投机不划算（模型卡已预告）。
• 匹配 vs 跨目标（同一 DFlash 草稿）：加速比几乎一致（HauhauCS 匹配 2.2x vs Huihui 跨 2.4x），
  匹配目标绝对速度反而略低（85 vs 100 t/s），根因是匹配目标 Q4_K_P 裸跑基线更低（38.7 vs 42.2 t/s），
  结论见 TL;DR。接受率随 prompt/目标在 0.61-0.91 波动。
• 通用规律：n_max≈4 与架构/规模无关；目标越慢越大，投机收益越高。

结果总览（服务端 eval tg，短 prompt 隔离 prefill，多取稳态）

加速比 = 相对各模型自己的裸跑（Bare = 1.00x）；括号为接受率；速度单位为 t/s；— 为该列未测试。
匹配/跨 指草稿与目标同发布者权重链（匹配模型）或异源 finetune（跨模型），定义见「背景」。

注 1：27B DFlash 用 zeeksa 草稿（block-16，1.72GB）、35B DFlash 用 Alittlehammer 草稿（block-16）；DSpark 用 satgeze 草稿（27B block-15 / 0.8B block-7）。
注 2：35B-A3B 的 n_max=8 也是负优化（108 t/s），n_max=4 才反超。
注 3：以上为 8192 上下文、短 prompt（4~11 token）测得的稳态值，长上下文见后文。

长上下文可行性（65536 / 128k 正常工况）

35B-A3B 65536 实测（2026-08-07，MTP 与 DFlash，-c 65536）

35B-A3B I-Compact（17GB）+ MTP 或 DFlash 草稿在 -c 65536 下均加载成功（n_ctx_slot=65536），显存专用 18.5~19.1GB / 共享 ~0.6GB，无溢出。

填充 ~52k token 后测 decode（短上下文 8k 对照）：

长上下文 decode 全部降到短上下文的 ~60%，但相对同上下文长度的裸跑（116~122）仍略高（~1.06x），投机在长上下文仍有小幅收益。prefill 52~62k token 约 39~51s（1300~1900 t/s）。

27B MTP 实测（2026-08-07，HauhauCS，-c 32768 / 65536）

27B HauhauCS MTP 版在 -c 32768 和 -c 65536 下均加载成功（显存专用 20.6GB / 共享 ~0.6GB，贴边未溢出）：

• 32k（28k 实测）：decode 64~72 t/s（短上下文 ~94 的 ~75%）
• 64k（52k 实测）：decode 58~64 t/s（短上下文 ~94 的 ~65%），prefill 52k 需 ~110s（474 t/s）

27B 长上下文可用但明显吃紧：64k 下显存贴边、prefill 显著变慢，32k 相对从容。27B 目标 + 独立草稿在 80k/128k 上更贴顶（见下）。

27B 独立草稿实测（2026-08-07，HauhauCS Q4_K_P + DFlash/DSpark）

27B 目标 + 独立草稿（DFlash 1.72GB / DSpark）加载情况：DFlash 在 -c 32768/81920/131072 均成功（128k 显存专用 22.30GB / 共享 0.58GB，贴顶未溢出）；DSpark 在 -c 32768/65536 成功，但 64k fill 触发显存溢出（见下）。

各上下文长度下的 decode（短上下文 8k 对照；27k 为代码类 prompt，67k/104k 为长文本填充）：

方案	短上下文(8k)	27k 代码	67k	104k
MTP	~94 t/s	72~77 t/s（~74）	58~64 t/s	42~43 t/s
DFlash	~85 t/s	68~77 t/s（~73）	53~55 t/s	42~46 t/s
DSpark	~74 t/s	~17.5 t/s	显存溢出	显存溢出

接受率：MTP 0.68-0.88（27k 代码 0.75-0.84，128k 0.68）；DFlash 全程 0.70-0.81（不崩）；DSpark 短上下文 0.52-0.71、长上下文代码崩到 0.018-0.030（两次独立测试复现）。prefill：67k 需 ~160s（417 t/s），104.7k 需 ~297s（352 t/s）。

DSpark 67k/104k 测不了：草稿 3.7GB（DFlash 仅 1.72GB），-c 65536 下 fill 触发显存溢出（shared 1.41GB spill），prefill 崩到 46 t/s（假慢）→ 64k 以上长上下文 DSpark 因显存不足实际不可用。

关键发现：长上下文代码场景 DFlash/MTP 与 DSpark 分化巨大。DFlash 接受率全程保持 0.7+，MTP 在 27k 代码 0.75-0.84（速度与 DFlash 打平）；DSpark 在长上下文代码下接受率崩到 ~2%，退化为比裸跑还慢。长上下文（尤其代码类）应选 DFlash 或 MTP。

128k 极限实测（2026-08-07，可行）

27B + DFlash 在 -c 131072 下加载成功（显存专用 22.30GB / 共享 0.58GB，贴顶未溢出），104.7k 上下文 decode 42~46 t/s（接受率 0.68-0.75）。128k 从"装不下"改为"可加载但慢"：decode 为短上下文 ~85 的 ~50%，prefill 104k 需 ~5 分钟。q4_0 KV 很省（GQA 少 KV 头），24GB 极限可到 128k。

可行性结论

• 65536 可行：35B（MTP/DFlash）和 27B（MTP/DFlash）均实测通过，24GB 干净 + q4_0 KV 即可；长上下文下投机速度较短上下文缩水（~60-75%），相对同长度裸跑仍略高（35B ~1.06x）。
• 27B 80k 可行：显存 21.68+1.13GB、decode 53~55 t/s；64k 更从容。
• 27B 128k 极限可行：-c 131072 加载成功（专用 22.30GB / 共享 0.58GB），104.7k 上下文 decode 42~46 t/s（接受率 0.68-0.75），prefill 104k 需 ~5 分钟。
• 长上下文代码首选 DFlash：DFlash 接受率 0.7+ 不崩，DSpark 在长上下文代码下崩到 ~2%。

启动配置

:: MTP（n_max=4，匹配权重首选；HauhauCS MTP 版，草稿头内置，零额外显存）
"D:\llm\llama-b10295\llama-server.exe" ^
 -m "D:\llm\models\SummonGovernance\Qwen3.6-27B-Uncensored-HauhauCS-Aggressive-MTP-GGUF\Qwen3.6-27B-Uncensored-HauhauCS-Aggressive-MTP-Q4_K_P.gguf" ^
 --spec-type draft-mtp --spec-draft-n-max 4 ^
 -ngl 99 -c 8192 -ctk q4_0 -ctv q4_0 -b 512 -ub 512 --parallel 1 ^
 -fa on --jinja --port 8195

:: DFlash（n_max=4，跨目标首选；zeeksa 草稿 block-16，破百配置）
"D:\llm\llama-b10295\llama-server.exe" ^
 -m "D:\llm\models\HuihuiMTP\Huihui-Qwen3.6-27B-abliterated-ggml-model-Q4_K.gguf" ^
 -md "D:\llm\models\zeeksa\Qwen3.6-27B-Uncensored-HauhauCS-Aggressive-DFlash-GGUF\Qwen3.6-27B-DFlash-Q8_0.gguf" ^
 --spec-type draft-dflash --spec-draft-n-max 4 ^
 -ngl 99 -c 8192 -ctk q4_0 -ctv q4_0 -b 512 -ub 512 --parallel 1 ^
 -fa on --jinja --port 8195

:: DSpark（n_max=4，i1 + satgeze 草稿）
"D:\llm\llama-b10295\llama-server.exe" ^
 -m "D:\llm\models\mradermacher\Qwen3.6-27B-Fable-Fusion-711-...\i1-Q4_K_S.gguf" ^
 -md "D:\llm\models\satgeze\Qwen3.6-27B-DSpark\Qwen3.6-27B-DSpark.gguf" ^
 --spec-type draft-dspark --spec-draft-n-max 4 ^
 -ngl 99 -c 8192 -ctk q4_0 -ctv q4_0 -b 512 -ub 512 --parallel 1 ^
 -fa on --jinja --port 8195

注意事项：

• --spec-draft-n-max 设 4（默认 3 也可）：别设成草稿的 block_size（DSpark 15 / DFlash 16），本机实测负优化，原因见「关键发现」。
• 启动前建议禁用/启用一次 7900 XTX 释放显存，目标 + 草稿 + KV + spec context 在 24GB 上非常紧，显存被系统占用时草稿会溢出到共享内存掉回假性低速（详见踩坑 #1）。

踩坑纪录

1. 草稿上 GPU 溢出 3.4GB 共享内存 → 5~10 t/s 假性低速：排查方法是用 PowerShell 查
   Get-Counter '\GPU Adapter Memory(*)\*'，看到 shared usage 数 GB 就是溢出；禁用/启用独显可释放。
2. 首次请求极慢（prompt eval 十几秒）：是 kernel JIT / 管线缓存冷启动，第二次请求恢复正常（19→36 t/s），
   测速务必跑 2 次取稳态。
3. n_max=block_size 是本机不适用（DSpark 15 / DFlash 16）：来自 PR 作者在 CUDA 上的规则（n_max=block_size），
   Windows Vulkan 上直接负优化；设 4。
4. --spec-draft-n-max 默认 3：不设也接近甜点；设成 4最佳。
5. 置信度截断（conf_min/p_min）对本场景无效：PR 作者实测只在并发 ≥8 时有用，单槽无收益。
6. 下载坑：hf CLI 不在 PATH，且 HF 仓库下载会先落缓存再同步到 --local-dir。

社区结论的对照

• PR #25173（wjinxu）：作者在 RTX 4090 + Qwen3-8B 上 matched n_max=7 → 1.88x；
  但同表里 Q4_K_M 目标 + 对话类（MT-Bench）= 0.87x（负优化），正好印证"n_max 大 + 低接受率场景会亏"。
• 置信度截断：作者原话 "Confidence pruning has no benefit at concurrency 1, begins to help at concurrency 8"。

局限性

• 上下文窄：多数测速在 -c 8192 下测得；65536 / 81920 / 131072 已实测（35B MTP/DFlash、27B MTP/DFlash，见「长上下文可行性」）。
• prompt 类型单一：测的是"你好"类高可预测短句，绝对 t/s 偏乐观；真实 agent/代码任务接受率回落。代码复核做了 27B i1 的 DSpark（76.7/acc 0.587）和 DFlash（~91/acc 0.61-0.77），以及 27B HauhauCS 的 32k 代码类（MTP ~74/acc 0.75-0.84、DFlash ~73/acc 0.70-0.81、DSpark ~17.5/acc 0.02），代码场景 DFlash/MTP 均优于 DSpark；35B 未做代码类复核，待验证。
• 接受率波动大：同一配置下接受率随 prompt/目标在 0.61-0.91 间波动，加速比是样本区间而非固定值。
• 单槽并发：parallel 1 测得，并发 ≥8 时置信度截断等参数才有收益，高并发场景未覆盖。
• 后端限定：结论基于 Windows Vulkan + 7900 XTX；PR 作者在 CUDA 上"n_max=block_size"规则与本机相反，其他后端/平台需重测。
• 单卡 24GB：显存紧张，KV 用 q4_0 压缩；更大显存或不同量化下数字会变。

方法口径

• 全部为 llama.cpp 服务端 print_timing 的 eval time（整段 decode 平均，非瞬时峰值），与 llama-bench tg 同源。
• 短 prompt（4~11 token）隔离 prefill；丢弃首次 JIT 冷启动，取多次稳态平均。

原始 bench 日志（证据）

Qwen3.6-27B HauhauCS-Q4_K_P（匹配，4 方案）：

HauhauCS Q4_K_P · Bare 裸跑

HauhauCS Q4_K_P · DSpark n_max=4

HauhauCS Q4_K_P · DFlash n_max=4

HauhauCS Q4_K_P · MTP n_max=4

Qwen3.6-35B-A3B MoE-Q4_K_M（跨，4 方案）：

35B-A3B · bare

35B-A3B · DSpark n_max=4

35B-A3B · DFlash n_max=4

35B-A3B · MTP n_max=4

测试日期：2026/08/07