PyTorch 2.15 erweitert MPS – Benchmarks und Release-Status bleiben zu prüfen

LLM-Decodierung: spezialisierte Pfade, uneinheitliche MoE-Zahlen

Während des Decodierens verarbeitet ein Sprachmodell neue Tokens typischerweise einzeln. Dadurch entstehen lineare Operationen mit einer einzelnen Eingabezeile, die sich von den großen Matrixmultiplikationen im Prefill unterscheiden. PyTorch 2.15 verbindet laut Beitrag vorhandene MPS-GEMV-Kernel – also Kernel für Matrix-Vektor-Produkte – mit `F.linear`. Für geeignete Formen kann außerdem die Bias-Addition in den Kernel integriert werden. In einem Test mit 96 BF16-Layerformen aus realen Modellen meldet das Team ein geometrisches Mittel von 1,23-facher Beschleunigung; bei großen Projektionen seien die Gewinne geringer. [1]

Für Mixture-of-Experts-Modelle führt der Beitrag eine native Implementierung von `grouped_mm` an. MoE-Layer verteilen Tokens auf unterschiedliche Experten; die Gruppen können unterschiedlich groß sein. In Version 2.14 seien Gruppenoffsets zunächst auf die CPU kopiert und die Gruppen einzeln abgearbeitet worden. Die neuen Metal-Kernel lesen die Offsets direkt auf der GPU; für kleine Gruppen, die beim Decodieren häufig auftreten, gebe es einen eigenen Kernelpfad. [1]

Bei der berichteten MoE-Leistung ist allerdings Vorsicht geboten. Im Überblick nennt der Beitrag für Qwen3.6-35B-A3B auf einem M3 Ultra mit `torch.compile` einen Anstieg von 9,4 auf 61,3 Tokens pro Sekunde und für LFM2.5-8B-A1B von 23,6 auf 123,6. Später zeigt er für dieselben Modelle andere Ausgangs- und Endwerte: bei Qwen 38,7 auf 51,7 Tokens pro Sekunde bei Kontextlänge 512 und 36,8 auf 48,7 bei 2048; bei LFM 77,1 auf 103,2 beziehungsweise 74,9 auf 98,7. [1]

Der Beitrag erläutert nicht ausreichend, wie sich die jeweiligen Testbedingungen unterscheiden. Die Zahlen aus dem Überblick legen eine fünf- bis sechsfache Steigerung nahe, während die später dargestellten Messreihen eher rund 1,3-fache Zuwächse zeigen. Ohne eine nachvollziehbare Zuordnung der Setups sollten Sie daraus keinen einzelnen allgemeinen Beschleunigungsfaktor ableiten. Auch die genannten Werte sind Messungen des Beitragsteams und keine unabhängige Bestätigung. [1]

Für die Praxis heißt das: Der technische Ansatz – weniger CPU-GPU-Abstimmung und spezialisierte Rechenpfade für kleine Gruppen – ist klar beschrieben; die Größenordnung des Nutzens muss jedoch für das konkrete Modell und den eigenen Kontextumfang gemessen werden. Das gilt insbesondere, wenn Ihre Anwendung auf stabile Latenz, hohen Durchsatz oder eine bestimmte lokale Mac-Konfiguration ausgelegt ist. [1]

Weitere Metal-Kernel für lineare Algebra und Training

PyTorch 2.15 soll außerdem zusätzliche Operationen der linearen Algebra auf MPS ausführen können. Genannt werden LU-Faktorisierung und -Lösung sowie Dreieckssysteme für komplexe Tensoren vom Typ `complex64`. Für kleine FP32-Matrizen bis 4 × 4 beschreibt der Beitrag einen Metal-Kernel, der Faktorisierung und Lösung verbindet. QR-Zerlegungen erhalten demnach blockierte Updates; für bestimmte Dreieckssysteme in Gated-DeltaNet-Workloads gibt es einen spezialisierten Pfad. [1]

