Engineering-Untersuchung: Layas Transformer auf die ANE bringen

Forschungsumgebung: Apple M3 Max (40 GPU-Kerne, 128 GiB Unified Memory), macOS 27.2, Core ML Tools 9.0, PyTorch 2.7.0 und NumPy 2.1.3. Dies ist ein unabhängiger Prototyp unter experiments/ane_engineering/; die veröffentlichte Laufzeit ist unverändert.

Aktuelles Ergebnis

Ein fester mehrsprachiger B=1, L=96-Prototyp weist den vollständigen Encoder, Decision Head und Scorer im antizipierten Compute Plan von Core ML erfolgreich der Neural Engine zu: 6,390 nichtkonstante Operationen bevorzugen ANE, mit geschätzten Kostengewichten, die sich zu ungefähr 1 summieren. Die verbleibenden 3,809 Einträge sind Konstanten. Der ursprüngliche Enumerated-Shape/SDPA-Export bevorzugte CPU für alle 1,318 zugewiesenen Operationen unter CPU_AND_NE, obwohl 988 einzelne Operationen ANE als unterstütztes Gerät aufführten.

Der vollständige Vorhersagepfad des Prototyps maß 5.167 ms p50 über 50 Screening-Aufrufe, einschließlich Tokenisierung, Embedding-Lookup, Attention-Masken, ANE-Inferenz, CPU-Action-Head-Berechnung, Kalibrierung und Formatierung. Der isolierte Core ML-Body maß 4.403 ms p50 über 30 Aufrufe mit synthetischen Embeddings. Letzteres ist eine Komponentenmessung und keine End-to-End-Geschwindigkeitsaussage. Modellladen und Kompilierung sind aus beiden Warm-Timings ausgeschlossen.

Auf der festen Längen-Teilmenge der ursprünglichen FP32-Golden-Reference stimmen 59/59 Antwortvergleiche überein, einschließlich acht Sprachen und choice/score/noul-Fragen. Die größte Änderung der kalibrierten Wahrscheinlichkeit beträgt 0.002925, und 100 wiederholte öffentliche Aufrufe sind endlich und liefern identische gerundete Ergebnisse. Das ursprüngliche 63-Fragen-Fixture enthält drei lange 1,024-Token-Eingaben und eine 147-Token-Eingabe mit 20 Optionen; diese vier Auswertungen werden vom L96-Export ausdrücklich übersprungen. In diesem Fixture treten wiederholte Rubriken auf. Das sind Regressionsvergleiche, keine 59 unabhängigen gelabelten Beispiele und kein Beweis unveränderter allgemeiner Aufgaben-Genauigkeit.

Separate L192- und L1024-Exporte legen ebenfalls alle 6,390 zugewiesenen Body-Operationen auf ANE. L192 besteht 60/60 Vergleiche; L1024 besteht das vollständige 63/63-Golden-Fixture. Beide bestehen 100 wiederholte öffentliche Aufrufe, und der maximale Fehler der kalibrierten Wahrscheinlichkeit bleibt 0.002925. Die Long-Input-Teilmenge selbst hat einen maximalen Fehler von 0.001128. Alle ausgewerteten Token-Nutzungszahlen stimmen mit der Referenz überein.

Dies sind serielle Screening-Läufe, keine gepaarten Vergleiche über Backends hinweg. Body-Timings verwenden 5 Warmup- und 30 gemessene Aufrufe; vollständige Kurzfrage-Timings verwenden 10 Warmup- und 50 gemessene Aufrufe. Der vollständige Pfad umfasst Host-Arbeit und Eingabeprüfungen. Der L96-Screen stammt aus der Zeit vor den letzten zusätzlichen Eingabevalidierungsprüfungen; der finale kontrollierte Vergleich verwendet den aktuellen Adapter und zeichnet seinen Quell-Fingerabdruck auf. Kompilier-/Ladezeiten werden in jedem Prozess nach der Konvertierung gemessen, nicht als Versprechen über den allerersten Systemstart mit leeren Framework-Caches. Große feste Graphen verrichten auch für kurze Anfragen gepaddete Arbeit. Ein praktischer Adapter würde separate Längen-Buckets wählen; jede Anfrage durch L1024 zu leiten, würde den Kurzeingabe-Vorteil verwerfen.

