Google kündigte TorchTPU am 20. Oktober 2026 als Open-Source-Backend an, mit dem PyTorch auf Googles TPUs läuft. Für einen einfachen Lauf zeigen die Beispiele vor allem einen Wechsel des Zielgeräts; verteilte Jobs brauchen zusätzlich TPU-spezifische Startkonfiguration. TorchTPU entstand in Zusammenarbeit mit Metas PyTorch-Team.
Für Entwicklerinnen und Entwickler bedeutet das: Ein vorhandenes PyTorch-Modell kann ein naheliegender Ausgangspunkt sein, doch Codeänderungen allein garantieren weder universelle Kompatibilität noch Spitzenleistung. Das Backend nutzt die gewohnte PyTorch-Semantik und unterstützt sowohl den direkten Ausführungsmodus als auch kompilierte Modelle.
Der einfache Einstieg: TPU als Zielgerät wählen
Googles Installationsbeispiel lautet pip install torch_tpu. Danach lässt sich ein Gerät mit torch.device("tpu") auswählen. Ein Beispiel des PyTorch-Projekts zeigt den Wechsel von .to("cuda") zu .to("tpu").
pip install torch_tpu
torch.device("tpu")
Im direkten Ausführungsmodus, dem sogenannten Eager-Modus, verarbeitet PyTorch Operationen unmittelbar. Für kompilierte Ausführung kann ein Modell mit torch.compile kompiliert werden. Die Google-Cloud-Dokumentation zu PyTorch auf TPU beschreibt Installation und Geräteauswahl.
Die Geräteänderung ist ein Einstieg, keine Leistungsoptimierung. Laut PyTorch-Projekt können Modellformen, Verteilung der Berechnung auf Geräte und einzelne Operationen weiterhin auf GPU-Hardware zugeschnitten sein. Für bessere TPU-Leistung kann deshalb eine Anpassung nötig sein. In einem dokumentierten Beispiel musste bei einer von GPU-Code ausgehenden Muse-Glimmer-30B-Portierung FlexAttention durch F.scaled_dot_product_attention ersetzt werden, weil FlexAttention in diesem Test nicht unterstützt wurde.
Verteilte Jobs benötigen TPU-spezifische Einrichtung
Bei verteilten Läufen kommt zur Geräteauswahl ein Backend für die Kommunikation zwischen Prozessen hinzu. TorchTPU verwendet dafür tpu_dist; das vorgesehene Modell startet einen Prozess pro Gerät. Der Start braucht außerdem Angaben zur TPU-Topologie und zur Slice-Konfiguration.
| Arbeitslast | Änderung in PyTorch | Zusätzliche Startanforderung |
| Einfacher Lauf | TPU als Gerät mit torch.device("tpu") oder .to("tpu") auswählen | TPU-Gerät für den Lauf auswählen |
| Verteilte Ausführung | tpu_dist als Backend verwenden | Ein Prozess pro Gerät sowie TPU-Topologie und Slice-Konfiguration festlegen |
Damit lässt sich der Aufwand besser abschätzen: Bei einem einfachen Lauf steht die Geräteauswahl im Vordergrund. Für verteilte Ausführung muss auch die Startumgebung zur TPU passen. Ein Wechsel des Gerätebezeichners allein deckt diese Einrichtung nicht ab.
Was die veröffentlichten Tests aussagen
Das PyTorch-Projekt berichtet, dass in einem ausgewählten Tier-1-Test 4.821 von 4.917 Modellen einen Lauf ohne Absturz bestanden. In einem separaten Tier-2-Test erreichten 638 von 657 repräsentativen Modellen numerische Parität mit einer GPU-Baseline. Für Tests zu begrenzter Dynamik meldete das Projekt korrekte Ergebnisse bei 834 von 839 kausalen Sprachmodellen.
Diese Zahlen betreffen unterschiedliche Testgruppen und Kriterien: Ein Lauf ohne Absturz ist kein Nachweis numerischer Gleichheit, und der Paritätstest gilt für die ausgewählten repräsentativen Modelle. Die Werte stammen aus Tests des PyTorch-Projekts, nicht aus einem standardisierten Vergleich sämtlicher TPU- und GPU-Arbeitslasten.
Als Skalierungstest berichtet das Projekt einen Trainingslauf mit Qwen3 MoE 235B auf bis zu 8.192 TPU-v7-Chips. Für die größte Konfiguration mit einer Batchgröße von 262.144 und einer Sequenzlänge von 4.096 nennt es 2.104 Tokens pro Sekunde je TensorCore, eine MFU von 27,1 Prozent und 31,2 Sekunden pro Trainingsschritt. Diese Messwerte beschreiben genau diesen Lauf und seine Konfiguration.
Gespeicherte Modellgewichte auf TPU laden
Kompatible PyTorch-Modellgewichte lassen sich über ein state_dict in ein initialisiertes Modell laden; torch.load kann gespeicherte Tensoren beim Laden einem Zielgerät zuordnen. Zusammen mit der TPU-Geräteauswahl von TorchTPU bietet das einen Weg, ein Modell mit gespeicherten Gewichten auf TPU auszuführen. Voraussetzung bleibt, dass Modell und verwendete Operationen mit der TPU-Ausführung kompatibel sind.
Modellgewichte sind nur ein Teil eines Trainings-Checkpoints. Optimizer- und Scheduler-Zustände sind davon getrennte Bestandteile und sollten bei der Umstellung als solche behandelt werden. Eine pauschale Übertragung jedes Checkpoints folgt nicht allein daraus, dass sich Modellparameter laden lassen.
Zu TorchTPUs Ökosystem gehören Integrationen mit Hugging Face, vLLM, SGLang, llm-d, TorchTitan und Ray. Das kann den Einstieg in vorhandene Werkzeuge erleichtern; für den konkreten Lauf bleiben Geräteauswahl, unterstützte Operationen und gegebenenfalls die verteilte TPU-Konfiguration entscheidend.
