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

时间:2026-07-04 08:15:41 来源:互联网

DSpark开源仅一周,便被独立开发者Abdur Rahim移植到Mac,使Gemma-4 12B和Qwen3-4B的生成速度分别提升1.6倍和1.4倍,且输出与原模型逐字节一致。

DSpark开源刚满一周,就顺利运行在了苹果电脑上。

这个移植版本被命名为mlx-dspark,它驱动的是Gemma-4 12B和Qwen3-4B两个模型。

安装后,这两个模型在Mac上的生成速度分别实现了1.6倍和1.4倍的提升。

img_6a4850acd232330.webp

更难得的是,它完成了一项大多数移植版本无法企及的任务——输出结果与原模型逐字节相同,毫不偏差。

换句话说,提速的同时,输出质量完全没有折损。

这项工作的作者是Abdur Rahim,他业余时间热衷开源项目,DSpark以来的第一个Mac原生版本完全由他一人独立完成。

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

针对DeepSeek于6月27日开源的DSpark,官方宣称在服务端场景下能实现60%到85%的提速。

但该技术当时仅部署于数据中心GPU,尚未推出适配苹果芯片的版本。

mlx-dspark正是这项技术的首个苹果芯片原生实现。

img_6a4850ace644d31.webp

DSpark的核心思路是:为目标模型配备一个较小的辅助模型,先由小模型快速生成若干候选词,再由目标模型一次性校验,通过的保留,未通过的退回重猜。

这一步骤在数据中心和苹果电脑上的成本结构存在差异。

在数据中心GPU上,校验一批候选词类似包车——无论乘坐几人都是固定费用,解码本身受内存带宽限制,多校验几个词几乎不增加额外时间。

苹果芯片则更像打表的出租车,校验的候选词越多,计费越高。

Rahim实测发现,Gemma-4 12B每多校验一个token,需额外耗费约14毫秒。他据此建立了成本模型,推断苹果芯片上的速度极限约为2.2倍。

随后,Rahim将辅助小模型从模型仓库中取出,分别配置给Gemma-4 12B和Qwen3-4B这两个目标模型。

他还把校验流程在MLX框架中重新搭建,并将权重量化至4-bit。

img_6a4850ad02d6932.webp

最终,在M4 Pro上对比苹果官方MLX工具:Gemma-4 12B的生成速度从18.4tok/s提升至约30tok/s,增幅约1.6倍;Qwen3-4B从52.9tok/s提升至约73tok/s,增幅约1.4倍。

此外,在mlx-dspark中,Rahim还完成了一项大多数移植工作未涉及的突破。

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

多数本地化大模型版本仅支持贪婪解码,即每一步只选取概率最高的词。

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

他亲自验证,该流程产生的输出严格等同于目标模型在相同温度下给出的精确分布,并非近似版本。

大多数投机解码仅实现贪婪模式,因为验证其正确性只需逐字比对,相对简单。

Rahim额外做的工作,是自行核对了采样模式下的输出分布,确保没有走样。

负责校验的目标模型该使用何种精度,是他亲身试出的一个关键点。

若小模型搭配未经指令微调的基础版目标模型,候选词通过率仅为47%;改用对应的指令微调版本后,通过率升至82%。

他还测试过将目标模型换成bf16精度,发现校验成本增长远高于通过率提升,反而拖慢速度,因此目标模型保持8-bit最为经济。

而负责预生成候选词的小模型则采用另一种精度策略。

草稿模型本身经过压缩,4-bit量化后仅1.8GB,装入内存毫无压力,运行无损。

最终,DSpark不仅实现了加速,还将论文中提到的16%至18%的接受率提升成功在设备端复现。

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

推文发布后,评论区出现一条留言——DFlash论文作者之一Jian Chen询问能否尝试他们团队的模型。

DFlash是z-lab于今年5月提出的另一种投机解码方案,团队带头人Zhijian Liu是UCSD助理教授,同时也是研究科学家。

img_6a4850ad12bfe33.webp

DFlash的思路与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。

img_6a4850ad2151e34.webp

但DFlash需一次性生成16个token,目标模型未必全部认可,实际通过校验的只是其中一部分,业内称之为“接受长度”,并非每次都能填满16个。

在开放聊天这类内容难以预测的场景中,接受长度较低,块无法填满,DFlash的优势难以发挥。

DSpark的Markov头正是为解决这一问题而设计:并行生成整块词时,后续位置各自独立计算,容易不协调,Markov头在这些位置间增加了依赖关系,专门纠正此问题。

结果,在聊天场景下,DSpark反而比DFlash更快。

img_6a4850ad3144a35.webp

随后更新的mlx-dspark v0.0.3正式将z-lab原版DFlash集成到包中,并新增参数,允许手动调节DFlash的有效块长度:聊天场景使用短块,代码和数学场景仍采用满16的整块。

至此,同一台Mac、同一个包即可同时完成聊天与代码、数学类任务,无需在DSpark和DFlash两个项目间反复切换。

通过整合DFlash方案,mlx-dspark现可同时处理聊天与代码任务,速度提升最高达2.1倍,且输出精度无损,未来有望扩展至更大模型。