Ein separater Lauf des tatsächlichen workload(1, long=True)-Fixtures bestätigt eine 1,024-Token-Anfrage statt einer auf diese Größe aufgefüllten kurzen Anfrage. Er misst 91.703 ms p50 / 94.776 ms p95 über 50 vollständige Vorhersagen nach zehn Warmup-Aufrufen; alle gerundeten Ausgaben bleiben stabil. Der historische MLX-Long-Input-Benchmark liegt bei 51.98 ms p50. Das sind keine gepaarten Messungen aus derselben Runde, aber dieser Screen liefert keinen Beleg dafür, dass der derzeitige ANE-Graph lange Eingaben beschleunigt. Der Eingabe-Hash, die tatsächliche Token-Länge, die aktuellen Experiment-Fingerabdrücke und die Roh-Timings bleiben in long1024-performance.json erhalten.

Rohbelege:

• Compute Plan des vollständigen Body und Komponenten-Timings
• Validierung der FP32-Referenz mit echten Eingaben und Complete-Predict-Timings
• L192-Validierung
• L1024-Validierung des vollständigen Fixtures
• Single-Layer-Plan und numerische Prüfungen
• Single-MLP-Plan und numerische Prüfungen

MLComputePlan beschreibt antizipiertes Placement, keinen Hardware-Ausführungs-Trace. CPU_AND_NE erlaubt CPU und ANE; es ist kein ANE-only-Schalter. In diesem Experiment bevorzugen alle zugewiesenen Heavy-Body-Operationen ANE, aber die Hardware-Telemetrie zur Laufzeit wird separat bewertet. Die nachfolgende Instruments-Diagnose zeichnete Neural Engine-Hardwareaktivität auf; ihre Tabelle ist global und kann nicht jedes Ereignis diesem Modell zuordnen. Der gepaarte MLX-Vergleich, die Leistungsintegrationsergebnisse und die Trace-Grenzen sind in ANE_BENCHMARKS.md berichtet. Ein nullwertiger ANE-Zähler eines Monitoring-Tools kann ohne Validierung dieses Zählers auf diesem OS/Gerät keine Abwesenheit von ANE-Aktivität belegen.

Warum der ursprüngliche Graph ein schlechtes ANE-Ziel war

Die Baseline erhält ein konventionelles B×L×C-Transformer-Layout, dynamische Shape-Operationen, über ganze Heads gebündelte Attention und Core MLs SDPA-Operator. Unter CPU/ANE-Auswahl enthält ihr Plan 24 SDPA-Operationen ohne berichtete Gerätezuweisung, plus viele Casts, Slices, Shape-Abfragen, Gathers und Transposes. Einige einzelne Operationen unterstützen ANE, aber der Graph als Ganzes wird nicht darauf partitioniert. Die Geräteunterstützung einzelner Operatoren ist daher kein ausreichender Beleg für einen nützlichen ANE-Ausführungspfad.

Der erfolgreiche Prototyp ändert mehrere Dinge gemeinsam. Er ist ein Beleg dafür, dass die Kombination ANE-Placement ermöglicht, keine abgeschlossene Ablation, die einen einzigen störenden Operator identifiziert. Feste SDPA im ursprünglichen Layout und explizite Attention als Kontrollen sind nützliche nächste unterscheidende Experimente.

Apples veröffentlichte Transformer-Richtlinie empfiehlt Channel-First-4D-Tensoren, 1×1-Konvolutionen für Projektionen, Per-Head-Attention und weniger Layout-Kopien. Diese Prinzipien motivierten die Implementierung; Apples historische DistilBERT-Speedups belegen keine 10×-Verbesserung gegenüber der bereits schnellen MLX-FP16-Baseline dieses Projekts. Apples ANE-Transformer-Artikel, Apples Referenzimplementierung.

