Google Tensor Processing Unit: Dein Guide für 2026

Du sitzt wahrscheinlich gerade in genau so einer Diskussion: Das Data-Team will mehr Rechenleistung für ein neues Modell. Das Produktteam will wissen, warum Experimente so lange dauern. Finance fragt, warum die Cloud-Rechnung steigt. Und irgendwo im Raum fällt der Satz: „Brauchen wir vielleicht TPUs statt GPUs?“

Genau an dem Punkt lohnt es sich, die google tensor processing unit nüchtern anzuschauen. Nicht als Marketingbegriff, sondern als Infrastrukturentscheidung.

Ich erklär dir das so, wie ich es einem Produktmanager im MLOps-Alltag erklären würde. Nicht chip-romantisch, sondern praktisch. Was ist eine TPU? Wofür ist sie stark? Wo ist sie die falsche Wahl? Und woran erkennst du, ob dein Projekt in der DACH-Realität wirklich davon profitiert?

Wenn GPUs an ihre Grenzen stoßen

Ein typisches Muster in Teams sieht so aus: Das erste Modell läuft auf einer GPU sauber. Dann wächst der Anspruch. Mehr Daten, größere Modelle, häufigere Retrainings, mehr A/B-Tests, zusätzlich Inferenz in Produktion.

Plötzlich kippt die Lage.

Die Trainingsläufe dauern zu lang. Die Queue auf den Instanzen wird voller. Jeder neue Versuch blockiert Ressourcen, die eigentlich schon für andere Teams eingeplant sind. Für das Produkt fühlt sich das wie eine simple Frage an. „Können wir die Qualität noch verbessern?“ Für das Platform-Team ist es eine Kapazitätsfrage.

Woran du die Grenze erkennst

Du brauchst nicht sofort eine TPU, nur weil ein Training langsam ist. Erstmal musst du unterscheiden, wo dein Engpass sitzt.

• Compute-Engpass: Dein Modell rechnet lange an dichten Matrix-Operationen. Genau da werden spezialisierte Beschleuniger interessant.
• Daten-Engpass: Deine Pipeline liefert Daten zu langsam nach. Dann hilft dir neue Hardware deutlich weniger.
• Experiment-Engpass: Zu viele Varianten, zu wenig Priorisierung. Das ist ein Produktproblem, kein Hardwareproblem.
• Produktions-Engpass: Das Training läuft noch okay, aber die Inferenzkosten steigen mit jeder neuen Nutzung.

Viele Teams schauen zu früh nur auf den Chip. In Wahrheit musst du zuerst den Workflow anschauen.

Wenn dein Modell auf Input wartet, kauft dir neue Rechenleistung vor allem eins ein: teurere Leerlaufzeit.

In der Praxis beobachte ich oft noch etwas Zweites: Teams vergleichen nur Hersteller und Modellnamen. NVIDIA hier, Google dort, neuer Chip da. Das ist selten die richtige Ebene. Wer die Infrastrukturdebatte nur als Beschaffungsfrage führt, landet schnell in einer Endlosdiskussion wie in den aktuellen Nachrichten rund um KI-Chips und Serverkapazitäten, etwa in diesem Bericht zu Hochschulen und NVIDIA-Systemen: https://www.kiweekly.de/news/reuters-chinesische-hochschulen-beschafften-trotz-us-kontrollen-server-mit-nvidia-ki-chips

Die eigentliche Frage

Die relevante Frage ist nicht „Ist eine TPU schneller?“ Sondern:

Ist dein Workload so beschaffen, dass die Spezialisierung einer TPU wirtschaftlich Sinn ergibt?

Wenn du diese Frage sauber stellst, wird die Entscheidung viel einfacher. Und oft auch unromantischer.

Was ist eine Google Tensor Processing Unit?

Eine Google Tensor Processing Unit, kurz TPU, ist ein speziell entwickelter Chip für maschinelles Lernen. Technisch ist das ein ASIC, also ein anwendungsspezifischer integrierter Schaltkreis. Auf Deutsch: kein Allzweckprozessor, sondern Spezialhardware.

