A Software Fix Nearly Triples Apple's M3 Neural Engine Bandwidth

Eileen Yoon, the developer behind the Asahi Linux project's reverse-engineered Neural Engine driver, published a write-up on Aug. 10, 2026 documenting a hardware quirk that has been silently capping the Apple M3 Neural Engine's memory bandwidth since the chip shipped. On an M3 MacBook Air with 24 gigabytes of memory, Yoon measured DRAM weight-streaming throughput collapsing to 17 to 19 gigabytes a second, against a nominal ceiling of 45 to 60 GB/s, whenever the total size of a model's weights happens to land on an exact multiple of 1 mebibyte.

That is not a rare coincidence. Model weights are packed into buffers by compilers that favor round allocation sizes, so a meaningful share of the models people actually run on the ANE, Apple's fixed-function matrix accelerator, was very likely hitting the throttle without anyone tracing the cause to a specific address arithmetic bug.

Splitting one transfer into two restores the missing bandwidth

Yoon traced the stall to the kernel DMA engine's prefetch ring: a wraparound calculation in the memory controller appears to misfire whenever a transfer boundary aligns exactly on a 1 MiB multiple, and the fix does not touch silicon at all. Instead of submitting one 1 MiB transfer, the workaround splits it into two 512 KiB transfers, which sidesteps the exact arithmetic condition that triggers the bug.

The before-and-after numbers, run on the same M3 Air, are the reason this is worth a full article rather than a changelog line. Llama 3.2 1B went from 10.0 to 24.3 tokens a second, with measured DRAM throughput climbing from 24.7 to 60.0 GB/s in the same run. Qwen3-8B, a heavier model with a larger memory footprint per token, improved from 1.36 to 2.97 tokens a second, with DRAM usage rising from 22.4 to 48.7 GB/s.

1. Llama 3.2 1B, before10 tokens/s
2. Llama 3.2 1B, after24.3 tokens/s
3. Qwen3-8B, before1.36 tokens/s
4. Qwen3-8B, after2.97 tokens/s

Source: Eileen Yoon, "Getting 50 GB/s Back Out of the ANE," accessed Sept. 13, 2026

That is not a modest tuning gain. It is close to a 2.4x improvement on the smaller model and a 2.2x improvement on the larger one, recovered entirely in software, on hardware that has been sitting on shelves and desks since the M3 generation launched. The ANEMLL project, an open framework for running large language models on the Neural Engine, is the direct beneficiary: any model it serves on M3 silicon inherits the fix once it is folded into the runtime's DMA path.

Why the ANE, not the CPU or GPU, is where this lands hardest

The bug matters more on the Neural Engine than it would on Apple's CPU or GPU cores because the ANE is a fixed-function dataflow engine, not a general-purpose processor with its own cache hierarchy to hide a memory stall behind. Spencer Bryngelson, an associate professor at the University of Texas at Austin who published a 300-page reverse-engineering reference for the chip covering the A11 through A18 and M1 through M5 generations, describes the ANE as bound by a DRAM-bandwidth ceiling once a workload crosses roughly a 2-megabyte working set. Below that threshold, on-chip buffering hides memory latency; above it, every stall in the DMA path shows up directly as fewer tokens a second, because there is no larger cache to absorb the wait.

That framing explains why a bug this specific produced a result this large. Large language model inference on a mobile-class accelerator is memory-bound almost by definition: the chip spends most of a token's compute budget waiting for weights to arrive from DRAM rather than doing arithmetic on the weights it already has. Cut the pipe carrying those weights to a third of its rated size, and the accelerator's matrix throughput never gets the chance to matter.

The number that matters is bandwidth per chip you already sold

The headline comparison in most accelerator coverage is peak throughput against a competing chip that does not exist on the reader's desk. That framing is close to useless here, because the competing chip is the same M3 silicon Apple already shipped, running the same firmware, with a two-line change to how it requests memory. Every M3 Mac in the field is a candidate for this exact multiplier, at zero marginal hardware cost, which is the kind of recovered capacity that a new accelerator generation cannot beat on price because there is no purchase involved at all.

Apple has not published an erratum or a Core ML changelog entry acknowledging the throttle, and nothing in Yoon's write-up or the ANEMLL project indicates whether the fix will ever ship in Apple's own runtime rather than staying confined to the reverse-engineered stack. That gap is the story's open edge: a bug this size, on a chip this current, sitting undocumented for roughly three years since the M3's late-2023 launch, is a fact about how little visibility even a well-resourced reverse-engineering effort has into Apple's own silicon errata.

What would change this read is Apple shipping a macOS or Core ML update that alters the DMA prefetch ring's behavior directly, which could either fold the fix in natively or, just as plausibly, change the address arithmetic enough to break Yoon's specific workaround. Until one of those happens, the fastest Neural Engine on an M3 Mac is not the one Apple shipped. It is the one running someone else's driver.

More from The Terminal: on the same silicon-archaeology beat, Intel's 8087 shipped with an undocumented microcode instruction that took decades to reverse-engineer, and on the on-device inference side, one developer's SSD-streaming trick let a 35-billion-parameter model run on 8 gigabytes of memory.