Prototyp-Architektur und numerischer Vertrag

model.py ist ein separates Exportmodell, das aus den ursprünglichen Checkpoint-Parametern gebaut wird:

• Hidden-Aktivierungen verwenden B,C,1,L. Jedes dichte Gewicht W[out,in] wird zu einem 1×1-Konvolutionskernel K[out,in,0,0], ohne Neutraining oder Gewichtsapproximation.
• Die Attention wird in einzelne 64-Kanal-Heads aufgeteilt. Der Key-Tensor wird einmal transponiert, und zwei explizite Einsums berechnen QK und AV unter Beibehaltung des 4D-Layouts. Softmax läuft über die Key-Achse, Dimension 1.
• RoPE teilt jeden Head in seine zwei 32-Kanal-Hälften. Seine Kosinus-, Sinus- und Basiswerte stammen aus dem ursprünglichen Modell, einschließlich des mehrsprachigen lokalen Theta 160000.
• Die Kanalnormalisierung erhält die ursprüngliche Reihenfolge normalized * weight + bias und das Epsilon. Sie kopiert nicht den anders geordneten Affin-Ausdruck oder das optionale Clipping in Apples Referenz-LayerNorm.
• Die erste Attention-Norm des Encoders bleibt die Identität; der Encoder verwendet exaktes erf-GELU, während die beiden Decision-Head-FFNs ReLU behalten.
• Vollständige Attention und Sliding-Window-Masken erhalten die Valid-Key-Maskierung und die Padded-Query-Regel. Der lokale Radius wird aus local_attention // 2 gelesen.
• Der finale Marker-Gather wird mit einem extern vorbereiteten One-Hot-Selektor und einem 4D-Einsum ausgedrückt. Der Graph behält 32 Marker-Slots, einschließlich inaktiver Slots; der Host ersetzt inaktive Logits durch den ursprünglichen Wert -1e4.

Eine gesamte ursprüngliche FP32-Encoder-Schicht und ihr BC1S-Pendant unterschieden sich in der PyTorch-Layoutprüfung um höchstens 2.29e-5. Der FP16-Core-ML-Schichtausgabefehler war größer, wie für diesen Präzisions-/Backend-Wechsel erwartet. Die Body-Probe enthielt ursprünglich einen Selbstvergleich; dieser ungültige Beleg wurde entfernt, und ihre Ganzkörper-PyTorch-Layoutprüfung ist ausdrücklich not_measured. Die echte Vollmodell-Validierung erfolgt stattdessen gegen die gespeicherten ursprünglichen FP32-Logits und -Entscheidungen.

Die unabhängigen CPU-Regressionen in test_ane_layout.py vergleichen zusätzlich einen vollständigen winzigen ConvBody mit dem ursprünglichen DecisionModel, unter Verwendung expliziter und SDPA-Attention-Orakel, dreier Fragetypen, geänderter Padding-Werte, Nicht-Null-Norm-Biases, mehrerer RoPE-Basen und eines nicht standardmäßigen Norm-Epsilons. Diese Tests decken Layout- und Maskierungssemantik ab, ohne sie mit der FP16-Hardwarepräzision des vollständigen Checkpoints zu vermengen. Alle fünf Layouttests bestanden lokal.

Der Attention-Prototyp fügt einen endlichen -1e4-Masken-Bias hinzu. Dieser hat das beabsichtigte Maskenverhalten auf den endlichen validierten Aktivierungen, ist aber keine bitweise Identität zum Ersetzen maskierter Scores durch -1e4 oder -infinity für beliebige extreme Eingaben. Ebenso wird nicht behauptet, dass die Core ML-FP16-Ausführung bitweise identisch mit dem ursprünglichen FP32-Modell ist.

