Apple eröffnet eine Hardware-Debatte neu: Reverse Engineering von Apples Neural Engine im Rückblick

Apples Neural Engine im M1 ist wieder in den Fokus gerückt – trotz einer dreijährigen Pause des Linux-Treiberprojekts, das ihr Verständnis ermöglichen sollte. Retrospectively Reverse-Engineering Apple's Neural Engine dokumentiert, warum dieser Beschleuniger bei früheren neuronalen Netzen glänzte, mit den heutigen Transformer-Workloads jedoch Schwierigkeiten hat.

Eileen Yoon, eine frühere Mitwirkende bei Asahi Linux, nahm die aufgegebene Arbeit wieder auf, nachdem Apple seine Hardware-Ausrichtung verändert hatte. Der M5 integriert einen Neural Accelerator in jeden GPU-Kern und behält zugleich eine separate Neural Engine mit 16 Kernen. Diese Kombination stellt die Annahme infrage, dass ein einzelner spezialisierter Beschleuniger Apples wachsende generative KI-Workloads tragen sollte.

Es geht um mehr als eine verspätete Analyse der Hardware. Die Untersuchung verknüpft Entscheidungen für Convolutional Neural Networks, kurz CNNs, aus der Zeit um 2017 mit Apples Reaktion auf moderne Sprachmodelle. GPUs setzen die eigenständige Neural Engine inzwischen unter Druck, weil Transformer auf flexible Planung und kontinuierliche Speicherbewegungen angewiesen sind.

Ein ruhender M1-Treiber wurde zur Hardware-Obduktion

Die neue Arbeit macht aus einem unvollendeten Linux-Treiber eine Darstellung dessen, wofür Apple maschinelles Lernen ursprünglich hielt.

Yoon entwickelte zuvor einen Linux-ANE-Treiber, der mit der Neural Engine in M1-Chips kommunizieren konnte. Das Projekt umfasste ein Kernel-Modul, eine Userspace-Bibliothek, Tests und Python-Bindings. Es bot einen Weg an Apples öffentlicher Software-Abstraktion vorbei, machte die Hardware jedoch nicht allgemein programmierbar.

Danach ruhte das Projekt drei Jahre lang. Yoon schreibt, die ANE habe zu spezialisiert gewirkt, um weitere Treiberarbeit zu rechtfertigen. Das Öffnen ihrer Hardwareschnittstelle würde nicht ändern, welche Operationen ihr festgelegter Datenpfad effizient ausführen kann.

Dieser Unterschied ist entscheidend. Ein herkömmlicher Treiber kann Fähigkeiten zugänglich machen, die bereits in der Hardware vorhanden sind. Er kann einen speziell entwickelten Datenflussbeschleuniger nicht in einen universellen Prozessor verwandeln.

Yoons Architektur-Rückblick stellt daher eine andere Frage als die ursprüngliche Treiberarbeit. Statt zu fragen, wie Linux Aufgaben einreichen kann, untersucht er Rechenarray, Scheduler, Speichersystem und Ausführungsmodell. Diese Komponenten machen die in das M1-Design eingebetteten Annahmen über Workloads sichtbar.

Die Untersuchung beschreibt 16 Rechenkerne, die um einen zentralen Block aus lokalem Speicher angeordnet sind. Jeder Kern enthält parallele Multiply-Accumulate-Einheiten, kurz MACs, die Eingaben multiplizieren und die Ergebnisse zu Akkumulatoren addieren. Diese Operationen bilden die Grundlage für Faltungen, Matrixmultiplikation und die bei Aufmerksamkeitsmechanismen verwendeten Skalarprodukte.

Die MAC-Einheiten allein erklären die Spezialisierung der Neural Engine nicht. Sowohl CNNs als auch Transformer benötigen Multiplikation und Akkumulation. Der entscheidende Unterschied liegt darin, wie Gewichte und Aktivierungen diese Einheiten erreichen, verfügbar bleiben und sich durch den Chip bewegen.

Apple stellte seine erste Neural Engine 2017 mit dem A11 Bionic vor. Damals konzentrierten sich neuronale Netze für Endverbraucher auf Bildklassifizierung, Gesichtsanalyse und andere dichte CNN-Workloads. Diese Netze boten regelmäßige Tensorformen und vorhersehbare Wiederverwendung.

