Google veröffentlicht TorchTPU als Open Source, während Amazons TorchNeuron in die Beta geht

Google hat TorchTPU am Dienstag, dem 20. Oktober, als Open Source veröffentlicht, zum Auftakt der PyTorch Conference in San Jose, und damit die eigenen Tensor Processing Units zu einem nativen Ziel für PyTorch-Code gemacht. Amazons TorchNeuron, einen Tag zuvor angekündigt, ging am 20. Oktober für Trainium2 und Trainium3 in die öffentliche Beta. Bei Google wechselt ein Modell auf eine TPU, indem sich der Device-String ändert; bei Amazon lautet die Änderung im Beispiel des Unternehmens model.to('neuron'). Beide Projekte liegen auf GitHub, und beide adressieren dieselben Kosten: die Ingenieurszeit, die ein Team aufwendet, damit eine funktionierende PyTorch-Codebasis irgendwo anders als auf Nvidia-Hardware läuft.

Zum Weiterlesen: Amazon will 8 Milliarden Dollar an Nvidia-Chips über ein Finanzierungsvehikel auslagern · DeepSeek veröffentlicht einen Open-Source-Software-Stack für Huaweis Ascend-Chips mit Blick auf CUDA.

Keines der beiden ist ein neuer Chip. Es handelt sich jeweils um ein Software-Backend zwischen PyTorch und einem Beschleuniger, das die Operationen des Frameworks abfängt und in etwas übersetzt, das der Chip ausführen kann. TorchTPU zielt auf TPUs, TorchNeuron auf Trainium. Beide docken über den PrivateUse1-Erweiterungspunkt von PyTorch an, den Mechanismus, mit dem ein Hardwarehersteller ein Gerät registrieren kann, ohne das Framework zu forken. Dieser Erweiterungspunkt ist der Grund, warum zwei konkurrierende Cloud-Anbieter in derselben Woche native Backends ausliefern konnten. Keiner von beiden besitzt PyTorch.

Was die beiden Veröffentlichungen tatsächlich enthalten

TorchTPU ist das ältere Projekt. Google zufolge begann die Arbeit Mitte 2025 mit Metas PyTorch-Team, und der PyTorch-Blog nennt es „eine Open-Source-Zusammenarbeit zwischen Google und Meta, die ein natives PyTorch-Backend für Google TPUs nach klaren Prinzipien einführt“. Es ersetzt den früheren Weg über PyTorch/XLA, das Google 2020 auf Lazy Tensors einführte. Diese Version verlangte von Entwicklern, kompilierbare Bereiche im Quellcode zu markieren, hatte lange Kompilierzeiten und unterstützte den Eager-Execution-Modus von PyTorch nicht. TorchTPU läuft standardmäßig eager, unterstützt torch.compile, registriert rund 450 Aten-Operatoren und implementiert TPU-Kollektive auf Prozessgruppen-Ebene, sodass verteilter Code für DTensor, FSDP und ähnliche APIs ohne separate Kommunikationsbibliothek funktioniert.

Googles Ankündigung listet vier Repositories auf: TorchTPU selbst, dazu TPU-Backends für vLLM und SGLang und eine TorchTitan-Integration. Die Serving-Engines wiegen mehr als die Schlagzeile. vLLM und SGLang gehören zu den wichtigsten Engines für das Ausliefern von Open-Weight-Modellen, und ein Backend, das nur in einem Trainingsskript funktionierte, würde die Inferenz auf GPUs lassen. Google nennt außerdem Integrationen mit llm-d 1.0, Ray, TorchRec, Hugging Face Transformers v5, wo device_map="tpu" ein Modell auf eine TPU lädt, und LiteRT, Googles On-Device-Runtime, die zum PyTorch-Ökosystem gestoßen ist. Eine TPU-Agent-Suite in der Preview soll Migrationsfragen beantworten und Fehler während einer Portierung beheben.