Der Kernpunkt ist einfach. TPUs sind dafür gebaut, Matrix-Multiplikationen sehr effizient auszuführen. Genau diese Rechenart steckt im Zentrum fast aller modernen neuronalen Netze.

Die einfachste Analogie

Ich nutze dafür gern dieses Bild:

Das ist der wichtigste Denkrahmen. Eine TPU ist nicht „einfach die bessere GPU“. Sie ist enger spezialisiert.

Was ist eigentlich ein Tensor

Der Begriff klingt komplizierter, als er im Alltag sein muss.

Für die Produktentscheidung reicht dieses Verständnis: Ein Tensor ist im ML-Kontext einfach eine strukturierte Ansammlung von Zahlen. Das kann ein Vektor sein, eine Matrix oder ein mehrdimensionales Zahlenfeld. Bilder, Tokens, Embeddings, Gewichte. Am Ende werden daraus numerische Strukturen, auf denen das Modell rechnet.

Und diese Rechnerei ist sehr oft: Zahlenblöcke mit anderen Zahlenblöcken multiplizieren.

Warum TPUs dafür so gut sind

Google führte die TPU 2015 intern ein. Die erste Generation, TPU v1, lieferte laut der verlinkten Übersicht 92 Billionen 8-Bit-Operationen pro Sekunde bei 40 Watt. Sie übertraf zeitgenössische CPUs und GPUs um den Faktor 15 bis 30 in der Geschwindigkeit und 30 bis 80 in der Energieeffizienz pro Watt. Mehr dazu in der Übersicht zur Tensor Processing Unit bei Wikipedia.

Das ist beeindruckend. Aber wichtig ist der Kontext: Diese Stärke gilt dort, wo die Architektur passt. Nicht bei beliebigen Rechenaufgaben.

Warum Produktteams hier oft falsch abbiegen

Viele hören „15 bis 30 mal schneller“ und denken sofort: Dann migrieren wir alles.

Das wäre ein Fehler.

TPUs sind stark, weil sie vieles weglassen, was allgemeine Hardware flexibel macht. Sie sind nicht dafür da, Grafiken zu rendern, allgemeine Business-Software auszuführen oder beliebige Mischworkloads elegant zu bedienen. Diese Einschränkung ist kein Nachteil am Rand. Sie ist der Kern des Designs.

Eine TPU gewinnt nicht, weil sie alles besser kann. Sie gewinnt, weil sie weniger können muss.

Google nutzte frühe TPUs unter anderem für Search, Photos, Translate und YouTube. Auch beim Sieg von AlphaGo gegen Lee Sedol im März 2016 spielten TPUs eine entscheidende Rolle. Das zeigt gut, worum es geht: hochvolumige, rechenintensive ML-Aufgaben, bei denen Spezialisierung zählt.

Die TPU-Architektur und ihre Generationen

Nicht jede TPU ist für denselben Zweck gedacht. Wenn du „TPU“ sagst, musst du eigentlich sofort nachfragen: Welche Generation und für welchen Job?

Ein Produktteam braucht selten die tiefste Chip-Physik. Aber du solltest verstehen, wie sich die Familien unterscheiden. Sonst vergleichst du Training, Inferenz und Skalierung wild durcheinander.

Von der ersten Spezialisierung zur grossen Skalierung

Die erste TPU war vor allem ein Beweis: Spezialhardware für ML kann in echten Produkten besser funktionieren als allgemeine Hardware.

Danach verschob sich der Fokus. Spätere Generationen wurden nicht nur für Inferenz, sondern auch für Training und für grosse verteilte Systeme gebaut. Damit kamen zwei Themen ins Spiel, die für Unternehmen relevant sind:

• Wie stark ist ein einzelner Chip
• Wie gut skaliert ein Verbund vieler Chips

TPU v3 und v4 im praktischen Blick

TPU v3 war ein wichtiger Schritt für grosse Trainingsjobs. In den verifizierten Daten wird sie als Generation beschrieben, die die Leistung auf 420 TOPS pro Chip anhob und mit Flüssigkühlung sowie Pods von 1.024 Chips arbeitete, die auf über 100 Petaflops kamen. Das machte grosse Modelle deutlich realistischer.

