TPU vs. GPU: Für wen sich welche Variante lohnt

Bei der Entscheidung zwischen GPUs und TPUs für KI-Anwendungen spielt neben den Preisen und den Leistungen vor allem die verwendete Software eine Rolle.

Wer ein eigenes Sprachmodell trainiert, Open-Source-Modelle anpasst oder Inferenz im großen Stil fährt, hat die Wahl zwischen NVIDIA GPUs und Google TPUs. Die reine Rechenleistung greift als Entscheidungskriterium zu kurz. Ausschlaggebend sind vier andere Punkte: die Architektur Ihrer Modelle, das Framework-Wissen im Team, die geplante Laufzeit der Last und die Frage, ob Sie sich an einen einzigen Cloud-Anbieter binden dürfen (und wollen).

Kurz gefasst sieht das Bild so aus: GPUs laufen fast überall, sind bei der Modellarchitektur flexibel und benötigen weniger Vorarbeit. TPUs liefern deutlich mehr Token fürs Geld, verlangen dafür einen anderen Software-Stack und einige Wochen Umbauzeit. Ab welchem Betriebsvolumen sich dieser Umbau auszahlt, lässt sich berechnen.

Zwei Bauweisen mit unterschiedlichen Stärken

NVIDIAs GPUs stammen aus der Grafikverarbeitung und sind frei programmierbar. Tausende Rechenkerne, die Streaming Multiprocessors, arbeiten parallel; spezialisierte Tensor Cores übernehmen Matrixrechnungen mit gemischter Genauigkeit. Die Blackwell-GPU B200 bringt native FP4-Tensor-Cores für höheren Inferenz-Durchsatz und eine eigene Hardware-Einheit zum Entpacken von Daten, die Engpässe beim Laden auflöst. Diese Vielseitigkeit kostet Chipfläche für Steuerlogik und Caches, die reine Matrixarbeit aber gar nicht braucht.

Abbildung: Funktionsweise von GPUs. Bild: Google

TPUs sind Spezialchips (ASICs). Ihr Kern ist das systolische Array in den Matrix Multiply Units. Daten fließen wellenartig durch ein zweidimensionales Gitter von Rechenknoten; das Ergebnis einer Zelle geht direkt als Eingabe in die Nachbarzelle. Teure Speicherzugriffe fallen dabei weitgehend weg, der Stromverbrauch sinkt, der Durchsatz bei dichten Matrixoperationen steigt. Ein TensorCore der TPU v4 besteht aus vier 128×128-MXUs und einer Vector Processing Unit mit 128 Lanes, die sich 128 MiB gemeinsamen Speicher teilen.

Hinzu kommen die SparseCores auf TPUs. Sie belegen rund fünf Prozent der Chipfläche und der Leistungsaufnahme, beschleunigen Modelle mit vielen Embeddings aber um den Faktor fünf bis sieben. Das betrifft vor allem Empfehlungsmodelle (DLRMs), wie sie für Werbeausspielung und Suchranking gebraucht werden. Liegen diese Embeddings stattdessen im CPU-Speicher, bricht die Leistung wegen der geringen Speicherbandbreite ein.

Abbildung: Funktionsweise von TPUs. Bild: Google

Für die Praxis folgt daraus: TPUs sind stark, wenn der Datenfluss vorab planbar ist. Bei Mixture-of-Experts-Modellen, die für jedes Token datenabhängig entscheiden, an welches Experten-Netzwerk sie weiterleiten, arbeiten NVIDIAs programmierbare Streaming Multiprocessors sauberer.

Die folgende Übersicht fasst die aktuell wichtigsten Beschleuniger zusammen.

Tabelle 1: Übersicht der wichtigsten GPUs und TPUs für den KI-Einsatz.Angaben aus Hersteller-Whitepapern, Hardware-Registern und wissenschaftlichen Publikationen.

