Apple Neural Engine im Detail: Nachträgliches Reverse-Engineering der M1-NPU

Eileen Yoon hat die Reverse-Engineering-Arbeit am Apple Neural Engine (ANE) nach drei Jahren wieder aufgenommen - diesmal nicht, um ihn nützlich zu machen, sondern um seine interne Architektur vollständig zu kartieren: Compute, Datenpfad, Scheduler, Speicher und Ausführungsmodell.

Warum das jetzt kommt

Der M5 (2025) trägt “LLM-Performance” als Headline-Feature - und hat die ANE-Cores direkt in die GPU-Cores integriert. Für Yoon das “offizielle Ende der standalone NPU”. Grund genug, die Design-Annahmen zu dokumentieren, die Apple 2017 mit dem A11 erstmals in Silizium gegossen hat.

Was im Inneren steckt

• 16 Compute-Cores mit je 128 FP16- (oder 256 INT8-) MAC-Lanes - zusammen 2048 parallele Reduktionen pro Zyklus, Zeit als einziger Reduktions-Achse
• Der Accumulator sättigt nachweislich bei exakt 2^15 - per CoreML-Probe mit FP16-Grenzwerten ausgetrickst
• tanh() wird nicht berechnet, sondern als 33-Einträge-Piecewise-Linear-LUT im Registerfile abgelegt - via HEX-Dump der kompilierten hwx-Dateien belegt, inklusive Linear-Interpolation zwischen den Stützpunkten
• Skalierung und Bias faltet der Compiler direkt in die Faltungsgewichte

Die eigentliche Erkenntnis: Nicht die MACs machten den ANE zum CNN-Beschleuniger, sondern der Dataflow um sie herum - mit “vorhersehbarer Wiederverwendung” von Daten. Genau diese Annahme brachen Transformer mit autoregressivem Decoding.

LLM-Decode: Bandbreite schlägt FLOPS

Beim Single-Token-Decode zählt nachgewiesenermaßen Lesebandbreite, nicht Peak-Compute. Die Messungen am M3: ANE Kernel-DMA 38 GB/s, Tile-DMA 59 GB/s, GPU 77,7 GB/s - und Kernel- plus Tile-Zugriffe laufen seriell, nicht parallel. Damit steht der ANE beim Transformer-Decode doppelt am DRAM-Roofline. Der M5-Schritt, die ANE-Cores in den GPU-Datenpfad zu falten, liest sich vor diesem Hintergrund wie ein Eingeständnis.

Original: eiln.github.io - Retrospectively Reverse-Engineering Apple’s Neural Engine