Für viele Teams ist TPU v4 die Generation, bei der die Architektur als Plattform greifbar wird. Laut der technischen Google-Cloud-Dokumentation erreicht jeder TPU-v4-Chip 275 TFLOPS, und ein Pod mit 4096 Chips skaliert auf 1,1 Exaflops. Die Details findest du in der Google-Cloud-Dokumentation zu TPU v4.

Wichtig daran ist nicht nur die nackte Zahl. Wichtig ist, dass v4 für verteiltes Training in grossem Massstab gebaut wurde.

Warum Pods für dich als Entscheider wichtig sind

Ein einzelner Chip ist noch keine Strategie. Für grosse Modelle zählt, wie gut viele Chips zusammenarbeiten.

Wenn du ein Team mit ambitionierten Trainingsjobs führst, musst du auf diese Fragen schauen:

• Kommunikation zwischen Chips: Schnelles Rechnen allein bringt wenig, wenn die Knoten dauernd aufeinander warten.
• Skalierung: Wird dein Training wirklich schneller, wenn du mehr Hardware dazuschaltest?
• Betriebsmodell: Kann dein Team diese Infrastruktur im Alltag sauber nutzen?

Googles Pod-Konzept adressiert genau das. Das ist einer der Gründe, warum TPUs in grossen Trainingsumgebungen so relevant wurden.

Für kleine Experimente ist Peak-Compute oft zweitrangig. Für grosse Trainingsjobs ist gute Skalierung oft der eigentliche Unterschied.

Ein praktischer Marktindikator dafür ist, dass grosse KI-Anbieter aktiv TPU-Kapazität sichern. Das sieht man auch in dieser Meldung zu zusätzlicher TPU-Rechenleistung für Anthropic: https://www.kiweekly.de/news/anthropic-sichert-sich-zusaetzliche-tpu-rechenleistung-von-google-und-broadcom

TPU v5e und Trillium im Unternehmenskontext

Für viele Unternehmen ist nicht das grösste Trainingssystem der spannendste Punkt, sondern die Frage: Was bringt mir das in Produktion?

Hier wird TPU v5e relevant. Diese Variante ist in den verifizierten Daten klar als kosteneffiziente Inferenz-Lösung positioniert. Sie ist also nicht nur „noch eine neuere TPU“, sondern eine andere wirtschaftliche Antwort auf produktive Workloads.

Dazu kommt mit Trillium eine noch neuere Generation, die laut den verifizierten Daten im November 2024 lanciert wurde und auf LLM-Workloads optimiert ist. Für Produktteams heisst das vor allem: Google differenziert die TPU-Familie inzwischen stärker nach realen Einsatzmustern.

Cloud TPU und Edge TPU nicht vermischen

Ein häufiger Denkfehler ist, alles unter „TPU“ zusammenzufassen.

Für Entscheidungsrunden hilft diese Trennung:

Für die meisten Unternehmensfragen im DACH-Kontext geht es um Cloud TPUs. Also um die Frage, ob du in der Google Cloud bestimmte ML-Workloads besser auf TPU statt GPU fährst.

Dein erster Workflow mit TPUs in der Google Cloud

Die gute Nachricht zuerst: Der operative Einstieg ist oft weniger dramatisch, als viele erwarten. Du brauchst kein Halbleiterwissen. Du brauchst eine klare Umgebung, ein unterstütztes Framework und einen Workload, der zur TPU passt.

Was du vor dem Start klären solltest

Bevor du irgendetwas provisionierst, prüf drei Dinge:

1. Framework
   Nutzt dein Team TensorFlow oder JAX? Dann ist der Einstieg in der Regel geradliniger. Bei PyTorch musst du genauer hinschauen, wie euer Stack aufgebaut ist.
2. Modelltyp
   Dein Modell sollte stark von den Rechenmustern profitieren, für die TPUs gebaut wurden. Dichte Matrix-Operationen sind ein gutes Zeichen. Stark irreguläre Abläufe eher nicht.
3. Ziel
   Willst du ein Training beschleunigen, Kosten in der Inferenz senken oder beides? Ohne klares Ziel misst du hinterher am Falschen.

Der pragmatische Startpfad

