DFlash 教程：先配对 Draft，再谈加速
DFlash 是一套投机解码工具和块扩散 draft 模型。draft 一次并行提出一块 token，目标模型再验证这些候选。项目提供本地 Transformers、Apple Silicon 上的 MLX，以及连接 vLLM、SGLang 等 OpenAI-compatible 服务的评测入口。
1. Target 和 Draft 必须配对
DFlash 不会把任意小模型变成任意大模型的草稿器。DFlash 2 当前列出的配对是 Muse-Glimmer-30B 和 Qwen3.8-27B。原版 DFlash 还列出 Qwen、Gemma、MiniMax、Kimi、GPT-OSS、Llama 和 GLM 等系列，但每个 target 都有对应 checkpoint。
目标模型仍负责验证。生成是否正确、每轮接受多少 token、最终能否加速，都取决于 target、draft、采样设置和推理后端。只看项目给出的单一速度数字，无法判断你的服务会不会变快。
2. 安装边界
基础 CLI 的安装命令是：
python -m venv .venv source .venv/bin/activate pip install dflash
本地加载模型需要额外依赖：
pip install "dflash[local]"
项目的 0.1.0 配置要求 Python 3.10+。基础依赖固定为 tqdm 4.70.0、datasets 5.0.1 和 requests 2.34.2。Linux 的 local extra 安装 PyTorch 2.13.0 与 Transformers 5.15.0；Apple Silicon 安装 MLX 0.32.0、MLX-LM 0.31.3 和 huggingface-hub 1.27.0。已有推理环境可能与这些固定版本冲突，单独建虚拟环境更省事。
3. 三条运行路径
Linux 上用 Transformers
从官方支持表选定 target 和 draft 后，用 README 给出的 Transformers 命令加载两套权重并运行 benchmark。模型权重和 gsm8k、math500、humaneval、mbpp、mt-bench 等数据集会占用磁盘和网络流量。
Apple Silicon 上用 MLX
MLX 路径适合本机快速验证。若 target 或 draft 是量化模型，官方建议 block_size 不超过 5。当前 MLX 量化矩阵乘内核在更宽的验证批次下可能变慢，因此参数更大不等于吞吐更高。
连接推理服务
服务端路径要求先单独安装并启动支持 DFlash 的 SGLang、vLLM、oMLX 或 llama.cpp。随后把服务的 OpenAI-compatible 地址传给 dflash 的 --base-url。安装 dflash 不会替你安装这些后端，也不会自动加载模型。
4. 用开关对照测真实收益
先关闭 draft，保存一组固定请求。采样温度、top-p、最大输出长度、并发、batch 和停止词都要锁定。至少记录首 token 时间、端到端总时延、每秒输出 token、峰值显存和错误率。
然后只开启 DFlash，重放同一组请求，并补记平均接受长度或接受率。短回复、低接受率、显存紧张或后端验证内核不合适时，draft 的额外开销可能吃掉收益。建议从 128 条接近生产分布的请求开始，不要只用一条演示 prompt 下结论。
5. 版本、费用与验证边界
DFlash 采用 MIT 许可，仓库没有订阅、充值额度、返佣或托管服务销售入口。本轮不做商业隔离。模型下载、GPU、云实例和所选推理服务仍会产生你自己的基础设施成本。
6. 与 EAGLE-3 对比
| 比较项 | DFlash | EAGLE-3 |
|---|---|---|
| Draft 方法 | 块扩散，并行提出 token block | 自回归 draft head |
| 官方入口 | Transformers、MLX 与 OpenAI-compatible 服务 benchmark | 训练、推理、checkpoint 与 SGLang SpecForge 链路 |
| 优先考虑 | 想测试扩散式 draft，或需要 Apple Silicon MLX 路径 | 已有匹配 EAGLE checkpoint，或准备训练 draft head |
EAGLE 官方仓库提供 EAGLE-3 的实现、训练入口和多组 checkpoint。选型时先看目标模型是否有官方匹配权重，再在同一硬件和请求集上做对照。
这里仅补原教程没有展开的事实和边界。安装命令与操作步骤仍以前文为准。
先判断这个项目是否适合你
适合谁用
适合已经自托管大模型、能固定请求集并测量端到端吞吐和延迟的推理团队。先用相同 prompt、采样参数、batch/concurrency 与输出长度分别跑不开启 draft 和开启 DFlash 的基线；同时记录显存、接受长度、首 token 与总时延。
采用建议
DFlash 把扩散式 draft 从论文推进到可调用的本地和服务端工具。是否值得采用只能靠同条件对照实验决定；先从一个官方配对的 target/draft 和 128 条固定请求开始，再决定是否承担额外模型、显存与后端复杂度。
原教程未展开的系统信息
核心功能
块扩散并行起草
draft 模型并行生成 token block，由目标模型验证，目标是减少自回归草稿阶段的串行开销。
架构与数据流
dflash 包负责 CLI、draft/target 配对与 benchmark。Transformers 和 MLX 在本进程加载目标模型及对应 draft；服务端路径把请求发到已加载 DFlash 的 OpenAI-compatible vLLM/SGLang 等服务。checkpoint 与目标模型必须匹配，目标模型仍负责验证，所以输出分布和实际吞吐取决于两者及推理后端。
常见问题
DFlash 2 的 draft 可以配任意目标模型吗？
不可以。DFlash 2 当前明确列出 Muse-Glimmer-30B 和 Qwen3.8-27B；target 与 draft 应按官方支持表配对。
安装 dflash 后会自动安装 vLLM 或 SGLang 吗？
不会。基础包只提供 CLI 与轻量依赖；服务端后端需要单独安装和启动，dflash 再通过 base URL 访问。
Apple Silicon 上的 block_size 越大越快吗？
不一定。官方对量化 target 和 draft 建议 block_size 不超过 5，因为 MLX 当前量化矩阵乘内核在更大验证宽度下会变慢。
如何判断 DFlash 在自己的服务上有收益？
用同一请求集、采样参数、并发和输出长度做开关对照，同时记录首 token、总时延、吞吐、显存和 draft 接受情况。