Der M1 übernahm diese Designlinie, als Apple seine eigenen Prozessoren auf den Mac brachte. Seine Neural Engine war für kompilierte Modelle optimiert, deren Dimensionen und Bewegungsmuster weitgehend im Voraus bekannt waren. Diese Spezialisierung senkte bei unterstützten Aufgaben Latenz und Energieverbrauch.

Der Rückblick behauptet nicht, dass die Neural Engine des M1 keine Transformer-Operationen ausführen kann. Er argumentiert, dass der umgebende Datenfluss einige Transformer-Muster ineffizient macht, insbesondere die autoregressive Dekodierung. Dabei wird jeweils ein Token erzeugt, während Modellgewichte und ein wachsender Attention-Cache wiederholt gelesen werden.

Diese Neubewertung schafft die zentrale Spannung des Artikels. Apple baute eine effiziente Engine, indem es Datenbewegungen auf einen erwarteten Workload zuschnitt. Moderne KI veränderte den dominanten Workload schneller, als sich eine feste Hardwarearchitektur verändern konnte.

Reverse Engineering von Apples Neural Engine im Rückblick legt die eigentliche Einschränkung offen

Die prägende Einschränkung der Neural Engine im M1 ist nicht ihre Rechenkapazität, sondern der Weg, den Daten um diese Recheneinheiten herum nehmen müssen.

Der reverse-engineerte Treiber sendet keine Befehle auf hoher Ebene wie CONV, MATMUL oder RELU direkt an die Hardware. Apples Compiler hat diese neuronalen Operationen bereits vor Beginn der Ausführung in Aufgabenbeschreibungen umgewandelt.

Eine Aufgabenbeschreibung ist ein strukturierter Block aus Konfigurationsdaten. Er programmiert Registergruppen, die Tensor-Dimensionen, Speicheradressen, Aktivierungsfunktionen, Abhängigkeiten und Datentransfers steuern. Der Treiber legt die Beschreibung im Speicher ab, richtet den Task Manager darauf aus und betätigt eine Hardware-„Türklingel“.

Nach dieser Einreichung steuert die Neural Engine den Auftrag bis zum Abschluss. Sie löst einen Interrupt aus, wenn die Aufgabe fertig ist. Der Hostprozessor steuert nicht jede mathematische Anweisung, während die Operation läuft.

Yoon folgert, dass der ANE ein Befehlssatz im vertrauten CPU- oder GPU-Sinn fehlt. Ihre Aufgabenbeschreibungen konfigurieren einen domänenspezifischen Datenpfad, statt ein beliebiges Programm bereitzustellen. Jede Beschreibung steht für einen Durchlauf durch diesen Datenpfad.

Die Aufgabe beginnt mit dem Laden von Konfigurationsregistern. Dedizierte Transferblöcke bewegen anschließend Gewichte und Eingabeaktivierungen aus dem Hauptspeicher in getrennte lokale Speicherbereiche. Die Rechenkerne führen Reduktionen aus, eine Nachverarbeitung wendet eine Aktivierung an, und ein weiterer Transferblock gibt das Ergebnis zurück.

Diese Abfolge begünstigt Operationen mit vorhersehbarer Wiederverwendung. Eine Faltung kann denselben kompakten Satz gelernter Filter auf viele Bildbereiche anwenden. Der Beschleuniger kann seine Rechenpfade auslasten, ohne wiederholt große neue Gewichtssätze abrufen zu müssen.

Transformer-Dekodierung verändert dieses Gleichgewicht. Jedes neue Token kann das Streamen eines wesentlichen Teils der Modellparameter erfordern. Die Rechenoperationen bleiben erkennbar, doch die Datenbewegung wird zum begrenzenden Kostenfaktor.

Das M1-Layout verschärft das Problem, weil es Speicher für Gewichte von lokalem Speicher für Aktivierungs-Kacheln trennt. Yoon identifiziert im Design etwa 1 MiB Kernel-Speicher und 2 MiB Kachel-Speicher. Die Untersuchung argumentiert, dass die Architektur nicht darauf ausgelegt war, lokal erzeugte Tensoren effizient als Gewichte zu interpretieren.

Für die Modelle, die Apple 2017 anvisierte, war das eine vernünftige Annahme. CNN-Inferenz behandelt gelernte Gewichte im Allgemeinen als feste Kernel und Aktivierungen als Daten, die zwischen Schichten fließen. Transformer-Attention verwischt diesen Unterschied, weil während der Ausführung erzeugte Werte spätere Matrixoperationen speisen können.

