Apple 的 ANE 被挖掘，AI 硬件公开，宣传的 38 TOPS 居然是"数字游戏"？

近日，有个大佬通过挖掘 Apple Neural Engine (ANE) ，针对苹果芯片底层 AI 逻辑做了一次细节公开，因为苹果 ANE（M4 芯片上为 16 核运算单元）长期以来是一个纯粹的“黑盒”，对大家来说缺少公开接口、文档和指令集架构 (ISA)，开发者只能通过 CoreML 框架间接调用，而这次作者 maderix 通过挖掘把 CoreML 给大家理清了一个清晰的轮廓。

技术视角

首先，maderix 是通过一些常用手段来获取数据：

• 利用 dyld_info 扫描私有 framework，通过 Method Swizzling hook CoreML （MIL）
• 成功得到完整的编译运行流程，实现了在内存中直接将 MIL（模型中间语言，类似于 NVIDIA 的 PTX）编译为 ANE 原生二进制文件

也就是实现了内存中将 MIL 直接编译为 ANE binary ，这可以让开发者绕过苹果的官方限制，直接在 ANE 上进行神经网络的训练和推理调用。

而在直接测试硬件底层的过程中，maderix 发现了几个关于 ANE 的结论：

1、算力 “38 TOPS” 是数字游戏

• 官方宣传 M4 ANE 算力为 38 TOPS

• 实测数使用 FP16 和 INT8 运行完全相同的操作，吞吐量没有任何变化

• 而 ANE 在执行 INT8 运算时，实际上会先将其反量化（Dequantize）为 FP16，然后再进行计算
• 所以苹果宣传的 “38 TOPS INT8” 是基于真实 FP16 峰值算力乘以 2 包装出来的数字，M4 ANE 的真实物理硬件峰值算力实际上是 19 TFLOPS (FP16)，不是 38 TOPS 真 INT8

是不是觉得有点懵逼，其实很好理解，通俗的讲：

• FP16 (16位浮点数)：可以理解为一种非常精确但也很“啰嗦”的图纸，它用 16 位二进制来记录一个数字，能表示很大范围和小数点后很多位，细节非常丰富，就像用高清相机拍的照片，文件大，但放大看也很清晰，在AI里模型训练这种需要高精度的阶段，就喜欢用这种“高清图纸”来确保准确性
• INT8 (8位整数)：这是一种相对“粗糙”但非常简洁的图纸，它只用8位二进制来表示整数，没法记录复杂的小数，就像把那张高清照片压缩成了占用空间小得多的缩略图，虽然丢失了一些细节，但核心内容（比如照片里是一只猫）还在，而且处理起来特别快、特别省空间

而苹果的 ANE 在处理 INT8 “图纸”时，并没有直接用“看缩略图”的快速方式，而是偷偷地把这张“缩略图”又还原（反量化）成“高清图纸”（FP16） ，然后再拿去处理，这就像是明明有一台能快速扫描缩略图的机器，苹果却非要先把缩略图放大成高清图，再用处理高清图的慢速机器去扫描。

2、本质它是卷积引擎，而非矩阵乘法引擎

• ANE 的底层硬件设计更倾向于处理卷积（Convolution）而非标准的矩阵乘法（Matrix Multiplication）

• 如果将相同的计算逻辑重写为卷积运算，吞吐量可以直接飙升 3 倍（这一点在苹果开源的 ml-ane-transformers 参考代码中曾有隐晦的暗示，里面大量用卷积模拟 Transformer 结构）

这就像一家专门做跑车发动机的工厂，你非要它去生产家用轿车的变速箱，它的效率就会变得低下，而「1x1 Conv 走卷积 datapath，MatMul 走 fallback 路径」可以理解为工厂内部有两条完全不同的“生产线” ：

• 1x1 Conv (1x1卷积)：这就像一个被工厂精心设计、铺满高速传送带的“专用超车道” ，工厂在设计之初，就为了处理这种任务铺设了最直接、最高效的物理电路，数据一上来，立刻就能进入这条为它量身定制的“卷积数据通路”（卷积 datapath），一路绿灯，飞速处理
• MatMul (矩阵乘法)：这就像一个“通用包裹”，工厂里没有为它修建直达的专用路，当这个任务到来时，它只能走一条“备用通道”（fallback 路径），这条“备用通道”可能是由更通用的电路拼接而成，或者需要先把“通用包裹”拆开、重新打包，才能勉强塞进现有的传送带上，整个过程自然就慢了很多。

3、硬件缓存约 32MB 的 SRAM

• maderix 通过不断扩展矩阵乘法的规模（Scaling Test），观察性能出现急剧下降的“断崖点”，由此反向推测出 ANE 内部拥有大约 32MB 的高速 SRAM 缓存，超过这个容量限制就会导致性能暴跌
• 所以 ANE 是典型的 dataflow + on-chip memory 设计，很像 TPU 的架构思路，小 batch 更高效，可以避免中间 tensor 溢出 SRAM

4、需利用计算图填满流水线

• 单操作低效：由于 ANE 的 16 个核心是基于流水线（Pipelined）设计的，如果只向它提交单个算子/操作，大部分核心将处于空转状态，只能发挥约 30% 的峰值性能

• 必须将 16 到 64 个操作 链接在一张计算图（Computation Graph）中一次性提交，这样不同的核心可以同时处理图中不同阶段的操作，从而将硬件利用率拉满至 94%
• 这么看 ANE 不是“单核算力 × 16”，而是“深度流水线机器”

