Engineering-Untersuchung: Kann dieser MLX-Port noch einmal 10× schneller werden?

Datum: 2026-09-19. Maschine: Apple M3 Max, 40 GPU-Kerne, 128 GiB Unified Memory, macOS 27.2, MLX / MLX Metal 0.32.2, FP16-Inferenz. Dieser Bericht enthält echte lokale Experimente, einschließlich eines handgeschriebenen Metal-Kernels. Er ändert weder die Produktions-Runtime noch veröffentlicht er quantisierte Gewichte.

Die getesteten Engineering-Änderungen liefern keine 10×. Verschachtelte Messungen stützen bescheidene, formabhängige Verbesserungen durch Kompilierung und das Pruning ungenutzter Ausgaben der letzten Decision-Head-Schicht. Ausgewählte Fälle verbesserten sich um etwa 3–8% anhand gepaarter Medianwerte pro Runde. Einige Intervalle bei größeren Batches enthalten keine Verbesserung. Ein eigener exakter erf-GELU/Gate-Kernel war numerisch erfolgreich, bot aber keinen konsistenten zusätzlichen Ende-zu-Ende-Vorteil gegenüber der MLX-Kompilierung. Naive 8-Bit- und 4-Bit-Backbone-Quantisierung reduzierte den Speicher, beschleunigte die größeren Pilot-Workloads nicht und veränderte Vorhersagen oder kalibrierte Wahrscheinlichkeiten.

Die mathematischen Grenzen und Approximation-Kompromisse werden separat in MATH_10X_RESEARCH.md untersucht. Die ursprüngliche Implementierungsprüfung steht in PERFORMANCE_RESEARCH.md; der Benchmark der veröffentlichten Checkpoints bleibt BENCHMARKS.md.

Experimentelle Kontrollen und Grenzen

Alle Forschungs-GPU-Arbeiten liefen seriell. Andere Agent-Arbeiten nutzten nur CPU/Dateisystem/Netzwerk. Die Maschine lief am Netzstrom, ohne aufgezeichnete pmset-Warnung zu Temperatur/Leistung und ohne gemeldete Swap-Nutzung während des Experiments. Normale Desktop-Aktivität lief weiter. Dies ist keine kontrollierte Thermalkammer oder eine ansonsten untätige dedizierte Benchmark-Maschine.

Die ersten Screening-Läufe führten jeden Kandidaten in einem frischen Prozess aus, mit 4–5 Warmups und 12–16 Stichproben. Sie offenbarten erhebliche Drift zwischen den Läufen. Zum Beispiel deutete der englische Ein-Frage-Pilot auf eine 1.24×-Kompilierungsverbesserung hin, während das anschließende verschachtelte Experiment nur etwa 1.03× fand. Die sequenziellen Pilot-Latenzen sind daher Screening-Belege, nicht die primäre kausale Geschwindigkeitsaussage.

Das Bestätigungsskript paired.py:

• Rotiert die Kandidatenreihenfolge innerhalb jeder Runde und verwendet dieselben Eingaben für jeden Kandidaten in dieser Runde.
• Ändert den tatsächlichen Zustandstext zwischen den Runden. Es generiert bis zu 16 Zustandsvarianten und behält Varianten mit derselben Tensor-Shape; mehrsprachige Kurzfälle haben 10 solche Varianten, während die anderen berichteten Fälle 16 haben.
• Verwendet unterschiedliche natürlichsprachliche Fragen, darunter 50 verschiedene Instruktionen für den größten kurzen Workload. Es prüft Eingabe-Hashes und cached keine Antworten, dedupliziert keine Fragen und verwendet keine kontextuellen Encoder-Zustände wieder.
• Wertet Ergebnisse aus und synchronisiert die GPU, bevor jeder Timer gestoppt wird. Es misst sowohl vorbereitete Forward-Aufrufe als auch den öffentlichen Vorhersagepfad, einschließlich Tokenisierung und Ausgabeformatierung. Das Laden des Modells ist ausgeschlossen.
• Führt nach dem Warmup 32 gemessene Runden für das englische Head/Compile-Experiment und 16 für die mehrsprachigen und Custom-Metal-Experimente aus. Jeder Kandidat sieht dieselbe Rundenzahl und Eingabesequenz.

Diese Eingaben unterscheiden sich von den veröffentlichten Baseline-Fixtures. Die Vergleiche unten sind innerhalb des Forschungsexperiments, nicht Vorher/Nachher-Vergleiche, die durch Division unzusammenhängender Tabellen entstehen. Das Forschungs-Batch-Limit ist 64, während die veröffentlichte API standardmäßig 16 verwendet. Wiederholte Zustandsvarianten sind absichtliche Wiederholungsmessungen; es gibt keinen Ergebnis-Cache.