Die Aussage zur Abdeckung ist konkret, die zur Leistung nicht. Google zufolge wurden 4.917 der meistgeladenen Hugging-Face-Modelle aus mehr als 500 Architekturfamilien validiert, und der PyTorch-Beitrag schreibt, TorchTPU werde bereits produktiv für Inferenz und Training genutzt, von „einigen der größten Google-Cloud-Kunden“, ohne sie zu nennen. Ein Modell ohne Anpassung laufen zu lassen und es gut laufen zu lassen, sind verschiedene Ergebnisse, und Googles eigener Beitrag schreibt, Spitzenleistung erfordere Formen, Sharding und Operatoren, die zur Architektur der TPU passen.

„Mit TorchTPU stehen TPUs neben GPUs und CPUs als native Option für PyTorch.“ — Mark Lohmeyer und Bill Jia, Google Cloud, 20. Oktober 2026

Amazons Ankündigung ist enger, und die Dokumentation benennt die Lücken ausdrücklicher. TorchNeuron registriert Trainium als Gerät neuron, unterstützt Eager und torch.compile, stellt Werkzeuge für eigene Kernel über das Neuron Kernel Interface bereit und leitet Profiling-Daten über den Standard torch.profiler in einen Viewer namens Neuron Explorer. Unterstützt werden DDP, FSDP2, Tensor- und Pipeline-Parallelität, DTensor und DeviceMesh. Hugging Face hat Trainium-Unterstützung upstream in Transformers, Diffusers, TRL und die eigene Kernel-Bibliothek aufgenommen, sodass device_map="neuron" auch dort funktioniert. Das Paket heißt pip install torch-neuronx, der Code steht unter Apache 2.0 bei aws-neuron/torch-neuronx.

Die Lücken sind von Amazon dokumentiert, nicht von Kritikern entdeckt. Nicht unterstützt werden dynamische oder symbolische Formen, Sparse Tensors, Forward-Mode-Autograd und mehrere kleinere Funktionen. In einem Lauf der Upstream-Testsuiten von PyTorch im August 2026 verzeichnete Amazon etwa 154.000 Testergebnisse. Rund 69.000 wurden aus einem gültigen Grund übersprungen, etwa 39.000 waren bewusste Neuron-Skips; die größte Gruppe mit rund 22.000 waren Operatoren ohne native Neuron-Implementierung. TNW fasste dasselbe Material als rund 22.000 übersprungene PyTorch-Tests zusammen. Beides ist korrekt: Die eine Zahl zählt die ganze Suite, die andere nur die Skips, die auf fehlende Operator-Abdeckung hindeuten.

Eine Zeile Code und die Monate drumherum

Der Device-String ist die Demo, nicht die Migration. Googles Beitrag schreibt, eine einzeilige Änderung bringe ein Modell zum Laufen, und schiebt dann den Vorbehalt zur Spitzenleistung nach. Amazons Vorführung ließ dasselbe Trainingsskript auf Trainium und auf einem konventionellen Chip laufen und erklärte, das Modell habe „dieselben Dinge mit derselben Geschwindigkeit“ gelernt; Durchsatz, Kosten oder Konvergenzzahlen wurden nicht veröffentlicht.

Was sich geändert hat, ist die Richtung der Arbeit. Vor diesen Backends bedeutete eine Portierung auf TPU oder Trainium, sich an einen herstellerspezifischen Stack anzupassen, Kernel neu zu schreiben, Numerik erneut zu validieren und einen Fork gegen das Upstream-PyTorch zu pflegen. Jetzt ist der erste Versuch eine Konfigurationsänderung, und die restliche Arbeit ist Tuning. Das ist eine kleinere Rechnung in einer Zeit, in der Käufer auf Kosten achten. Amazon spricht von Ingenieurszeit. Google spricht von Wahlfreiheit zwischen TPUs, GPUs und CPUs unter einem Betriebsmodell.