Ein Key-Value-Cache veranschaulicht das Problem. Der Cache speichert Repräsentationen früherer Tokens, damit das Modell sie während der Generierung erneut verwenden kann. Sein Inhalt wächst mit längeren Gesprächen oder Dokumenten, wodurch effizienter Speicherzugriff zunehmend wichtiger wird.

Feste Tensor-Dimensionen sind nicht das zentrale Hindernis. Eine kompilierte Aufgabe kann über eine sich ändernde Cache-Länge iterieren, und der Aufwand für die Aufgabeneinreichung kann gering bleiben. Schwieriger ist es, Daten wiederholt durch Pfade zu führen, die auf die Wiederverwendung in CNNs zugeschnitten sind.

Deshalb bieten reine Angaben zu Operationen pro Sekunde nur einen unvollständigen Vergleich. Die Spitzenrechenleistung beschreibt, wie schnell das MAC-Array unter günstigen Bedingungen arbeiten kann. Sie zeigt nicht, wie oft diese Einheiten auf Gewichte, Aktivierungen oder Zwischenergebnisse warten.

Unabhängige Forschung ist aus einer anderen Richtung zu einer kompatiblen Schlussfolgerung gelangt. Die Orion-Forschungsarbeit aus dem Jahr 2026 beschreibt 20 Einschränkungen beim Programmieren der ANE über private Schnittstellen. Die Autoren nennen Kompilierung, Speicherlayout und numerisches Verhalten als praktische Hürden.

Orion berichtet dennoch über aussagekräftige Transformer-Ergebnisse. Auf einem M4 Max erzeugte das System für GPT-2 mit 124 Millionen Parametern mehr als 170 Tokens pro Sekunde. Zudem trainierte es ein Modell mit 110 Millionen Parametern 1.000 Schritte lang in 22 Minuten.

Diese Messungen zeigen, dass die ANE Workloads von Sprachmodellen ausführen kann. Sie belegen nicht, dass sie für jedes große Modell oder jede Phase der Inferenz das beste Ziel ist. Der Unterschied zwischen technischer Möglichkeit und architektonischer Eignung bleibt entscheidend.

Apples öffentliche Software hält die Hardware auf Distanz

Entwickler können die Neural Engine über Core ML anfordern, doch Apple kontrolliert weiterhin, wie Workloads kompiliert, aufgeteilt und verteilt werden.

Apple stellt die Neural Engine primär über Core ML bereit, sein öffentliches Framework für die Bereitstellung von Modellen für maschinelles Lernen. Entwickler liefern ein kompatibles Modell, während das Framework entscheidet, ob einzelne Operationen die CPU, GPU oder Neural Engine nutzen sollen.

Apples Compute-Unit-Steuerungen erlauben einer Anwendung, Kombinationen dieser Prozessoren zuzulassen. Ein Entwickler kann alle verfügbaren Einheiten freigeben oder GPU beziehungsweise Neural Engine ausschließen. Die öffentliche Schnittstelle bietet keine direkte Programmierung der Aufgabenbeschreibungen der ANE.

Dieses Modell schützt die Portabilität über Apple-Geräte hinweg. Eine Anwendung kann die benötigte Vorhersage beschreiben, ohne das Registerlayout einer bestimmten Chipgeneration zu kodieren. Apple kann Compiler und Planungsrichtlinien überarbeiten, während die Anwendungsschnittstelle stabil bleibt.

Der Kompromiss ist mangelnde Transparenz. Entwickler können sich nicht darauf verlassen, dass Core ML jede unterstützte Operation auf einer bestimmten Engine platziert. Sie können das endgültige Low-Level-Programm auch nicht mit der Kontrolle untersuchen, die man von GPU-Compute-APIs erwartet.

Apple erklärt, dass die Core-ML-Ausführung CPU, GPU und Neural Engine nutzen und dabei Speicherverbrauch sowie Energiebedarf senken kann. Dieser Ansatz eignet sich für Anwendungen, die effiziente On-Device-Inferenz ohne hardwarespezifische Optimierung anstreben.

