Qwen3.8-27B 开源这几天，Mac 圈子的话题已经从"能不能跑"变成了"怎么跑得快"。毕竟 27B、4-bit 量化、十六二十 GB 内存就能装下，还带图片理解和 MTP，确实是这两年最适合塞进 Mac 的模型之一。
但很多人装完就卡在一个尴尬的位置：能跑，可十几二十 token 每秒，干点正事就开始嫌慢。于是这周社区里最热闹的，就是给 27B 上"投机解码"加速。MTP、DFlash2、DSpark，三个名字来回被提，提速倍数一个比一个喊得高。
我把这几天小红书、知乎、B 站上的实测和官方数据捋了一遍，给你一个大实话版本：这三条路提速逻辑一样，但脾气完全不同，选错了不是不快，是直接翻车。
先说清楚：三条路其实是同一个思路
MTP、DFlash2、DSpark 本质都是"投机解码"——让一个小一点的草稿模型先猜后面好几个 token，大模型一次性批量验证，猜对的直接采纳，省掉大模型一个一个往外蹦的时间。所以它们都不改变输出质量，只改速度，这点可以放心。
区别在草稿是谁、怎么猜：
MTP 是 Qwen3.8 自带的原生多头，权重就在官方模型里，属于"标配"。优点是兼容最好、额外占用小；缺点是提速温和，官方基准里平均接受长度 4.28。
DFlash2 是 Inco AI 和 Z-Lab 这两天刚放出来的专用草稿模型，1.92B、约 3.85GB，走"块扩散"路线，一次并行猜一整块。官方在 H200 单并发下测出 2.7~3.4 倍吞吐，五项基准平均接受长度 4.80，比 MTP 和 DSpark 都高。小红书这是目前纸面和短上下文爆发最强的一条路。
DSpark 是社区更早期的草稿方案，接受长度 3.62，属于"DFlash2 出来之前的过渡选项"，现在基本可以不优先看了。
提速归提速，先泼一盆冷水：长上下文是 DFlash2 的死穴
这是我最想提醒的一点，也是很多人只看"提速 3 倍"就冲、然后回来骂街的地方。
有用户用 llama.cpp 把三种加速在同一个 27B 上拉通测了一遍，结论很扎心：DFlash2 从 32K 上下文开始，速度直接从三十多 token 暴跌到 9 token/秒；DSpark 从 64K 开始掉到 15；而 MTP 一路拉到 77K+ 都没崩，只是提速幅度小，稳在 23~25。小红书
Mac 这边也没好到哪去。一位 M4 Max（128GB）用户用 Ollama + MLX 后端、nvfp4 量化加 MTP 做了完整的上下文深度扫描：短上下文 63.1 token/秒，4K~16K 稳在 42 上下，31K 开始断崖式掉到 11.3，63K 也只有 12.1。他的原话结论：16K 以内常规问答放心用，当编程助手"活能干但节奏偏慢"。哔哩哔哩
原因不复杂：草稿模型猜得准不准，很依赖上下文状态，块扩散这种激进猜法在短上下文里命中率极高，上下文一长就开始露馅，猜得越多、被主模型驳回得越多，反而白算。而且长上下文本身的内存账也不好算——Qwen3.8 用的是"3 层 linear attention + 1 层 full attention"的混合架构，64 层里只有 16 层是 full attention，传统 KV Cache 估算公式直接套会得出误导性的数字，目标上下文能不能装下，得按自己机器的实测来。知乎
所以判断标准其实很简单——看你平时把上下文用到多长。日常问答、写代码、跑 Agent，多数时候上下文也就几 K 到十几 K，那 DFlash2 的爆发你能吃满；可你要是拿它啃长文档、整本代码库、几十 K 的上下文，那 168 token/秒的爽感跟你没关系，老老实实 MTP。
顺带说下"168 token/秒"是哪来的：有 M5 Max 用户实测 DFlash2 飙到 168，MTP 大概 70~90。但这个数字有两个前提——一是 M5 Max 这种内存带宽拉满的顶配，二是短上下文。换成 M4 或者上下文一长，完全不是这个数，别拿顶配峰值当自己的预期。小红书
三个没人明说、但很容易踩的坑
第一个坑：MTP 的草稿千万别跟着量化。有 MacBook Air M5 24G 用户实测过，同一个底子，草稿用 fp16 是 15 token/秒，草稿量化后只剩 12，干脆不开 MTP 反而还有 9——等于量化草稿把接受率打下来了，白猜一轮，越优化越慢。小红书看到"位数更低=更快"就上头的，这次会翻车。
第二个坑：草稿模型是额外占内存的。27B-4bit 主体大概 15GB、24G 的 Mac 本来就踩着线跑（有人实测主体约 15GB、加 256MB 的 MTP 草稿，峰值到 18GB 上下），你要是再上 DFlash2，草稿还要再吃约 3.85GB，24G 直接就更紧了，一个不留神就顶到内存上限被中止。小红书所以小内存机器上，MTP 那个轻量多头反而是更现实的选择，DFlash2 更适合 48G 起步、内存有余量的机器。
第三个坑：很多运行器里，MTP 默认是不开的。有人用 oMLX 跑 27B-4bit，默认只有 17.9 token/秒；去 Models 页把主模型和 MTP 草稿模型两个都下好，再到 Model Settings 里打开 VLM MTP 开关、把 Drafter 指到 MTP 草稿，速度直接到 26.4，提升 47.5%。小红书也就是说，"我没开加速"和"我开了没效果"之间，常常只差一个没找到的开关。oMLX 0.6.3rc2 起也适配了 DFlash2，想折腾的可以直接在设置里换草稿。
按你的情况，直接对号入座
把这几天的实测和讨论归拢一下，其实可以按内存和用法切成四档：
24G 内存、日常用：就老实用 27B-4bit + 原生 MTP，草稿留 fp16。15 token/秒上下，够用，别折腾。想再稳一点选 oQ3.5e 这类量化。
32G、想兼顾速度：4bit 主体 + MTP 是安全牌；如果上下文都在 16K 以内、又馋 DFlash2 的速度，可以试，但留意内存余量。
48G 及以上、追求爆发：DFlash2 随便上，短上下文提速最猛。用 oMLX 的话 0.6.3rc2 已适配，4bit 草稿、block size 别超过 5。小红书
主力是长上下文（32K+）：别犹豫，MTP。它是唯一长上下文不崩的路线，速度不惊艳但靠谱。
最后算笔账：提速到底在帮你省什么
本地跑 27B 真正的爽点，其实是"不再按 token 付费"。有部署文章算过：一个每月 3000 万输入、750 万输出 token 的用量，走云 API 按高峰价是一笔持续的月账单；而本地最大的持续成本是电费——一台平均 100W、全天开机的机器，一个月约 72 度电。知乎
当然这不是说本地一定更省，得看你本来有没有这台机器、调用量多大、当地电价。更现实的做法是混合路由：稳定、重复、涉密的任务扔给本地 27B，复杂、突发、要顶级能力的回退云端。知乎在这个前提下，你给 27B 上加速，本质是在扩大"本地能接住的活"的范围——速度上去了，原本嫌慢只能丢给云端的任务，现在本地也能消化，账单才真的往下走。
接下来值得盯的信号
DFlash2 刚出没几天，生态还在快速适配，SGLang、vLLM、llama.cpp、oMLX、MLX 都已经或正在接，但各家成熟度不一样，建议用之前先看对应工具的最新分支。另外它在 Mac + MLX 下的长上下文表现，目前样本还少，32K 崩的那个数据来自 llama.cpp 侧，MLX 上会不会同样崩、崩在哪个点，值得等更多人实测。
一句话收尾：想要爆发选 DFlash2，想要省心、尤其是长上下文，就 MTP；24G 小内存别硬上重草稿。 提速这事，方向选对比数字好看重要得多。
