DeepSeek 开源一周就被搬进了 Mac,一个业余工程师干的事

📡 AI新闻 2026-08-07 约 14 分钟阅读

DeepSeek 开源一周就被搬进了 Mac,一个业余工程师干的事 DeepSeek 的 DSpark 技术开源才一周,就被人移植到了苹果电脑上。 移植版叫 mlx-dspark,跑的是 Gemma-4 12B 和 Qwen3-4B 两个模型。装上之后,Mac 上的生成速度分别提了 1.6 倍和

💡 你将学到

DeepSeek 开源一周就被搬进了 Mac,一个业余工程师干的事 DeepSeek 的 DSpark 技术开源才一周,就被人移植到了苹果电脑上。 移植版叫 mlx-dspark,跑的是 Gemma-4 12B 和 Qwen3-4B 两个模型。装上之后,Mac 上的生成速度分别提了 1.6 倍和

DeepSeek 开源一周就被搬进了 Mac,一个业余工程师干的事

DeepSeek 的 DSpark 技术开源才一周,就被人移植到了苹果电脑上。

移植版叫 mlx-dspark,跑的是 Gemma-4 12B 和 Qwen3-4B 两个模型。装上之后,Mac 上的生成速度分别提了 1.6 倍和 1.4 倍——Gemma-4 12B 从每秒 18 个 token 涨到约 30 个,Qwen3-4B 从 53 涨到约 73 个。

翻译成人话:以前 Mac 上跑大模型像挤牙膏,现在至少是水龙头开了一半。

更狠的是,它做到了大多数移植版本做不到的事——输出和原模型逐字节相同,一个字不差。速度换来了,质量没丢。

动手的人叫 Abdur Rahim,一个业余时间捣鼓开源项目的工程师。DSpark 开源后的第一个 Mac 原生版本,一个人搞定的。

给大模型配个"打下手"的帮手

DSpark 的原理不复杂:给目标大模型配一个更小的模型打下手。小模型先快速蹦出几个候选词,目标模型再一次性核对——对的收下,错的打回去重猜。

但这一步在数据中心 GPU 和苹果芯片上的成本,完全是两套逻辑。

数据中心的 GPU 上,核对一批候选词像包车——坐几个人都是一口价,解码本就是内存瓶颈,多核对几个词几乎不花额外时间。苹果芯片更像打表的出租车,核对的候选词越多,表跳得越多。Rahim 实测,Gemma-4 12B 每多核对一个 token,要多花约 14 毫秒

他把这笔账算成了一个成本模型,结论是:苹果芯片上的理论速度天花板大约在 2.2 倍。现在做到的 1.6 倍,离天花板还有空间。

Rahim 把打下手的小模型从 HuggingFace 搬过来,用 MLX 框架重新搭了核对流程,权重量化成 4-bit。小模型压缩后只有 1.8GB,装进 Mac 内存毫无压力,跑起来还是无损。

比别人多走了一步

多数把大模型移植到本地的版本,只支持"贪婪解码"——每一步都挑概率最高的那个词,简单粗暴。

Rahim 把 DSpark 论文里的温度采样方法也实现了。草稿模型给出候选词后,有一套精确的概率接受机制,没通过的词从残差重新采样。他亲自核对过,输出严格等于目标模型在同样温度下的精确分布,不是打了折扣的近似版。

他还踩出一个精度搭配的坑:如果小模型配的是没经过指令微调的基础版,候选词只有 47% 能通过核对;换成指令微调版,这个比例涨到 82%。但把目标模型升到 bf16 精度却得不偿失——核对成本涨得比通过率涨得多,反而更慢。最后他锁定的最优方案是目标模型留在 8-bit

这些细节,论文不会告诉你,只有亲手做移植的人才能摸出来。

评论区一条留言,又带出了另一个技术

推文发出去后,评论区来了一条留言——DFlash 论文的作者之一 Jian Chen 问:能不能试试我们团队的模型?

DFlash 是今年 5 月 z-lab 的论文提出的另一种加速方案,带头人 Zhijian Liu,UCSD 助理教授兼 NVIDIA 研究科学家。思路和 DSpark 截然不同:它用一次并行的"块扩散"去噪一整块 16 个 token,而不是像 DSpark 那样一步步带依赖关系去猜。

Rahim 迅速动手。同一台 Mac 上,跟刚测完的 DSpark 跑了一轮头对头对比。

代码和数学任务上,DFlash 的接受长度到 5.95~6.20,速度约 36 tok/s,约 2.1 倍——跑赢了 DSpark。

但在开放聊天这种内容不好预测的场景里,接受长度上不去,块填不满,DFlash 的优势反而发挥不出来。DSpark 的 Markov 头正是为了解决同一个问题存在——并行蹦出一整块词,越往后的位置是各自独立算出来的,容易互相不搭调,Markov 头给这些位置之间加了依赖关系。

结果很清楚:聊天场景 DSpark 更快,代码和数学 DFlash 更强

v0.0.3 版本正式把 DFlash 接入了同一个包,还加了一个参数,可以手动调整块长度。同一台 Mac、同一个包,聊天和代码数学都能兼顾,不用在两个项目之间来回搬了。

这件事为什么值得关注

三个信号:

第一,Mac 跑大模型不再是"能跑就行"的阶段了。 以前本地部署的痛点无非两个:慢、质量打折。DSpark + DFlash 的组合拳,同时解决了速度(提 60% 到 110%)和精度(逐字节无损)的问题。M4 Pro 上每秒跑 30 个 token 的 Gemma-4,已经足够胜任日常的代码辅助和内容生成。

第二,一个业余开发者能干翻团队。 Rahim 不是 DeepSeek 的员工,不是苹果的员工,只是一个自己捣鼓开源项目的工程师。DSpark 开源一周、DFlash 论文发出两个月,他一个人就把两项技术都搬上了 Mac,还做了论文没写的工程优化。开源生态的杠杆效应在这里体现得淋漓尽致——技术开源的那一天,就是它在所有平台上生长的起点。

第三,投机解码正在从数据中心走向设备端。 DSpark 和 DFlash 代表的"大小模型协作"思路,将成为苹果芯片上跑大模型的标准范式。Rahim 自己也说了,同样的方法用在更大的 Qwen3-8B 和 14B 上应该也能跑通。这条路一旦走通,Mac 不再是"推理弱"的代名词——至少跑本地模型,够用了。


来源:量子位 / 36氪 项目地址:https://github.com/ARahim3/mlx-dspark 原文链接:https://www.36kr.com/p/3879842615308547

相关文章
2026-08-08
100W功耗跑出RTX 4080级性能?中国魔改卡RTX 4080M实测
2026-08-08
豆包、千问、元宝集体叫停智能体:7月15日起,你的AI伴侣没了
2026-08-08
内存巨头SK海力士280亿美元杀入纳斯达克,这场IPO赌的是AI的命

💬 评论 (0)

暂无评论,来说两句吧~

登录后评论