8.192 TPU-Chips vom Typ v7x, ein Modell mit 235 Milliarden Parametern und 28 Prozent Model-FLOPs-Auslastung – mit diesen Zahlen belegte Google auf der PyTorch Conference 2026 in San Jose, dass PyTorch auf TPUs inzwischen nahezu linear skaliert. Der Durchsatz pro Chip blieb über den gesamten Cluster hinweg weitgehend konstant. Dahinter steht eine Entscheidung, die technisch unscheinbar beginnt: Google und Meta haben TorchTPU als Open Source veröffentlicht, ein natives Backend für Tensor Processing Units.
Die Zusammenarbeit ist ungewöhnlich. Meta hat PyTorch 2016 selbst initiiert und hätte Gründe gehabt, die eigene Plattform eng an einen Hardwarelieferanten zu binden. Stattdessen beschreibt Jana van Greunen, bei Meta für die PyTorch-Entwicklung verantwortlich, die Motivation mit dem Bedarf an Rechenleistung und Hardwarevielfalt: Ein einzelner Architekturpfad reiche für die eigenen Ansprüche nicht mehr aus.
TorchTPU ersetzt einen Konsekutivdolmetscher durch eine direkte Leitung
Der alte Weg über PyTorch/XLA, seit 2020 im Einsatz, arbeitete mit Lazy Tensors: Das Framework sammelte die Operationen eines Modells ein, ohne sie sofort auszuführen, und übergab das Gesammelte dann als Ganzes an einen Compiler. Das ist, als würde ein Konsekutivdolmetscher erst den kompletten Absatz mitschreiben, um ihn anschließend vorzutragen. Es funktioniert, verlangt aber Umbauten am Satz – in der Ankündigung ist von „intrusive source-code modifications“ die Rede, also von Eingriffen in den Quellcode, die ein Modell erst TPU-tauglich machten.
TorchTPU setzt weiter unten an, am Dispatcher von PyTorch. Diese Vermittlungsschicht entscheidet, welche Implementierung eine Operation auf welchem Gerät bekommt; sie ist der Punkt, an dem PyTorch fremde Hardware überhaupt erst als Zieladresse akzeptiert. Google registriert die TPU dort über PrivateUse1, den offiziellen Erweiterungspunkt des Frameworks für eigene Beschleuniger. Für Anwenderinnen und Anwender heißt das: Aus model.to(„cuda“) wird model.to(„tpu“), und der Rest bleibt stehen. Der Wechsel der Hardware ist damit keine Migration mehr, sondern eine Konfigurationsfrage.
Eine Zeile Code ist der Anfang, nicht das Ende der Arbeit
Die Ankündigung räumt eine Einschränkung ein. Ein Modell laufe nach dem Wechsel zwar ohne weitere Änderungen, Spitzenleistung sei damit aber nicht zu erreichen. Die Formen der Tensoren, die Aufteilung über mehrere Chips und die verwendeten Operationen eines Modells sind häufig auf GPU-Architekturen hin entworfen; auf einer TPU bleiben dann Reserven liegen. Die eine Zeile macht ein Modell lauffähig, nicht schnell.
Google setzt bei dieser Lücke auf Agenten. Bill Jia, Vizepräsident für Engineering im Bereich Core ML/AI, stellte zum Abschluss eine TPU-Agent-Suite vor, derzeit als Preview auf GitHub verfügbar. Sie hängt sich in Coding-Umgebungen ein und soll Onboarding, Diagnose und Leistungsoptimierung automatisieren – also die Arbeit übernehmen, die zwischen lauffähig und schnell liegt. Ob das trägt, müssen reale Projekte zeigen.
Was heute bereits auf TPUs läuft: vLLM, SGLang und TorchTitan
Weil TorchTPU am Dispatcher ansetzt, funktionieren Modelle aus dem Hugging-Face-Ökosystem nach Angaben der Entwickler ohne Anpassung. Auch die Inferenz-Engines vLLM und SGLang laufen nativ, für das Training in großem Maßstab steht TorchTitan bereit, das dichte Modelle, Mixture-of-Experts-Architekturen und Diffusionsmodelle abdeckt. Ray und llm-d verteilen die Last über mehrere Hosts in Kubernetes. Vier Repositories wurden gemeinsam geöffnet: TorchTPU selbst sowie die Anbindungen vLLM-TorchTPU, SGLang-TorchTPU und TorchTitan.
Entscheidend ist, dass die Werkzeuge mitkommen, mit denen Teams tatsächlich arbeiten. Wer eine Inferenzstrecke betreibt, entscheidet selten über das Framework allein, sondern über den Stack aus Engine, Scheduling und Betrieb. Dass dieser Stack auf der TPU mitgeliefert wird, senkt die Einstiegshürde deutlich.
Warum Meta einen zweiten Hardwarepfad braucht
Zongwei Zhou, Software Engineer bei Meta, sagt, sein Team habe TorchTPU gemeinsam mit Google entwickelt, um die TPU zu einem erstklassigen nativen Ziel für PyTorch zu machen. Die Begründung ist betrieblich und nicht strategisch: Leistung, Zuverlässigkeit und Wartbarkeit im Produktivbetrieb. Für ein Unternehmen, das große Sprachmodelle in Serie trainiert, ist das nachvollziehbar – jede Abhängigkeit von einem einzigen Chiphersteller wird zum Risiko, sobald die Nachfrage die Fertigung übersteigt.
Google war mit dieser Öffnung nicht allein. AWS brachte am 20. Oktober TorchNeuron in eine öffentliche Beta, ein natives Backend für die eigenen Trainium-Chips, bei dem ebenfalls ein .to(’neuron‘) als einzige Änderung genügen soll. Beide Backends registrieren sich über denselben Erweiterungspunkt PrivateUse1. Der erste TorchNeuron-Release hat allerdings Lücken: Laut einem Bericht von The Next Web fehlen dynamische Eingabeformen, und rund 22.000 PyTorch-Tests werden übersprungen.
Die Lock-in-Frage verschiebt sich, sie verschwindet nicht
In einer Analyse für Forkast argumentiert Blair Hayes, die Bindung habe sich verlagert statt aufgelöst: Der Erweiterungspunkt von PyTorch liefere zwar eine gemeinsame Sprache für Entwickler, die Optimierungs- und Lieferebenen blieben aber fest in Herstellerhand. Der Stecker ist genormt, das Innenleben der Steckdose nicht. Wer auf Spitzenleistung angewiesen ist, wird weiterhin die Optimierung des jeweiligen Anbieters brauchen.
Die Reaktionen in der Community fallen gemischt aus. Der Thread auf Hacker News erreichte 379 Punkte; ein Kommentar freute sich, dass man nicht mehr gegen XLA kämpfen müsse, andere fragten, wo man eine TPU überhaupt kaufen könne. Ein Kommentator, dessen Firma die On-Premises-Varianten geprüft hatte, berichtete von der Entscheidung, bei Nvidia zu bleiben. Solche Sätze markieren den Abstand zwischen Konferenz und Einkauf. Eine native PyTorch-TPU-Integration ist eine technische Voraussetzung, kein Beschaffungsargument.
Der Token-Hunger ist der Treiber
Warum das alles gerade jetzt passiert, erklärte Mark Collier, Executive Director der PyTorch Foundation: Inferenz hat das Training als größte Rechenlast in Rechenzentren überholt. Daraus entsteht nach seinen Worten ein enormer Hunger nach Tokens. Seine Folien zeigten, wie schnell dieser Markt sich bewegt – DeepSeek soll sein Flash-Modell in 37 Tagen um 60 Prozent günstiger gemacht haben, Kimi K3 auf identischer Hardware in 33 Tagen 68 Prozent schneller geworden sein.
Mazin Gilbert von der Agentic AI Foundation legte eine weitere Zahl daneben: Am 6. Februar 2026 habe der Tokenverbrauch von Agenten den menschlichen überholt, seither sei er um das 14-Fache gewachsen, der menschliche um das 2,8-Fache. Solche Zahlen sollte man prüfen, bevor man sie weiterverwendet: Die öffentlichen Daten stammen von einer einzigen Plattform, OpenRouter, und bilden damit einen Ausschnitt, nicht den Gesamtmarkt. Die Richtung ist trotzdem erkennbar: Die Nachfrage verschiebt sich von Trainingsläufen zu dauerhaft laufender Inferenz.
Was das für eigene Trainings- und Inferenz-Setups bedeutet
Für die meisten Teams ändert sich kurzfristig wenig. Wer heute auf Nvidia trainiert, hat keinen Grund zur Panikmigration, und ein Wechsel der Hardware bleibt eine Entscheidung über Kosten, Verfügbarkeit und Werkzeugreife. Was sich ändert, ist die Option: PyTorch auf TPUs ist kein Sonderweg mit eigener Toolchain mehr, sondern ein Ziel, das sich über denselben Code ansprechen lässt. Der Preis dafür ist Nachjustieren bei Sharding und Operationen.
Offen ist, ob daraus ein Muster wird. Zwei große Cloud-Anbieter öffnen innerhalb von zwei Tagen native Backends für ihre eigenen Beschleuniger, beide über denselben Erweiterungspunkt, beide mit der Aussage, der Wechsel sei eine Zeile. Das deutet darauf hin, dass das Framework stabil bleibt und die Hardware darunter austauschbar wird, zumindest theoretisch. Praktisch entscheidet die Qualität der Werkzeuge, der Dokumentation und der Fehlerbilder darüber, ob aus einer Zeile Code ein echter Wechsel wird. Zhou sagte in seiner Keynote, alles sei quelloffen und ab heute verfügbar. Das sei erst ein Anfang.
Quelle: infoq.com