runtime.py stellt eine CPU→ANE→CPU-Grenze für den gesamten Transformer bereit, statt eines Gerätewechsels pro Schicht:

1. Die CPU tokenisiert jede Frage, sammelt nur die angeforderten Embedding-Zeilen und konstruiert Additiv-Masken fester Form, Typvektoren und Marker-Selektoren. Sie verwendet keine kontextuellen Hidden States oder K/V zwischen Fragen wieder.
2. Ein Core ML-Aufruf führt die Embedding-Normalisierung, alle 22 Encoder-Schichten, beide Decision-Head-Schichten und die Scoring-Konvolutionen aus.
3. Die CPU leitet Action-Features aus der unkalibrierten Raw-Logit-Softmax ab und führt den kleinen ursprünglichen Action Head in FP32 mit erf-GELU aus. Die öffentliche Kalibrierung und Ausgabeformatierung verwenden dann die bestehende Implementierung.

Der exportierte Body hat FP16-Berechnung, während der kleine Host-Action-Head FP32 ist. Der Embedding-Lookup verwendet die ursprünglich gespeicherten Gewichte. Die Safetensors-Quelldatei enthält 169 FP16-Tensoren und einen FP32-Tensor: „FP32-Referenz“ beschreibt die ursprüngliche PyTorch-Ausführung, nicht die Behauptung, dass der ursprüngliche Checkpoint vollständig in FP32 gespeichert ist. Diese Mixed-Precision-Grenze ist Teil des numerischen Vertrags des Prototyps. Aktionswahrscheinlichkeits-Differenzen von null auf gesättigten Fixtures beweisen keine Action-Logit-Identität.

Der Adapter weist inkompatible Paketdimensionen, außerhalb des Bereichs liegende IDs/Marker, ungültige Maskenwerte, leere Attention-Key-Zeilen und Eingabelängen zurück, die seine feste Kapazität überschreiten. Sein Standard-Eingabelimit ist 96 Tokens, und seine Batchgröße ist eins; mehrere Fragen werden sequenziell ausgeführt. Er schneidet eine Anfrage nie still ab, um in den kürzeren Export zu passen.

Reproduktion, Herkunft und Qualitäts-Gates

Führe dies vom Repository-Stamm in der fixierten .venv aus. Generierte Pakete werden von Git ignoriert; kein dupliziertes Embedding-NPZ oder großes Gewichtsartefakt ist erforderlich. probe.py lehnt ein vorhandenes Ausgabeverzeichnis ab. Neue Exporte zeichnen ursprüngliche Gewichts-/Konfigurations-SHA256-Werte, Paketinhalt-Hashes, Shape, Tool-Versionen und Experiment-Quell-Fingerabdrücke in einem Manifest auf.

Die Reproduktionsbefehle schreiben unter artifacts/ane-repro/, weil die committeten Experimentverzeichnisse bereits Berichte und Manifeste enthalten. Wähle ein anderes neues Verzeichnis, wenn du einen Export wiederholst; keiner der Exporter verwendet still ein vorhandenes Paket wieder.

Installiere die Konvertierungs-, Entwicklungs- und Kompressionsforschungs-Abhängigkeiten mit pip install -e '.[convert,dev,research]' (oder den entsprechenden uv sync-Extras). Das Research-Extra fixiert kmeans1d==0.4.0; diese optionale Abhängigkeit wird für die gruppierten FP16-K-means-Experimente verwendet und in neuen Manifesten festgehalten.

