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

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：DeepSeek新技术移植苹果芯片 Mac本地大模型提速60%要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题