到底谁更快：MTP 对比 DFlash：英文居然最重要？

若苗瞬

554人浏览 · 2026-05-31 01:42:58

若苗瞬 · 2026-05-31 01:42:58 发布

文章目录

（零）前言
（一）实际项目测试
（二）偏理论的测试
- （2.1）实测方法
- （2.2）实测结果/结论
（三）分析总结
（四）建议

（零）前言

总算把 MTP 和 DFlash 都跑起来了。
心里希望能把100 token/s的速度，变成300-400 token/s 。那该多好啊😄

硬件环境: Intel i9-12900F + 64GB(DDR4-3000) + 4060Ti-16GB
软件环境: Windows 11 专业版 25H2 和下列LLM后端软件 :

llama.cpp
beellama fork for 【DFlash】
am17an 's llama.cpp fork for 【Gemma4 MTP】

（一）实际项目测试

用企业知识库的UI外壳，我顺手做了一个小助理程序，用它进行的测试。
但企业知识库和个人小助理，都不是最适合这种生成式的场景。它们的输入很大，知识库RAG，网站信息内容，甚至新闻内容本地。而输出相对很小……但好歹是实际的项目。

用户问题:

B站上的前10个热门内容

MTP Draft: 3
DFlash Draft: auto

下面表格中的生成速度 tokens/s，是指从Streaming流式输出开始计时，到回答结束的速度。
显示数字会稍微快于实际生成速度（因为漏了第一个token生成时间）。
但模型混合token和tool时，又会过早的计时，导致显示速度慢很多。
生成前时长包括多轮工具调用，加上LLM自己的PP时间。
理论上PP时间不会从MTP或DFlash中收益，反而会被影响。
这些时间只能作为参考，因为网路环境和服务方响应不会每次相同。
有些模型会直接知道B站是Bilibili，猜到热门是hot，于是直接发指令，省掉2步上万的token。
各个模型可能不是严格的同一个模型，比如MTP和非MTP版本，比如因为显存因素换了模型。
💡这部分都是人看着出结果的，可以相信测试数据（包括DFlash速度）。

（1.1）gemma-4-31B-IQ2M

⚠️：显存不足的边缘，如果显存用尽，则DFlash速度会非常慢，下降到个位数速度。

Prompt Token(总计): 18676
Completion Tokens: 726

模型	生成速度 tokens/s	生成前时长 ms	总时长 ms
原版	21.16	25631	59944
MTP	39.2	21902	39581
DFlash	38.18	25353	44213

（1.2）gemma-4-26B-A4B-IQ2M

Prompt Token(总计): 18xxx-19xxx
Completion Tokens: 8xx

模型	生成速度 tokens/s	生成前时长 ms	总时长 ms
原版	80.97	10650	20507
MTP	100.74	10178	18325
DFlash	102.06	12322	20104

（1.3）Qwen3.6-27B-IQ2M

⚠️：显存不足的边缘，特别是DFlash。

Prompt Token(总计): 186xx
Completion Tokens: 10xx

由于在工具阶段输出了Token，影响了后续速度计算，并只能人工估算生成前时长。

模型	生成速度 tokens/s	生成前时长 ms	总时长 ms
原版	16.61	28735	64855
MTP	25.2	24325	43195
DFlash	20.91	21782	61045

（1.4）Qwen3.6-35B-A3B-IQ3XXS（IQ1M）

Prompt Token(总计): 182xx
Completion Tokens: 7xx-8xx

模型	生成速度 tokens/s	生成前时长 ms	总时长 ms
原版	77.72	15689	27090
MTP	136.07	13774	19265
DFlash	86.23	12971	23208

（1.5）Qwen3.5-9B-Q4

补充个小点的模型，显存肯定够的。
DFlash Q8

Prompt Token(总计): 16xxx-19xxx
Completion Tokens: 7xx-8xx

模型	生成速度 tokens/s	生成前时长 ms	总时长 ms
原版	46.11	10850	27960
MTP	86.72	13831	24218
DFlash	64.78	14340	28478

（1.6）Qwen3.5-9B-Q8

DFlash BF16

Prompt Token(总计): 19272
Completion Tokens: 873