Standardmäßig löst die Konvertierung laya-multilingual zum fixierten Hugging Face-Checkpoint des Repositories auf und lädt ihn bei Bedarf herunter. Übergib --source /path/to/checkpoint, um vorhandene lokale Dateien zu verwenden. Die Validierung verwendet standardmäßig das im Paketmanifest festgehaltene Quellverzeichnis. Die ANEAgent-Laufzeit selbst akzeptiert nur lokale Dateien; sie verifiziert vor dem Laden die ursprünglichen Gewichts-/Konfigurations-Hashes, die feste Form und den Paketinhalt-Hash. Die Validierung weist außerdem eine Golden Reference mit einem abweichenden Quellgewichts-Hash zurück. Der gemessene SHA256 des mehrsprachigen Quellgewichts ist 9d628fd971b700382ac6f65920a86f149777b2e748e0c955fb3b19695aa8f204.

# Small placement probes, then the complete model.
.venv/bin/python -m experiments.ane_engineering.probe \
  --kind mlp --length 96 --output artifacts/ane-repro/mlp96
.venv/bin/python -m experiments.ane_engineering.probe \
  --kind layer --length 96 --output artifacts/ane-repro/layer96
.venv/bin/python -m experiments.ane_engineering.probe \
  --kind body --length 96 --output artifacts/ane-repro/body96
.venv/bin/python -m experiments.ane_engineering.validate \
  --package artifacts/ane-repro/body96/model.mlpackage \
  --length 96 --repeats 100 \
  --output artifacts/ane-repro/validation96.json

Der Validator verlangt, dass alle ausgewerteten Argmax-Entscheidungen übereinstimmen, kalibrierte und Action-Wahrscheinlichkeitsfehler <=0.02, endliche Ausgaben, unveränderte Token-Nutzung und identische wiederholte öffentliche Ausgaben. Ein fehlgeschlagener Kandidat schreibt passed: false und beendet sich erfolglos. Übersprungene Fälle bleiben unvalidiert, selbst wenn die Teilmenge fester Form besteht. Der anfängliche L96-Bericht hatte diese Gates nach der Messung ausdrücklich angewendet; er ist entsprechend markiert, ohne seine aufgezeichneten Timings zu ändern.

Längere feste Exporte und ihre vollständigen Golden-Reference-Validierungsbefehle:

.venv/bin/python -m experiments.ane_engineering.probe \
  --kind body --length 192 --output artifacts/ane-repro/body192
.venv/bin/python -m experiments.ane_engineering.validate \
  --package artifacts/ane-repro/body192/model.mlpackage --length 192 \
  --output artifacts/ane-repro/validation192.json
.venv/bin/python -m experiments.ane_engineering.probe \
  --kind body --length 1024 --output artifacts/ane-repro/body1024
.venv/bin/python -m experiments.ane_engineering.validate \
  --package artifacts/ane-repro/body1024/model.mlpackage --length 1024 \
  --output artifacts/ane-repro/validation1024.json
.venv/bin/python -m experiments.ane_engineering.benchmark \
  --package artifacts/ane-repro/body1024/model.mlpackage --length 1024 --long \
  --output artifacts/ane-repro/long1024-performance.json

Diese Befehle reproduzieren die oben aufgeführten unabhängig geprüften längeren Exporte. Ihr Placement und ihre numerische Treue wurden getrennt vom L96-Graphen geprüft; kurze Anfragen auf 1024 Tokens aufzufüllen, ist nicht die vorgeschlagene Produktionsrichtlinie.

Kompressions-Screening und das 10×-Ziel

palettize.py bereitet unabhängige Weight-Only-Palettenvarianten vor, mit 8-Bit-Uniform-Lookup-Tabellen als kostengünstigstem ersten Screening-Kandidaten. Nur Konvolutionsgewichte größer als 2048 Elemente werden ausgewählt; RoPE-Konstanten, Normalisierung, Aktivierungsmathematik und Host-Action-Gewichte bleiben unverändert. Gruppierte Ausgabekanäle verwenden separate Lookup-Tabellen. K-means ist ein teurerer Modus. Er verwendet die installierte kmeans1d-Implementierung für diese FP16-Gruppen. Core ML Tools 9.0 parallelisiert unabhängige Gruppen über ein Process-Pool-starmap, wenn num_kmeans_workers > 1; die Experimente verwenden acht Worker für Offline-K-means und einen Mathematikbibliothek-Thread pro Worker. Die Worker-Anzahl ändert den Exportdurchsatz, nicht das beabsichtigte Codebook-Ziel. Kandidaten mit niedrigeren 6/4-Bit sind separate approximative Artefakte, keine exakten Implementierungen.

