事件概述
Reddit
用户 /u/No_Shift_4543 在 r/LocalLLaMA 社区开源了 DFlash——
一款专为 Apple Silicon 设计、基于 MLX 运行的投机解码（speculative decoding）实现。该项目在
搭载 64GB 统一内存的 M5 Max 上、使用 MLX 0.31.1 进
行基准测试，针对 Qwen3.5-9B 实现了 4.13 倍的吞吐量提升——
基准速度从 30.96 tok/s 跃升至 127.07 tok/s，在 2048 token 长度
下 token 接受率达到 89.4%。该项目无需对 MLX 进行任何 fork，可
直接在官方 mlx_lm 上运行。
此
次发布采用了经过修订的基准测试方法：作者将此前自
定义的 Python 循环替换为官方 mlx_lm.stream_generate 作为基准，并坦承
旧方法曾导致加速数据虚高。当前结
果取 3 次运行的中位数，每次测试之间设
有 10 秒冷却间隔。
为何值得关注
长 期以来，投机解码几乎是服务器端的专属 优化手段——NVIDIA 硬件、vLLM、大型数据中心。而 DFlash 将目 光投向了日益壮大的本地推理群体：那些在 Apple Silicon 上运行模型的工程师。这一场景的约束条件与服务器端截然不同：统一内存 架构、带宽受限的执行环境，以及没有独立显 存。4.1 倍的加速数据对于 10B 以 下模型而言意义重大，尤其适用于以延迟为首 要瓶颈的交互式编程助手和本地 agent 循环场景。
89% 的接受率——较上 一版本的约 82% 有所提升——是衡量生产可用性的核心指标。一旦接 受率低于 80%，投机解码的额外开销就会在长文本生成场景中 侵蚀性能收益。此次提升源于 bf16 计算路径中的数值精度修复，而 非架构层面的变更——这表明此前的基准测试低 估了基准线性能和开销本身。
不同模型规模之间的性能差异，是 任何考虑将其用于部署的工程师必须重视 的关键警示。27B-4bit 模型仅实现 1.90 倍加速（ 32.35 → 62.78 tok/s），35B-A3B-4bit 模型则达到 1.69 倍（142.12 → 240.21 tok/s）。作者将 这一差距直接归因于一个结构性限制：当量化目标模型本 身已经足够快时，bf16 草稿模型反而成为瓶颈。面向 大型量化模型的工程师应据此调整预期。
技术细节
DFlash 通过块扩散（block diffusion）方式，使 用一个小型草稿模型并行生成 16 个 token，再 由目标模型在单次前向传播中完成全 部 16 个 token 的验证。只有通过目标模型验证的 token 才会被提交—— 作者将这一过程定义为无损（lossless）。
该架构专 门针对 Qwen3.5 的混合 GatedDeltaNet + attention 设计进行了优化。其 核心机制是「tape-replay 回滚」：一个自定义 Metal kernel，仅对 已接受的步骤在 GatedDeltaNet 循环状态中进行重 放，从而避免完整的 checkpoint 保存与恢复开销。作者认为这正是在长 文本生成中维持高接受率的关键所在。纯 attention 架构模型（如 Qwen3、Gemma）同样受支持，但无 法从 tape-replay 机制中获益。
一个值得关注的工 程发现：在统一内存硬件上，针对 batched-GEMV、fused gated SiLU 以及自定义 SDPA 所编写的 Metal kernel，性 能反而逊于原生 MLX 实现。作者由 此得出结论：在带宽受限的芯片上，数值精度与算法正确性比计算层 面的优化更为重要——这对于习惯了 GPU kernel 调 优的工程师而言是一个反直觉的结果。
其他实现细节如 下：
- 针对序列长度 ≥ 1024 token 的长上下文验证，采用 J IT 两遍 SDPA kernel
- 在投机解码各周期中保持 bf16 路径的数值稳定性
- 仓库中提供了 1 024、2048 和 4096 token 长度下的完整测试结果
- 无需 自定义 MLX fork，直接运行于官方 MLX 0.31.1
基准测试 汇总（2048 tokens，M5 Max 64GB）
- Qwen3.5-4B：53.74 → 219. 83 tok/s（4.10 倍，接受率 89.3%）
- Qwen3.5-9B：30.96 → 127.07 tok/ s（4.13 倍，接受率 89.4%）
- Qwen3.5-27B-4bit：32.35 → 62.78 tok/s（1.90 倍，接受 率 89.1%）
- Qwen3.5-35B-A3B-4bit：142.12 → 240.21 tok/s（1.69 倍，接受率 88 .7%）
后续关注点
作者公布的 路线图包括全 attention 模型优化与草稿模型压缩——这两 项工作将直接针对目前已识 别的两大主要局限：量化目标模型上收益不足，以及非 GatedDeltaNet 架构无法从 tape-replay 中获益。
值得关注 MLX 上 游的反应。Apple 的 MLX 团队历来对 能够显著提升吞吐量的社区贡献保持积极回 应。若 DFlash 的方案具备可复现性，tape-replay 机制或块 扩散草稿策略的相关实现，有望在 30 至 60 天内出现在 MLX 官 方版本中。
Qwen3.5 模型系列是这一方案的关键依赖。 阿里巴巴对 GatedDeltaNet 混合架构的持续迭代，将决 定此项优化能否保持长期相关性，还 是需要随之进行架构层面的重构。未来版 本中任何对 Qwen 循环状态设计的调 整，都将要求对 tape-replay kernel 进行相应更新。
社区在 M3 和 M4 硬件上的复现结果，将是 最直接的验证信号。M5 Max 代表了当前 Apple Silicon 的 顶级规格；而在 M3 Pro 或搭载较 小统一内存的 M4 上的测试结果，将有助于 厘清带宽约束是否线性扩展，以 及该优化方案是否存在内存容量下限。