Im Alltag würde ich den ersten TPU-Test nicht mit eurem komplexesten Produktionsmodell machen. Nimm einen kleinen, repräsentativen Job. Ziel ist nicht sofort maximale Performance, sondern Lernkurve ohne Chaos.

Ein schlanker Ablauf sieht so aus:

• Projekt in Google Cloud vorbereiten
  Aktiviere die benötigten APIs und prüfe, in welcher Region TPU-Ressourcen für deinen Use Case verfügbar sind.
• TPU-VM oder passende Laufzeit anlegen
  In der Console wählst du die TPU-Ressource und die passende VM-Konfiguration.
• Per SSH verbinden
  Danach richtest du deine Python-Umgebung, Abhängigkeiten und das Framework ein.
• Beispieljob starten
  Erst ein Baseline-Modell. Dann ein kleiner Ausschnitt eures echten Codes.
• Auslastung beobachten
  Prüfe, ob die TPU wirklich arbeitet oder ob deine Pipeline sie ausbremst.

Die wichtigste Code-Änderung

Viele erwarten einen kompletten Rewrite. Oft ist es deutlich weniger.

Bei TensorFlow oder JAX geht es häufig darum, den Accelerator sauber zu adressieren und den Trainingscode so laufen zu lassen, dass das Framework die Rechenoperationen passend auf die TPU legt. Die eigentliche Arbeit liegt danach meist nicht im „Portieren“, sondern im Feintuning der Datenpipeline und Batch-Logik.

Das ist ein wichtiger Unterschied.

Die erste Hürde ist selten das Starten der TPU. Die eigentliche Arbeit beginnt, wenn du sie sauber auslasten willst.

Woran du erkennst, dass der Test schief läuft

Der häufigste Fehlstart sieht so aus: Das Team startet auf TPU, misst enttäuschende Ergebnisse und erklärt das Thema für erledigt.

Oft steckt dahinter eines dieser Probleme:

• Zu kleine Batches: Dann bleibt die Hardware unterfordert.
• CPU-lastige Vorverarbeitung: Die TPU wartet auf Daten.
• Nicht unterstützte oder unpassende Operationen: Das Framework muss Umwege gehen.
• Falscher Vergleich: TPU-Test gegen stark optimierte GPU-Pipeline oder umgekehrt.

Ein realistisches Mini-Szenario

Nehmen wir an, dein Team betreibt ein Bildklassifikationsmodell für Qualitätskontrolle.

Der erste vernünftige Test wäre nicht, sofort die gesamte Trainingshistorie auf TPU neu zu rechnen. Besser ist:

Was für MLOps-Teams wirklich zählt

Für mich ist die Kernfrage im Betrieb nie nur „läuft es?“, sondern:

• Ist das reproduzierbar?
• Kriegt das Team Debugging und Monitoring in den Griff?
• Passt das in euren bestehenden CI/CD- und MLOps-Stack?
• Kann Produkt damit schneller lernen oder nur teurer experimentieren?

Wenn du darauf keine guten Antworten hast, bringt dir auch ein starker Accelerator wenig.

Typische Anwendungsfälle für dein Team

TPUs wirken abstrakt, solange man nur über FLOPS, Pods und Architekturen spricht. Der Punkt wird erst klar, wenn du auf konkrete Teamprobleme schaust.

Industrie und Fertigung

Ein Werk will Bilddaten aus der Qualitätskontrolle schneller auswerten. Das Modell erkennt Defekte auf Bauteilen. Solche Workloads bestehen oft aus genau den Rechenmustern, für die spezialisierte ML-Hardware attraktiv wird.

Der operative Vorteil liegt nicht nur in Tempo. Er liegt darin, dass du Modelle häufiger aktualisieren und produktionsnah betreiben kannst, ohne deine GPU-Kapazitäten komplett zu blockieren.

Finanzmodelle und Risikobewertung

Im Finanzumfeld entstehen schnell grosse Inferenzlasten. Modelle für Klassifikation, Prognose oder Betrugserkennung laufen nicht einmal am Tag, sondern fortlaufend.

Da wird die Frage relevant, wie effizient du produktive Inferenz betreibst. Nicht jede Bank braucht TPUs. Aber Teams mit hoher Last und klar standardisierten Modellen sollten sie zumindest sauber prüfen.