Kompressionsgrößen beziehen sich auf das exportierte Transformer-Body-Paket. Die ursprüngliche Embedding-Tabelle mit 196.608 Millionen Einträgen bleibt auf dem Host, wobei pro Anfrage nur angeforderte Zeilen nachgeschlagen werden, und die kleinen Host-Action-Gewichte bleiben unverändert. Ein Body-Paket, das um etwa den Faktor zwei schrumpft, ist keine Halbierung des gesamten Checkpoints, des Laufzeitspeichers oder der Energie pro Anfrage.

.venv/bin/python -m experiments.ane_engineering.palettize \
  --package artifacts/ane-repro/body96/model.mlpackage \
  --bits 8 --mode uniform --group-size 32 \
  --output artifacts/ane-repro/body96-w8
.venv/bin/python -m experiments.ane_engineering.validate \
  --package artifacts/ane-repro/body96-w8/model.mlpackage --length 96 \
  --output artifacts/ane-repro/validation96-w8.json

# Independent K-means candidates; inspect each validation exit status.
for bits in 8 6 4; do
  VECLIB_MAXIMUM_THREADS=1 OPENBLAS_NUM_THREADS=1 OMP_NUM_THREADS=1 \
    .venv/bin/python -m experiments.ane_engineering.palettize \
    --package artifacts/ane-repro/body96/model.mlpackage \
    --bits "$bits" --mode kmeans --group-size 32 --workers 8 \
    --output "artifacts/ane-repro/body96-w${bits}km"
  .venv/bin/python -m experiments.ane_engineering.validate \
    --package "artifacts/ane-repro/body96-w${bits}km/model.mlpackage" --length 96 \
    --output "artifacts/ane-repro/validation96-w${bits}km.json"
done

Die beiden Uniform-W8-Screens behalten beide alle 59 Fixture-Argmax-Entscheidungen und bestehen 100 wiederholte Aufrufe, scheitern aber am Wahrscheinlichkeits-Gate: Gruppengröße 32 erreicht 0.023612 Fehler und Gruppengröße 4 erreicht 0.033858. Der W8-K-means/Group32-Screen besteht mit maximalem Fehler 0.014393 und 59/59 Entscheidungen. Gesättigte Aktionswahrscheinlichkeiten verbergen Action-Logit-Differenzen bis 16.24 für diesen K-means-Kandidaten; das Bestehen dieses kleinen Regressions-Fixtures belegt keine erhaltene allgemeine Kalibrierung oder Aufgaben-Genauigkeit. Komprimierte Kandidaten bleiben separat identifizierte approximative Modelle.

Der feste W6-K-means/Group32-Kandidat behält ebenfalls 59/59 Argmax-Entscheidungen und stabile wiederholte Ausgaben, scheitert aber mit maximalem Wahrscheinlichkeitsfehler 0.052243. Sein maximaler Action-Logit-Fehler beträgt 76.62. Das Reduzieren der Gewichte auf sechs Bit erfüllt daher nicht das unveränderte Akzeptanz-Gate, obwohl seine Screening-Latenz für kurze Anfragen nahe bei FP16 bleibt.

W4-K-means/Group32 behält ebenfalls 59/59 Entscheidungen, aber der maximale Wahrscheinlichkeitsfehler steigt auf 0.200221 und der maximale Action-Logit-Fehler auf 605.30. Er scheitert am selben Gate. Das Fehlen von Argmax-Änderungen in allen fünf komprimierten Screens zeigt, warum die gesättigten Entscheidungen dieses Fixtures allein ein unzureichender Akzeptanztest sind.