Bei den reinen Leistungskriterien pro Chip liegen die GPUs vorn, sowohl beim Speicher als auch bei der Rechenleistung. Ein einzelner B200 hält ein Modell mit über 100 Milliarden Parametern in FP16 komplett im lokalen Speicher. Bei der TPU v6e mit 32 GB muss dasselbe Modell über mehrere Chips verteilt werden, was Latenz durch Chip-zu-Chip-Kommunikation erzeugt. Google zielt mit dem TPU-Design ohnehin auf etwas anderes: viele kleinere Chips, sehr verlustarm zu einem Pod verdrahtet.

Die Unterschiede zwischen GPUs und TPUs fasst die folgende Grafik zusammen:

Abbildung: Unterschiede zwischen GPUs und TPUs. Gepromptet von hardwarewartung.com. KI-generiert per GPT-Images 2.0.

Netzwerk: erst ab tausenden Chips ein Thema

Innerhalb eines Racks verbindet NVIDIA seine GPUs über NVLink und NVSwitch, im NVL72-System mit bis zu 1,8 TB/s bidirektional. Über Rack-Grenzen hinweg kommen klassische Paketnetze zum Einsatz, InfiniBand oder Ethernet in Clos- oder Fat-Tree-Topologien. Hier wachsen die Kosten überproportional mit der Clustergröße, weil unzählige optische Transceiver und tiefe Switch-Hierarchien nötig werden. Dazu kommt der Fehler-Radius (Fault Explosion Radius): Fällt in einem streng partitionierten Tensor-Parallelism-Ring eine einzelne GPU aus, stehen Dutzende intakter GPUs still, weil die Symmetrie des Rings gebrochen ist.

Google verdrahtet seine TPU-Chips physisch in einer 3D-Torus-Topologie und schaltet ab der v4-Generation Optical Circuit Switches dazwischen. Winzige MEMS-Spiegel lenken Lichtstrahlen direkt von einer Glasfaser in die nächste, auf der physikalischen Schicht, ohne den Umweg über eine elektrische Umwandlung. Drei Effekte sind für Betreiber interessant:

• Die optische Infrastruktur schlägt mit weniger als fünf Prozent der Systemkosten und unter drei Prozent des Energieverbrauchs zu Buche.
• Fällt ein Knoten aus, legen die Spiegel das Netz innerhalb von Millisekunden um den defekten Knoten herum. Ein Trainingslauf über Wochen läuft weiter, ohne ihn neu aufzusetzen zu müssen.
• Die Topologie skaliert gut: Vom TPU-v2-Supercomputer mit 256 Knoten ging es auf 9.216 Knoten beim Ironwood-System (v7), bei 39-fach höherer Bisektionsbandbreite.

Das ist allerdings nur dann von Bedeutung, wenn Sie Zehntausende Chips über Monate synchron laufen lassen, also beim Pre-Training eigener Foundation-Modelle.

Der Software-Stack entscheidet häufiger als die Hardware

Am Software-Stack scheitern Projekte deutlich öfter als an der Rechenleistung. PyTorch ist der Standard in Forschung und Industrie. Der Code läuft Zeile für Zeile, und das Debugging funktioniert mit normalen Python-Werkzeugen. Zwischenwerte lassen sich jederzeit ausgeben. Weil das CUDA-Ökosystem von Nvidia seit Jahren darauf abgestimmt wird, erscheinen hardwarenahe Kernel wie FlashAttention-3 oder über OpenAI Triton erzeugte Custom-Kernel dort Wochen bis Monate früher als auf anderen Plattformen. Etwa 95 Prozent der auf Hugging Face veröffentlichten Modelle sind PyTorch-nativ und laufen auf einer NVIDIA-GPU ohne Anpassung.

JAX geht den umgekehrten Weg. Berechnungen sind reine Funktionen ohne Seiteneffekte; der XLA-Compiler übersetzt den gesamten Berechnungsgraphen zur Laufzeit, fusioniert Speicheroperationen und erzeugt statischen Maschinencode für die TPU. Mit vmap und pmap verteilt sich Code fast ohne Umbau von einem Chip auf tausende Knoten. In Transformer-Benchmarks verarbeitete ein Colab-Setup mit TPU v3 über 2.500 Beispiele pro Sekunde, während vergleichbare PyTorch-Läufe an Speichergrenzen stießen.