Für Forschende, die architektonische Grenzen untersuchen, ist er weniger zufriedenstellend. Ein Benchmark könnte auf einen anderen Prozessor zurückfallen, einen Graphen über mehrere Prozessoren aufteilen oder auf Compiler-Transformationen treffen, die das zugrunde liegende Hardwareverhalten verschleiern.

Die Reverse-Engineering-Arbeit beseitigt einen Teil dieser Unsicherheit. Sie untersucht Aufgabenbeschreibungen, Registerschreibvorgänge, Warteschlangen, Interrupts und Speicherpfade unterhalb von Core ML. Diese Perspektive hilft dabei, durch Software auferlegte Einschränkungen von durch das Silizium geschaffenen Beschränkungen zu unterscheiden.

Private Schnittstellen schaffen jedoch eigene Unsicherheit. Ihnen fehlen Apples öffentliche Kompatibilitätsgarantien, und sie können sich mit einem Betriebssystem-Update ändern. Forschungscode, der heute funktioniert, könnte nach Änderungen am Compiler, Modellformat oder Runtime-Dienst versagen.

Diese Lücke bringt Apple in eine ungewöhnliche Position. Das Unternehmen liefert dedizierte Hardware für maschinelles Lernen für Smartphones, Tablets, Macs und Headsets aus. Unabhängige Entwickler haben jedoch nur begrenzte Kontrolle über einen der markantesten Blöcke in diesen Prozessoren.

Für Mainstream-Anwendungen kann diese Einschränkung eine bewusste Produktentscheidung sein. Apple optimiert das gesamte Gerät und entscheidet, wo jede Operation ausgeführt wird. Die meisten Entwickler profitieren stärker von vorhersehbarer Bereitstellung als von direktem Registerzugriff.

Entwickler generativer KI benötigen häufig das Gegenteil. Sie experimentieren mit Quantisierungsformaten, Attention-Kerneln, Cache-Layouts und fusionierten Operationen. Außerdem vergleichen sie die Leistung über sich rasch wandelnde Modellarchitekturen hinweg.

GPUs ermöglichen diese Experimente, weil ihre Programmiermodelle allgemeinere Rechenoperationen bereitstellen. Entwickler können neue Kernel implementieren, ohne auf einen dedizierten Compilerpfad warten zu müssen. Dafür tragen sie mehr Verantwortung für Synchronisierung, Speicherzugriffe und Performance-Tuning.

Die eigenständige Neural Engine steht am anderen Ende dieses Spektrums. Ihr Compiler und ihr fester Datenpfad können eine effiziente Ausführung liefern, wenn ein Modell dazu passt. Ändert sich die Arbeitslast, wird die Spezialisierung vom Vorteil zur Einschränkung.

Apples Softwarestrategie verhindert, dass Entwickler diese Spannung direkt auflösen. Core ML kann Hardwareunterschiede verbergen, aber es kann ein auf CNNs ausgerichtetes Speichersystem nicht wie eine flexible GPU agieren lassen. Reverse Engineering legt die Grenze offen, die das Framework normalerweise verdeckt.

Der M5 macht die GPU zum Hauptkonkurrenten

Apples M5 schafft die eigenständige Neural Engine nicht ab, gibt der GPU jedoch eine direktere Rolle in der KI-Roadmap des Unternehmens.

Apple kündigte den M5 im Oktober 2025 mit einer 10-Core-GPU an, die in jedem Core einen Neural Accelerator enthält. Der Chip behielt zudem eine verbesserte 16-Core-Neural-Engine. Dieses Design platziert spezialisierte Matrixhardware auf beiden Seiten des Architekturwettbewerbs.

Laut Apples M5-Chip-Ankündigung bietet die neue GPU mehr als die vierfache Spitzen-KI-Rechenleistung der M4-GPU. Apple erhöhte zudem die Bandbreite des Unified Memory auf 153GB/s, knapp 30 Prozent über dem M4.

Dabei handelt es sich um von Apple kontrollierte Messungen, und die Details der Arbeitslast bestimmen die tatsächliche Anwendungsleistung. Dennoch ist der Ort der neuen Beschleuniger aufschlussreicher als der Schlagzeilen-Multiplikator. Apple integrierte sie in programmierbare GPU-Cores, statt sich ausschließlich auf die separate Neural Engine zu verlassen.

