Dokumentation

ANE-Machbarkeit: äquivalente Transformationen und ein messbares 10×-Ziel

Forschungsdatum: 2026-09-20. Hardware: M3 Max, 40-Kern-GPU, 128 GiB. Dieses Dokument beschreibt Hypothesen und mathematische Schranken, keine Behauptung eines neuen gemessenen Speedups. Der Ausgangspunkt sind die ursprünglichen Laya-Gewichte und die schnellere MLX-FP16-Laufzeit. Die Engineering-Experimente und Messungen können die Ausgangsbeobachtungen unten überholen.

Das beste erste Experiment ist eine Neuschreibung des gesamten Transformers mit fester Form und Channel-First, gefolgt von einer Inspektion des Ausführungsplans. Das plausibelste Größenordnungsziel ist die Energie pro abgeschlossener Entscheidung, sofern das Modell eine nützliche Latenz und Genauigkeit behält. Allein das Ändern einer Core ML-Compute-Unit-Einstellung ist kein ausreichender Beleg dafür, dass die Neural Engine das Modell ausgeführt hat.

Die nachfolgenden Engineering-Experimente haben diese Neuschreibung implementiert, und der gemessene Geschwindigkeits-/Energiebericht hält nun die Ergebnisse fest. Der unkomprimierte Kandidat verbessert die Effizienz, hat aber das 10×-Ziel nicht erreicht. Die Hypothesen und der ursprüngliche Nenner unten bleiben als Forschungsaufzeichnung erhalten; verwende den späteren Vergleich mit kompiliertem MLX für gemessene Performance-Aussagen.

Das Ziel definieren, bevor optimiert wird

Für dieselben Eingaben, denselben Checkpoint, dieselbe Präzisionsrichtlinie und dieselbe Anzahl abgeschlossener Entscheidungen definiere:

t = elapsed time / completed decisions
P = average measured power over that same interval
E = integrated energy / completed decisions = P × t

S = t_MLX / t_candidate                    speed gain
R = P_MLX / P_candidate                    power reduction factor
S × R = E_MLX / E_candidate                 energy efficiency gain

Verwende in dieser Identität die Blockmittel-Latenz, kein Latenzperzentil. Berichte P50 und P95 getrennt. Ein Ergebnis, das 2× schneller bei einem Fünftel der Leistung ist, ist eine 10×-Energieverbesserung. Ein Ergebnis, das halb so schnell ist, benötigt eine 20×-Leistungsreduktion, um dieselbe 10×-Energieverbesserung zu liefern. Geschwindigkeit mit einer bereits berechneten Energieverbesserung zu multiplizieren, zählt die verstrichene Zeit doppelt.

Es gibt zwei verschiedene Leistungstests:

  1. Gesättigte sequenzielle Inferenz: Messe tatsächlichen Durchsatz, Latenz und Joule pro Entscheidung. Ein leistungsärmerer, aber langsamerer Kandidat ist nicht automatisch effizienter.
  2. Gleiche angebotene Last, etwa dieselbe Snake-Tick-Rate: Beide Kandidaten müssen dieselbe Arbeit innerhalb der Frist erledigen. Berichte die mittlere Leistung, die Gesamtinterval-Energie, Fristfehltreffer und abgeschlossene Entscheidungen. Länger schlafen oder Arbeit verwerfen ist keine Optimierung.

Halte die gemessene Leistungsdomäne fest. CPU + GPU + ANE-Telemetrie ist nicht notwendigerweise die Leistung der ganzen Maschine oder des Akkus und darf nicht als solche bezeichnet werden. Berichte die rohe Energie und, falls brauchbar, die gepaarte um Leerlauf bereinigte Energie. Wenn Last minus Leerlauf nahe am Rauschen liegt, bewahre die Unsicherheit, statt sie still zu begrenzen und ein enormes Verhältnis zu melden. Halte Tokenisierung, Eingabekopien, CPU-Fallback und Nachverarbeitung innerhalb der Abrechnungsgrenze des Endpunkts.

Ausgangsbelege und der Nenner

