DSpark 杀入本地推理，Unsloth 让 DeepSeek-V4-Flash 跑出 2 倍速，120 tokens/s 零精度损失

8 月 6 日，Unsloth AI 宣布为的 GGUF 量化版本启用 DSpark 投机解码支持，本地推理速度提升约 1.4–2 倍，且输出精度不变。在 B200 GPU 上，该模型从原先的约 60 tokens/s 直接跃升至 120 tokens/s。

DSpark 是 DeepSeek 在 6 月底公开的投机解码算法，通过附加一个小型草稿模型一次预测多个 token、再由主模型在单次前向传播中批量验证，用内存换速度。

Unsloth 将 DSpark 草稿模型打包为 GGUF 格式并在 llama.cpp 中集成，用户只需额外下载约 10GB 草稿文件、添加一行启动参数即可启用。已默认开启 DSpark。

单颗 DGX Spark 也能跑，社区直呼"不用订阅了"

Unsloth 公告发布后，陆续有用户报告实测结果。确认在单颗 DGX Spark 上 DSpark 运行顺畅。此前 AI 博主 Mia 整理的基准测试显示，2× DGX Spark 集群跑 DeepSeek-V4-Flash-0731 可达约 82 tokens/s；DSpark 将 B200 上的解码速度从 60 tokens/s 推至 120 tokens/s，社区正测试 DGX Spark 上能兑现多少提速。

在 DSpark 发布前一天公开表示，在 2× DGX Spark 上跑 V4-Flash-0731 后"可能不再需要订阅任何 AI 服务"。另一位用户回复 Unsloth 称自己双卡 Spark 此前已跑到 80 tokens/s，"迫不及待想打破自己的纪录"。

中文科技博主（粉丝 11.5 万）发推称"自己部署 DeepSeek-V4-Flash 的愿望达到了顶峰"，该推获得 27 条回复、近 7,000 次浏览。

独立开发者则点出一个悖论："DeepSeek 开源了一个本地跑得如此快的模型，以至于他们自己的 API 定价变得难以自圆其说。"

AI 从业者呼吁社区尽快搞定双卡 Spark 的 DSpark 配方，24 小时内获 21 次点赞和 10 次书签。Plainsupport Agent Orchestration 团队负责人评论道："Unsloth 是我们从未意识到自己需要的本地 LLM 救世主。"

V4-Flash 发布仅六天，从 API 挤爆到本地起飞

DeepSeek 于 7 月 31 日正式发布，这是 V4-Flash 的正式版本，取代了此前的预览版。该模型拥有 284B 总参数（13B 活跃参数），支持 1M token 上下文窗口，在 Terminal Bench 2.1（82.7 分）、DeepSWE（54.4 分）、NL2Repo（54.2 分）等多项基准上超越了参数规模更大的 DeepSeek-V4-Pro（预览版）。

8 月 4 日，编程智能体平台因"前所未有的调用量"出现容量问题，公开致歉并表示正在修复。同日，发布指南教用户用 2× DGX Spark 集群本地运行 V4-Flash-0731。

8 月 5 日，AI 博主整理了 DGX Spark 硬件上的最佳模型清单，2× Spark 跑 V4-Flash-0731 被列为"甜蜜点"配置。

DSpark 论文由 DeepSeek 团队于 7 月 6 日上传至 arXiv（），声称在生产环境中实现了 60–85% 的单用户生成速度提升。llama.cpp 项目随后通过集成了 DSpark 支持。

Unsloth 的 8 月 6 日公告是这一链条的最后一环——将 DSpark 从论文和服务器端技巧变成任何人在本地可以一键启用的功能。

不算力、不量化、不蒸馏——投机解码如何做到"无损提速"

DSpark 提速的机制与量化、蒸馏、剪枝等常见加速手段完全不同。它不修改模型权重，输出与原始模型逐字节一致。

核心逻辑是"投机解码"：附加一个轻量级的草稿模型（drafter），由草稿模型一次性预测接下来若干个 token，主模型在单次前向传播中并行验证全部候选 token，保留最长的正确前缀，丢弃错误部分。原本需要 N 次前向传播才能生成的 N 个 token，现在可能 1 次就完成。

DSpark 在传统投机解码基础上做了两个关键改进。其一，在并行草稿骨干网络上附加一个轻量序列头，让每个 token 能瞥见前一个 token 的信息，从而解决并行草稿模型的"后缀衰减"问题：模块尾部的 token 因缺乏上下文依赖而被频繁拒绝。效果是接受的 token 块比此前最优方法长 16–30%。其二，引入置信度调度验证：在高并发负载下，验证器根据每个 token 的"存活概率"动态裁剪验证长度，跳过必定被拒绝的尾部 token，避免浪费 GPU 批次容量。

Unsloth 将 DSpark 草稿模型导出为两个 GGUF 文件：Q8_0 量化版（10.9GB）和 BF16 无损版（11.3GB）。在 llama.cpp 中通过 --spec-type draft-dspark --spec-draft-n-max 3 即可启用，Unsloth 推荐 n-max=3 为最佳默认值，对应约 1.9 倍解码加速。代价是额外约 10GB 内存/显存占用。对于 128GB 内存的机器，搭配 3-bit 量化的主模型（IQ3_XXS，约 103GB）和 DSpark Q8_0 草稿模型，总量约 114GB。

120 tokens/s 改写本地推理的性价比方程

在此次 DSpark 落地之前，本地推理的速度劣势是自托管方案最大的软肋。AI 博主 Mia 在 8 月 5 日整理的实测基准显示，2× DGX Spark 集群跑 V4-Flash-0731 的无 DSpark 速度约为 82 tokens/s，与云 API 的响应延迟在同一量级，但硬件投入门槛令多数个人开发者却步。

Unsloth 的数据显示，DSpark 在 B200 GPU 上将解码速度从约 60 tokens/s 推至约 120 tokens/s。更关键的是，DeepSeek-V4-Flash-0731 采用 MIT 许可证，Unsloth 的 GGUF 量化方案做到了 Q8_K_XL（162GB）完全无损。团队逐张量对比了全部 1,328 个张量，KL 散度约等于零，top-token 一致率 100%。

的评论直指核心矛盾：模型开源且本地推理速度逼近 API 服务，API 按 token 计费的商业模式面临结构性压力。DSpark 论文披露的数据也印证了这一趋势：在生产环境中，同吞吐量下每个用户的实际生成速度快了 60–85%，此前需要排队等待的交互式场景因此获得显著改善。

本地推理的速度门槛，被一个 10GB 的草稿模型击穿了

DSpark 不需要新硬件、不需要重新训练、不修改模型权重。它只要求多下载约 10GB 文件，多敲一行启动参数。投机解码从论文走向 llama.cpp 主线、再被 Unsloth 打包为即用 GGUF 的过程，将本地推理从"能跑"推到了"跑得爽"的阶段。DeepSeek 开源了模型权重，Unsloth 开源了提速方案，两件事加起来，自托管 AI 的总拥有成本在速度维度上与云 API 正面交锋。