Die GPU verbindet spezialisierte Matrixausführung mit einer Umgebung, die bereits für sich wandelnde Algorithmen geeignet ist. Apple zufolge können Entwickler die Neural Accelerators über Tensor-APIs in Metal 4 programmieren. Das eröffnet einen öffentlichen Weg zu GPU-basierten KI-Workloads, ohne das private Befehlsformat der eigenständigen ANE offenzulegen.

Yoon interpretiert diesen Wandel als den Anfang vom Ende der eigenständigen NPU, also der Neural Processing Unit. Diese Formulierung ist bewusst provokant, und Apples Produktentscheidungen bestätigen bislang keinen tatsächlichen Rückzug.

Der M5 enthält weiterhin eine separate Neural Engine. Apple beschreibt sie als schneller und bringt sie mit Systemfunktionen wie Bildverarbeitung und der Erzeugung räumlicher Personas in Verbindung. Diese Aufgaben ähneln den begrenzten, vorhersehbaren Inferenz-Workloads, die dedizierte Beschleuniger gut bewältigen.

Die besser belegbare Schlussfolgerung ist enger gefasst. Apple behandelt die GPU nun als primäres Ziel für anspruchsvolle generative KI-Workloads, während die Neural Engine ihre Rolle bei effizienter Systeminferenz behält.

Diese Aufteilung entspricht den per Reverse Engineering gewonnenen Erkenntnissen. Eine GPU kann Matrixbeschleunigung mit flexiblen Speicheroperationen, allgemeinen Kerneln und direktem Entwicklerzugriff kombinieren. Eine NPU mit fester Funktion kann den Overhead für stabile Graphen mit bekannten Ausführungsmustern minimieren.

Keines der beiden Designs gewinnt bei jeder Arbeitslast. Ein General-Purpose-Prozessor verwendet Fläche und Energie für Flexibilität, die eine feste Pipeline vermeidet. Eine spezialisierte Engine verliert an Anpassungsfähigkeit, wenn Modelle neue Datenbewegungsmuster verlangen.

Der M5 deutet darauf hin, dass Apple beides will. Seine separate Neural Engine kann etablierte On-Device-Funktionen unterstützen, während GPU Neural Accelerators auf Modelle zielen, deren Operatoren und Speicherverhalten sich weiter verändern.

Diese Hybridstrategie setzt auch Apples Software-Stack unter Druck. Core ML muss zwischen zunehmend leistungsfähigen Prozessoren wählen. Metal muss Entwicklern genug Kontrolle geben, um die neuen GPU-Einheiten auszunutzen. Der Compiler muss vermeiden, Daten so häufig zwischen Prozessoren zu verschieben, dass Transferkosten die Beschleunigung aufzehren.

Der Druck entsteht daher nicht einfach durch Nvidia gegen Apple oder macOS gegen Linux. Es ist ein Wettbewerb innerhalb von Apples eigenem Silizium zwischen Festfunktions-Effizienz und programmierbarer Beschleunigung.

Dieser Wettbewerb begann lange vor der generativen KI. Apples Chips teilen Arbeit bereits zwischen CPUs, GPUs, Media Engines, Bildprozessoren und Sicherheitshardware auf. Der Unterschied besteht heute darin, dass sich das Design von KI-Modellen in einem Tempo verändert, das lange Hardwareplanungszyklen besonders riskant macht.

Die Entwicklung und Validierung eines dedizierten Blocks kann Jahre dauern. Transformer-Architekturen, Attention-Varianten und Quantisierungstechniken können sich innerhalb weniger Monate verändern. Anpassungsfähigere Beschleunigung in die GPU einzubetten, senkt die Kosten falscher Annahmen.

Reverse Engineering beweist nicht das Ende der Neural Engine

Der Rückblick erklärt einen architektonischen Fehlabgleich, kann aber weder Apples künftigen Produktplan belegen noch jede neuere ANE-Implementierung vermessen.

Die tiefsten Erkenntnisse betreffen die M1-Generation. Apple hat seitdem mehrere Prozessorfamilien ausgeliefert, und interne Details können sich ohne öffentliche Dokumentation verändern. Schlussfolgerungen über spätere Chips erfordern direkte Messungen statt visueller Ähnlichkeit oder Marketingnamen.

Yoon räumt Unsicherheit bei Teilen der Analyse des physischen Layouts ein. Die-Bilder können große Speicherblöcke und wiederkehrende Rechenstrukturen sichtbar machen, erklären aber nicht jede Routing-Entscheidung. Einige Schlussfolgerungen bleiben fundierte Interpretationen.