Der aktuelle mehrsprachige MLX-Benchmark misst eine einzelne 91-Token-Frage mit 7.870 ms P50 / 9.870 ms P95. Der englische MLX-Benchmark misst eine 93-Token-Frage mit 13.334 / 13.734 ms. Das sind End-to-End-predict-Messungen, ohne Modellladen und Warmup. Ein neuer Vergleich muss den stärksten anwendbaren MLX-Pfad erneut ausführen, einschließlich seiner Opt-in-Compile- und Prompt-Cache-Einstellungen, wo die Workload sie zulässt; ein historisches Eager-Ergebnis ist kein dauerhafter Nenner.

Der bestehende mehrsprachige Core ML-Export misst 11.277 ms P50 mit CPU + GPU, 78.037 ms mit ALL und 81.336 ms mit CPU + NE. Der letztgenannte Plan verzeichnet 1,318 CPU-bevorzugte Operationen und keine NE-bevorzugten Operationen; 24 SDPA-Operationen haben unbekannte Gerätemetadaten. Das belegt keine NE-Ausführung. Der Plan listet viele Operationen als NE-unterstützt, was von NE-bevorzugt verschieden ist. Apple beschreibt die Compute-Plan-Gerätenutzung als antizipierte Gerätenutzung, sodass selbst ein günstiger Plan durch Laufzeit-Profiling oder beobachtbare NE-Aktivität gestützt werden sollte.

Das bestehende FP16-Regressionsgate ist 100% Fixture-Argmax-Übereinstimmung, endliche deterministische Ausgaben und höchstens 0.02 absolute Abweichung bei kalibrierten und Action-Wahrscheinlichkeiten. Das ist eine Konvertierungstreue-Prüfung auf einem kleinen Korpus. Sie belegt keine allgemeine Aufgaben-Genauigkeit, keine Snake-Kompetenz und keine Qualität eines komprimierten Modells.

Äquivalente Graphtransformationen

Apples Transformer-Deployment-Studie motiviert vierdimensionale BC1L-Aktivierungen, 1×1-Konvolutionen, die Aufteilung der Attention in Heads und die Reduktion von Layout-Kopien. Ihr veröffentlichtes 10×-Beispiel ist ein anderes Modell, Gerät und eine andere Baseline; es lässt sich nicht auf den MLX-Vergleich hier übertragen. Betrachte diese Layout-Empfehlungen als Kandidaten, die auf diesem OS und Chip zu testen sind, nicht als vollständigen aktuellen Hardware-Supportvertrag.

Lineare Projektionen und das gated MLP

Sei X[b,l,i] die bestehende Aktivierung, und definiere U[b,i,0,l] = X[b,l,i]. Für eine lineare Schicht:

Y[b,l,o] = sum_i W[o,i] X[b,l,i] + bias[o]
K[o,i,0,0] = W[o,i]
Conv2D(U,K)[b,o,0,l] = Y[b,l,o]

Dies ändert Layout und Operatordarstellung, ohne die reellwertige Funktion zu ändern. Behalte dieses Layout über den gesamten Encoder und beide Transformer-Schichten des Decision Head. Eine Umwandlung hin und zurück um jede lineare Schicht kann den Nutzen zunichtemachen. QKV kann eine einzelne D → 3D-Konvolution bleiben; teile ihre Kanalausgabe in Q, K und V auf. Ebenso: Erhalte die bestehende fusionierte D → 2I-Encoder-Projektion, teile die Kanäle in Value und Gate auf, wende das ursprüngliche exakte GELU auf Value an, multipliziere mit Gate und projiziere I → D.

Bei FP16 richtet sich eine durch 32 teilbare Sequenzbreite außerdem an der in Apples Studie beschriebenen 64-Byte-Ausrichtung der letzten Achse aus. Die anfänglichen Shapes sind B=1,L=96 für das kurze API-Fixture und B=3,L=64 für die kompakte Snake. Eine Empfehlung von Vielfachen von 32 folgt hier diesem Puffermodell; sie ist keine Erlaubnis, jede Workload auf eine große beliebige Länge aufzufüllen. Snake braucht keine 96 Tokens.

Attention und RoPE

Behalte für jeden Head Q und V als (B,d,1,L) und transponiere K zu (B,L,1,d). Berechne:

