DeepSeek开源一周被移植苹果芯片：本地推理的”苹果时刻”来了？

DeepSeek开源一周被移植苹果芯片：本地推理的”苹果时刻”来了？

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

移植版本叫mlx-dspark，跑的是Gemma-4 12B和Qwen3-4B这两个模型。装上之后，这两个模型在Mac上的生成速度分别提了1.6倍和1.4倍。

更难的是，它做到了大多数移植版本做不到的一件事——输出和原模型逐字节相同，一个字都不差。

也就是说，速度换来了，质量一点没丢。

苹果芯片跑大模型，为什么这么难？

先说背景。

DeepSeek在6月27日开源的DSpark，官方给出的数字是服务端场景下能提速60%到85%。不过这套技术当时只有数据中心GPU上的实现，没有适配苹果芯片的版本。

为什么？

因为数据中心GPU和苹果芯片的架构逻辑完全不同。

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

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

Abdur Rahim（一个业余时间捣鼓开源项目的工程师）实测过，Gemma-4 12B每多核对一个token，要多花约14毫秒。他把这套账算成了一个成本模型，得出的结论是：苹果芯片上的速度天花板在2.2倍左右。

投机解码：让两个模型”打配合”

DSpark的核心思路是投机解码（Speculative Decoding）。

简单说，就是配一个更小的模型给目标模型”打下手”。小模型先一口气蹦出几个候选词，目标模型再一次性核对，对的收下，错的打回去重猜。

这一步的成本，在不同硬件上不一样。

数据中心GPU的内存带宽高，多核对几个词几乎不增加成本。但苹果芯片的统一内存架构，每多核对一个token，都要付出实打实的时间代价。

Rahim把这套流程在MLX框架里重新搭了一遍，权重量化成4-bit。结果，在M4 Pro上，对比苹果官方的MLX工具：

– Gemma-4 12B的生成速度从18.4tok/s涨到约30tok/s，是原来的约1.6倍 – Qwen3-4B从52.9tok/s涨到约73tok/s，是原来的约1.4倍

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

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

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

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

多数投机解码只做贪婪版本，是因为验证贪婪模式的正确性很简单，逐字比对就行。Rahim多做的这一步，是自己把采样模式下跑出来的输出分布核对了一遍，确认没有走样。

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

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

DFlash是z-lab今年5月发的论文里提出的另一种投机解码方案。思路和DSpark不太一样，它用一次并行的”块扩散”去噪一整块16个token，而不是像DSpark那样一步步带着依赖关系去猜。

Rahim迅速动手。

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

结果：

– 代码和数学任务上，DFlash整块解码的接受长度能到5.95到6.20，速度约36tok/s，达到约2.1倍，跑赢了DSpark – 但是，DFlash一次要蹦出一整块16个token，而目标模型未必全部认可，实际能通过核对的只是其中一部分 – 在开放聊天这种内容不好预测的场景里，接受长度上不去，块填不满，DFlash的优势发挥不出来 – DSpark的Markov头正是为了对付同一个毛病存在的，并行蹦出一整块词，越往后的位置是各自独立算出来的，容易互相不搭调，Markov头给这些位置之间加了一层依赖关系，专门纠正这个问题 – 结果就是，在聊天场景里，DSpark反而比DFlash更快

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

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

本地推理的”苹果时刻”

这件事的意义，不只是”Mac跑大模型更快了”。

它标志着本地推理正在从”能用”走向”好用”。

过去，本地跑大模型的痛点是什么？

1. 速度慢 – 没有GPU加速，生成速度感人 2. 质量差 – 量化后输出质量下降明显 3. 场景单一 – 只能跑特定模型，不能灵活切换

mlx-dspark解决了什么？

1. 速度 – 1.6倍到2.1倍的提升，已经接近”可用”门槛 2. 质量 – 逐字节相同，质量零损失 3. 场景 – 同一个包支持聊天和代码，不用来回切换

更重要的是，这套技术是开源的。

Rahim一个人，一周时间，就把DeepSeek的数据中心技术移植到了苹果芯片。这说明什么？

说明本地推理的技术门槛，正在快速降低。

对行业的三个判断

1. 本地推理将成为AI应用的”第二战场”

过去几年，AI应用的竞争焦点在云端。谁的服务更快、更便宜、更稳定，谁就能赢。

但从mlx-dspark的出现可以看出，本地推理正在成为新的竞争维度。

当本地推理的速度和质量接近云端，用户会有更强的动力把计算留在本地。隐私、延迟、成本，这些本地推理的天然优势，会被进一步放大。

2. 开源生态正在加速技术扩散

DSpark开源一周，就被移植到苹果芯片。这个速度说明什么？

说明开源生态的技术扩散速度，远超我们的想象。

一个数据中心的技术，一周内就能被移植到消费级硬件。这意味着，技术壁垒正在快速消失。

未来的竞争，不再是”谁有这项技术”，而是”谁能把这项技术用好”。

3. 苹果芯片的AI潜力被低估

苹果芯片的统一内存架构，一直被诟病不适合跑大模型。

但mlx-dspark证明，只要算法适配得当，苹果芯片也能跑出不错的效果。

更重要的是，苹果芯片的功耗优势。数据中心GPU跑大模型，功耗几百瓦。苹果芯片跑同样的模型，功耗可能只有几十瓦。

当能效比成为关键指标，苹果芯片的AI潜力，可能被严重低估了。

写在最后

mlx-dspark的出现，不是本地推理的终点，而是起点。

它证明了一件事：本地推理，正在从”能用”走向”好用”。

当速度提升1.6倍到2.1倍，质量零损失，场景灵活切换，本地推理的”苹果时刻”，可能真的来了。

一个人，一周时间，就把数据中心技术移植到了消费级硬件。这说明，技术壁垒正在快速消失。

对于开发者来说，这是一个好消息。

对于用户来说，这也是一个好消息。

因为当技术门槛降低，选择变多，最终受益的，是每一个使用AI的人。