Forschung und grosse Sprachmodelle

Hier wird der TPU-Fall am deutlichsten. Der globale TPU-Markt wurde 2024 auf 5,3 Milliarden USD geschätzt und soll laut Prognose bis 2034 auf 37,9 Milliarden USD wachsen. In derselben Quelle wird auch beschrieben, dass PaLM mit 540 Milliarden Parametern auf 6.144 TPU-v4-Chips trainiert wurde. Das zeigt, wie stark TPUs bei grossen KI-Workloads positioniert sind. Die Angaben stammen aus der Marktanalyse von Global Market Insights zum TPU-Markt.

Diese Art von Training ist für die meisten Unternehmen kein Alltagsjob. Aber sie zeigt, wo die Plattform architektonisch zuhause ist.

Life Sciences und Proteinfaltung

Ein starkes Beispiel aus der Forschung ist AlphaFold. In den verifizierten Daten wird beschrieben, dass AlphaFold auf TPUs lief und das jahrzehntealte Problem der Proteinfaltung löste. Für Unternehmen im Pharma- oder Biotech-Umfeld ist das relevant, weil es zeigt, dass TPUs nicht nur für Chatbots und Suchsysteme interessant sind, sondern auch für wissenschaftlich anspruchsvolle Modelle.

Wenn dein Use Case aus grossen, wiederholbaren ML-Rechenmustern besteht, lohnt sich eine TPU-Prüfung. Wenn dein Use Case vor allem aus unregelmässiger Logik besteht, eher nicht.

Ein Blick auf Unternehmensalltag statt Frontier-Forschung

Nicht jedes Team trainiert ein Modell in PaLM-Grösse. Realistischer sind diese Fragen:

• Läuft bei uns täglich viel Inferenz in Produktion?
• Sind unsere Trainingsjobs wiederkehrend und teuer?
• Haben wir einen klaren Weg von Modelltraining zu Betrieb?
• Ist die ML-Nutzung breit genug im Unternehmen, damit Spezialisierung Sinn ergibt?

Dass KI in Unternehmen operativ immer stärker ankommt, sieht man auch jenseits der Infrastruktur. Ein Beispiel ist diese Meldung zur Weiterbildung und zum KI-Einsatz im Arbeitsalltag: https://www.kiweekly.de/news/synthesia-report-ki-ist-in-der-weiterbildung-im-unternehmensalltag-angekommen

Gerade in der DACH-Region ist das relevant. Viele Unternehmen sind nicht auf der Suche nach dem „grössten Modell“, sondern nach verlässlicher, wirtschaftlicher KI im Betrieb. Dort kann TPU interessant werden.

Performance Kosten und der GPU-Vergleich

Jetzt zur eigentlichen Managementfrage: TPU oder GPU?

Wenn du nur auf allgemeine Verfügbarkeit und Flexibilität schaust, gewinnen GPUs oft. Wenn du auf bestimmte ML-Workloads mit klarer Skalierung und hohem Produktionsvolumen schaust, können TPUs wirtschaftlich besser aussehen.

Der direkte Vergleich

Was bei TPUs wirtschaftlich interessant ist

Für Inferenz ist TPU v5e besonders spannend. Laut den verifizierten Daten bietet sie bis zu 2,5-mal höhere Leistung pro Dollar und eine 1,7-fache Beschleunigung gegenüber TPU v4 für Inferenz-Workloads. Das steht in der Produktdokumentation zu Google Cloud TPU.

Das ist eine wichtige Aussage. Nicht, weil du damit automatisch sparen wirst. Sondern weil sie zeigt, dass Google selbst die TPU-Familie klar auf Kosten pro produktivem KI-Output trimmt, nicht nur auf absolute Rechenleistung.

Die Spezialisierungsfalle

Hier wird’s unbequem. Eine TPU kann in ihrer Nische hervorragend sein. Aber genau diese Nische ist der Haken.

Wenn dein Team heute vieles auf GPUs macht, dann nutzt es oft unbewusst deren Vielseitigkeit:

• Modelltraining
• Experimente
• Preprocessing-nahe Aufgaben
• verschiedene Frameworks
• gemischte Teams und Workloads