Der Bericht von TechCrunch über das Paar brachte die strategische Lesart auf den Punkt: „Amazon und Google arbeiten offensichtlich daran, Nvidias Vorteil zu beenden.“ Derselbe Artikel ergänzte, dass nichts davon bedeutet, Entwickler würden Nvidias Hardware massenhaft verlassen. Ein Hersteller kann eine Hürde beseitigen, ohne den Kunden zu gewinnen.

Metas Beteiligung deutet auf Optionalität. Jana van Greunen, Director of PyTorch Engineering bei Meta, sagte, TorchTPU erlaube Meta, „unsere PyTorch-Workloads auf Google TPUs zu bringen, den Engineering-Teams direktes Feedback zu geben und die Flexibilität des Ökosystems aufzubauen, die alle brauchen“. Das beschreibt einen zweiten Weg in die Produktion, nicht einen Abschied von Nvidia. Meta hat das Backend mitentwickelt.

Die kommerziellen Einsätze sind groß genug, um die Koordination zu erklären. Amazon zufolge hat das Geschäft mit eigenen Chips eine jährliche Umsatzrate von 25 Milliarden Dollar überschritten, und CEO Andy Jassy sagte im April 2026, es könne 50 Milliarden Dollar wert sein (TNW). Google kündigte im April 2026 seine TPUs der achten Generation an, die 8t für Training und die 8i für Inferenz, und hat einen erweiterten Anthropic-Vertrag über mehrere Gigawatt TPU-Kapazität. Laut Yahoo Finance arbeitet das Unternehmen zudem daran, OpenAI zu beliefern. Jeder Workload, der ohne Umschreiben auf diesen Chips läuft, ist Kapazität, die die Cloud mit Silizium füllen kann, das sie kontrolliert.

Die Benchmarks sind Hersteller-Benchmarks

Googles Schlagzeilenzahl ist echt, aber eng. Google zufolge erreichte TorchTitan, der eigene Trainings-Referenzstack, bis zu 52 Prozent Model-FLOPs-Auslastung auf Qwen 3 8B, während er auf 8.192 Ironwood-TPUs skalierte, und der neue Eager-Modus DeferAndFuse kann 50 Prozent oder mehr schneller sein als strikte Eager-Ausführung. Beides sind Messungen von Google, auf Google-Hardware, mit der Softwarekonfiguration des Unternehmens. Sie belegen, dass der Softwarestack weniger Engpass ist als früher. Sie zeigen nicht, dass eine TPU für eine gegebene Aufgabe schneller oder billiger ist als eine GPU.

Amazons nützlichste Zahl kommt von einem Kunden, nicht aus einer Testsuite. Deepgram, Anbieter von Sprachmodellen, wird mit der Aussage zitiert, Trainium verarbeite „etwa 60 Prozent mehr Eingabe-Audiosekunden pro Dollar als unsere bestehenden GPU-Baselines“, nach einer mehrere Monate dauernden Portierung. Die Baseline ist Deepgrams eigene Flotte, kein benannter Nvidia-Teil, und die Kennzahl sind Audiosekunden pro Dollar bei einem Sprach-Workload. Das ist bedeutsam für alle, die Sprache ausliefern, und kein allgemeines Ergebnis.

Warum ein Backend CUDA nicht aufhebt

Ein Backend beseitigt eine Schicht der Wechselkosten. Die anderen beseitigt es nicht. CUDAs Vorteil ist nicht eine einzelne API, die PyTorch abstrahieren könnte. Es ist die angesammelte Menge an Bibliotheken, abgestimmten Kernels, Profilern, Debuggern und Antworten auf die Probleme anderer, die sich über mehr als ein Jahrzehnt um Nvidias Hardware gebildet hat. Ein Team mit einem eigenen Attention-Kernel, einem fusionierten Optimierer und einem Jahr Leistungsarbeit besitzt Werte, die ein Device-String nicht mit hinübernimmt.