Der Preis dafür: JAX verlangt zustandsloses Programmieren, und Tensoren brauchen statische Formen. Bei variablen Batch-Größen oder datenabhängigem Kontrollfluss kompiliert XLA während der Laufzeit ständig neu, was die Leistung zerstört. Speculative Decoding nach Art von EAGLE3 scheiterte über PyTorch/XLA in der Praxis regelmäßig an Speicherbeschädigungen und genau diesen Rekompilierungsstürmen. Auf GPUs läuft dieselbe Technik heute stabil.

Inferenz: getrennte Welten

Auf GPUs haben sich vLLM, TensorRT-LLM und Text-Generation-Inference durchgesetzt. vLLM brachte mit PagedAttention die Fragmentierung des KV-Caches unter Kontrolle; dazu kommen Continuous In-Flight Batching und Quantisierungsverfahren wie AWQ, GPTQ und bitsandbytes, die derzeit ausschließlich auf CUDA laufen.

Auf TPUs übernimmt JetStream diese Rolle. Es beherrscht ebenfalls Continuous Batching sowie INT8-Quantisierung für Gewichte, Aktivierungen und KV-Cache. Gegenüber dem älteren Saxml-Stack verdreifachte JetStream die Zahl der Token pro Dollar beim Ausliefern von Gemma-Modellen. Für die TPU v6e nennt Google eine Time to First Token von 5 bis 20 Millisekunden bei Modellen der 7-Milliarden-Klasse, gleichauf mit B200-GPUs unter vLLM. Saxml wurde zum 24. April 2025 abgekündigt; wer es noch einsetzt, sollte den Wechsel einplanen.

Praktisch heißt das: Beim Umzug von GPU auf TPU müssen Modellcode, Serving-Engine, API-Endpunkte und Monitoring mitwandern.

Preise und ein Rechenbeispiel

TPUs gibt es ausschließlich zur Miete in der Google Cloud. Das bindet Sie auf Infrastrukturebene an einen Anbieter, erlaubt Google aber sehr aggressive Preise. GPUs bekommen Sie bei mehreren Hyperscalern, bei Spezialanbietern wie Lambda (H100 ab etwa 1,49 bis 3,00 USD pro Stunde und Chip) und im eigenen Rechenzentrum. Die folgenden Listenpreise der Google Cloud zeigen die Größenordnung; je nach Region weichen sie ab.

Tabelle 2:  Preise für gemietete GPUs und TPUs (Auswahl). GCP-Listenpreise, GPU-Angaben je 8er-Instanz, TPU-Angaben je Einzelchip. Quellen: TPU-Preisliste, Preise für beschleunigte VMs und Dynamic Workload Scheduler.

Drei Preismodelle stehen zur Wahl: On-Demand, Committed Use Discounts über ein oder drei Jahre und die Flex-start-Preise des Dynamic Workload Scheduler für zeitlich flexible Batch-Jobs.

Was das über ein Jahr bedeutet, zeigt eine einfache Rechnung für acht Chips im Dauerbetrieb (8.760 Stunden):

• 8x H100 zum On-Demand-Preis: rund 775.000 USD. Mit 3-Jahres-CUD sinkt der Betrag auf etwa 340.000 USD.
• 8x TPU v5e zum On-Demand-Preis (8 × 1,20 USD): rund 84.000 USD. Mit 3-Jahres-CUD etwa 38.000 USD.

Der Durchsatz relativiert diese Spanne. Eine 8xH100-Instanz erzeugt bei Llama2-70B über 4.000 Token pro Sekunde, acht TPU v5e kommen auf rund 2.175 Token pro Sekunde. Pro Token bleibt damit ein Kostenvorteil von etwa Faktor fünf auf Seiten der TPU. Berichte aus großskaligem LLM-Training nennen Spannen von Faktor vier bis zehn.