analyze.py berechnet Verhältnisse eager_time / candidate_time pro Runde und explorative Perzentil-Bootstrap-Intervalle für deren Median, unter Verwendung von 2,000 Resamples der Rundenindizes. Diese Intervalle berücksichtigen nicht jede Quelle von Betriebssystemrauschen oder serieller Korrelation und ersetzen keine Replikation über mehrere Sitzungen. Ein Verhältnis unabhängig berechneter p50-Werte kann vom medianen gepaarten Verhältnis abweichen.

Rohes JSON enthält alle Zeitmessungen, Eingabe-Hashes, Umgebungsmetadaten, Paritätsmetriken und den zum Messzeitpunkt aufgezeichneten Quell-Fingerabdruck. Die Experiment-Skripte wurden anschließend formatiert und um disjunkte optionale Kandidaten erweitert; frühere Fingerabdrücke beschreiben diese früheren Skriptversionen.

Kompilierung und exaktes Final-Head-Pruning

Vier Pfade wurden verglichen:

1. Eager: das veröffentlichte FP16-DecisionModel.
2. Kompiliert: mx.compile um das geladene, ausgewertete, eingefrorene Modell, unter Verwendung normaler Shape-Spezialisierung.
3. Ausgewähltes Q + kompiliert: in der letzten Head-Schicht die vollständige QKV-Projektion und K/V beibehalten, aber nur CLS-/Options-Marker-Attention-Queries ausgeben. Die Ausgabeprojektion und das FFN nur auf diesen ausgewählten Ausgaben ausführen.
4. Volle Attention + ausgewählte Ausgaben + kompiliert: den ursprünglichen vollständigen QKV- und SDPA-Aufruf beibehalten, dann CLS-/Options-Ausgaben vor der Ausgabeprojektion und dem FFN sammeln. Dies behält die ursprüngliche Attention-Kernel-Shape bei und entfernt dennoch den größten Teil der ungenutzten dichten Arbeit des Final-Heads.

Beide Pruning-Prototypen bewahren die mathematischen Abhängigkeiten des Modells. Sie berechnen weiterhin alle QKV-Projektionen; sie realisieren nicht die zusätzlichen Q-only-Projektionseinsparungen aus der mathematischen Obergrenzen-Berechnung. Das Ändern von GEMM- und SDPA-Shapes kann die Fließkomma-Rundung verändern. Keiner der Prototypen ist ein Decoder-Cache, ein Early Exit oder eine Approximation, die frühere Transformer-Schichten weglässt.

Ende-zu-Ende-p50-Latenz, Millisekunden:

Quellen: Englische gepaarte Daten und mehrsprachige gepaarte Daten.

Für den Pfad mit voller Attention/ausgewählten Ausgaben umfassen die gepaarte Median-Beschleunigung und die explorativen 95%-Intervalle:

Die Intervalle für die englischen 50 Fragen und den mehrsprachigen langen Batch enthalten 1. Sie belegen keine wiederholbare Verbesserung. Der Selected-Q-Pfad ist bei den mehrsprachigen Fällen short-16 und long-1 etwas besser, aber kein Pruning-Pfad dominiert jede Shape. Alle Kandidatenintervalle, Forward-Messungen und rohen Verhältnisse pro Runde stehen in paired_analysis.json.

Die Kompilierung stimmte exakt mit den Eager-Logits, Action-Logits und kalibrierten Wahrscheinlichkeiten bei den 1,530 Fragevergleichen mit geänderten Eingaben über die beiden Modellfamilien in diesem Head/Compile-Experiment überein. Beide Pruning-Pfade stimmten bei allen 1,530 Argmax-Entscheidungen überein, mit einer maximalen Abweichung der kalibrierten Wahrscheinlichkeit von 0.0001883. Der Full-Attention-Pruning-Pfad bestand außerdem die separate 63-Fragen-Fixture-Suite für jedes Modell: 126/126 Übereinstimmung, mit maximalen Wahrscheinlichkeitsunterschieden 4.31e-5 für Englisch und 6.48e-6 für Mehrsprachig. Dies sind Regressionstests, keine Aussage über Task-Genauigkeit bei 1,530 unabhängig gelabelten Beispielen.

