逆向苹果ANE神经网络引擎：2G内存流畅运行260亿大模型

一台只有 8G 内存的普通 Mac，怎么跑得动 260 亿参数的 AI 大模型？ 按常规算法，260 亿参数就算压成 4 位量化，模型文件也得 14G。 内存只要小于 16G，电脑刚加载就会直接卡死。 但最近开源社区出了个新项目，把整个模型跑起来，居然只占了 2G 内存。 更夸张的是，生成速度飙到了每秒 100 多个字。 这是怎么做到的？

秘密在模型的架构里。 这次跑的模型是谷歌的 Gemma 4 26B。 名字叫 26B，总共有 260 亿参数，但它用的是混合专家架构（MoE）。 整个模型被拆成了很多个专门干活的小专家。 每次生成一个字，不需要全部专家同时上场，只要激活其中几个，实际参与计算的参数只有 40 亿左右。 之前有个开发者叫 Andrey Mikhaylov，做了个叫 Turbo Fieldfare 的引擎。 他的思路很直接： 既然每次只用一小部分专家，为什么要把 14G 的模型全塞进内存里？ 他把模型必须常驻的骨架网络和注意力缓存留在内存里，只占 1.35G。 剩下的所有专家权重，全扔在固态硬盘上。 需要哪个专家，就临时从硬盘读哪个。 靠着苹果电脑统一内存和超高速固态硬盘，这套引擎在普通 Mac 上真跑起来了。

但这么干有两个巨大的痛点。 第一个痛点是解码慢，在高配 Mac 上撑死也就每秒跑二三十个字。 第二个痛点更致命，是提示词预填充慢得令人抓狂。 你想想，你在对话框里输入一段几百字的问题，模型要一口气读懂你的上下文。 这下坏了，几百个字同时算，几乎所有的专家瞬间全被叫醒。 固态硬盘哪怕再快，同时并发读取几千次，硬盘读写直接被堵死。 电脑就像在泥潭里推车，半天吐不出第一个字。

怎么破这个局？ 另一位开发者 zw5 看了代码，觉得还能榨出更狠的性能。 他连出了三招，直接把生成速度翻了三四倍，冲过了每秒 100 个字。

先解决最头疼的预填充卡死问题。 他盯上了苹果芯片里一直被闲置的硬核部件：神经网络引擎 ANE。 苹果每一颗 M 系列芯片里，都有这个 16 核的专用矩阵计算单元。 但在本地大模型圈子里，无论是开源工具还是苹果自家的开发框架，几乎全在用显卡 GPU 跑。 ANE 为什么没人用？ 因为苹果把底层驱动封得死死的，只开放了高层的 CoreML 框架，很多自定义的模型算子根本跑不了。 这位开发者直接逆向工程了苹果的私有接口，绕过所有限制，把底层的计算图直接下发给 ANE 硬件。 有了这个专门做矩阵加速的硬件分担压力，最卡顿的提示词预处理，直接被这颗平时睡觉的芯片接管了。

预填充搞定了，硬盘读写的死结怎么解？ 原本的引擎为了省内存，自己在软件层写了一套繁琐的换页算法，手动决定哪个专家进缓存、哪个专家踢回硬盘。 开发者一琢磨：操作系统本身不就是最懂内存调度的吗？ 他直接干掉了手写的缓存层，改用系统的内存映射 mmap。 把硬盘上的模型文件直接映射进虚拟地址空间。 哪个专家被频繁用到，macOS 的系统页面缓存就会自动把它留在空闲内存里，零拷贝直接调。 不用在应用层费心管，操作系统的内核级调度反而快得多。

最后就是把解码速度推上极限。 既然从硬盘读权重再快也有物理延迟，那就别生成一个字读一次。 他加了推测解码。 先让一个小巧的草稿模型在内存里飞快地猜出后面好几个字。 然后让大模型在一次计算里，把这几个字一口气全验完。 原本要来回读好几次硬盘的动作，一次批量计算就搞定了。

三招叠在一起，瓶颈全被绕开了。 提示词不卡了，硬盘读取次数被大幅压缩，平时闲着的 ANE 硬件也被拉来干活。 最终的成绩单，就是在 2G 的超低内存开销下，硬生生跑出了每秒 100 多个字的推理速度。 谁能想到，一台被认为只能用来办公的入门款 Mac，把芯片深处的隐藏角落全抠出来之后，也能把这么大的模型跑得飞起。