DeepSeek新技术移植苹果芯片！Mac本地大模型加速60%

DSpark开源才刚满一周，就已经被搬进了苹果电脑。

这套移植方案名叫 mlx-dspark，目前率先跑通了 Gemma-4 12B 和 Qwen3-4B 这两个模型。

装上之后，Mac 上这两个模型的生成速度分别提升了 1.6 倍和 1.4 倍。

更难能可贵的是，它做到了一件大多数移植版本都办不到的事——输出结果与原始模型逐字节保持一致，一个字都不差。

换句话说，速度提上去了，质量却一分不少。

干这件事的人叫 Abdur Rahim，一个业余时间捣鼓开源项目的工程师。DSpark 开源以来的第一个 Mac 原生版本，就是他一个人搞定的。

苹果电脑跑大模型，提速 60%

DeepSeek 在 6 月 27 日开源了 DSpark，官方给出的数据是：在服务端场景下，它能提速 60% 到 85%。

不过，这套技术目前只有数据中心 GPU 上的实现，并没有适配苹果芯片的版本。

mlx-dspark 正是这套技术的第一个苹果芯片原生版本。

DSpark 的思路是，给目标模型配一个更小的“助手”模型。小模型先一口气蹦出几个候选词，目标模型再一次性核对——对的收下，错的打回去重猜。

这一步的成本，在数据中心和苹果电脑上，差别很大。

在数据中心的 GPU 上，核对一批候选词更像包车，坐几个人都是一口价。解码本身就是内存瓶颈，多核对几个词几乎不额外花时间。

苹果芯片则更像打表的出租车——核对的候选词越多，表跳得就越多。

Rahim 实际测了一次，Gemma-4 12B 每多核对一个 token，要多花约 14 毫秒。他把这笔账算成了一个成本模型，得出的结论是：苹果芯片上的速度天花板大约在 2.2 倍左右。

总之，Rahim 把那个“助手”小模型从 HuggingFace 的 checkpoint 里搬了过来，分别配给 Gemma-4 12B 和 Qwen3-4B 这两个目标模型使用。

他还把整个核对流程在 MLX 框架里重新搭了一遍，并将权重做了 4-bit 量化。

结果出来了：在 M4 Pro 上，对比苹果官方的 MLX 工具，Gemma-4 12B 的生成速度从 18.4 tok/s 涨到了约 30 tok/s，提升了约 1.6 倍；Qwen3-4B 则从 52.9 tok/s 涨到了约 73 tok/s，提升了约 1.4 倍。

另外，在 mlx-dspark 里，Rahim 还做了一件大多数移植工作没做的事。

移植版本，也能高精度还原

大多数把大模型搬到本地的版本，只支持贪婪解码——也就是每一步都挑概率最高的那个词。

但 Rahim 在 mlx-dspark 里，把 DSpark 论文里描述的温度采样方法也实现了出来。草稿模型给出候选词，接受概率是 min(1, p/q)，没通过的部分则从残差中重新采样。

他自己核对过，这套流程跑出来的输出，严格等于目标模型在同样温度下会给出的精确分布，而不是打了折扣的近似版本。

大多数投机解码只做贪婪版本，原因很简单：验证贪婪模式的正确性很容易，逐字比对就行。

Rahim 多做的这一步，是自己把采样模式下跑出来的输出分布认认真真地核对了一遍，确认没有走样。

负责核对的目标模型该配哪个精度，也是他自己试出来的一个坑。

如果小模型配的是没经过指令微调的基础版目标模型，蹦出的候选词只有 47% 能通过核对；换成对应的指令微调版本，这个比例直接涨到了 82%。

他还测过把目标模型换成 bf16 精度，结果核对成本涨得比通过率涨得多，反而更慢。所以，目标模型默认留在 8-bit 上是最划算的选择。

负责打前站蹦候选词的小模型，则用的是另一套精度。

草稿模型本身被他做了压缩，4-bit 量化之后只有 1.8 GB，装进内存毫无压力，跑起来还是无损。

最终的结果是，DSpark 不仅实现了加速，也确实把论文里提到的 16% 到 18% 接受率提升，在设备端完美复现了出来。

DFlash 也接了进来，代码任务更快

推文发出后，评论区来了一条留言——DFlash 论文的作者之一 Jian Chen 问，能不能试试他们团队的模型。

DFlash 是 z-lab 今年 5 月发表的论文中提出的另一种投机解码方案，作者团队带头人是 UCSD 助理教授 Zhijian Liu，他同时也是 NVIDIA 的研究科学家。

DFlash 的思路和 DSpark 不太一样。它用一次并行的“块扩散”去噪一整块 16 个 token，而不是像 DSpark 那样一步步带着依赖关系去猜。

Rahim 迅速行动起来。

他用 Jian 自己写的移植脚本，把 z-lab 发布的 gemma4-12B-it-DFlash 接到 mlx-vlm 的 Gemma-4 目标模型上。在同一台 Mac 上，跟自己刚测完的 DSpark 又跑了一轮头对头对比。

在代码和数学任务上，DFlash 整块解码的接受长度能达到 5.95 到 6.20，速度约 36 tok/s，达到约 2.1 倍，跑赢了 DSpark。

但问题也随之而来：DFlash 一次要蹦出一整块 16 个 token，而目标模型未必全部认可，实际能通过核对的只是其中一部分。业内管这个叫“接受长度”——不是每次都能把 16 个全填满。

所以，在开放聊天这种内容不好预测的场景里，接受长度上不去，块填不满，DFlash 的优势就发挥不出来。

DSpark 的 Markov 头正是为了对付同一个毛病而存在的。并行蹦出一整块词，越往后的位置是各自独立算出来的，容易互相不搭调，Markov 头给这些位置之间加了一层依赖关系，专门纠正这个问题。

结果就是，在聊天场景里，DSpark 反而比 DFlash 更快。

而后更新的 mlx-dspark v0.0.3，正式把 z-lab 原版 DFlash 接入了包中，还加了一个参数，可以手动把 DFlash 的有效块长度调短——聊天场景用短块，代码和数学场景仍然用满 16 的整块。

这样一来，同一台 Mac、同一个包，就能同时完成聊天和代码、数学类的任务，再也不需要在 DSpark 和 DFlash 两个项目之间来回搬运了。

Rahim 在推文里说，同样的方法，用在更大的 Qwen3-8B 和 14B 草稿模型上，应该也能跑通。

参考链接：

[1]https://x.com/_ARahim_/status/2072021710602432577

[2]https://github.com/ARahim3/mlx-dspark