Sobald du auf TPUs gehst, triffst du eine architektonische Vorentscheidung. Du sagst im Kern: Dieser Teil unserer KI-Landschaft ist standardisiert genug, dass sich Spezialisierung lohnt.

Das ist der Punkt, den viele in Infrastrukturdeals ausblenden. Auf Makroebene wirken grosse GPU- und KI-Rechenzentrumsdeals spektakulär, etwa wie in dieser Meldung zum Meta-CoreWeave-Abkommen: https://www.kiweekly.de/news/coreweave-vereinbart-ki-infrastruktur-deal-mit-meta-ueber-21-milliarden-dollar

Für dein Unternehmen zählt aber nicht die Schlagzeile. Es zählt, ob dein eigener Workload genug Wiederholung und Volumen hat.

Meine Faustregel aus dem Alltag

TPUs sind oft die bessere Wahl, wenn mehrere Bedingungen zusammenkommen:

• Dein Modelltyp passt gut zu TPU-Stärken
• Du hast wiederkehrende Last statt sporadischer Experimente
• Dein Team akzeptiert geringere Flexibilität
• Google Cloud ist ohnehin Teil eurer Plattformstrategie

GPUs bleiben oft die bessere Wahl, wenn eines davon gilt:

• Ihr seid noch stark in der Experimentierphase
• Ihr habt viele unterschiedliche Frameworks und Workloads
• Ihr braucht maximale Portabilität
• Ihr wollt Infrastruktur-Risiko niedrig halten

Die falsche Frage ist „Welcher Chip ist besser?“. Die richtige Frage ist „Welche Einschränkungen akzeptieren wir für welche Effizienzgewinne?“

Migrationstipps von GPU auf TPU

Wenn du bereits GPU-Workloads hast, migrierst du idealerweise nicht mit einem Big Bang. Du migrierst selektiv.

Die wichtigste Einsicht dabei ist simpel: Nicht jeder GPU-Job wird auf einer TPU automatisch gut laufen. TPUs sind für Matrix-Multiplikationen optimiert. Die Entscheidung für TPUs ist laut der ByteByteGo-Einordnung eine architektonische Vorentscheidung, die sich erst ab einer passenden Skalierung wirklich lohnt. Die Quelle dazu ist der Beitrag über die Spezialisierung von Google TPUs bei ByteByteGo.

Eine kurze Migrations-Checkliste

• Starte mit einem Kandidatenmodell
  Nimm nicht den chaotischsten Legacy-Job, sondern ein Modell mit klaren, dichten Rechenmustern.
• Prüfe die Datenpipeline zuerst
  Wenn Vorverarbeitung und Datenzufuhr nicht mithalten, wirkt die TPU schwächer, obwohl der Flaschenhals woanders sitzt.
• Halte den ersten Test klein
  Erst Funktionsfähigkeit und Profiling. Danach Optimierung.
• Beobachte Framework-Reibung
  TensorFlow und JAX sind oft natürlicher. Bei bestehendem PyTorch-Stack musst du genauer prüfen, wie viel Anpassung ihr akzeptieren wollt.
• Miss End-to-End statt nur Training
  Produktiv zählt nicht der schönste Einzelbenchmark, sondern der gesamte Weg von Daten bis Deployment.

Woran Migrationen scheitern

Die meisten Fehlschläge entstehen nicht wegen zu wenig Rechenleistung. Sie entstehen, weil Teams die Spezialisierung unterschätzen.

Ein GPU-Stack verzeiht mehr. Eine TPU verlangt mehr Disziplin bei Architektur, Datenfluss und Betriebsmodell. Wenn dein Team diese Klarheit nicht hat, ist eine TPU keine Abkürzung, sondern ein Multiplikator für bestehende Unordnung.

Wenn du solche Infrastrukturentscheidungen laufend besser einordnen willst, lohnt sich ein Blick auf KI Weekly. Dort bekommst du jeden Sonntag die wichtigsten KI-Entwicklungen, Tools und Praxisbeispiele auf Deutsch, ohne Hype und mit Fokus auf Entscheidungen, die im Arbeitsalltag wirklich relevant sind.

*Drafted with the Outrank tool*