Am Tag der PyTorch Conference 2026 hat Google Cloud mitgeteilt, dass TorchTPU, entwickelt gemeinsam mit dem PyTorch-Team von Meta, auf GitHub als Open Source verfügbar ist. Laut Google sind TPUs damit wie GPUs und CPUs eine native Geräteoption in PyTorch, und bestehender Code laufe weitgehend ohne Änderungen.
Die Ankündigung stammt von Mark Lohmeyer, Vice President für KI und Recheninfrastruktur bei Google Cloud, und Bill Jia, Vice President Engineering. Das Code-Repository liegt in der Organisation google-pytorch; die zugehörigen Backends für vLLM und SGLang wurden jeweils in die Organisationen der beiden Projekte aufgenommen.
Einmal veröffentlicht, gleich mehrere Frameworks angebunden
TorchTPU unterstützt das Debugging im Eager-Modus und kann über torch.compile die TPU-Auslastung steigern und den Speicherbedarf senken. Am selben Tag wurden zahlreiche vor- und nachgelagerte Projekte angebunden:
- Inferenz: vLLM und SGLang haben jeweils ein natives PyTorch-Backend. Ersteres unterstützt Continuous Batching, Quantisierung und Multi-Chip-Parallelität, Letzteres nutzt RadixAttention, um den KV-Cache wiederzuverwenden. llm-d 1.0, gemeinsam mit Red Hat und IBM veröffentlicht, übernimmt Prefix-Cache-bewusstes Routing sowie die Trennung von Prefill und Decode.
- Training: TorchTitan hat Modelle wie Llama 3 70B/405B, Qwen 3 8B/32B, Qwen 3 235B (MoE) und FLUX.1 12B validiert; das Reinforcement-Learning-Framework VeRL hat ein TPU-Backend und ein GRPO-Referenzrezept übernommen, derzeit als Vorschauversion.
- Ökosystem: Hugging Face Transformers v5 lädt Modelle mit einer Zeile,
device_map="tpu", auf die TPU und hat zudem eine nächtlich laufende TPU-Continuous-Integration für Transformers aufgebaut; Ray kann CPU, GPU und TPU in einer Pipeline zusammenführen.
Google nennt zwei Gruppen von Leistungswerten. TorchTitan erreicht 52 % MFU bei Qwen 3 8B und skaliert auf bis zu 8192 Ironwood-Chips (TPU v7x) nahezu linear. Der Partner Zenteiq steigerte mit llm-d und GKE die tägliche Generierung pro 1000 TPU-v6e-Chips von 1,47 auf 5,97 Milliarden Token, also um mehr als das Vierfache. Beide Werte stammen aus Messungen von Google oder dem Partner; eine vollständige Konfiguration zur Reproduktion enthält die Ankündigung nicht.
Warum Meta mit auf die Bühne kommt
Jana van Greunen, Engineering Director für PyTorch bei Meta, wird in der Ankündigung mit einem Satz zitiert:
"We cannot be constrained by a single hardware architecture."
Wir dürfen uns nicht an eine einzige Hardwarearchitektur binden.
Sie erwähnt, TorchTPU trage bereits „geschäftskritische Produktionsszenarien“ in Metas großen Modellen, Werbe- und Empfehlungssystemen. Wie viele TPUs dafür im Einsatz sind und welchen Anteil sie an Metas Rechenleistung ausmachen, wurde diesmal nicht offengelegt. Auch Hugging Face, Inferact (das Unternehmen hinter vLLM) und RadixArk (hinter SGLang) äußerten sich, jeweils mit Blick auf „Hardwarevielfalt“.
In derselben Woche legt auch AWS nach
Stellt man TorchTPU neben TorchNeuron, das AWS einen Tag zuvor vorgestellt hat, gehen beide Anbieter denselben Weg. TorchNeuron ist das native PyTorch-Backend für Trainium, steht unter Apache 2.0 als Open Source, befindet sich seit dem 20. Oktober in der öffentlichen Beta und unterstützt Trainium2 und Trainium3; Nutzer müssen lediglich .to('neuron') aufrufen. Auch hier dienen Transformers v5 und TorchTitan als Aushängeschild, und der erwähnte PyTorch-Engineering-Director von Meta hat ebenfalls ein Empfehlungszitat für AWS beigesteuert.
Der Unterschied liegt im Detail. AWS hat seine Testmethodik offengelegt: Blindtests mit 100.000 Hugging-Face-Modellen und den PyTorch-Upstream-Tests mit rund 154.000 Ergebnissen, von denen etwa 39.000 von Neuron bewusst übersprungen wurden, darunter Funktionen wie Sparse-Tensoren und dynamische Shapes, die die erste Version nicht unterstützt. Google listet dagegen nur die unterstützten Komponenten auf; welche Operatoren auf die CPU zurückfallen und welche Funktionen fehlen, wird in der Ankündigung nicht in vergleichbarer Detailtiefe beschrieben.
Beide stützen sich auf geräteunabhängige Schnittstellen, die die PyTorch-Community in den letzten Jahren geschaffen hat, etwa den Erweiterungspunkt PrivateUse1 und torch.accelerator. Bisher liefen PyTorch-Nutzer auf TPUs vor allem über PyTorch/XLA und die Übersetzung durch den XLA-Compiler, deren Debugging-Erfahrung immer wieder kritisiert wurde. Mit dem nativen Backend sinkt die Migrationshürde von „Code ändern“ auf „Gerätenamen ändern“.
Für Entwickler ist der realistischste Test, wie sich Modelle schlagen, die nicht auf der offiziellen Validierungsliste stehen. Die TorchTPU-Dokumentation nennt als TPU-Typen nur v6e und Ironwood; ob ältere Generationen funktionieren und wie schnell sie sind, hat Google bislang nicht gesagt. Auch das begleitende TPU-Agent-Plugin befindet sich noch in einer frühen Vorschau.
Quellen: Offizieller Google-Cloud-Blog, offizieller PyTorch-Blog (TorchNeuron-Ankündigung), CocoLoop, TorchTPU-GitHub-Repository; MFU- und Durchsatzwerte beruhen auf den Eigenmessungen von Google und Partnern.