Dem gegenüber steht der Umbau. Die Migration einer Inferenz-Pipeline umfasst die Portierung der Modelle nach MaxText/JAX, das Neuschreiben eigener CUDA-Kernel in XLA über JAX Pallas, die Umstellung der API-Endpunkte (JetStream spricht andere Schnittstellen als die OpenAI-kompatible API von vLLM) und den Neuaufbau der Observability-Dashboards. Erfahrene Teams veranschlagen dafür etwa drei bis fünf Wochen reine Engineering-Zeit. Wer seine Modelle über High-Level-APIs wie Keras 3.0 anspricht, kommt schneller durch, weil die Abstraktion die Hardware verdeckt.

Rechnen Sie also gegen: einmalig drei bis fünf Personenwochen gegen jährlich sechsstellige Einsparungen bei dauerhafter Last. Bei sporadischen Experimenten oder wechselnden Modellen sieht die Rechnung entsprechend anders aus.

Strom und CO₂

TPUs liegen historisch beim Verhältnis von Leistung zu Watt zwei- bis dreimal besser als vergleichbare GPUs. Google misst das über die Compute Carbon Intensity (CCI), also die CO₂-Äquivalente je Fließkommaoperation. Die Metrik zählt den kompletten Lebenszyklus mit, von der Rohstoffgewinnung über die Chipfertigung bis zum Rechenzentrumsbau, also auch Scope-3-Emissionen. Von der TPU v4i zur v6e verbesserte sich die CCI um den Faktor drei, beim Ironwood-Chip gegenüber der v5p um den Faktor 3,7.

GPUs stehen pro FLOP ebenfalls gut da: Die H100 erreicht bis zu 1,4 TFLOPS pro Watt. Die absoluten Zahlen sind allerdings hoch: Ein B200-Chip zieht 1.000 bis 1.200 Watt und verlangt Flüssigkeitskühlung auf Rack-Ebene mit entsprechenden Anforderungen an das Rechenzentrum. Für Unternehmen mit verbindlichen CO₂-Zielen und prüffähigem ESG-Reporting sind TPUs deshalb die einfachere Wahl, weil sich die Lebenszyklus-Emissionen sauber nachweisen lassen.

GPU oder TPU? 7 Fragen führen zur Entscheidung

1. Dürfen Sie sich an die Google Cloud binden? TPUs gibt es nirgendwo sonst und auch nicht für den eigenen Serverraum. Wer eine Multi-Cloud-Strategie fährt oder aus Compliance-Gründen on-premise betreiben muss, landet automatisch bei GPUs.
2. Wie sehen Ihre Modelle aus? Dichte Transformer passen gut auf TPUs. Mixture-of-Experts-Modelle wie Mixtral oder DeepSeek V4 mit ihrem token-abhängigen Routing laufen auf GPUs mit Expert Parallelism deutlich runder.
3. Was kann Ihr Team? Ein reines PyTorch-Team ohne JAX-Erfahrung braucht Einarbeitungszeit. Das sollten Sie einrechnen, wenn Sie den Einsatz von TPUs erwägen.
4. Gibt es Dauerbetrieb im Steady State über einen längeren Zeitraum? Das kann eine Umstellung auf TPUs rechtfertigen. Wechselnde Experimente und kurze Läufe sprechen dagegen eher für GPUs.
5. Welche Workloads laufen neben LLMs? Computer Vision, 3D-Rendering, Robotik-Simulationen und wissenschaftliches Rechnen sind GPU-Terrain, weil TensorRT und cuDNN dort den Standard setzen.
6. Wie groß ist ein einzelnes Modell? Passt es in 192 GB, kommen Sie mit einer B200 aus. Auf TPUs verteilen Sie dasselbe Modell über viele Chips, mit entsprechendem Kommunikationsaufwand.
7. Gibt es CO₂-Vorgaben? Wenn Ihr ESG-Reporting Scope-3-Emissionen der IT ausweisen muss, liefert die CCI-Metrik der TPUs belastbare Zahlen.

