苹果M3神经引擎带宽受限：拆分传输可从17 - 19GB/s恢复至约60GB/s！

转载于 2026-09-13 17:15:29 发布 · 8 阅读

引言

苹果M3神经引擎（ANE）存在一个RTL性能错误，当总权重大小为1 MiB的整数倍时，DRAM权重流式传输吞吐量会从标称的45 - 60 GB/s降至17 - 19 GB/s，目前这影响了[ANEMLL](https://github.com/anemll/anemll) 15个模型中的7个。通过避开内核DMA引擎推测预取环中的问题路径，Llama 3.2 1B的令牌吞吐量从10.0提升到24.3令牌/秒（DRAM使用率从24.7提升到60.0 GB/s），Qwen3 - 8B从1.36提升到2.97令牌/秒（DRAM使用率从22.4提升到48.7 GB/s）。

发现

在对神经引擎单令牌解码的DRAM权重流式传输吞吐量（GB/s）进行分析时，使用了公式：\[ X[1,D] \times W[D,N] = Y[1,N]. \]当\(N = 4096\)时，注意到\(D = 1536\)的运行速度几乎比Llama 3.2默认的\(D = 2048\)快3倍。

静态（纯KernelDMA）每个副本的中位微秒数，N = 4096：

| D | 576 | 768 | 1024 | 1280 | 1536 | 2048 |

| --- | --- | --- | --- | --- | --- | --- |

| rep a | 150.4 | 196.8 | 238.1 | 293.8 | 310.9 | 997.6 |

| rep b | 157.8 | 190.2 | 250.1 | 288.3 | 326.8 | 995.0 |

| rep c | 148.7 | 189.6 | 249.4 | 275.2 | 316.5 | 995.4 |

在D = 2048附近对D进行扫描：

带宽与D的关系图

当D = 2048时，吞吐量为16.93 GB/s；当D = 2016时，吞吐量为44.5 GB/s，这意味着吞吐量下降了27.57 GB/s，从44.5降至16.93 GB/s，降低比例达61.96%。这些扫描数据是在M3 Air上收集的，在一次运行中，相同的温度和负载条件下重复进行了40次。还确保ANE寄存器文件的DMA大小和地址是唯一变化的变量。

于是对整个D范围进行了扫描，发现D = 2048处存在共振现象。对吞吐量（GB/s）和张量维度（D）进行快速傅里叶变换（FFT）后发现，内存控制器的吞吐量在张量维度空间中存在一个波长为2048的主导谐波，且是一个低谷。所有D = 2048的倍数都被限制在17 - 19 GB/s的固定带宽下限。在D = 2048的倍数处，吞吐量从标称的45 - 60 GB/s急剧下降到17 - 19 GB/s，而在大约256行之外又恢复到标称值。这不是一个RTL正确性错误，但在2048附近的请求被强制进入一个单独的、缺乏信用的调度机制，导致吞吐量不合理地降低了28 - 43 GB/s。

假设1 - DRAM空间相关性

核心竞争

神经引擎有核心级并行，ANE有16个核心并行工作，通过将缓冲区均匀地划分为\(N\)份来分配工作。每个核心会从DRAM中获取权重缓冲区的不同部分，但16个核心会在同一周期内并行地从DRAM中请求各自的部分。如果每个核心从DRAM中获取各自的部分，那么无论启用一个核心还是全部16个核心，流式传输延迟应该相同。然而，如果由于核心竞争导致带宽下降，那么在D = 2048的受限制情况下，减少核心数量反而可能提高吞吐量。对D = 2048和D = 2016的活动核心数量进行扫描后发现，对于D = 2016和D = 2048，从1个到16个活动核心的延迟保持不变，这意味着即使只有1个核心，吞吐量限制仍然存在。

地址竞争

即使排除了核心级竞争，仍然怀疑由于2的幂次周期导致了DRAM竞争。像2048这样的2的幂次步长，每次循环都会增加\(2^k\)，这意味着低\([0..k - 1]\)位是恒定的。DRAM会对物理地址进行哈希处理，以便让步长访问模式在不同存储体之间实现空间去相关。因此，哈希函数将低位比特折叠或使高位\(2^k\)比特重叠，都可能解释这种2的幂次周期性。

为了测试DRAM空间相关性是否是问题所在，对权重获取的地址进行了随机打乱处理。地址被随机打乱并分布在整个约64 MiB的IOVA区域（跨度为59.90 MiB），这样在页面内和页面外都实现了打乱。为了排除无风扇M3 Air上的热漂移影响，基线样本和打乱样本在每次运行中交替进行。基线的中位吞吐量为31.37 GB/s，随机打乱地址后的中位吞吐量为32.29 GB/s。随机打乱后的持续吞吐量平均高出1 GB/s，这表明在这次运行中，可能通过打乱处理解决了一些空间相关性问题，但这在所有情况下尚未得到证明，且打乱处理无法恢复约200%的吞吐量下降，不足以解释性能崩溃的原因。

假设2 - RTL整数溢出

内核维度

公式\[ X[1,D] \times W[D,N] = Y[1,N]. \]中，\(D\)（Cin）表示每个内核的长度，包含\(D\)个FP16（2字节）权重，即\(2D\)字节；\(N\)（Cout）表示内核的数量，每个核心处理\(N/16\)个内核。由于最初的图表是在N固定为4096的情况下对D进行扫描的，实际上从未确定这个低谷是由\(D\)引起的，还是由\(D\)和\(N\)的乘积引起的，这个乘积决定了每个核心在整个任务中必须处理的内核总字节数。

为了分离未知变量，对\(D\)和\(N\)进行反向扫描，使得编译后的任务每个核心都有相同的1 MiB静态内核数据。执行的寄存器文件的十六进制差异显示，只有相关字段（地址、大小）发生了变化。任何D和N的组合，只要每个核心的内核总字节数为1 MiB，都会使核心吞吐量下降到观察到的17 GB/s。鉴于每个核心的常驻“L1” KMem为64 KiB，现在知道在1 MiB上存在某种推测预取/信用机制。相反，现在知道可以通过不传输1 MiB的倍数来避免性能崩溃；编译器可以通过拆分任何编译后每个核心正好为1 MiB内核DMA的任务来解决这个问题。

推测预取

高带宽内存控制器以最小传输“行”粒度而不是单字节进行操作。如果内核DMA的行粒度是64字节，当N = 4096时，每增加D = 2048，请求的总字节数就会增加1 MiB，1 MiB的传输请求总共需要\(\texttt{0x4000}\)个64字节的行。现在推测，在\(\texttt{0x4000}\)行处会发生计数器溢出。

在\(\texttt{0x4000}\)或\(2^{14}\)处发生的溢出需要14位的存储空间，苹果Silicon使用的16 KiB虚拟内存页面大小就是\(2^{14}\)字节。对于16 KiB的页面，地址位（\([13:0]\)）是页面偏移量，在虚拟到物理地址的转换中保持不变。对低地址位（`addr & 0x3fff`）进行的预取算术运算会导致14位溢出。

定义\(k\)为传输跨越的\(\texttt{0x4000}\)行周期数，称为一圈；定义\(x\)为距离第\(k\)个低谷的行数。以\(x\)为归一化参数，V形低谷在每个\(\texttt{0x4000}\)行周期的低谷周围\(x = \pm256\)行处完全恢复。低谷正好出现在一个虚拟内存页面大小的DMA行数内，这看起来像是一个深度为一个页面的预取窗口。

手动叠加\(D = 2048\)（\(k = 1\)）和\(D = 4096\)（\(k = 2\)）的带宽曲线，当以低谷为中心重新对齐时，会得到几乎相同的带宽曲线。现在绘制每个\(k\)在\(x = 0, 32, 64, 128, 256\)处的带宽图，可以注意到每个\(k\)曲线在\(x \to 0\)时向内汇聚。

每个\(k\)圈的时间曲线实际上是第1圈曲线的垂直缩放版本，第6圈的曲线比第1圈大约陡6倍。在以\(k\cdot\texttt{0x4000}\)为中心重新对齐每个低谷后，所有\(k\)的带宽曲线都汇聚到同一条线上。在测量数据中，每圈的斜率确实与\(k\)呈线性关系（每个的R² = 0.96 - 0.99），斜率为\(= 3.18 \cdot k\) 微秒/行。

综合这些观察结果，可以得出以下结论：受限制的传输“模式”每\(k\)次重复一次；每个周期内的带宽模式主要由相对于中心的位移\(x\)决定；当\(x = 0\)时，无论\(k\)的值是多少，传输速率都会下降到相同的\(B(0)\)。所以，\(x\)选择带宽状态，\(k\)决定该状态重复的次数。

预取环前瞻每次请求一个1 MiB的环。该环将总传输大小视为\(k\)个重复的1 MiB池进行获取。如果每个1 MiB预取有某个带宽曲线\(B(x)\)，那么总传输时间为\(t(k,x) = \frac{S(k,x)}{B(x)} = \frac{k\cdot1\ \text{MiB}+64x}{B(x)}\)。关于\(x\)的斜率为\(\frac{\partial t(k,x)}{\partial x} \approx -k\cdot1\ \text{MiB}\ \frac{B'(x)}{B(x)^2}\)，对于较小的\(x\)值（<256），斜率主要由\(k\)决定。每圈16 MiB的情况下，18 GB/s的下限对应每圈900微秒。在256行内从下限（约18 GB/s）恢复到上限（约45 GB/s），每圈时间大约减半，平均为(900 - 380)/256 = 2微秒/行。如果在边界附近更陡峭（约3.2），那么每圈每线3.18微秒的斜率是合理的。

可能的RTL错误

最有可能的是，内核DMA中的推测预取环存在问题，其14位的头/尾地址算术运算省略了一个溢出/周期位。因此，当传输大小恰好是\(2^{14} = \texttt{0x4000}\)的整数倍时，会将“还剩一圈”错误地识别为“已完成”，从而导致预取请求管道饥饿。推测路径无法在数据消耗之前发出足够的请求，因此虽然数据仍然可以完成传输，但会将原本应该是带宽受限的流式传输变成走走停停的传输。

苹果Silicon的16 KiB页面（\(2^{14}\)字节）使得使用14位地址进行操作很有吸引力，但14位算术运算会使每\(k\cdot\texttt{0x4000}\)的间隔产生重叠，这意味着相隔0x4000的传输会产生相同的内部环状态。实际上，0x4000行的周期性可以用14位行指针溢出算术来解释。

由于没有周期位来识别是“完整一圈”而不是“已完成”，预取器在整个0x4000行的传输中不会发出前瞻请求，导致整个传输被限制在17 - 19 GB/s的慢速非推测路径上，这可能是串行路径。对最多一个页面进行前瞻预取是合理的，64字节粒度的行指针的256行对应一个16 KiB的页面，这解释了为什么低谷在256行或一个页面的窗口内能够完全恢复。

软件修复

修复方法是不要请求1 MiB的内核传输。最简单的软件解决方法是找出所有总大小为1 MiB的kernelDMA任务，并将1 MiB拆分为非1 MiB倍数的块，例如两个512 KiB的传输。调度N个任务带来的亚毫秒级延迟开销，与灾难性的30 GB/s - 50 GB/s预取限制相比可以忽略不计。另一个选择是对传输进行填充，使其距离1 MiB +/- 8 KiB（256行），但这需要更多工作，因为它会改变计算图。

将每个核心1 MiB的传输进行拆分可以恢复正常带宽：一个`0x4000`行的任务为17.25 GB/s；两个`0x2000`行的任务为45.52 GB/s，快2.66倍；四个`0x1000`行的任务为44.83 GB/s，快2.60倍。对照实验证实，2.6倍的加速直接来自于避免预取错误。