PyTorch 2.13: bis zu 4× weniger GPU-Speicher beim LLM-Training und 12,3× schnelleres FlexAttention

PyTorch 2.13 erscheint am 8. Juli 2026 mit 3.328 Commits von 526 Mitwirkenden seit dem letzten Release – und bringt Änderungen, die direkt drei chronische Schmerzpunkte von ML-Ingenieuren adressieren: GPU-Speicher beim Training großer Modelle, Aufmerksamkeitsgeschwindigkeit auf Apple Silicon und Komplexität des verteilten Trainings. Darüber hinaus wird die Plattformunterstützung auf Arm Armv9-A, Intel XPU und Python 3.15 erweitert, und das safetensors-Format wird nativ ohne externe Bibliothek unterstützt.

Verlust-Fusion: bis zu 4× weniger GPU-Speicher

Die beeindruckendste Neuerung in PyTorch 2.13 ist die neue Klasse nn.LinearCrossEntropyLoss. Auf den ersten Blick wirkt es wie eine Feinheit, aber die Implikationen sind erheblich für jeden, der Sprachmodelle mit großem Vokabular trainiert.

Der Standardablauf beim LLM-Training: Die abschließende lineare Schicht projiziert den verborgenen Zustand des Modells in den Vokabularraum (z. B. 100.000 Token), dann berechnet der Cross-Entropy-Verlust den Fehler im Vergleich zur richtigen Antwort. Das Problem liegt in der Größe der Zwischenergebnisse: Bei Modellen mit Vokabularen von 100.000 und mehr Token erfordert diese lineare Projektion enorme Tensoren, die auf der GPU gespeichert werden müssen, um den Gradienten bei der Rückwärtspropagation berechnen zu können.

nn.LinearCrossEntropyLoss fusioniert diese zwei Schritte in einer Operation – Projektion und Verlust werden gemeinsam berechnet, der Kernel materialisiert nie das vollständige Zwischenergebnis und hält es nicht im VRAM. Das Ergebnis: bis zu 4× geringerer GPU-Spitzenspeicherbedarf für das Training von Modellen mit großem Vokabular. Die API ist als Drop-in-Ersatz konzipiert – sie funktioniert mit Label Smoothing, Weight Tying und Z-Loss-Regularisierung, und die Migration erfordert minimale Codeänderungen.

Warum ist LinearCrossEntropyLoss so wichtig?

Selbst mit modernen GPUs mit 80 GB VRAM steht das LLM-Training vor Speicherbeschränkungen, die diktieren, welche Batch-Größe verwendet werden kann, wie lange Sequenzen das Modell sehen kann und wie groß ein Modell überhaupt trainierbar ist. Die Speicherschranke ist nicht abstrakt – sie bestimmt, welche Experimente mit der verfügbaren Hardware durchgeführt werden können.

Eine Reduzierung des Spitzenspeicherbedarfs um 4× bedeutet praktisch, dass man auf derselben GPU ein größeres Modell trainieren, eine größere Batch-Größe verwenden oder mit längerem Kontext arbeiten kann. Für Forschungslabore und Startups ohne Zugang zu Clustern mit Hunderten von GPUs ist das ein greifbarer Fortschritt, der verändert, was mit verfügbaren Ressourcen erreichbar ist – ohne teurere Hardware kaufen zu müssen.

FlexAttention auf Apple Silicon: bis zu 12,3× schneller

PyTorch 2.13 bringt FlexAttention auf das MPS-Backend (Apple Silicon). Bei spärlichen (Sparse) Aufmerksamkeitsmustern – wie Sliding-Window-Attention, die in Langkontextmodellen verwendet wird – beträgt die Beschleunigung bis zu 12,3× im Vergleich zu SDPA (Scaled Dot-Product Attention).

Konkrete Messungen sprechen für sich: Eine Sequenz von 32.768 Token mit einem gleitenden Fenster von 256 Elementen erfordert mit FlexAttention ~35 ms gegenüber ~431 ms mit Standard-SDPA auf demselben Apple-Silicon-Chip. Dieser Unterschied verwandelt Langkontext-Inferenz auf dem Mac von theoretisch machbar in praktisch schnell.

