Das Wichtigste in Kürze
PyTorch-Code kann Googles TPUs jetzt nativ ansprechen – ohne separate Portierungsschicht. Google hat TorchTPU am 20. Oktober 2026 auf der PyTorch Conference als Open Source veröffentlicht, entwickelt gemeinsam mit dem PyTorch-Team von Meta. Bestehender PyTorch-Code für Training und Serving wandert mit minimalen Änderungen auf Cloud TPUs. Teams können TPU, GPU und Trainium so nach Kosten und Qualität vergleichen, bevor sie Budget binden.
Was hat Google veröffentlicht?
TorchTPU registriert die TPU als vollwertiges PyTorch-Gerät: Code, der heute .to("cuda") aufruft, kann .to("tpu") aufrufen und seine Trainingsschleife unverändert behalten. Bisher lief PyTorch auf TPUs über die separate Schicht PyTorch/XLA, die viele Teams schwerer zu debuggen fanden als den GPU-Pfad. In Googles Ankündigung, verfasst von Mark Lohmeyer und Bill Jia, heißt es, TPUs reihten sich nun „neben GPUs und CPUs als native Option für PyTorch“ ein.
Das Backend unterstützt Eager Execution für die Entwicklung und torch.compile für Produktionsleistung. Parallel hat Google eine frühe Vorschau der TPU Agent Suite veröffentlicht – einen KI-Coding-Agenten, der beim Onboarding, bei der Fehlerdiagnose und beim Inferenz-Tuning hilft – und LiteRT (vormals TensorFlow Lite) ins PyTorch-Ökosystem überführt, um Modelle auf Smartphones, Laptops und Embedded-Geräte zu exportieren.
Welche Werkzeuge funktionieren bereits mit TorchTPU?
Die eigentliche Nachricht ist das Ökosystem. Laut TechCrunch hat Google vor dem Start direkt mit Meta, Hugging Face, Inferact (dem Unternehmen hinter vLLM) und RadixArk (dem Entwickler von SGLang) zusammengearbeitet. Nach Googles Angaben sieht der unterstützte Stack zum Start so aus:
- Training: TorchTitan-Rezepte für Llama 3, Qwen 3 und FLUX.1; VeRL für Post-Training per Reinforcement Learning (Vorschau); Ray für gemischte CPU-, GPU- und TPU-Jobs.
- Serving: TorchTPU-Backends für vLLM und SGLang sowie llm-d 1.0, das CNCF-Sandbox-Projekt für verteilte Inferenz, unterstützt von Red Hat und IBM.
- Modelle: Hugging Face Transformers v5 deployt mit
device_map="tpu"auf TPUs; auch Diffusers und TorchRec sind abgedeckt.
Google nennt ein Kundenergebnis: Zenteiq meldete mit llm-d einen viermal höheren aggregierten Inferenzdurchsatz und steigerte die Tageskapazität von 1,47 auf 5,97 Milliarden Tokens pro 1.000 TPU-v6e-Chips.
Warum ist eine zweite PyTorch-Portierung wichtig?
Nvidias Vorsprung beruht stark darauf, dass CUDA das Standardziel für PyTorch ist. Amazon hat diesen Standard am 19. Oktober mit TorchNeuron für Trainium angegriffen; Google folgte einen Tag später. Wenn zwei Hyperscaler native Backends ausliefern und ihre Arbeit upstream in PyTorch selbst einbringen, wird hardwareneutrales PyTorch zur erwarteten Grundlage statt zum Anbieterexperiment.
Für Einkäufer bedeutet das Verhandlungsmacht. Läuft derselbe Modellcode auf drei Beschleunigerfamilien, werden GPU-Reservierungen, TPU-Zusagen und Trainium-Kapazität zu vergleichbaren Positionen in der Verhandlung.
Was ist noch nicht belegt?
Die Auslastungs- und Durchsatzzahlen stammen von Google und seinen Partnern, nicht aus unabhängigen Benchmarks. In seiner technischen Vorschau vom April hat Google selbst eingeräumt, dass wechselnde Sequenzlängen und Batchgrößen eine Neukompilierung auslösen und dass Spitzenleistung auf TPUs weiterhin ein Refactoring des Modells erfordern kann. Eigene CUDA-Kernel wandern nicht per Geräte-Flag mit, und TPUs gibt es nur in Google Cloud – die Portabilität gilt also zwischen Chips, nicht zwischen Clouds.
Was das für Software-Teams in den USA und der EU bedeutet
Teams, die Modelle in reinem PyTorch trainieren, fine-tunen oder ausliefern, haben jetzt eine realistische dritte Option für gleichmäßige Workloads mit hohem Volumen wie Batch-Inferenz, Embeddings und Fine-Tuning-Läufe. Entscheidend sind die Kosten pro Token oder pro Trainingslauf mit Ihren eigenen Modellen, das Latenzprofil beim Serving über vLLM oder SGLang und die Kapazität in den Regionen, die Sie nutzen dürfen.
Es gilt dieselbe Disziplin, die schon Trainium testbar gemacht hat: Geräteauswahl in der Konfiguration, keine hart codierten CUDA-Aufrufe im Hauptpfad und ein reproduzierbares Evaluationsset.
Was bedeutet das für KI-Teams im DACH-Raum?
Für viele Mittelständler und Scale-ups in Deutschland, Österreich und der Schweiz ist GPU-Rechenzeit der größte Einzelposten im KI-Budget – und die Debatte um digitale Souveränität macht jede zusätzliche Bindung an einen US-Hyperscaler erklärungsbedürftig. TorchTPU senkt die Wechselkosten zwischen Chips, bindet TPU-Workloads aber vollständig an Google Cloud. Mit TorchNeuron für AWS und TorchTPU für Google gilt deshalb: Wer seine PyTorch-Pipelines jetzt hardwareneutral aufstellt, behält die Option offen, zwischen Anbietern, europäischen GPU-Clouds und eigener Infrastruktur zu wechseln.
Regulatorisch ändert der Chipwechsel nichts an den Pflichten, wohl aber an der Dokumentation. Prüfen Sie vor dem Pilot, ob TPU v6e und Ironwood in den für Ihr Konto freigegebenen EU-Regionen tatsächlich verfügbar sind. Eine neue Verarbeitungsumgebung gehört ins Verzeichnis von Verarbeitungstätigkeiten nach Art. 30 DSGVO, und wer Modelle unter dem EU AI Act dokumentieren muss, sollte die Hardware-Umgebung in der technischen Dokumentation festhalten.
Was ML-Teams in diesem Quartal tun sollten
- CUDA-Abhängigkeiten erfassen. Listen Sie eigene Kernel, reine CUDA-Bibliotheken und hart codierte Geräteaufrufe in Trainings- und Serving-Code auf.
- Gerät zur Einstellung machen. Steuern Sie die Beschleunigerwahl jeder Pipeline über die Konfiguration, damit GPU-, TPU- und Trainium-Läufe identischen Code nutzen.
- Mit dem Serving starten. Benchmarken Sie ein Produktionsmodell über vLLM oder SGLang auf TPU gegen Ihr aktuelles GPU-Setup und messen Sie Latenz, Durchsatz und Kosten pro Million Tokens.
- Dynamische Shapes testen. Spielen Sie echten Traffic mit unterschiedlichen Prompt-Längen ab, um zu sehen, ob Neukompilierung die Latenz beeinträchtigt.
- Regionen und Zusagen prüfen. Klären Sie die TPU-Kapazität in Ihren freigegebenen EU-Regionen und wie sich ein Wechsel auf bestehende GPU- oder AWS-Zusagen und die DSGVO-Dokumentation auswirkt.
Häufige Fragen
Was ist Google TorchTPU?
TorchTPU ist ein Open-Source-PyTorch-Backend, das PyTorch-Modelle nativ auf Google Cloud TPUs ausführt. Google hat es am 20. Oktober 2026 öffentlich freigegeben, nachdem es gemeinsam mit dem PyTorch-Team von Meta entwickelt wurde.
Wie viel Code muss ich ändern, um PyTorch auf TPUs zu betreiben?
Laut Google nur minimal: Code, der das GPU-Gerät anspricht, kann stattdessen das TPU-Gerät ansprechen, und Hugging Face Transformers v5 nutzt device_map="tpu". Eigene CUDA-Kernel und reine CUDA-Bibliotheken müssen weiterhin portiert werden.
Worin unterscheidet sich TorchTPU von Amazon TorchNeuron?
Beide lassen PyTorch nativ auf einem Nicht-Nvidia-Chip laufen. TorchTPU zielt auf Google Cloud TPUs und kommt mit einem KI-Portierungsagenten sowie LiteRT für den Edge-Export; TorchNeuron, einen Tag früher angekündigt, zielt auf AWS Trainium. Beide laufen nur in der jeweils eigenen Cloud.
Ist TorchTPU produktionsreif?
Google und Meta beschreiben einen produktiven Einsatz, und llm-d 1.0 gilt als produktionsreif, doch die Leistungszahlen sind Herstellerangaben. Fahren Sie einen Pilot mit eigenen Modellen und eigenem Traffic, bevor Sie Produktions-Workloads verlagern. Für DACH-Teams gehört dazu die Prüfung, ob die Daten in den freigegebenen EU-Regionen bleiben.
Quellen
Google Cloud — TorchTPU is now open source: run native PyTorch on TPUs (October 20, 2026)
TechCrunch — Google has joined Amazon in attacking Nvidia’s stronghold with AI app developers (October 20, 2026)
Google Developers Blog — TorchTPU: Running PyTorch natively on TPUs at Google scale (April 7, 2026)
Techzine — Google and Meta are making AI chips more accessible with TorchTPU (October 21, 2026)