Wann GPUs die pragmatische Wahl sind

Bei schnellem Prototyping und kurzer Time-to-Market, beim Feintuning bestehender Open-Source-Modelle per LoRA, bei MoE-Architekturen, bei Bildverarbeitung und HPC sowie überall dort, wo eine Anbieterbindung ausgeschlossen ist, sind GPUs die erste Wahl.

Wann sich TPUs auszahlen

Beim Pre-Training eigener Foundation-Modelle über zehntausende Chips, bei dem die optische Vernetzung Ausfälle abfangen soll, sind TPUs zu bevorzugen. Das gilt auch bei kostenoptimierter Inferenz im großen Volumen, etwa hunderten Millionen API-Anfragen täglich oder schwerer Batch-Verarbeitung. Es profitieren auch Teams, die bereits funktional programmieren und im Google-Ökosystem verankert sind. Für TPUs sprechen außerdem Aspekte der Green-IT und der Bedarf an auditierbaren Zahlen.

Die Alternative

AWS bietet mit Trainium und Inferentia eigene Beschleuniger an. Trainium bringt 96 GB HBM2e pro Chip und trainiert laut AWS-eigenen Benchmarks für etwa die Hälfte der Kosten eines vergleichbaren A100-Jobs. Der Software-Aufwand über das Neuron-SDK ähnelt dem TPU-Weg. Wer ohnehin auf AWS sitzt, sollte diese Variante mitprüfen, bevor er über einen Cloud-Wechsel nachdenkt.

FAQs: Häufige Fragen zur Entscheidung zwischen GPUs und TPUs

Sind TPUs für Inferenz wirklich günstiger?

Pro erzeugtem Token in aller Regel ja, und das mit deutlichem Abstand. Eine TPU v5e kostet On-Demand rund 1,20 USD pro Stunde, eine H100 liegt bei den großen Anbietern oft über 12,00 USD pro Stunde und Chip. Die H100 liefert pro Chip mehr Durchsatz, der Preisunterschied gleicht das aber mehr als aus. Mit JetStream erreicht die v5e in Inferenz-Szenarien häufig die dreifache Leistung je investiertem Dollar.

Laufen vLLM oder TensorRT-LLM auf einer TPU?

Nicht in nativer, schneller Form. vLLM, TensorRT-LLM und SGLang stecken tief in CUDA; PagedAttention und FlashAttention-3 sind hochspezialisierte CUDA-Kernel. Für TPUs müssen Sie auf JetStream wechseln, das vergleichbare Funktionen mitbringt. Der Wechsel bedeutet den kompletten Austausch der Inferenz-Engine.

Worin unterscheiden sich TPU v5e und v5p?

Das „e“ steht für Efficiency: 16 GB Speicher, 197 TFLOPS, sehr niedriger Preis, gedacht für Inferenz und das Training mittelgroßer Modelle. Das „p“ steht für Performance: 95 GB HBM, 459 TFLOPS, höherer Mietpreis und höherer Verbrauch, ausgelegt auf das Pre-Training großer Foundation-Modelle.

Unser Team arbeitet nur mit PyTorch. Kommen TPUs trotzdem in Frage?

Ja, über PyTorch/XLA. Der Code muss vom XLA-Compiler übersetzt und in statische Berechnungsgraphen gebracht werden. Bei dynamischen Datenstrukturen kompiliert XLA während der Laufzeit ständig neu, was die Leistung deutlich senkt. Planen Sie also eine bewusste Überarbeitung ein, insbesondere den Verzicht auf dynamische Shapes.

Warum passen MoE-Modelle besser auf GPUs?

Mixture of Experts Modelle (MoE) leiten Tokens datenabhängig an unterschiedliche Experten-Netzwerke weiter. Dieses verzweigte Routing bricht den gleichmäßigen Datenfluss im systolischen Array; Teile des Arrays laufen leer. NVIDIAs programmierbare Streaming Multiprocessors verarbeiten solche unregelmäßigen Muster mit weniger Verlust als TPUs.