这个就更好理解，ANE 在这里不是“16个独立工人”，而是一条“16道工序的自动化流水线”，它的16个核心不是独立的，而是像接力赛一样串起来的，每个核心负责AI计算中的一个特定阶段。

这计算图就是交给那条16道工序流水线的一份详细的、总装的“流程图” ，这样在完整的全貌流程图下，流水线的总调度才能完整工作起来。

5、极致的 0mW 空闲功耗

• ANE 拥有极为强悍的硬件级电源门控（Power Gating）技术

• 在空闲状态下，ANE 不是进入低功耗待机模式，而是做到完全断电、零泄漏，功耗为绝对的 0mW，这也解释了其在移动端设备上极佳的能效表现

最后，作者得到一个结论：ANE 对于小规模操作， CoreML 会增加 2-4 倍的开销 ，而在高吞吐量配置下，由于 ANE 计算时间占据主导地位，这种差距会缩小，但对于延迟敏感型工作负载（例如 LLM 令牌解码、实时推理），CoreML 的开销则非常显著。

而在这里一点，结合前面的例子，我们就可以理解，ANE 是一条极速货运流水，而 CoreML 是“标准报关”的关口，小规模操作，比如「只想寄一个小包裹」 ：

• 你把包裹拿到报关行（CoreML），他们开始走流程：填表、开箱检查、重新打包、录入系统……这些手续本身花了5分钟
• 手续办完，包裹才被送流水线，“嗖”一下到了目的地，实际运输只用了1分钟

从这点看，ANE 不是通用 GPU，而是卷积优化机器 + 深流水线架构，总结下来：一个拥有 19 TFLOPS FP16 算力、32MB SRAM 缓存的“卷积加速I器”，需要通过图编译的批处理来喂饱其 16 核流水线，并具备移动端顶级的电源管理能力。

另外，M4 的 CPU 核心也采用了苹果的 SME（可扩展矩阵扩展）技术，他们之间的对比：

• ANE： 大批量推理、16 层以上的深度图、能量受限场景以及持续吞吐量
• SME ： 单标记解码（零调度开销）、ANE 不支持的自定义操作、小型矩阵以及任何需要 FP32+ 精度的操作

所以，M4 上理想的 LLM 推理策略是混合模式 ：在 ANE 上进行预填充（大批量、高吞吐量），在 SME 上进行解码（单标记、对延迟敏感）。

这个就类似于：

• 当你向 AI 提一个长问题，或者给它一篇长文章时，ANE 开始全力工作，它以极高的吞吐量和能效，快速处理这大批量的输入数据，建立起理解所需的中间状态（Keys和Values缓存），这就像把所有的参考文献快速扫描、索引好
• AI开始一个字一个字地回答你，这个阶段 SME 接管工作，每要生成一个新词，它都需要基于当前已有的上下文，做一次小型矩阵运算，因为“零调度开销”和极快的数据存取，它能以最低的延迟完成每一步，让你感觉对话是流畅、实时的，这就像用极快的打字速度，把思考结果敲出来

另外，这个项目还有一些极限性能体现，例如 maderix 而为了让单步训练耗时压缩到 9.3 毫秒（持续输出 1.78 TFLOPS 的算力），必须进行极底层优化，确保 CPU 和 ANE 绝不互相等待：

• GCD 异步 cblas 重叠计算 ：当 ANE 正在疯狂计算下一步的前向传播时，CPU 正在并行运行矩阵乘法 (cblas_sgemm) 来计算当前步的权重梯度，两者完全重叠运行。
• 通道优先 (Channel-First) 内存布局 ：将 CPU 端的数据布局格式彻底重写，与 ANE 底层原生的 [1, C, 1, S] IOSurface 共享内存格式完全对齐。，从而消灭了数据在两个芯片间来回拷贝、转置 (Transpose) 产生的性能开销。
• 前向抽头 (Forward Taps) ：在标准的反向传播中，经常需要重新计算某些值（耗时操作），所以直接让 ANE 在执行前向传播时，顺便把中间的隐藏状态和注意力分数直接以 Concat（拼接）的形式“吐”出来并缓存，反向传播时直接白嫖这些数据

更极客的是项目中的 exec() 重启法 ，因为 ANE 编译器存在严重的内存泄漏，在一个进程里连续编译大约 119 次后系统就会崩溃，而 每次权重更新，都必须重新编译 ANE 程序，这意味着每跑 119 步训练程序就会死掉。

而为了“逃课”，maderix 在训练循环中写了一个逻辑：定期保存当前的 Checkpoint，然后直接调用系统的 exec() 命令杀掉并重新启动自己的进程，通过这种不断“自杀并转生”的方式，暴力清空内存状态，完美绕过了苹果底层的内存泄漏限制。

基于这个，甚至有人发现 M3 Ultra 的 ANE 算力可以接近 3090 ，因为 M3 Ultra 本质上是 两个 M3 Max 级别 die 拼接（UltraFusion），两个 ANE cluster 却是可以实现真实的 37 TFLOPS ：

另外，这里两个 ANE cluster 是物理分离，每个 cluster 有自己的调度，需要以双线程启动才能使用 2×ANE 。

所以整个基准测试，也可以看作是一个对 ANE 的极限性能压制场景。

参考链接

github.com/maderix/ANE