Sowohl Whole-Model- als auch Per-Block-Kompilierung wurden gescreent. Das Block-Experiment bewahrte ebenfalls alle 63 englischen Fixture-Ausgaben, belegte aber keinen wesentlichen Vorteil gegenüber der Whole-Model-Kompilierung. Die Shape-Spezialisierung muss in einem Service begrenzt sein. Das Modell verwendet Python-formabhängige Reshapes und Masken, sodass das wahllose Anwenden von shapeless=True unsicher ist. Der offizielle Compile-Leitfaden dokumentiert Shape-Spezialisierung und State Capture.

Der erste Aufruf des englischen Whole-Model-Kandidaten dauerte 2,166.7 ms, gefolgt von etwa 12.75 ms Warm-Forward-p50 in diesem Pilot; ein erster Aufruf einer neuen B16-Shape dauerte 272.4 ms. Das JSON-Feld heißt cold_forward, bedeutet aber den ersten Kandidatenaufruf nach der Eager-Referenzinferenz, nicht eine vollständig kalte Anwendung oder einen frisch initialisierten Metal-Treiber. Nachfolgende Kandidaten verwendeten bereits kompilierte Metal-Kernels wieder, sodass ihre Erstaufrufzeiten keine kontrollierte Rangfolge der Kaltstartkosten sind. Der kompilierte aktive/Spitzen-MLX-Speicher für Englisch short-1 betrug im Pilot etwa 803.6/918.6 MiB; für Mehrsprachig etwa 614.1/676.9 MiB. Diese Allocator-Messungen umfassen nicht jede hostseitige Compiler-Allokation und belegen keine Speichergrenzen bei unbegrenztem Shape-Wechsel. Siehe Englischer Compile-Pilot und mehrsprachiger Compile-Pilot.

Selektive Quantisierung: nützliche Speichereinsparungen, ungeeignet als Geschwindigkeitsaussage

Der Prototyp ruft nn.quantize nach dem Laden des dichten FP16-Modells auf. Er wählt nur lineare encoder.layers.*-Module aus, mit affiner Gruppengröße 64, und kompiliert dann das resultierende Modell. Embeddings, Normen, der Decision-Head, der Scorer und der Action-Head bleiben FP16. Dies vermeidet das Casten gepackter Integer-Gewichte durch den aktuellen dichten Loader und vermeidet die nicht teilbare Eingabebreite 1028/772 des Action-Heads. Es wird kein quantisiertes Checkpoint-Format oder Ladevertrag ausgeliefert. Die offizielle quantisierte Schichtimplementierung von MLX liefert diesen Auswahlmechanismus.

Das mehrsprachige 4-Bit-Ergebnis veranschaulicht, warum die kleine Fixture-Suite allein nicht ausreicht: Ihre 63 Fixture-Argmaxes blieben gleich, aber 7 von 26 Entscheidungen bei unterschiedlichen Workloads änderten sich. Dies sind Übereinstimmungsmessungen gegenüber FP16, nicht Ground-Truth-Genauigkeitsmessungen. Eine absolute Wahrscheinlichkeitsänderung von 0.8008 entspricht 80.08 Prozentpunkten.

Bei englischen short-16-Pilot-Eingaben betrug die FP16-Eager/Kompiliert-Ende-zu-Ende-p50 91.26/87.94 ms; 8-Bit/4-Bit kompiliert war 96.66/93.20 ms. Die Short-1-Quantisierung wirkte in diesem Screening-Lauf etwas schneller, größere Shapes dagegen nicht. Das Screening großer Shapes für Mehrsprachig zeigte ebenfalls keinen Geschwindigkeitsgewinn, aber seine sequenziellen Läufe wiesen erhebliche Drift auf. Diese Beobachtungen rechtfertigen, eine pauschale Beschleunigungs- oder Release-Aussage abzulehnen, nicht, präzise Verlangsamungsfaktoren ohne verschachtelte quantisierte Replikation zuzuweisen. Weitere Quantisierungsarbeit erfordert aktivierungsbewusste Kalibrierung oder Fine-Tuning und eine repräsentative gelabelte Qualitäts-Suite.

Rohquellen: Englisch 8-Bit, Englisch 4-Bit, Mehrsprachig 8-Bit, Mehrsprachig 4-Bit.

Handgeschriebenes Metal: exakte GELU/Gate-Fusion wurde implementiert und getestet

kernels.py implementiert einen echten eigenen Metal-Kernel, der die beiden verketteten MLP-Zweige liest, dieselbe erf-basierte GELU berechnet, mit dem Gate multipliziert und eine einzelne Ausgabe schreibt. Er ersetzt die GELU nicht durch tanh-GELU oder eine Sigmoid-Approximation. Der Kernel verwendet die eigenen erf- und expm1-Helfer von MLX v0.32.2 und bewahrt deren Lizenzen und Hinweise in vendor/README.md. Er unterstützt explizit nur FP16 und verwendet den sicheren Metal-Math-Modus. Der offizielle Custom-Kernel-Leitfaden beschreibt diese API und ihre Math-Mode-Steuerung.