score[b,k,0,q] = sum_c Q[b,c,0,q] K[b,k,0,c] / sqrt(d)
weight = softmax(score + additive_mask, axis=key)
out[b,c,0,q] = sum_k weight[b,k,0,q] V[b,c,0,k]

Die Key-Achse ist in dieser Darstellung Achse 1. Konkateniere die Head-Ausgaben auf der Kanalachse. Das ist dieselbe Attention-Funktion; eine falsche Softmax-Achse ändert sie still. Apples Referenz-Attention-Implementierung demonstriert die entsprechenden zwei vierdimensionalen Kontraktionen. Inspiziere die konvertierten MIL-Operatoren: Ein einsum zu schreiben garantiert nicht das beabsichtigte Gerät oder Lowering.

Wende RoPE vor QK auf die Kanalpaare jedes Heads an. Erhalte die Split-Half-Konvention, die ursprünglichen Positionen und das Theta pro Schicht des Checkpoints. In diesem mehrsprachigen Checkpoint verwenden sowohl das vollständige als auch das lokale RoPE Theta 160000. Die ersten und zweiten Hälften von allen zusammen konkatenierten Heads zu trennen ist falsch; teile innerhalb jedes 64-Kanal-Heads. Eine positionsabhängige Rotation lässt sich im Allgemeinen nicht in eine einzelne positionsunabhängige Gewichtsmatrix falten.

Die lokale Regel ist bidirektional abs(q-k) <= 64, inklusive. Erhalte das Key-Padding und die bestehende Padded-Query-Regel. Konstante positionsabhängige Teile können vor dem Tracing für feste Shapes berechnet werden; eine Änderung des Sample-Paddings muss weiterhin die Key-Maske beeinflussen. Den mathematischen Ausschluss durch eine endliche große negative Maske zu ersetzen, ist eine numerische Approximation, sofern sie nicht dem Finite-Precision-Verhalten der ursprünglichen Implementierung entspricht; verifiziere adversariale und gepaddete Eingaben.

LayerNorm ist nicht mit anderen Normalisierungen austauschbar

Für jedes (b,l) nur über Kanäle reduzieren:

mu = mean_c U
v = mean_c (U-mu)^2
normalized = (U-mu) / sqrt(v + epsilon)
output = normalized * gamma + beta

Erhalte das ursprüngliche Epsilon, die affine Reihenfolge, die Populationsvarianz, die Identitätsnormalisierung der ersten Schicht, das exakte GELU und die Residual-Reihenfolge. Apples Referenz-LayerNorm verwendet eine andere affine Reihenfolge; ihr DistilBERT-Adapter kompensiert dies durch Transformation des Bias. Diese Klasse direkt zu kopieren und Layas State-Dict zu laden, wäre bei Nicht-Null-Biases falsch. Ein expliziter Affin-Ausdruck in Originalreihenfolge vermeidet außerdem eine Division durch ein möglicherweise nullwertiges Gamma.

Aktivierungen zu begrenzen, GELU auf tanh umzustellen oder LayerNorm durch RMSNorm zu ersetzen, ändert die Funktion. Wenn quadrierte Werte überlaufen, ist eine positive Umskalierung eine mathematisch äquivalente Option:

normalize(x/a, epsilon/a^2) = normalize(x, epsilon), for a > 0

Die Finite-Precision-Akkumulation benötigt weiterhin Paritätstests. FP32-Reduktionen können Kopien oder CPU-Fallback kosten; inspiziere daher den Plan, statt das numerische Verhalten still zu lockern.

Nicht unterstützte Arbeit an die Modellgrenzen verschieben

Wenn Embedding-Lookup, dynamischer Marker-Gather oder der Action-Tail eine zusammenhängende NE-Region verhindern, erstelle einen separaten Kandidaten mit dieser Partition:

CPU: tokenizer → selected embedding rows → embedding LayerNorm
NE candidate: all encoder layers → type embedding addition → both heavy head layers
CPU: marker/CLS selection → small scorer → raw-probability features → action head