Hinzugekommen ist auch deterministische Rückwärtspropagation für FlexAttention – bit-für-bit reproduzierbare Gradienten werden mit torch.use_deterministic_algorithms(True) aktiviert, mit weniger als 1 % Zeitoverhead bei langen Sequenzen. Gradientenreproduzierbarkheit ist wichtig für das Debugging und für Produktionstraining-Pipelines, bei denen Konsistenz zwischen Durchläufen erwartet wird.

Neues Kompilierungs-Backend und verteiltes Training

PyTorch 2.13 führt das CuTeDSL „Native DSL”-Backend für Inductor ein – eine Alternative zu Triton für GEMM- und RMSNorm-Operationen auf NVIDIA-GPUs. Die Kernel-Kompilierung ist dank eines Subprocess-Pools schneller, der den GIL-Engpass beseitigt: Die parallele Kernel-Kompilierung blockiert nicht mehr am Python Global Interpreter Lock, sodass der gesamte Kompilierungsprozess auf Systemen mit mehreren Kernen schneller ist.

Auf der verteilten Front ersetzt die neue Bibliothek torchcomms das ältere c10d-Backend als modernen Kommunikationsschicht für verteiltes Training. Sie bringt strukturiertes Logging, Collective Tracing und bessere Fehlertoleranz – Graceful Timeout und Unterstützung für die Wiederherstellung partieller Knotengruppen, wenn ein Teil des Clusters vorübergehend ausfällt. FSDP2 erhält Kommunikationsüberlappung: reduce-scatter- und all-gather-Operationen können nun parallel fließen (opt-in via set_separate_reduce_scatter_group), was den Durchsatz des verteilten Trainings in Clustern mit schnellen Netzwerkverbindungen erhöht.

Eine praktische Kleinigkeit, die Integrationskopfschmerzen erspart: torch.load("foo.safetensors") funktioniert nun nativ ohne installierte externe safetensors-Bibliothek – das Format wird automatisch erkannt und geladen.

Erweiterte Plattformunterstützung: Arm, Intel XPU, Python 3.15 und Breaking Changes

PyTorch 2.13 erweitert die Plattformunterstützung auf mehreren Ebenen gleichzeitig:

Arm Armv9-A: torch.compile unterstützt AArch64-Prozessoren der Neoverse-V2- und AWS-Graviton4-Serie mit Propagierung von 128-Bit- und 256-Bit-SVE-Merkmalen. Cloud-Server auf Basis der Armv9-A-Architektur sind nun eine vollwertige Plattform für kompilierten PyTorch.

Intel XPU Telemetrie: Neue APIs zur Überwachung von Intel-XPU-Geräten – torch.xpu.device_memory_used(), CPU-Auslastung, Leistungsaufnahme, Takt und Temperatur – geben ML-Ingenieuren die Sichtbarkeit, die sie bisher nur für CUDA-Geräte hatten.

Python 3.15: Binäre Unterstützung unter Linux (x86_64 und aarch64), einschließlich der Free-Threaded-Variante (3.15t). Hinweis: torch.compile unter Python 3.15 ist noch nicht verfügbar, und das torchvision-Binärpaket für 3.15 wurde nicht erstellt – beides kommt in zukünftigen Versionen.

CUDA: Die Standardversion wird CUDA 13.0; CUDA-12.8- und 12.9-Builds wurden aus der Binärpaket-Matrix entfernt.

Breaking Changes: Benannte Tensoren (Named Tensors) wurden in diesem Release endgültig aus PyTorch entfernt – ein Hard-Deprecation, das über mehrere Versionen hinweg angekündigt worden war. Die verteilten Kollektive all_gather_into_tensor und reduce_scatter_tensor wurden in all_gather_single und reduce_scatter_single umbenannt. Der Bazel-Build wurde entfernt, und CPython 3.13t fällt aus der Linux-Binärmatrix heraus.

Das Apple-Silicon-MPS-Backend erhält eine umfangreiche interne Migration: Copy-, Cast-, Reduktions-, Sort-, Scatter/Gather- und Embedding-Backward-Operationen gehen nun direkt auf native Metal-Compute-Kernel, was den Kompilierungsoverhead von MPSGraph beseitigt, der die First-Run-Latenz verlangsamte.

Für Nutzer, die Details direkt von den Autoren erfahren möchten: Am 22. Juli 2026 um 11:00 Uhr Pacific Time wird ein Live-Q&A mit Alban Desmaison, Andrey Talman und Piotr Białecki (Moderator: Chris Gottbrath) veranstaltet.