Über acht repräsentative Aktivierungs-Shapes hinweg hatten 27,958,016 zufällig generierte FP16-Ausgabeelemente exakt gleiche Werte wie die ursprüngliche Operation. Der Microbenchmark vergleicht numerische Gleichheit, nicht das Vorzeichenbit von Null. Vollmodell-Tests mit geänderten Eingaben stimmten ebenfalls exakt überein: 474/474 Fragevergleiche über die beiden Modellfamilien, plus beide 63-Fragen-Fixture-Suiten, mit null Unterschied bei Logit, Action-Logit oder kalibrierter Wahrscheinlichkeit.

Dieses Korrektheitsergebnis übersetzte sich nicht in einen konsistenten Geschwindigkeitsvorteil gegenüber dem fusionierten kompilierten Ausdruck von MLX. Zum Beispiel betrug bei 1,312 Tokens und Zwischenbreite 2,624 das pro Aufruf synchronisierte Aktivierungs-Timing 0.378 ms für Eager-GELU-dann-Gate, 0.268 ms für mx.compile und 0.280 ms für den eigenen Kernel. Bei 8,192 Tokens und Breite 1,152 betrugen die entsprechenden Werte 0.846/0.764/0.714 ms. Diese Microbenchmarks enthalten Dispatch- und Synchronisierungs-Overhead und sind Screening-Sonden; sie sind keine Messungen der isolierten Geräteausführungszeit. Vollständige Eingaben, Rohzeiten und Gleichheitsprüfungen stehen in microbench.json.

Der eigene Kernel wurde dann in jede Encoder-MLP eingebaut und im vollständigen Modell mit rotierender Kandidatenreihenfolge und wechselnden Eingaben gemessen:

Die vollständigen gepaarten Läufe mit eigenem Kernel verwenden eine zweite Modellinstanz mit identischen Gewichten, damit die unveränderte und die eigene Implementierung ohne Mutation oder veraltete kompilierte Captures koexistieren. Ihre absoluten Zeiten dürfen nicht mit dem früheren Head-Pruning-Lauf verglichen werden. Die bescheidenen gemischten Ergebnisse stützen es nicht, den eigenen Kernel als allgemeine Performance-Verbesserung zu veröffentlichen. Quellen: Englische gepaarte Metal-Daten und mehrsprachige gepaarte Metal-Daten.

Wo eigenes Engineering weitere Untersuchung verdient

Das Modell ruft bereits mx.fast.scaled_dot_product_attention, mx.fast.rope und eine optimierte Layer-Normalisierung auf. Sein D64-Boolean-Mask-SDPA-Pfad ist fusioniert; es gibt keinen fehlenden Flash-Attention-Schalter, der eine 10×-Lücke erklärt. Die lokale Attention durchläuft weiterhin dichte Key/Value-Kacheln. Ein echter bidirektionaler Window-Kernel könnte diese Kacheln überspringen und dabei den inklusiven Abstand <=64 und die Padding-Semantik bewahren, aber seine Whole-Model-Arithmetikgelegenheit ist bei kurzen Eingaben klein und bei den veröffentlichten langen Shapes begrenzt. Die bestehende Quellprüfung und der Mathematik-Bericht quantifizieren diesen Unterschied.

Nützliche nächste Projekte mit ihren Beleg-Anforderungen sind:

• Window-Attention für lange Eingaben: Kachelgrenzen für D64, das tatsächliche bidirektionale Fenster und gepaddete Batches spezialisieren. Gegen fusioniertes dichtes SDPA bei 512/1024 Tokens und dann im vollständigen Modell vergleichen. Dieser Kernel wurde nicht gebaut oder gebenchmarkt in diesem Bericht.
• Dense-Kernel-Epiloge und Scheduling: die Fusion des gated MLP Epilogs in GEMM oder die Verbesserung des Short-M-Matrix-Schedulings untersuchen. MLX verwendet bereits spezialisierte Metal-GEMM-Implementierungen, sodass deren Ersatz ein echtes Dispatch-/Kernel-Profil und gemessene Gewinne für die exakten M/N/K-Shapes erfordert. Das Standalone-Aktivierungsergebnis zeigt, warum ein weiterer elementweiser Kernel allein nicht ausreicht.
• Längenbewusstes Batching und geteilte CPU-Vorbereitung: exakte Input-IDs bewahren, während geteilter Zustandstext einmal tokenisiert wird, bevor jede Fragesequenz konstruiert wird, und kleine Elemente nicht auf unzusammenhängende lange Elemente padden. Der mehrsprachige long-8-Pilot verbrachte etwa 13.1 ms mit der Vorbereitung von Eingaben, gegenüber Hunderten von Millisekunden Ende-zu-Ende. Selbst die vollständige Eliminierung dieser Vorbereitung würde bei diesem Workload keine 10× erzeugen. Queueing-Latenz und Anzahl eindeutiger Inferenzen müssen Teil jeder Batching-Aussage sein.
• Ein kleinerer, gemeinsam antwortender Student: Wenn 10× eine Produktanforderung ist, destilliere oder entwerfe das Modell neu, um den größten Teil der dichten Arbeit zu entfernen oder viele feste Fragen mit einer kontextuellen Kodierung zu beantworten. Dies ändert das gelernte Modell und erfordert repräsentatives gelabeltes Training/Evaluation; es ist keine exakte Port-Optimierung. Die Wiederverwendung eines beliebigen kontextuellen Zustands/KV über Fragen hinweg im aktuellen bidirektionalen Encoder ist ungültig.

Acht eigenständige FP16-GEMM-Sonden der Encoder-Eingabeprojektion erreichten 0.66–11.55 TFLOP/s einschließlich Synchronisierung pro Aufruf. Die große englische M=4096, N=5248, K=1024-Sonde erreichte 11.55 TFLOP/s; die mehrsprachige M=8192, N=2304, K=768-Sonde erreichte 7.96 TFLOP/s. Dies sind beobachtete Durchsatzwerte, keine Hardware-Spitzenwerte oder Obergrenzen für den Full-Graph-Durchsatz. Small-M-Messungen werden besonders von Submission- und Synchronisierungskosten dominiert; ein gestreamter Graph amortisiert sie anders. Sie zeigen, welche Shapes ein Profiling verdienen, nicht den Beweis, dass kein besserer Kernel existieren kann. Die 10×-Durchsatzbudgets für gleiche Arbeit im Mathematik-Bericht bleiben theoretische Anforderungen statt gemessener Gerätefähigkeiten.

Reproduktion und Release-Entscheidung

Die Skripte verwenden die bestehende .venv und lokale fixierte Checkpoints. Führe GPU-Befehle sequenziell aus, niemals parallel zum formellen Benchmark:

# Screening: repeat for eager, compiled, blocks, q8, q4, selected-compiled.
.venv/bin/python -m experiments.engineering.run_variants \
  --model laya --variant compiled --iterations 12 --warmup 4 --quality \
  --output experiments/engineering/reproduced-compiled.json

# Primary confirmation, including 50 genuinely different questions.
.venv/bin/python -m experiments.engineering.paired \
  --model laya --iterations 32 \
  --output experiments/engineering/reproduced-laya-paired.json
.venv/bin/python -m experiments.engineering.paired \
  --model laya-multilingual --iterations 16 --cases short1,short16,long1,long8 \
  --output experiments/engineering/reproduced-multilingual-paired.json

# Hand-written kernel microbench and complete-model comparison.
.venv/bin/python -m experiments.engineering.microbench
.venv/bin/python -m experiments.engineering.paired \
  --model laya --iterations 16 --cases short1,short16,long1 --metal \
  --output experiments/engineering/reproduced-metal-paired.json
.venv/bin/python -m experiments.engineering.run_variants \
  --model laya --variant metal-compiled --iterations 5 --warmup 3 \
  --cases short1 --quality --output experiments/engineering/reproduced-metal-quality.json

# CPU-only paired analysis.
.venv/bin/python -m experiments.engineering.analyze

Alle experimentellen Python-Dateien bestehen die Ruff-Formatierungs- und Lint-Prüfungen. Die stabile Runtime, die ursprünglichen Benchmark-Ergebnisse und die veröffentlichten FP16-Checkpoints bleiben die Release-Artefakte. Kompilierung und exaktes Final-Head-Pruning sind glaubwürdige optionale zukünftige Optimierungen nach einer Cold-Shape-/Cache-Politik und breiterer Qualitätsvalidierung; die gemessenen Gewinne rechtfertigen es nicht, dem Standardpfad stillschweigend Kompilierungslatenz oder einen eigenen Kernel hinzuzufügen. Es wird keine 10×-Beschleunigung, kein produktionsreifer quantisierter Checkpoint und kein gemessener Gewinn durch einen lokalen Window-Kernel beansprucht.