Nur die Endpunkte wechseln zwischen Engines. Lagere nicht die Attention oder LayerNorm jeder Schicht auf die CPU aus. Bei mehrsprachigem B=1,L=96 ist ein FP16-Embedding-Tensor 147,456 Bytes groß; bei B=3,L=64 sind es 294,912 Bytes. Beziehe diese Kopien und jede Ausgabekopie des vollständigen Hidden State in die End-to-End-Messung ein.

Die mehrsprachige Token-Tabelle hat 196,608,000 Parameter, aber jede Anfrage sammelt nur ihre Token-Zeilen. Sie muss nicht in einen ANE-Transformer-Subgraph ausgeliefert werden und darf nicht bei jeder Vorhersage als vollständiger Tabellenlesevorgang gezählt werden. Ihre LayerNorm hat keine Positionsabhängigkeit, sodass eine Offline-Vornormalisierung der Tabellenzeilen real-arithmetisch äquivalent ist. Sie kann Rundung und Speicherpräzision ändern, was eine eigene Paritätsprüfung erfordert. Der Action Head verwendet Wahrscheinlichkeiten aus rohen Marker-Logits, vor der Temperaturkalibrierung; seine Features aus öffentlichen kalibrierten Wahrscheinlichkeiten zu rekonstruieren, ändert das Checkpoint-Verhalten.

Arithmetische Schranken für eine 10×-Latenzaussage

Sei D die Hidden-Breite, I die gated Zwischenbreite des Encoders, N die Anzahl der Encoder-Schichten und H=2 die Anzahl der Decision-Head-Schichten. Die wichtigste Parameteranzahl der Matrix pro Token und die dichte Arithmetik sind:

A = N(4D^2 + 3DI) + 12HD^2
F_dense(B,L) = 2BLA + 4B(N+H)L^2D

Multiplikation und Addition zählen getrennt. Diese Gleichungen schließen Normen, Aktivierungen, Embeddings, Scoring, Masken, Kopien und Laufzeit-Overhead aus. Sie sind kein Profiler. Sie modellieren die aktuelle dichte Attention-Berechnung auch für maskierte lokale Schichten.

Checkpoint D / I / N A FP16-Hauptmatrix-Bytes Dichte Arbeit bei B=1,L=96 Erforderliche effektive Rechenleistung für 10× unter aktueller MLX-P50
Mehrsprachig 768 / 1152 / 22 124,452,864 248.91 MB 24.574 GFLOP 31.23 TFLOP/s innerhalb von 0.787 ms
Englisch / typisierte Architektur 1024 / 2624 / 28 368,312,320 736.62 MB 71.848 GFLOP 53.89 TFLOP/s innerhalb von 1.333 ms, unter Verwendung der englischen Baseline

Das sind erforderliche erreichte Raten, keine behaupteten ANE-Spitzenwerte. Eine Layout-Neuschreibung entfernt Overhead, aber nicht diese dichten Projektionen. Die Hardware muss außerdem eine sequenzielle Kette von 24 oder 30 Attention-/MLP-Blöcken ausführen.

Ein optimistisches Streaming-Modell liefert eine weitere bedingte Untergrenze:

t >= max(F / effective_compute, bytes_from_DRAM / effective_bandwidth)

Der M3 Max mit 40 GPU-Kernen ist mit 400 GB/s Unified-Memory-Bandbreite spezifiziert. Wenn jede Haupt-FP16-Matrix einmal pro Anfrage aus dem DRAM geholt wird, kostet selbst der volle Zugriff auf diese Bandbreite mindestens 0.622 ms für Mehrsprachig und 1.842 ms für Englisch. Der tatsächliche ANE-Bandbreitenzugriff kann kleiner sein, und gecachte oder komprimierte Gewichte ändern die Annahme. Das ist keine unbedingte physikalische Untergrenze. Es zeigt, warum 10× englische Latenz beim unkomprimierten Streaming besonders anspruchsvoll ist und warum die Messung der Energie auch dann nützlich ist, wenn sich die Latenz nur mäßig verbessert.