Auch für Singulärwertzerlegung meldet das Team Verbesserungen beim Umgang mit sehr kleinen Singularwerten, sehr großen oder kleinen Eingabewerten und der Vervollständigung einer Basis bei `full_matrices=True`. Diese Änderungen sollen laut Beitrag auch Ergebnisse von Pseudoinversen und Least-Squares-Berechnungen verlässlicher machen. Die Quelle quantifiziert diese Verbesserungen nicht allgemein; Unternehmen mit numerisch sensiblen Workloads sollten daher weiterhin eigene Korrektheitstests durchführen. [1]

Für Audio-, Bild- und Trainingspfade führt die Ankündigung neue oder angepasste Kernel für `conv1d`, Padding, Dropout, Upsampling im Backward-Pass und den Backward-Pass von `conv2d` im Channels-last-Format auf. Bei Reflection- und Replication-Padding sollen die neuen Metal-Implementierungen sowohl schneller sein als auch Korrektheitsprobleme im Backward-Pass beheben. Diese Aussagen beziehen sich auf die vom Team beschriebenen Änderungen; die tatsächliche Relevanz hängt von den Operationen und Tensorformen im jeweiligen Modell ab. [1]

Video-Decodierung: weniger Treiberspeicher im konkreten Test

Der auffälligste Speicherwert betrifft laut Hugging Face das geteilte VAE-Decodieren von Wan2.2. Bei einem vollständigen Decode mit 28 Tiles fallen dem Beitrag zufolge 8.764 Padding-Aufrufe an. Die Umstellung des Constant-Paddings von MPSGraph auf Metal senke den Spitzenwert des Treiberspeichers in diesem Test von rund 270,1 auf 8,1 GiB. [1]

Wichtig ist die Unterscheidung zwischen Treiberspeicher und den Tensoren, die PyTorch selbst ausweist. Der Beitrag beziffert den Spitzenwert der aktuellen Tensorallokationen auf 4,422 GiB mit MPSGraph-Padding und 4,095 GiB mit Metal-Padding. Auch der vom Allocator reservierte Spitzenwert bleibt in beiden Messungen bei 8,070 GiB; stark verändert sich der ausgewiesene Gesamtwert des Treiberspeichers außerhalb des Allocators. Die oft zitierte Reduktion von 270 auf 8 GiB bedeutet daher nicht, dass die Tensorbelegung selbst um denselben Faktor sinkt. [1]

Als Analyse lässt sich daraus ableiten, dass die Änderung in diesem spezifischen geteilten VAE-Workflow vor allem die mit der bisherigen Padding-Ausführung verbundene Speicherbelastung adressiert. Der Messwert belegt nicht, dass andere Video-Modelle oder alle MPS-Anwendungen denselben Rückgang erreichen. Für Teams, die solche Pipelines einsetzen, ist ein Vergleich der gesamten Speicherbilanz – einschließlich Treiberspeicher – aussagekräftiger als ein Blick allein auf die Tensorallokationen. [1]

Korrektheit, Softmax und mehr Kontrolle über Streams

Auch Korrektheitsverbesserungen sind Teil der Ankündigung. Das Team berichtet, dass ein geändertes Constant-Padding den zuvor fehlerhaften Qwen-Image-2.1-VAE-Encoder auf MPS korrigiere: Ein Encode-Decode-Durchlauf erreiche nun 29,95 dB PSNR und liege damit laut Beitrag näher am CPU-Ergebnis als der vorherige Wert von 10,06 dB. Der Beitrag verweist auf eine Fehlermeldung aus ComfyUI; die Zahlen sind jedoch ebenfalls Angaben der Projektbeteiligten und keine unabhängige Qualitätsprüfung. [1]

Für Token-Sampling nennt der Beitrag eigene Metal-Kernel für `softmax` und `log_softmax`. Bei einer FP32-Zeile mit 128.256 Logits sinke die gemessene Laufzeit demnach von 57 auf 7 Mikrosekunden, also auf etwa ein Achtel. Gerade bei großen Ausgabewortschätzen kann dieser Schritt relevant sein; die Quelle zeigt jedoch einen Mikrobenchmark und keine durchgängige Messung eines vollständigen Produktionssystems. [1]