Die Untersuchung konzentriert sich zudem auf die Hardwarestruktur statt auf einen umfassenden Anwendungsbenchmark. Sie zeigt, warum Speicherbewegungen bestimmte Workloads begrenzen dürften. Sie vergleicht jedoch nicht jedes Modell unter identischen Leistungsgrenzen über ANE, GPU und CPU hinweg.

Orion liefert nützliche neuere Messungen, nutzt jedoch private APIs und Forschungssoftware. Seine GPT-2- und TinyStories-Experimente zeigen Zugriff und Fähigkeiten, nicht eine breite Produktionsreife für aktuelle große Sprachmodelle.

Ein weiteres offenes Projekt hat direktes Training über reverse-engineerte private Schnittstellen berichtet. Seine M4-Messungen verorten den FP16-Durchsatz bei etwa 18,6 Billionen Operationen pro Sekunde und den INT8-Durchsatz bei etwa 35,1 Billionen Operationen pro Sekunde. Diese Werte hängen von ausgewählten Convolution-Konfigurationen ab und sollten nicht auf vollständige Modelle verallgemeinert werden.

Die Reife der Software ist genauso wichtig wie die Hardware. Ein hochoptimierter Compiler kann Graphen umstrukturieren, Operationen zusammenführen und Transfers reduzieren. Ein Forschungstreiber kann die Engine zwar korrekt freilegen, dabei aber viel Leistung ungenutzt lassen.

Auch das gegenteilige Risiko gilt. Spitzen-Mikrobenchmarks können Recheneinheiten unter Idealbedingungen auslasten und zugleich reale Modellengpässe verschleiern. End-to-End-Latenz, Speichernutzung, Energieverbrauch und Kompilierungszeit entscheiden darüber, ob ein Beschleuniger einer Anwendung hilft.

Apple könnte die eigenständige Neural Engine auch neu gestalten und ihren Produktnamen beibehalten. Größerer gemeinsamer Speicher, überarbeitete Datenpfade oder neue Aufgabenformate könnten die beim M1 gefundenen Einschränkungen beheben. Die M5-Ankündigung legt diese Detailtiefe nicht offen.

Sicherheit ist ein weiterer Grund für kontrollierten Zugriff. Apple setzt Neural-Engine-Hardware in geschützten biometrischen Workflows ein. Die Plattform-Sicherheitsdokumentation des Unternehmens beschreibt Zustandsrücksetzungen und Speicherkontrollen für den sicheren Betrieb der Neural Engine auf neueren Systemen.

Diese Rolle erfordert nicht, dieselbe Hardware für beliebige Linux-Workloads zu öffnen. Sie bedeutet auch, dass die fortgesetzte Präsenz des Blocks Aspekte der Systemarchitektur widerspiegeln kann, die über Sprachmodelle für Verbraucher hinausgehen.

Energieeffizienz bleibt ein weiterer fehlender Vergleich. Autoregressives Decoding läuft möglicherweise natürlicher auf programmierbarer GPU-Hardware, doch eine dedizierte Engine kann bei Vision-, Audio- und Klassifizierungsaufgaben weiterhin überlegen sein. Apple verkauft batteriebetriebene Geräte, bei denen diese Einsparungen zählen.

Die glaubwürdige Aussage lautet daher nicht, dass die Neural Engine gestorben ist. Vielmehr decken ihre ursprünglichen Designannahmen nicht länger die gesamte Bandbreite strategisch wichtiger KI-Workloads ab.

Diese Unterscheidung hält Retrospectively Reverse-Engineering Apple's Neural Engine in der Evidenz verankert. Das Projekt beleuchtet eine architektonische Weggabelung, während Apples Produktveröffentlichungen bestimmen werden, wie weit das Unternehmen welchem Weg folgt.

Drei Signale werden zeigen, welche Architektur gewinnt

Apples nächste APIs, Benchmarks und Chip-Layouts werden zeigen, ob die M1 Neural Engine ein dauerhaftes Vorbild oder ein spezialisierter Zweig war.

Das erste Signal ist der Entwicklerzugang zu den Neural Accelerators der M5-GPU. Metal 4 muss nützliche Tensoroperationen offenlegen, ohne so viel Scheduling zu verbergen, dass Forschende erneut vor einer Black Box stehen.