Für einen gemessenen Anteil f der End-to-End-Zeit, der um den Faktor s verbessert wird, liefert Amdahls Gesetz S = 1 / (1-f+f/s). Selbst eine unendliche Beschleunigung einer Region kann 10× nicht erreichen, sofern sie nicht mindestens 90% der ursprünglichen Latenz einnimmt. Die analoge Schranke verwendet bei der Zielsetzung von Joule pro Entscheidung den Anteil der gemessenen Energie, nicht der FLOPs. Die Selected-Query-Optimierung des finalen Heads entfernt nur wenige Prozent der Modellarithmetik; die lokale Attention-Sparsity ist bei L<=64, wo das lokale Fenster alle Positionen abdeckt, ebenfalls vernachlässigbar. Keines von beiden liefert einen glaubwürdigen eigenständigen 10×-Weg.

Kompression und architektonische Änderungen haben unterschiedliche Verträge

Kandidat Gleiche reellwertige Checkpoint-Funktion? Was es realistisch ändern kann
BC1L-Layout, 1×1-Projektionen, statische Positionen/Masken, Head-Aufteilung Ja, wenn Gleichungen und Eingaben erhalten bleiben Scheduling, Lokalität, Compiler-Partitionierung, Speicherkopien
CPU-Endpunkt-Partition, Offline-Embedding-Norm, ausgewählte Queries im finalen Head Ja in reeller Arithmetik; Rundung validieren Nicht unterstützte Operationen, Paket-Footprint, etwas ungenutzte Arbeit
8/6/4-Bit-Palettierung oder Gewichtsquantisierung Im Allgemeinen nein Gewichtsverkehr/-speicher und möglicherweise Inferenzenergie/-latenz
Pruning gelernter Nicht-Null-Gewichte oder Low-Rank-Faktorisierung Nein, sofern keine algebraisch exakte Struktur existiert Matrixarithmetik und -verkehr nach Wiederherstellung/Kalibrierung
Early Exit, Token-Pruning, weniger Schichten, schmalerer Student Nein Potenziell große Einsparungen; neues Modell und Qualitätsvertrag
Hidden-State-Wiederverwendung über beliebige Fragen hinweg Nein für diesen bidirektionalen Encoder Ungültige Abkürzung; kontextuelle Zustände hängen von der Frage ab
Caching identischer Antworten auf ganze Eingaben Exakt bei Cache-Treffern Workload-Merkmal; keine ungecachte Inferenzgeschwindigkeit

Apples aktuelle Optimierungsübersicht verweist auf Palettierung für NE-Speicher-/Latenzgewinne und identifiziert den neueren W8A8-Compute-Pfad mit A17 Pro/M4. Extrapoliere diesen neueren Hardware-Speedup nicht auf diesen M3 Max. Der Quantisierungs-Performance-Leitfaden warnt außerdem, dass Aktivierungs-Dequantisierung die CPU/GPU-Ausführung verlangsamen kann. Hole zuerst eine NE-residente Baseline und teste dann die Gewichts-Palettierung von 8 Bit abwärts, wobei empfindliche Normen/Scorer nach Bedarf erhalten bleiben.

Das Packen von FP16-Gewichten auf acht oder vier Bit ergibt ein ideales Gewichtsspeicher-Verhältnis von 2× oder 4× vor Metadaten. Das ist kein gleicher Latenzmultiplikator: Dekompression, Aktivierungsbewegung und Berechnung bleiben bestehen. Pruning hilft nur dann zur Laufzeit, wenn die gewählte Darstellung die Nullen tatsächlich ausnutzt. Das Entfernen beliebiger Heads/Schichten oder eine Low-Rank-Trunkierung erfordert Qualitätswiederherstellung und kann die ursprüngliche Modellidentität nicht ohne Einschränkung bewahren.

Für eine Logit-Fehlerschranke pro Eingabe ||z'-z||_infinity <= delta ist ein hinreichendes Argmax-Zertifikat top1(z)-top2(z) > 2delta. Bei identischer positiver Kalibrierungstemperatur T liefert Softmax’ Unendlichkeitsnorm-Lipschitz-Schranke ||p'-p||_infinity <= delta/(2T). Das sind nützliche Diagnosen auf ausgewerteten Eingaben, kein globales Zertifikat für Quantisierung. Erhalte getrennte Close-Margin- und mehrsprachige Evaluierungs-Slices; gesättigte Beispiele können große Logit-Fehler verbergen.

