这两天本地大模型圈，估计都被同一个缩写刷屏了：DFlash2。
8月18日，面向 Qwen3.8-27B 的投机解码草稿模型 DFlash2 发布（Hugging Face 上的 incoai/Qwen3.8-27B-DFlash2-GGUF 直接冲上热门）。哔哩哔哩宣传数字越传越猛：“无损提速5倍”“M5 Max 跑70 tok/s”“最高4.6倍”。哔哩哔哩有UP主干脆开了期视频，标题就叫《投机解码还是投机倒把？》。哔哩哔哩
发布一周，B站、小红书、知乎上的实测数据已经够互相印证了。我全翻了一遍，先说结论：DFlash2 是真提速，但社区实测范围横跨 1.26 倍到 4.07 倍，差距大得超出想象；更扎心的是，写代码、跑长上下文这些场景，它可能还不如免费的 MTP。
DFlash2是什么：给模型配了个"抢答搭档"
30秒说清楚。DFlash2 不是新大模型，而是一个投机解码的草稿模型：用块扩散一次猜一整块 token，再让主模型 Qwen3.8-27B 统一验证。验证通过直接采纳，验证错了重来，输出结果和原模型一字不差——这就是"无损"的意思。
公开测试数据里，GSM8K 的 acceptance length 是 5.13～5.39，平均每步能放行5个多 token；Q4_K_M 量化的草稿模型只有 1.1GB，显存开销可以忽略；Apache-2.0 协议，可商用。哔哩哔哩
门槛也有：llama.cpp 主线还没合并，得自己编译 PR#27342 分支。哔哩哔哩SGLang 那边倒是已经把配方加进了 Qwen3.8 Cookbook。
社区实测账本：1.26倍到4.07倍，都是真数
官方演示是 Qwen3.8-27B 在 M5 Max 上跑约 70 tok/s，社交媒体把它和"最高4.6倍加速"拼成了一句疯传的话。一位做 Mac 实测的UP主说得准：tok/s 不是硬件参数，是一条测量结果。哔哩哔哩
这一周社区跑出来的实测，全部是用户自测，不是官方数字：
RTX 4090 24G + llama.cpp：一位玩了两天的用户给出三场景对照——轻聊天从原生 45 提到 90+ tok/s（峰值150，长时间平均回到90），约2倍；深度思考 25 提到 50；但写代码（含工具调用）25 只提到 30，还不如 MTP 的 50。
RTX 6000D + SGLang（NVFP4，262K上下文）：并发1提速 2.81 倍（30.5→85.7 tok/s），并发2 4.07 倍，并发8 3.37 倍。这是目前社区最严谨的一份工程测量，作者自己标注：建议按自己的 workload 重跑。小红书
Mac mini M4 Pro 48G + oMLX：16.9～17.3 → 21.3～23.6 tok/s，只有 1.26～1.37 倍。同模型同4bit，这才是大多数 Mac 用户该对标的结果。哔哩哔哩
同一个 DFlash2，一头4倍出头，一头1.3倍。差在哪？主要三个变量。
变量一：你拿它干什么活
这是最反直觉的一条。投机解码的提速完全取决于草稿"猜中率"。Mac Studio M3 Ultra 上有一份分任务实测：短推理（算术题）95.1 tok/s，草稿接受率 87%；换到 Python 代码审查，掉到 59.2 tok/s，接受率 64.9%；长文写作再掉到 45.4 tok/s，接受率只剩 54.1%。小红书输出越开放，草稿越难猜。
所以那位 4090 用户的结论很实在：干什么活，选什么解码方式。哔哩哔哩评论区还有人在 256K 上下文下测出 DFlash2 不如 MTP，直接弃用；也有人反馈自己机器上草稿采用率极低，“有时候就20几”。个体差异真实存在，别拿任何一个数字当自己的预期。
变量二：上下文有多长
这个坑是小红书用户先踩出来的：同一台机器在 llama.cpp 下，DFlash2 从 32K 上下文开始速度暴跌到 9 t/s；DSpark 从 64K 开始跌到 15 t/s；而不起眼的 MTP，77K+ 上下文还稳在 23～25 t/s。小红书
含义很直接：如果你主要用法是喂长文档、跑长会话、Agent 带长工具上下文，演示里那些亮眼速度基本与你无关。顺带一个测速常识：不标上下文长度的速度对比，都可以打折扣看——128K 和 256K 是两个世界。
变量三：你用什么推理栈
DFlash2 不是孤立存在的，它是推理框架 + 量化格式的组合拳：
llama.cpp 路线要自己编译分支，官方 Vulkan 版没效果；
SGLang 路线跑得最舒服（262K 上下文、并发4倍），但前提是 NVFP4 模型 + FP8 KV cache + 工作站级显存；
AMD 这边一份 W7900 48G 的 ROCm 实测很有代表性：Base 29.4 tok/s，MTP 41.3，DFlash2 最高约 41.6。小红书A卡上 DFlash2 和 MTP 基本打平，想靠它大幅提速的可以先省了折腾；
Mac 路线 oMLX/mlx-dspark 还在成熟中，M4 Pro 实测 1.26 倍，不太值得动手。
想提速的人，按优先级排三条路
第一条路：先领免费收益——Qwen3.8 自带的 MTP。
模型内置的多 token 预测，零成本。Ollama 默认就带了这套参数（这也是同配置下 Ollama 比自己裸跑 llama-server 快15%的原因）；自己跑 llama-server 的，照着加两个投机解码参数即可——有知乎用户在 7900 XTX 24G 上从 35.88 提到 47 t/s（+30%），一次草拟4个平均接受3.96个，而且长上下文不崩。知乎注意：2080Ti 等老卡上有人测出接受率不到40%。哔哩哔哩个体差异要自测。
第二条路：24G显存N卡、以轻聊天写作为主——上 DFlash2。
实测约2倍提速，草稿只多吃 1.1GB 显存，显存富余时 MTP 和 DFlash2 还能同时开。哔哩哔哩代价是自己编译 llama.cpp（社区有预编译包流传，第三方二进制自行评估风险）。写代码、跑长上下文为主的，劝退，理由见上。
第三条路：工作站卡、要并发服务——SGLang + NVFP4。
并发2提速 4.07 倍、并发8吞吐 515 tok/s，但部署门槛最高，适合服务多人，不适合个人玩家。小红书
Mac 用户建议再等等：M4 Pro 实测 1.26 倍基本无感，官方演示的 70 tok/s 是 M5 Max 顶配数字，别代入自己的机器。哔哩哔哩
最后
DFlash2 是真的，但它不是通用提速卡：轻聊天场景接近翻倍，代码场景平庸，长上下文崩盘，A卡和 Mac（暂时）都占不到大便宜。这周社区实测真正推进的一个共识是——tok/s 不是硬件参数，是一条测量结果；不标场景、上下文和推理栈的提速数字，都别全信。
接下来值得盯三个信号：llama.cpp 主线是否正式合并 DFlash2 支持（决定要不要长期养编译分支）；32K+ 长上下文暴跌有没有修复方案；SGLang 的配方会不会覆盖更多模型。前两个落地之前，DFlash2 都还是极客玩具，不是默认选项。