Das Startmaterial räumt das stellenweise ein. Googles TorchTPU-Beitrag schreibt, die Standardimplementierung der Kollektive kompiliere jedes Kollektiv in ein separates Modul, was 30 bis 40 Prozent Ende-zu-Ende kosten könne, und dass begrenzte dynamische Formen noch gebaut werden; torch.compile erzwinge derzeit dynamic=False. Amazons erste TorchNeuron-Version lässt dynamische Formen und die anderen oben genannten Funktionen aus. Open Source heißt nicht fertig. TorchNeuron ist eine öffentliche Beta, und Googles Dokumentation beschreibt eine Reife, die je nach Funktion variiert.

PyTorch selbst ist heute neutraler Boden. Meta schrieb das Framework 2016 und übertrug es 2022 an die Linux Foundation, sodass ein Google- oder Amazon-Backend als Ökosystemarbeit ankommen kann statt als proprietärer Umweg. Die Konferenz der Stiftung ist der Ort, an dem beide Veröffentlichungen landeten. Diese Vereinbarung gibt den Herstellern einen Grund, die gemeinsame Schicht zu verbessern: Ein Fix, der in PyTorch landet, hilft ihrer Hardware, ohne dass Entwickler einen Herstellerstack übernehmen müssen.

Die folgenreichere Arbeit steckt womöglich in den Pull Requests. Amazon zufolge reicht das Unternehmen Änderungen am Hauptzweig von PyTorch ein, um fest verdrahtete CUDA-Annahmen zu entfernen, und der TorchNeuron-Beitrag listet sie auf. Google steuerte LiteRT zum PyTorch-Ökosystem bei und arbeitete über Hugging Face, vLLM und SGLang statt an ihnen vorbei. Diese Änderungen würden die nächste Portierung billiger machen.

Was als Beleg gelten würde

Ein unabhängiger Benchmark würde mehr klären als beide Startbeiträge. Der Test ist leicht zu beschreiben: dasselbe Modell, dieselben Batch-Größen und dieselbe Präzision, gemessen auf einer TPU, einer Trainium-Instanz und einer Nvidia-GPU, mit Kosten pro Token. Ein benannter Kunde, der eine abgeschlossene Migration und die Rechnung davor und danach beschreibt, hätte ähnliches Gewicht. Dasselbe gälte für zusammengeführten Upstream-Code: Operator-Abdeckung und geräteagnostische Änderungen, die in PyTorch angenommen werden, statt in einem Hersteller-Repository zu liegen.

Einschränkungen

Die beiden Veröffentlichungen sind Softwareankündigungen, keine Leistungsergebnisse. Keines der Unternehmen hat unabhängige, vergleichbare Leistungszahlen für einen der Stacks auf einem gemeinsamen Modell gegen Nvidia-Hardware veröffentlicht. TorchNeuron ist eine öffentliche Beta mit dokumentierten Funktionslücken, und TorchTPUs Dokumentation beschreibt unterschiedliche Reife, einen genannten Aufschlag auf dem Standardpfad für Kollektive und unfertige Arbeit an dynamischen Formen. Die „85 Prozent“, die in der Berichterstattung auftauchen, sind nicht eine Zahl: Amazon zufolge schreiben 85 Prozent der KI-Forscher und -Entwickler in PyTorch, während TechCrunch schreibt, PyTorch werde „nach einigen Angaben“ von 85 Prozent der KI-Apps genutzt. Beides ist zugeschrieben, und beide messen unterschiedliche Populationen. Die Migration wird zudem schrittweise verlaufen: Ein Backend senkt die Kosten, einen zweiten Lieferanten zu versuchen, und die Beschaffung läuft weiterhin über gemessene Kosten pro Token und über Liefertermine.

Beide Backends lassen sich jetzt herunterladen. Der Benchmark, der klären würde, was die Portierung wert ist, ist noch nicht veröffentlicht.

Titelbild: „Google Data Center, Council Bluffs Iowa“ von Chad Davis, CC BY 2.0, über Wikimedia Commons.