AREX Feed Article
云端降价的同一周，Unsloth 让 DeepSeek-V4-Flash 在本地跑出了 2 倍速度
参数越来越大，本地还跑得动吗？
7 月 31 日，DeepSeek 把 V4-Flash-0731 推入公开测试。284B 总参数，13B 激活，1M 上下文窗口。各项指标都在说：这是一个云端模型。
同一天，OpenAI 把 GPT-5.6 Luna 的价格砍掉八成。云端大模型的价格战打到这个份上，本地部署还有什么意义？
8 月 6 日，Unsloth AI 给出了一个简洁的回答：DSpark。他们把 DeepSeek 内建的投机解码模块挂载到 GGUF 量化模型上，让 DeepSeek-V4-Flash-0731 的本地推理速度翻了一倍。
120 tok/s，精度纹丝不动
Unsloth 在 NVIDIA B200 上实测了 DSpark 的加速效果。未启用 DSpark 时，模型纯推理速度为 62.6 tok/s。启用后，随着投机 token 数从 1 增加到 3，速度一路攀升：85.8 → 105.4 → 119.7 tok/s，最高加速 1.91 倍。
继续增加投机 token 数到 5，速度反而跌回约 100 tok/s。Unsloth 给出的建议是 --spec-draft-n-max 3，这是当前的最佳平衡点。
关键一句在公告里："no accuracy change"。DSpark 是 DeepSeek 官方内置在 V4-Flash-0731 检查点中的投机解码模块，不是事后打补丁的第三方插件。主模型（verifier）和草稿模型（drafter）共同训练，输出分布完全一致。投机解码的原理决定了它只改变速度，不改变模型输出——主模型验证通过的 token 直接保留，被拒绝的 token 按主模型的分布重新生成。
这意味着同样的 prompt，同样的回答，只是更快了。
猜对了免费，猜错了不亏
投机解码的优雅之处在于它的"无风险加速"机制。传统的自回归生成是一个 token 一个 token 地算，每一步都要等上一步的结果。
DSpark 把这件事拆成两步：一个轻量级草稿模型一次预测 N 个 token，主模型一次性并行验证。验证通过的前 K 个 token 被接受（K ≤ N），剩下 N-K 个被丢弃，主模型从这个位置重新开始。
用更直白的话说：草稿模型负责"猜"，主模型负责"核准"。猜对了，这些 token 近乎免费；猜错了，回到主模型的决策路径上，不付出任何质量代价。这就是"猜对了免费，猜错了不亏"。
Unsloth 的测试数据清楚地展示了这个机制的上限。《AINews》引用的社区测试显示，在 DGX Spark 上，DSpark 将单流解码速度从约 20 tok/s 提升到 28-30 tok/s，多用户并发场景下从 12.2 tok/s 提升到 33 tok/s（单流）和 53-68 tok/s（4 并发聚合）。另一位用户 @yume_arasaki 在双 DGX Spark 配置上已经跑出 80 tok/s，看到这条公告后表示"迫不及待要刷新自己的记录了"。
DSpark 的额外内存开销约为 10 GB。Unsloth 给出的完整内存需求表如下：1-bit 量化需要约 102 GB，2-bit 约 112 GB，3-bit 约 120-145 GB，4-bit 近无损约 172 GB，Q8 完全无损约 179 GB。
一台 DGX Spark 标称 128 GB 统一内存。以 1000 进制换算，实际可用约 130 GB，能容纳 UD-IQ3_XXS（104 GB）加 DSpark 草稿模型（约 10 GB）。日本技术博客 DevelopersIO 的作者 Morishige 实测后确认：2-bit 和 3-bit 量化都能在单台 DGX Spark 上运行，llama.cpp 的推理速度甚至超过了此前专用的 DwarfStar 4 引擎。
Unsloth 的 GGUF 量化本身也有故事。他们的 UD-Q8_K_XL 是唯一完全无损的量化方案：DeepSeek-V4-Flash 的官方权重中，96% 的路由专家以 MXFP4 格式存储，Unsloth 直接按位重打包，不做任何舍入。他们逐张量对比了全部 1328 个张量，与官方权重逐位一致，推理时的 KL 散度约为 0，top-token 一致率 100%。相比之下，其他提供商的量化方案因为对专家层重新量化，引入了 5-30% 不等的权重误差。
200M 次下载背后的两个人
Unsloth AI 由 Daniel Han 和 Michael Han 兄弟于 2023 年创立，总部在旧金山。2024 年夏季入选 Y Combinator S24 批次，完成 50 万美元种子轮融资。
这家 8 人团队的号召力远超其规模。在 GitHub 上积累了 65K 星标，模型下载量超过 2 亿次。他们最早以微调优化闻名，能让 LLM 微调速度提升 2 倍、显存占用降低 70%，随后拓展到推理优化和量化分发。
Daniel Han（CEO）曾在 AMD Advancing AI 2025 和 Microsoft Build 2026 等活动上发表演讲，公开场合多次强调 Unsloth 的开源立场。Unsloth Dynamic 2.0 是他们的第二代 GGUF 量化方案，在精度-体积边界上持续压制同类产品。
Unsloth 的商业模式并不直接向终端用户收费。他们的核心工具链保持开源，收入来自企业支持和定制化服务。这种模式让他们在开源社区积累了极高的信任。当 Unsloth 说某个量化是"无损"的时候，社区会认真对待这个声明。
本地推理在打一场什么仗
在 Unsloth 这条公告之前，DeepSeek-V4-Flash 的本地部署生态已经相当活跃。
llama.cpp 在 6 月 29 日通过 PR #24162 合并了 DeepSeek V4 的核心支持，7 月底又修复了聊天模板的兼容性。但投机解码相关的 PR（#25642、#25683）至今未进入主分支，这意味着普通用户即使下了 DSpark 草稿模型，也无法在 llama.cpp 主线中启用。
antirez 的 DwarfStar 4 是另一个选择。这个专门为 DeepSeek V4 编写的推理引擎原生支持 DSpark 投机解码，在单台 DGX Spark 上冷启动仅需 17 秒——相比之下 llama.cpp 需要 6 分半。但 DwarfStar 4 是专用引擎，无法运行其他模型架构。
vLLM 代表了服务器端推理的另一种思路，但它的优化方向是吞吐量而非单用户延迟，不太适合本地部署场景。
Unsloth 的策略是把 DSpark 做进 GGUF 分发管道里。用户不需要编译特殊分支，不需要切换推理引擎，只要下载对应的 GGUF 文件和草稿模型，就能在 llama.cpp 上直接启用加速。这是让本地部署"可以日用"最关键的一步。降低使用门槛跟提升技术指标同样重要。
社区的反应验证了这一点。拥有 18K 粉丝的 Harley Lewis Foote 转发时说"120 tok/s on your own box, no accuracy drop"。中文社区博主 @geekbb（11.5 万粉丝）说"自己部署 DeepSeek-V4-Flash 的愿望达到了顶峰"。
NVIDIA 的 AI/LLM 开发者关系工程师 @jayrodge15 留言纠正了一个常见误解："I read it as DGX Spark"，暗示很多人把 B200 上的 120 tok/s 数据误读为 DGX Spark 的结果。芬兰开发者 Petri Kuittinen 也在评论区提醒："The claimed 120 token/s was measured on Nvidia B200 = cloud server level GPU, not on Nvidia DGX Spark。"
这种热情与谨慎并存的社区氛围，说明本地 AI 正在从爱好者圈层走向实际可用。当人们开始较真"这个数字是在什么硬件上跑的"，说明他们真的在考虑部署了。
从"能跑"到"好用"还有多远
Unsloth 的 DSpark 公告解决了一个具体问题：让 284B 模型在本地跑得更快。但更深层的信号是，开源大模型的本地部署正在跨过一条关键分界线。
以前的问题是"能不能跑"：内存够不够、兼容支不支持、量化会不会崩。现在的问题变成了"跑得快不快""用起来顺不顺手""长上下文下速度会不会掉"。当讨论从生存问题转向体验问题，意味着本地推理已经完成了从 0 到 1 的跨越。
剩下的路还很长。llama.cpp 主线尚未合并投机解码，DSpark 在 CUDA 上偶发崩溃的 issue 还挂在 GitHub 上，Q8 无损量化需要 179 GB 内存，对于绝大多数个人用户来说仍然遥不可及。但方向已经清楚了：让已有模型跑得更聪明，而不是指望硬件无限变强。
Daniel Han 在 LinkedIn 分享这条公告时用的表述很低调："DSpark's the speculative decoding module attached to the checkpoint itself, not a separate model." 这句话道破了关键——加速不是外挂，是模型自己的原生能力。Unsloth 做的事情，是把这种能力从云端带到了本地。
参考链接：