分享自己的经验 7900 XTX Vulkan 主线 llama.cpp DSpark / DFlash/MTP 投机解码实测：Qwen3.6-27B TG峰值接近100t/s
-
硬件：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 +satgezeDSpark /zeeksaDFlash 草稿；Qwen3.6-35B-A3B MoETL;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）
n_max 服务端 eval tg（token generation） 接受率 平均接受长度 15 29~36 0.14-0.26 3.1-4.9 8 29~34 0.32-0.35 3.5-3.8 5 63~82 0.41-0.60 3.0-4.0 4 71~81 0.51-0.61 3.0-3.4 裸跑 41.7 — — 真实代码 prompt 复核（n_max=4）：76.7 t/s，接受率 0.587，用代码类任务而非"你好"类高可预测短句，结论稳健。
为什么 n_max 大反而慢（机制）
- target verify 每次验证整块草稿，这是 27B 目标的主导成本。
n_max=15 时 15 个 token 只被接受 ~4 个，73% 的验证工作量浪费在被拒绝的 token 上；
n_max=4 时 ~4 个接受 3.4 个，浪费趋近于零。 - 接受率沿 block 衰减（PR #25173 作者原话 "acceptance decays along the block"）：
位置越深越难预测，n_max=15 把低接受率的尾部（8~15）也扩散出来，全是白算。 - 每条规则都有适用范围：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（跨模型），定义见「背景」。目标模型 模型大小 Bare DSpark（n_max=4） DFlash（n_max=4） MTP（n_max=4） Qwen3.6-27B HauhauCS-Q4_K_P（匹配） 16.33GB 38.7 64~80（1.65~2.07x，0.52-0.71） 78~89.5（2.02~2.31x，0.66-0.75） 84.6~99.8（2.19~2.58x，0.71-0.88） Qwen3.6-27B Huihui-Q4_K（跨） 15.7GB 42.2 81（1.92x，0.61-0.69） 90~112（2.13~2.65x，0.68-0.91） — Qwen3.6-27B i1 Fable Q4_K_S（跨） 14.7GB 41.7 76.7（1.84x，0.51-0.61） 89.6~91.7（2.15~2.20x，0.61-0.74） 83.8~91.9（2.01~2.20x，0.60-0.70） Qwen3.6-35B-A3B MoE-Q4_K_M（跨） 15.85GB 159.5 170~190（1.07~1.19x，0.69-0.79） 196~237（1.23~1.49x，0.65-0.85） 204~226（1.28~1.42x，0.69-0.76） Qwen3.5-0.8B（原生精度） ~0.7GB ~300（估算） 119.6（~0.40x，0.10） — — 注 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 对照）：
方案 短上下文 长上下文(52~62k) 相对长裸跑 裸跑 159.5 t/s 116~122 t/s 1.00x MTP 204~226 t/s 125~129 t/s ~1.06x DFlash 196~237 t/s 121~139 t/s ~1.06x 长上下文 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）。
踩坑纪录
- 草稿上 GPU 溢出 3.4GB 共享内存 → 5~10 t/s 假性低速：排查方法是用 PowerShell 查
Get-Counter '\GPU Adapter Memory(*)\*'，看到 shared usage 数 GB 就是溢出；禁用/启用独显可释放。 - 首次请求极慢（prompt eval 十几秒）：是 kernel JIT / 管线缓存冷启动，第二次请求恢复正常（19→36 t/s），
测速务必跑 2 次取稳态。 - n_max=block_size 是本机不适用（DSpark 15 / DFlash 16）：来自 PR 作者在 CUDA 上的规则（n_max=block_size），
Windows Vulkan 上直接负优化；设 4。 --spec-draft-n-max默认 3：不设也接近甜点；设成 4最佳。- 置信度截断（conf_min/p_min）对本场景无效：PR 作者实测只在并发 ≥8 时有用，单槽无收益。
- 下载坑：
hfCLI 不在 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
-
@Johnalee4 很扎实的实测，特别是 n_max=4 对 CUDA 规则的修正。补三个可以继续挖的点：
-
单通道内存大概率是 prefill 瓶颈。你的配置里 48GB DDR5 单通道，内存带宽只有双通道的一半（DDR5-6000 单通道约 48GB/s，双通道约 96GB/s）。你自己的数据能印证：27B 在 104k 上下文 prefill 只有 352 t/s、67k 是 417 t/s，这远低于 7900 XTX 的正常 prefill 水平——Vulkan 长上下文 prefill 是 host 侧受限的（CPU 喂 token + 内存带宽），不是 GPU 算力问题。补一根内存组双通道，prefill 时间大概率能砍 30-50%，你那个 128k 五分钟的 prefill 能明显缩短。这是整套配置里性价比最高的升级。
-
n_max 规则差异的带宽视角：CUDA 上草稿 verify 开销小（kernel 调度便宜），所以作者 n_max=block_size 的规则成立；Vulkan/AMD 上 verify 要完整跑一遍目标前向，草稿+目标同时驻留 24GB，verify 多算的部分直接挤占 decode 的带宽（7900 XTX 960GB/s 总量不变）。n_max=4 把验证被拒 token 的浪费压到最低，本质是省带宽而不是省算力。这也解释了为什么 DSpark 3.7GB 草稿在长上下文更吃亏——草稿越大，每次 verify 读的权重越多，带宽占用越高。
-
9B coder 的预期管理：你 0.8B 的数据已经说明规律——目标越快，投机收益越小（0.8B 上 DSpark 只有 0.40x，净降速）。9B coder 目标比 27B 快 3-4 倍，预计 DFlash 加速比在 1.1-1.4x 之间，还要吃掉 1.72GB 草稿显存，24GB 卡上性价比一般。想验证值得跑一次，但预期别拉太高。
-