Drei Experimente und Akzeptanz-Gates

  1. Äquivalenter NE-Graph mit fester Form. Exportiere mehrsprachig B=1,L=96,K=4 und Snake B=3,L=64,K=4 mit BC1L-Projektionen, korrektem Per-Head-RoPE, expliziter Attention und ursprünglichem LayerNorm/GELU. Vergleiche Eingabearrays und einzelne Schichtausgaben mit dem ursprünglichen Graphen. Inspiziere, welche großen Projektionen und Attention-Blöcke NE-bevorzugt sind, und prüfe dann die tatsächliche NE-Aktivität zur Laufzeit. Eine Anzahl unterstützter Ops allein ist kein Erfolg. Führe die entsprechende optimierte MLX-Baseline in abwechselnden Blöcken erneut aus.
  2. Eine zusammenhängende Transformer-Insel. Wenn der erste Graph fragmentiert, verschiebe das Embedding und den kleinen finalen Tail an CPU-Grenzen. Vergleiche dies mit dem Vollgraph-Kandidaten unter derselben Leistungsmessung. Behalte einen Kandidaten nur, wenn vollständige Vorhersagen Latenz oder Energie über die beobachtete Lauf-zu-Lauf-Variation hinaus verbessern. Beziehe alle Kopien ein; ein schneller isolierter Encoder reicht nicht.
  3. Energieorientierte Kompression, nachdem das Placement funktioniert. Sceene 8-Bit-Palettierung, dann 6/4-Bit als separate approximative Varianten. Führe das unveränderte Fixture-Gate aus, zurückgehaltene choice/score/noul-Aufgaben, mehrsprachige Eingaben, knappe Gleichstände und Snake-Trajektorien. Veröffentliche Genauigkeit, Wahrscheinlichkeitsabweichung und Kalibrierung zusammen mit der Performance. Aggressive Kompression oder Destillation gehört in ein separat benanntes Modell, wenn sie das gelernte Verhalten ändert.

Verwende vor einer Launch-Aussage dieselben Checkpoint-/Eingabe-Hashes und eine abwechselnde Baseline/Kandidat-Reihenfolge; schließe die Kaltkompilierung aus, berichte sie aber separat. Verwende mindestens fünf anhaltende Blöcke pro Finalist und behalte rohe Latenz-, Aufruf- und Leistungsproben. Fordere die ursprüngliche Fixture-Übereinstimmung und die bestehenden Wahrscheinlichkeitstoleranzen, ohne sie zu lockern, um den Kandidaten zu bestehen, plus stabile endliche Ausgaben und begrenzten Speicher. Miss lange Eingaben und Eingaben an Formgrenzen getrennt von kurzen Demos mit fester Form.

Erkläre 10× nur dann, wenn das relevante Geschwindigkeits-, Gleichlast-Leistungs- oder Energieverhältnis mindestens zehn beträgt, mit einer Unsicherheit, die die Aussage stützt, und dabei die genannten Latenz- und Aufgabenqualitätsgrenzen eingehalten werden. Wenn die untere Unsicherheitsgrenze zehn nicht erreicht, berichte das gemessene Verhältnis. Ein kleinerer Energiegewinn mit verifizierter NE-Ausführung bleibt nützlicher Beleg; er ist kein Größenordnungsergebnis.

Dokumentationsherkunft

Verwendete den erforderlichen Context7-CLI-Workflow: löste Core ML Tools zu /apple/coremltools auf und fragte dann das Transformer-Operator-/Layout-Lowering und das NE-Kompressionsverhalten ab (insgesamt drei Befehle). Prüfte Apples Forschungsartikel, Referenzquelle, aktuelle Core ML-Optimierungsdokumentation, Compute-Plan-Dokumentation und die oben verlinkte Gerätespezifikation. Modellgleichungen, Parameteranzahlen und Ausgangsmessungen wurden aus diesem Repository und seinem MLX-Schwesterprojekt abgeleitet. Von diesem Forschungszweig wurde kein konkurrierender GPU/ANE-Benchmark ausgeführt.