Was bringt Optical Circuit Switching konkret?

Zwei Dinge. Erstens spart die optische Vermittlung Strom, weil die Signalumwandlung entfällt; die gesamte optische Ebene liegt unter drei Prozent des Systemverbrauchs. Zweitens und wichtiger im Betrieb: Fällt ein TPU-Knoten aus, lenken die MEMS-Spiegel das Netz in Millisekunden um ihn herum, und ein wochenlanger Trainingslauf läuft weiter.

Haben GPUs einen Speichervorteil?

Einen deutlichen. Eine H100 bietet 80 GB HBM3, eine B200 bis zu 192 GB HBM3e bei 8 TB/s Bandbreite. Die TPU v6e kommt auf 32 GB pro Chip. Große Modelle müssen auf TPUs über mehr Chips verteilt werden. Wenn Sie ein sehr großes Modell auf wenigen Knoten ausliefern wollen, hat NVIDIA den besseren Formfaktor.

Wie lange dauert eine Migration von CUDA auf JAX/JetStream?

Für eine komplexe Inferenz-Pipeline etwa drei bis fünf Wochen mit einem eingespielten Team. Eigene CUDA-Kernel in C++ haben auf der TPU keine Entsprechung und müssen in XLA neu geschrieben werden, etwa über JAX Pallas. Dazu kommen Client-API-Endpunkte und Monitoring-Dashboards. Wer über Keras 3.0 arbeitet, kommt spürbar schneller durch.

Wie fügen sich TPUs in eine bestehende Kubernetes-Umgebung?

Google hat TPUs tief in die Google Kubernetes Engine eingebunden. Über dedizierte TPU Node Pools provisionieren Sie sie wie CPU- oder GPU-Ressourcen, auch in vernetzten Slice-Topologien wie 4×8. Für die Inferenz stehen vorkonfigurierte JetStream-Container bereit. Load-Balancing, Auto-Scaling und Orchestrierung greifen wie gewohnt.

Wofür brauchen wir die Compute Carbon Intensity im Reporting?

Die CCI beziffert die CO₂-Äquivalente je Fließkommaoperation und zählt dabei die graue Energie aus Chipfertigung und Rechenzentrumsbau mit, also Scope 3. Damit lassen sich Einsparungen im KI-Betrieb prüffähig belegen.

Unterstützen TPUs Speculative Decoding?

Theoretisch ja, praktisch bislang mit Reibung. Das Verfahren erzeugt Entwurfstoken und validiert sie. Das ist stark datenabhängig und läuft den statischen Formvorgaben von XLA zuwider. Versuche über PyTorch/XLA endeten oft in Speicherbeschädigungen und Rekompilierungsstürmen. Auf CUDA-Systemen, etwa mit SGLang, funktioniert das heute zuverlässig.

Fazit für die Praxis

Der Preisunterschied pro Token spricht bei großen, gleichmäßigen Lasten klar für TPUs. Er wird aber erst dann zum Argument, wenn Ihre Modelle dichte Matrixarbeit leisten, Ihr Team den JAX-Weg mitgeht und Sie die Bindung an die Google Cloud akzeptieren können. Fehlt eine dieser Bedingungen, holen Sie den theoretischen Vorteil im Betrieb selten ein. GPUs bleiben die Wahl, wenn Sie schnell liefern müssen, mit wechselnden Modellen arbeiten oder Hardware im eigenen Haus betreiben.

Ein pragmatischer Zwischenweg besteht darin, Training und Inferenz getrennt zu betrachten. Viele Unternehmen entwickeln und feintunen auf GPUs und verlagern anschließend genau die Modelle auf TPUs, die dauerhaft hohe Anfragevolumen bedienen. Für diesen Schritt reicht ein überschaubares Zeitfenster, und er lässt sich an einem einzelnen Dienst erproben, bevor Sie die gesamte Plattform anfassen.