模型	生成速度 tokens/s	生成前时长 ms	总时长 ms
原版	31.69	13802	41350
MTP	72.81	12391	24382
DFlash	56.98	14045	29456

（1.7）实测总结

最快的是Qwen3.6-35B-A3B-IQ3XXS的MTP，大概136tokens / 秒。
总之MTP在稠密模型上提升大些，在混合专家模型上提升较小。
Gemma4和Qwen3.6情况也各不同。

和社区用户讨论的不一样，DFlash没有带来 3x 或 4x 的速度提升……
甚至在同样Qwen模型的测试中，不如MTP的速度。

我非常不解然后咨询了GPT，然后进行了下面的系列理论测试。

（二）偏理论的测试

（2.1）实测方法

目的，针对DFlash上面的奇怪表现，为了排除其它干扰。
测试方式是让LLM输出一段文字，中英文都是同样的提示，看时间和接受率。

$body = @{
    model = "default"
    messages = @(
        @{
            role = "user"
            content = "请写一篇1000字关于春天的文章"  
            # or Write a 3000-word article about spring.
        }
    )
    stream = $false
} | ConvertTo-Json -Depth 10

然后发送给LLM：

Invoke-RestMethod `
    -Uri "http://127.0.0.1:8999/v1/chat/completions" `
    -Method Post `
    -Headers @{
        Authorization = "Bearer sk-xxxx-xxx-xxxx"
    } `
    -ContentType "application/json" `
    -Body $body

得到类似的结果：

choices : {@{finish_reason=stop; index=0; message=}} 
created : 1780141580 
model : Qwen3.6-35B-A3B-UD-IQ1M.gguf 
object : chat.completion 
usage : @{completion_tokens=2237; prompt_tokens=20; total_tokens=2257;} 
timings : @{cache_n=0; prompt_n=20; prompt_ms=319.925; prompt_per_token_ms=15.99625; prompt_per_second=62.5146518715324; predicted_n=2237; predicted_ms=29860.885; predicted_per_token_ms=13.3486298614215; predicted_per_second =74.914055628291; draft_n=1742; draft_n_accepted=390}

（2.2）实测结果/结论

⛔⛔⛔⛔⛔⛔⛔⛔⛔⛔⛔⛔⛔⛔⛔⛔⛔⛔⛔⛔⛔⛔⛔⛔⛔
⚠️已确认 beellama fork 有输出质量问题，下面的DFlash部分结论极可能无效。
⛔⛔⛔⛔⛔⛔⛔⛔⛔⛔⛔⛔⛔⛔⛔⛔⛔⛔⛔⛔⛔⛔⛔⛔⛔

因为不太易读，所以直接说观察到的现象：

草稿接受率非常影响速度，主模型相同的情况下，几乎就是成正比。
大点的量化模型接受率会好很多。
英文比中文接受率高非常多。

Qwen IQ1_M 中文 ≈ 22%，接受率非常低，浪费了很多draft token。
~~Qwen IQ2_M 中文 ≈ 38%，模型只大了点点，接受率提高了大概72%。~~ （未验证生成结果）
~~Qwen IQ2_M 英文 ≈ 64%，英文比中文接受率高了68%。~~ （未验证生成结果）

作为对比，MTP ≈ 80~90%，但设置的--spec-draft-n-max只在2 or 3。再大接受率降低，反而会慢。

为什么社区用户他们测试的情况这么好，逐渐清晰了：

他们都说英文或者字母文字的语言。
测试的环境通常都是4090以上，A100，H100，多卡环境（至少跑Q4级别以上的模型）
有时测试的甚至是上百B的模型，他们真有钱……

（三）分析总结

用小学生都看得懂的语言比喻并总结：

（3.1）MTP vs DFlash

把模型看成一位经验丰富的老师写文章。

MTP：老师提前规划。—— 老师写下当前这句话时，脑子里已经顺便想好了后面几句话。等真正写到后面时，发现和自己刚才想的一样，就直接拿来用。因为“预测的人”和“验证的人”其实是同一个老师，所以接受率通常很高，经常能达到 80% 以上。边想边写会影响一些速度，但收获更大。
DFlash：学生帮老师打草稿。—— 老师在写文章时，旁边有个聪明学生在猜老师接下来会怎么写。
学生能一次猜很多内容，甚至十几步以后。老师写到那里时，会检查学生的草稿，觉得对就采用，不对就丢弃。因为“预测的人”和“验证的人”是两个人，所以接受率天然比 MTP 低。房间里多坐个学生，所以空调零食的开销也更大些。

（3.2）大小模型的区别

主模型大，像经验丰富的老教师。知识广，判断稳定，写出来的内容质量更高。但思考速度慢。
主模型小，像刚毕业的年轻老师。知识没那么全面，但反应很快。写得快，但犯错概率更高。

在 DFlash 里小的草稿模型就是学生。学生越聪明（量化越高），越能猜中老师想法；学生太弱，草稿就会被大量丢弃。学生和老师不存在“量化匹配”，都是越大越聪明越好，而不是Q4学生需要对应Q4老师。

（3.3）Qwen3.6 和 Gemma4 的可能区别

Qwen3.6 更像温和的老师。学生猜对了很多内容时，老师愿意大段采用。尤其英文场景下，接受率很高。
Gemma4 更像谨慎的老师。即使学生写出了草稿，老师也更喜欢自己重新确认。

💡：这个不一定，是主观感觉。社区讨论大多觉得Qwen更加好，我主观觉得Gemma更好。

（3.4）中文和英文的影响

⚠️关于的DFlash部分结论极可能无效。
⚠️这部分很可能是一本正经的胡说八道。
⚠️内容是否可预测，很可能更多受生成方式的影响（少提示词生成文章 vs 多提示词总结内容 vs 编程代码生成）。不思考仅直觉，也觉得应该比用哪种人类语言影响更大。

从语言结构上说，英文通常是说具体内容先，再补充条件。而中文是先说形容，最后再说真正的内容。

英文：我喝了几杯，昨天晚上，在一家不错的店里，和几个朋友。
中文：我昨天晚上，和几个朋友，在一家不错的店里，吃了3两面。

明显中文更难猜…… 而且家大应该知都道，中文顺序的其实响影不阅读。

咳咳，对于DFlash来说：

英文像固定套路作文。老师写：“The spring season is known…”，学生很容易猜到后面是：“for its beautiful flowers”。因为常见搭配很多，选择范围相对比较窄。所以 DFlash 接受率高。
中文像开放式作文。老师写：“春天来临的时候……”，后面可能是：万物复苏，大地回暖，百花盛开，人们走出家门，都说得通……学生猜中了意思，不一定猜中老师最终选择的具体词语。💡 PS: 紫霞猜中了开头，但没猜中结局，因为她不说英文？

所以 DFlash 接受率会明显下降。MTP 受语言影响较小，因为预测和验证本来就是同一个老师完成的，即使中文有很多表达方式，老师自己通常还是知道自己下一步准备怎么写。因此 MTP 在中文和英文之间的差距远小于 DFlash。

（四）建议

显存优先，不要爆显存。如果显存不够用内存，那就别要求任何速度了。
大模型优先，如果显存够，尽量选大一些的量化模型（满足第一条的同时）。
同等体积的MOE模型如果能胜任，则可以不必用慢更多的Dense模型（满足1,2条的同时）。
暂时用MTP，继续观望DFlash或其它新技术。

其它可以参考的信息：

长期实测结果：
《Three Months of Speed-Up Experiments on a 3090 Ti: Autoregressive DFlash MTP for Qwen3.6-27B》
PFlash的论文基础和实现：
但它们的项目我之前编译了没过，后来费尽力气确实Windows下搞不定，还是用WSL2编译了。
但结果一言难尽，很多时候模型都无法正常用，比如不调用工具，统计数据有token但实际未输出。
换了很多模型总算完整跑了一次后。速度只有别的情况十分之一不到，所以暂时不考虑追加太多。
噢，最重要的是，貌似RAG和网站查询类，并不适合prefill。
《PFlash: 10× prefill speedup over llama.cpp at 128K on a RTX 3090》
PS：然后顺便WSL2下跑了vllm，但因为模型不同无法直接对比。
通常vllm更偏向企业部署，估计作者/用户/模型都没考虑这么小的显存情况吧。
量化模型名称里面的简写：
《On llama.cpp quant names》
如何选择适合自己配置的GGUF量化模型：
《Which GGUF is right for me?》