Vertiefende Analyse · Etwa 6 Min. Lesezeit
PyTorch MPS: Decodierung, Korrektheit und Treiberspeicher getrennt messen
Das PyTorch-Team von Hugging Face erklärt MPS-Änderungen für den Release-Kandidaten 2.15, mit getrennten Belegen zu gruppierter Decodierung, FP8-Speicherung, Padding und künftiger 2.16-Arbeit.
- Hier veröffentlicht
- Datum der Quelle
- Quelle geprüft
Ein technischer Beitrag vom 20. Oktober von PyTorch-Mitwirkenden bei Hugging Face erklärt, wie spezialisierte Metal-Kernel die Arbeit des MPS-Backends auf Apple silicon verändern. Er bietet einen Installationsweg für den Release-Kandidaten von PyTorch 2.15 und einen getrennten Ausblick auf 2.16. Sein Nutzen liegt in konkreten Engpässen und Messungen, nicht in einem Beschleunigungsfaktor für jede Mac-Anwendung.
Nachrichten anhören
Diesen Artikel vorlesen oder mit den Nachrichten fortfahren.
Vorlesen wird vorbereitet…
Gerätestimme
Browser oder Gerät verarbeiten die Sprache. AISubHub sendet den Text nicht an eine Audio-API. Stimmen und Wiedergabe bei gesperrtem Bildschirm hängen vom Gerät ab.
Beim Fortsetzen kann sich ein kurzer Satzteil wiederholen.
Auf einen Blick
- Die dokumentierte Umgebung erfordert Apple silicon, macOS 15 oder neuer und Python 3.11 oder neuer. Der Beitrag stellt 2.15 als Release-Kandidaten vor und trennt davon 2.16-Arbeit in Nightly-Builds oder noch laufender Prüfung.
- Eine Decodierspezialisierung für gruppierte Matrixmultiplikation liefert in den gezeigten M3-Ultra-Versuchen mit torch.compile ungefähr den 1.3-fachen Durchsatz. Ein separates Softmax-Diagramm misst Mikrosekunden eines einzelnen Operators, nicht die Latenz einer vollständigen Antwort.
- Bei einer Wan2.2-VAE-Decodierung mit 28 Kacheln sinkt der berichtete gesamte Treiberspeicherhöchstwert von 270.135 auf 8.108 GiB, während der vom Allocator reservierte Höchstwert bei 8.070 GiB bleibt. Dies sind unterschiedliche Speichermessgrößen.
1. Zuerst Version und betroffenen Ausführungsschritt bestimmen
Die Autoren bezeichnen sich als PyTorch-Team von Hugging Face, das gemeinsam mit PyTorch-Maintainern und weiteren Mitwirkenden am Upstream-Projekt arbeitet. Ihre Erklärung konzentriert sich darauf, ausgewählte MPSGraph-Pfade durch spezialisierte Metal-Kernel zu ersetzen. Das ist Backend-Entwicklung: Modelle können profitieren, ohne dadurch neue Modellveröffentlichungen zu werden, und ein schnellerer Kernel belegt keine besseren Modellantworten. Die genannte Umgebung erfordert einen Mac mit Apple silicon, macOS 15 oder neuer und Python 3.11 oder neuer.
Der Beitrag lädt ausdrücklich dazu ein, einen Release-Kandidaten von 2.15 in einer separaten Umgebung auszuprobieren. Spätere Abschnitte behandeln 2.16-Änderungen, die in Nightly-Builds verfügbar sein können oder noch geprüft werden. AISubHub hat den späteren Status stabiler Versionen nicht unabhängig überprüft. Für einen reproduzierbaren Vergleich sollten genauer Build, Gerät, dtype, Compiler-Einstellung und Arbeitslast festgehalten werden, bevor man zwischen diesen Abschnitten wechselt. Sonst lässt sich eine künftige Optimierung leicht mit einer Funktion der getesteten Version verwechseln.
2. Die Decodierspezialisierung verändert eine kleine, wiederholte Operation
Beim Prefill verarbeitet ein Modell einen Eingabeblock; beim Decodieren verarbeitet es wiederholt eine kleine Eingabe für das nächste Token. Der Beitrag verbindet F.linear mit vorhandenen Matrix-Vektor-Kerneln und passenden fusionierten Bias-Additionen. Über 96 BF16-Layer-Formen wird eine Beschleunigung im geometrischen Mittel um den Faktor 1.23 berichtet. Kleine Projektionen profitieren am meisten, während große Layer nahe der Bandbreitengrenze ungefähr bei Faktor eins bleiben. Das ist eine Sammlung von Layer-Messungen, kein Durchschnitt für ein vollständiges Modell.
Bei Mixture-of-Experts-Ausführung liest die native gruppierte Matrixmultiplikation Gruppen-Offsets auf der GPU, statt sie auf die CPU zu kopieren und die Gruppen einzeln zu durchlaufen. Das gezeigte Diagramm zur Decodierspezialisierung nutzt einen M3 Ultra mit torch.compile: Qwen3.6-35B-A3B steigt bei Kontext 512 von 38.7 auf 51.7 Tokens pro Sekunde und bei Kontext 2048 von 36.8 auf 48.7. Getrennt davon berichtet der Beitrag größere Vergleiche ganzer Versionen gegenüber 2.14. Diese Vergleiche, der Kernel-Vergleich von ungefähr Faktor 1.3 und spätere 2.16-Messungen verwenden unterschiedliche Ausgangspunkte; sie dürfen weder zusammengeführt noch multipliziert werden.
3. FP8-Speicherung und Softmax-Zeit beantworten verschiedene Fragen
Die FP8-Erweiterung unterstützt Tensoren vom Typ torch.float8_e4m3fn mit einem Byte pro Wert gegenüber zwei bei FP16 oder BF16. F.scaled_mm unterstützt Skalierung pro Tensor und pro Zeile. Das kann den Speicherbedarf geeigneter Tensoren reduzieren, halbiert aber nicht den Speicher einer ganzen Anwendung: Andere Tensoren, Arbeitsbuffer und Laufzeitallokationen bleiben bestehen. Auch Quantisierung und Ausgabe-dtype im Beispiel beeinflussen das numerische Verhalten. Native FP8-Matrixmultiplikation beschreibt der Beitrag als Grundlage künftiger Metal-Shader-Arbeit. Die heutige Speicherunterstützung ist daher keine allgemeine Zusage einer Hardwarebeschleunigung.
Das Softmax-Diagramm ist ein weiteres, getrenntes Experiment. Für eine FP32-Logit-Zeile mit einer Vokabulargröße von 128,256 zeigt es 57.4 Mikrosekunden unter MPSGraph und 7.1 beim Metal-Kernel; der Text rundet auf 57 und 7. Ein ungefähr achtmal schnelleres Softmax kann einen Schritt beim Token-Sampling verkürzen, doch weitere Arbeit bestimmt weiterhin die gesamte Generierungszeit. AISubHub-Analyse: Neben dem teuren Operator sollte auch der vollständige Pfad gemessen werden. Die Einheiten müssen erhalten bleiben, damit Mikrosekunden pro Aufruf nicht zu einer unbelegten Aussage über Sekunden pro Antwort werden.
4. Padding macht Speicher außerhalb des Tensor-Allocators sichtbar
Das Wan2.2-Beispiel betrifft ausdrücklich Wan-AI/Wan2.2-TI2V-5B-Diffusers mit 8,764 Aufrufen für konstantes Padding während einer VAE-Decodierung mit 28 Kacheln. Die Verlagerung des Paddings auf Metal verändert den berichteten gesamten Treiberspeicherhöchstwert von 270.135 auf 8.108 GiB. Der vom Allocator reservierte Höchstwert beträgt jedoch in beiden Konfigurationen 8.070 GiB, und der Höchstwert der aktuellen Tensorallokation ändert sich nur von 4.422 auf 4.095 GiB. Eine reine Allocator-Messung würde den größten Teil dieses konkreten Problems übersehen. Das Ergebnis besagt nicht, dass nun jedes Videomodell nur acht GiB benötigt.
Korrektheit ist ein eigener Vorteil. Für einen VAE-Rundlauf aus Codierung und Decodierung von Qwen-Image-2.1 berichten die Autoren nach der Padding-Korrektur eine bessere Übereinstimmung mit der CPU-Referenz: Der PSNR steigt von 10.06 auf 29.95 dB. Das betrifft den getesteten Rekonstruktionsablauf, nicht einen allgemeinen Qualitätswert für Bildgenerierung. Weitere genannte Änderungen umfassen komplexwertige lineare Algebra, Rückwärtsrechenpfade und Attention-Broadcasting. Eine sinnvolle Upgrade-Prüfung betrachtet daher neben dem Durchsatz auch numerische Ausgaben und den maximalen Treiberspeicher, bei gleichem Modell und gleichen Operationsformen.
5. Künftige Arbeit und lokale Validierung sichtbar halten
Der 2.16-Ausblick umfasst Änderungen bei der Übergabe von Befehlsbuffern, vollständig auf Metal ausgeführte Attention und weitere MPSGraph-Migrationen. Die Autoren warnen, dass ein Teil der Arbeit noch geprüft wird. Die künftigen Attention-Beispiele verwenden zudem einen M5 Pro und bestimmte Kopf-Dimensionen, anders als das Decodierdiagramm auf dem M3 Ultra. Weder diese Zahlen noch die Größenreduktion einer mitgelieferten Bibliothek dürfen als gemessener Vorteil der Installation des 2.15-Kandidaten auf irgendeinem Mac dargestellt werden.
Öffentliche MPS-Streams und das Aufzeichnen der Stream-Nutzung von Tensoren geben Python-Aufrufern mehr Planungskontrolle, doch das Beispiel synchronisiert weiterhin vor dem Lesen des Ergebnisses. Der Beitrag nennt außerdem verbleibende Operationsgrenzen und laufende Arbeit zur Beseitigung von Unterbrechungen des Kompilierungsgraphen. AISubHub leitet daraus ab, eine separate Umgebung mit den tatsächlichen dtype-Werten, Formen, Synchronisierungen und Ausgabetoleranzen der Anwendung zu testen. Wir haben den vollständigen Beitrag und alle drei Diagramme gelesen; wir haben weder PyTorch installiert noch Beispiele ausgeführt, verlinkte Pull Requests geprüft oder Zeit-, Qualitäts- oder Speicherergebnisse reproduziert.
Warum es wichtig ist
AISubHub-Analyse: Backend-Upgrades sollten mit getrennten Aufzeichnungen für vollständigen Decodierdurchsatz, Operatorzeiten, Ausgabekorrektheit und maximale Treiberspeichernutzung bewertet werden. So lässt sich erkennen, welche berichtete Änderung einen echten Anwendungsengpass trifft, ohne ein Kernel-Ergebnis zu einer universellen Modellaussage zu machen.
Grenzen und Verfügbarkeit
Alle Messungen werden den PyTorch-Mitwirkenden von Hugging Face und ihren genannten Konfigurationen zugeschrieben. Der Beitrag beschreibt einen Release-Kandidaten von 2.15 und grenzt 2.16-Arbeit davon ab; die spätere stabile Verfügbarkeit wurde nicht unabhängig geprüft. AISubHub hat die Software weder installiert oder ausgeführt noch Benchmarks reproduziert oder verlinkte Implementierungen untersucht. Daraus folgt keine allgemeine Garantie für Geschwindigkeit, ausreichenden Speicher oder numerische Qualität.
Quellen und Belege
Datum der Quelle: · Quelle geprüft:
KI-gestützte redaktionelle Beiträge, anhand der genannten Primärquellen geprüft. Anbieterangaben werden zugeordnet; eine Aufnahme ist keine Empfehlung.