Funktionierende Werkzeuge würden die These stärken, dass Apple für sich schnell wandelnde Modelle programmierbare GPU-Beschleunigung gewählt hat. Begrenzte APIs oder eingeschränkte Operatorunterstützung würden diese Interpretation schwächen und eine größere Rolle für von Core ML verwaltete Hardware bewahren.

Das zweite Signal ist die End-to-End-Leistung bei repräsentativen Transformer-Workloads. Sinnvolle Vergleiche müssen Prompt-Verarbeitung, Token-Generierung, Speicherverhalten bei langem Kontext, Energieverbrauch und Modellladezeit umfassen.

Mikrobenchmarks allein werden die Frage nicht entscheiden. Ein Prozessor kann beim Matrixdurchsatz führen und dennoch Zeit durch Gewichtstransfers, Cache-Bewegungen oder Graph-Kompilierung verlieren. Messungen sollten zudem ausweisen, welche Recheneinheit jede Operation ausgeführt hat.

Ergebnisse aus M5-Anwendungen werden besonders wichtig sein. Lokale Sprachmodelle und Diffusionssoftware können die neuen GPU-Beschleuniger unter Workloads testen, die Apple ausdrücklich hervorgehoben hat. Konsistente Gewinne würden den Schritt hin zu Beschleunigung in programmierbaren Cores bestätigen.

Das dritte Signal ist die Architektur von Apples nächster eigenständiger Neural Engine. Apple kann die Bezeichnung mit 16 Cores beibehalten und darunter Speichergröße, Interconnects, Scheduling und unterstützte Präzision verändern.

Ein neu gestaltetes lokales Speichersystem würde die Annahme infrage stellen, dass sich der eigenständige Block seinem Ende nähert. Minimale Änderungen in Verbindung mit größeren GPU-Investitionen würden Yoons Interpretation stützen.

Linux-Fortschritte bieten einen sekundären Weg zur Überprüfung. Die Asahi-Community verfügt über umfassende Erfahrung darin, Apple silicon durch Clean-Room-Beobachtung und Experimente zu dokumentieren. Ihre Reverse-Engineering-Arbeit hat bereits offene Treiber für andere undokumentierte Blöcke hervorgebracht.

Ein nutzbarer ANE-Treiber würde Forschenden erlauben, die Entscheidungen von Core ML mit direkter Aufgabenübermittlung zu vergleichen. Er könnte auch zeigen, ob alternative Compiler Leistung zurückgewinnen können, die Apples öffentliches Framework unzugänglich lässt.

Linux-Unterstützung sollte jedoch nicht mit dem wichtigsten kommerziellen Ergebnis verwechselt werden. Der Treiber ist relevant, weil er verborgenes Hardwareverhalten in überprüfbare Evidenz verwandelt. Apples eigene Geräte, Frameworks und Workloads werden über die Zukunft der Architektur entscheiden.

Entwickler sollten beobachten, wo Apple neue öffentliche Programmierbarkeit platziert. Sie sollten außerdem theoretischen Durchsatz von vollständiger Anwendungsleistung trennen. Der Prozessor mit der größten Schlagzeilenzahl ist nicht zwangsläufig derjenige, der Modelldaten effizient bewegt.

Teams, die ähnliche technische Untersuchungen durchführen, benötigen eine dauerhafte Dokumentation von Experimenten, Registerbefunden, Benchmarks und verworfenen Hypothesen. Eine durchsuchbare Engineering-Wissensdatenbank kann diese Evidenz verknüpft halten, während sich Werkzeuge und Chipgenerationen verändern.

Retrospectively Reverse-Engineering Apple's Neural Engine hält letztlich einen seltenen Moment fest, in dem älteres Silizium eine neue Strategie erklärt. Der M1 zeigt Nutzen und Kosten, CNN-Annahmen in Hardware zu verankern. Der M5 zeigt, wie Apple Flexibilität hinzufügt, ohne Spezialisierung sofort aufzugeben.

Die nächste Frage ist konkret: Werden künftige Apple-Chips programmierbare GPU-Beschleunigung ausbauen und die Neural Engine stabilen Systemaufgaben überlassen, oder wird Apple den eigenständigen Block für Transformer neu aufbauen? Beobachten Sie die APIs und das Speicherverhalten, nicht nur die TOPS-Zahl.