Neu sind laut Beitrag außerdem öffentliche MPS-Streams und ein Kontextmanager, mit denen Python-Code Arbeit einem Stream zuweisen kann. `Tensor.record_stream` soll dem Allocator mitteilen, dass ein Tensor in einem anderen Stream verwendet wird. Das schafft zusätzliche Kontrolle über die Ausführung, bedeutet aber auch, dass Anwendungen bei asynchroner Nutzung Synchronisation und Lebensdauer von Tensoren korrekt behandeln müssen. [1]

Weitere neu unterstützte Operationen umfassen unter anderem `frexp`, `logspace`, `take`, `put_` und bestimmte Vergleiche mit vorzeichenlosen Ganzzahlen. Für `logspace` nennt die Quelle eine Einschränkung bei ganzzahligen oder booleschen Ausgaben mit mehr als einem Element. Auch die MPS-Implementierung von Scaled-Dot-Product-Attention erhält laut Beitrag eine Korrektur für Broadcasting über Batch- und Head-Dimensionen. [1]

Was Unternehmen vor einem Wechsel prüfen sollten

Die Neuerungen betreffen unterschiedliche Ebenen: Speicherformate, einzelne Operatoren, GPU- und CPU-Abstimmung sowie die Fehlerkorrektheit bestimmter Modellpfade. Ein Versionswechsel kann deshalb je nach Workload sehr unterschiedliche Auswirkungen haben. Für einen aussagekräftigen Vergleich sollten Sie dieselben Modelle, Eingabeformen und Kontextlängen auf der bisherigen und der neuen Version ausführen und neben Tokens pro Sekunde auch Speicherverbrauch, Ergebnisqualität und Laufzeit einzelner Operationen erfassen. Diese Empfehlung folgt aus den unterschiedlichen Messgrößen und Testbedingungen, die der Beitrag selbst verwendet. [1]

Prüfen Sie außerdem die Kompatibilität von macOS und Python sowie die Verfügbarkeit der tatsächlich benötigten Operatoren. Die MPS-Dokumentation beschreibt den Backend-Ansatz und die Nutzung des Geräts, ersetzt aber keine Prüfung der konkreten Modellbibliotheken oder des eigenen Workflows. Die Apple-Seite weist für ihre dort dokumentierte PyTorch-Version zudem darauf hin, dass sich MPS im Beta-Status befindet; diese Aussage bezieht sich ausdrücklich auf PyTorch 2.11 und ist kein Statusnachweis für Version 2.15. [1][2][3]

Für die nächste Version skizziert Hugging Face bereits Änderungen in PyTorch 2.16, darunter vollständig auf Metal ausgeführte Attention und weitere Migrationen weg von MPSGraph. Ein Teil der Arbeiten sei bereits in `main` oder Nightly-Versionen verfügbar, andere Änderungen befänden sich noch in Prüfung. Die dazu genannten Leistungswerte sind daher Vorschauen und keine Zusage für die ausgelieferte Version. [1]

Unterm Strich zeichnet PyTorch 2.15 laut Ankündigung ein breiteres Einsatzfeld für MPS: FP8 kann den Speicherbedarf der Werte reduzieren, spezialisierte Kernel sollen bestimmte LLM- und Bildverarbeitungspfade beschleunigen, und einzelne Korrekturen adressieren Fehler in konkreten Workflows. Die stärksten Zahlen sollten Sie jedoch differenziert behandeln: Der Blog ist die Primärquelle für die angekündigten Änderungen, aber keine unabhängige Leistungsvalidierung; bei den MoE-Werten bleibt zudem eine nicht erklärte Abweichung bestehen. [1]

Quellen

1. [1] MPS in PyTorch 2.15 — https://huggingface.co/blog/mps-pytorch-2-15 (abgerufen am 2026-10-20)
2. [2] MPS backend — PyTorch 2.14 documentation — https://docs.pytorch.org/docs/stable/notes/mps.html (abgerufen am 2026-10-20)
3. [3] Accelerated PyTorch training on Mac - Metal - Apple Developer — https://developer.apple.com/metal/pytorch (abgerufen am 2026-10-20)