Alle komprimierten Varianten behalten 6,390 NE-bevorzugte gerätezugewiesene Operationen, 59/59 Fixture-Argmax-Übereinstimmungen und 100 stabile wiederholte Aufrufe. Die verbleibenden Planeinträge umfassen Konstanten und Weight-LUT-Rekonstruktionsausdrücke; Placement-Metadaten allein beweisen nicht, wie viele komprimierte Daten während einer Anfrage aus dem DRAM wandern. Die drei K-means-Exporte dauern mit acht Offline-Workern jeweils 186.50, 56.13 und 23.90 Sekunden. Setup und Worker-Prozesse sind vor jeder Inferenzmessung abgeschlossen.

Diese seriellen 50-Aufruf-Screens belegen keine Speedup-Verhältnisse. Der FP16-Screen stammt aus der Zeit vor den letzten Eingabevalidierungsprüfungen, und die Screens sind nicht verschachtelt. W8 K-means ist der einzige komprimierte Finalist für den stärkeren Sitzungsvergleich in ANE_BENCHMARKS.md. Die abgelehnten Varianten bleiben als Beleg für die Präzisionsgrenze erhalten, nicht als empfohlene Deployments. Die Kompression wurde nur für diese mehrsprachige L96-Teilmenge validiert; das 63-Fragen-L1024-Ergebnis oben betrifft den separaten FP16-Export.

Die Core ML-Palettenkompression rekonstruiert Gleitkommagewichte aus indizierten Lookup-Tabellen; kleinere gespeicherte Tensoren belegen für sich genommen keine schnellere Inferenz oder niedrigere Energie. Jede Variante benötigt dieselben Präzisions-Gates, einen frischen Compute Plan und einen gepaarten End-to-End-Geschwindigkeits-/Energievergleich. Core ML-Palettierungsdokumentation.

Das anfängliche erfolgreiche ANE-Placement etabliert einen glaubwürdigen Optimierungspfad, kein 10×-Ergebnis. Der Vergleich muss MLX FP16 verwenden, einschließlich seiner kompilierten Variante, wo sie schneller ist, und denselben Aufgabenumfang berichten. Die Leistung muss über vollständige Anfragen integriert werden. Sowohl die Brutto-Systemenergie als auch jede um Leerlauf bereinigte Schätzung sollten mit ihren Messgrenzen berichtet werden. Die unabhängige mathematische Prüfung ist ANE_MATH.md.

Was die manuelle Implementierung belegt

Die nützliche manuelle Arbeit hier ist eine vollständige, unabhängig validierte Neuschreibung des Berechnungsgraphen in ein Layout, das Core ML auf ANE abbilden kann. Dies ändert das Ausführungs-Placement, während die trainierten Parameter erhalten bleiben. Es ist wesentlich effektiver als das Ändern von compute_units am ursprünglichen Graphen. Es entfernt nicht die 24 sequenziellen Attention-/MLP-Blöcke oder deren dichte Projektionsarbeit.

Der nächste exakte Kandidat für lange Anfragen ist eine Attention, die tatsächlich nur lokale Fenster besucht, implementiert mit festen Query-/Key-Tiles und den ursprünglichen Padding- und RoPE-Regeln. Der aktuelle Graph berechnet weiterhin eine dichte Score-Matrix und wendet eine lokale Maske an. Ein gekachelter Graph könnte diese Arbeit reduzieren, aber mehr Slices, Grenzen und kleine Kontraktionen könnten das ANE-Scheduling untergraben; sein Placement, seine Präzision und sein End-to-End-Nutzen bleiben ungemessen. Weitere Gewichtskompression erfordert Kalibrierung oder Qualitätswiederherstellung nach den obigen Fehlschlägen. Destillation oder weniger Schichten würden ein neues Modell einführen und eine breitere Aufgabenqualitäts-Evaluierung erfordern. Keine dieser nicht implementierten Richtungen liefert heute einen Beleg für einen 10×-Gewinn.