TPU Ironwood einrichten: 12 Schritte [2026]

Google hat seine siebte TPU-Generation Ironwood (intern TPU7x, offiziell auch TPU v7 genannt) im Lauf des Jahres 2026 allgemein verfügbar gemacht. Für Teams, die bisher nur mit Nvidia-GPUs trainiert haben, ist das ein guter Zeitpunkt für einen zweiten Blick auf Googles Tensor Processing Units. Dieses Tutorial zeigt Schritt für Schritt, wie Sie ein Google-Cloud-Projekt für TPU Ironwood vorbereiten, eine TPU-Ressource anlegen und ein erstes Trainings-Workload mit JAX oder PyTorch/XLA starten. Sie brauchen dafür kein Vorwissen zu TPUs, aber Grundkenntnisse in der Kommandozeile und ein aktives Google-Cloud-Konto.

Am Ende dieses Tutorials haben Sie ein vollständig lauffähiges Projekt: ein Google-Cloud-Projekt mit aktivierter TPU-API, eine gebuchte TPU7x-Ressource, eine funktionierende JAX- oder PyTorch/XLA-Umgebung und ein kleines Transformer-Modell, das tatsächlich auf der TPU trainiert. Dazu kommen 13 konkrete Schritte, sieben Codebeispiele mit erwarteten Ausgaben, fünf typische Einsteigerfehler und acht Fehlerbilder samt Lösung, die in der Praxis am häufigsten auftreten. Rechnen Sie für die komplette Einrichtung, inklusive Wartezeit auf ein genehmigtes Kontingent, mit etwa 40 bis 60 Minuten reiner Bearbeitungszeit, wobei die Kontingent-Freigabe selbst je nach Region auch mehrere Stunden bis Tage dauern kann und getrennt von der eigentlichen Setup-Zeit einzuplanen ist.

Warum TPU Ironwood 2026 relevant für Ihr Team wird

Bislang war die TPU-Welt für viele Teams außerhalb von Google ein Randthema, weil Nvidia mit CUDA, einem riesigen Ökosystem und breiter Framework-Unterstützung den Ton angab. Mit Ironwood ändert sich zumindest die Ausgangslage für zwei Gruppen: Teams, die bereits große Modelle über Google Cloud ausliefern, und Teams, die an Trainingskosten für sehr große Modelle sparen wollen. Google positioniert Ironwood nach eigenen Angaben als erste TPU-Generation, die explizit für das “Zeitalter der Inferenz” gebaut wurde, also für Situationen, in denen nicht mehr das Training, sondern das Bereitstellen und Ausliefern von Antworten den größten Teil der Rechenlast ausmacht.

Ein weiterer Faktor ist die Energieeffizienz. Laut einer Analyse von Google Cloud liegt die Compute Carbon Intensity von Ironwood etwa 3,7-mal besser als bei der älteren TPU-v5p-Generation, gemessen als geleistete Rechenarbeit pro Einheit ausgestoßenem Kohlenstoff. Für Unternehmen mit eigenen Nachhaltigkeitszielen oder EU-Berichtspflichten ist das ein Argument, das über reine Rechenleistung hinausgeht. Gleichzeitig bleibt der Umstieg nicht ohne Aufwand: Wer heute auf CUDA-spezifische Bibliotheken oder proprietäre Nvidia-Tools setzt, muss Teile der Trainings-Pipeline anpassen, weil TPUs über JAX oder PyTorch/XLA statt über CUDA angesprochen werden.

Wichtig ist auch die Einordnung im Wettbewerbsumfeld. Auf der Cloud-Next-Konferenz 2026 hat Google bereits die achte TPU-Generation angekündigt, während Nvidia parallel an neuen Beschleuniger-Generationen arbeitet. Wer jetzt mit Ironwood startet, sammelt praktische Erfahrung mit Googles Software-Stack, bevor der nächste große Versionssprung ansteht, und kann bestehende JAX- oder PyTorch/XLA-Pipelines bei künftigen Hardware-Wechseln meist unverändert weiterverwenden, weil sich an der Framework-Schicht wenig ändert.

Für Teams in Österreich und dem übrigen DACH-Raum kommt ein praktischer Aspekt hinzu: Google Cloud betreibt europäische Regionen, in denen Daten innerhalb der EU verarbeitet werden können, was die Einhaltung von DSGVO-Vorgaben bei Trainingsdaten mit Personenbezug erleichtert. Prüfen Sie vor dem produktiven Einsatz trotzdem im Detail, welche TPU-Regionen tatsächlich Ironwood-Kapazität anbieten, da nicht jede europäische Region von Anfang an mit der neuesten Generation ausgestattet ist.

Was ist Google Cloud TPU Ironwood (v7)?

TPU Ironwood ist Googles siebte Generation eigens entwickelter KI-Beschleuniger. Anders als die Vorgänger ist Ironwood laut Google Cloud primär für Inferenz ausgelegt, also für das Bereitstellen bereits trainierter Modelle in großem Maßstab, unterstützt aber ebenfalls Training. Jeder Ironwood-Chip liefert rund 4.614 FP8-TFLOPs an Spitzenrechenleistung, kombiniert mit 192 GB HBM3e-Speicher und etwa 7,37 TB/s Speicherbandbreite. Zum Vergleich: Das entspricht laut den technischen Angaben von Google etwa dem Sechsfachen der Speicherkapazität und dem 4,5-Fachen der Bandbreite der Vorgänger-Generation Trillium (TPU v6e).

Ironwood-Pods skalieren laut Google Cloud auf bis zu 9.216 Chips in einem einzigen, flüssigkeitsgekühlten System, verbunden über Inter-Chip Interconnect (ICI), Optical Circuit Switch (OCS) und ein Data Center Network. Das Ziel dahinter: riesige Modelle serverübergreifend trainieren oder ausliefern, ohne dass ein einzelner Chip zum Flaschenhals wird. In der Cloud-TPU-Dokumentation heißt es dazu knapp: “Führen Sie ein Trainings-Workload mit einem für TPU7x optimierten Rezept aus” – ein Hinweis darauf, dass Google fertige Trainings-Rezepte für gängige Modellarchitekturen mitliefert, statt Nutzer bei null anfangen zu lassen.

Parallel zu Ironwood hält Google die sechste Generation Trillium (TPU v6e) im Angebot, die weiterhin als Trainings-Arbeitspferd für viele Teams dient. Auf der Cloud-Next-Konferenz 2026 kündigte Google zusätzlich eine achte Generation an: TPU 8t für Training und TPU 8i für Inferenz, gefertigt im 2-Nanometer-Verfahren von TSMC, mit Verfügbarkeit erst gegen Ende 2027. Für ein Setup im Jahr 2026 bleiben Ironwood und Trillium die relevanten, tatsächlich buchbaren Optionen.

Architektur: ICI, OCS und DCN im Zusammenspiel

Was Ironwood von einer klassischen Chip-Generation unterscheidet, ist weniger der einzelne Chip als das Gesamtsystem drumherum. Google beschreibt Ironwood-Pods als System aus drei Netzwerk-Ebenen: dem Inter-Chip Interconnect (ICI) für die direkte, latenzarme Verbindung benachbarter Chips, dem Optical Circuit Switch (OCS) für die dynamische Umschaltung zwischen größeren Chip-Gruppen und dem Data Center Network (DCN) für die Anbindung ganzer Pods aneinander. Erst das Zusammenspiel dieser drei Ebenen erlaubt es, bis zu 9.216 Chips wie einen einzigen, riesigen Beschleuniger mit gemeinsamem Speicherpool erscheinen zu lassen.

Für die Praxis bedeutet das: Sie müssen sich als Entwickler kaum um die Verkabelung zwischen den Chips kümmern. XPK und die Cloud-TPU-Runtime übernehmen das Sharding von Modell und Daten über die verfügbaren Chips automatisch, sofern Sie die von Google mitgelieferten Trainings-Rezepte oder die Standard-Sharding-APIs von JAX nutzen. Wer eigene, sehr spezifische Parallelisierungsstrategien braucht, kann tiefer eingreifen, für den Einstieg reicht aber die Standardkonfiguration aus Schritt 10 in diesem Tutorial völlig aus.

TPU Ironwood im Vergleich: Trillium und Nvidia-GPUs

Bevor Sie sich für eine TPU-Generation entscheiden, lohnt sich ein Blick auf die nackten Zahlen. Die folgende Tabelle stellt Ironwood dem Vorgänger Trillium gegenüber und ordnet grob ein, wofür sich welche Generation eignet. Als Faustregel gilt: Wer bereits produktiv auf Trillium trainiert und zufrieden ist, muss nicht sofort wechseln, denn Google unterstützt beide Generationen parallel. Wer dagegen neu einsteigt oder ein Modell mit besonders großem Speicherbedarf pro Chip plant, sollte gleich mit Ironwood starten, weil sich ein späterer Umstieg wegen unterschiedlicher Runtime-Versionen nicht ohne Anpassungsaufwand erledigen lässt.

Merkmal	Trillium (TPU v6e)	Ironwood (TPU v7 / TPU7x)
Generation	6. Generation	7. Generation
Peak-Rechenleistung pro Chip	918 TFLOPs (bf16)	4.614 TFLOPs (FP8)
Speicher pro Chip	ca. 32 GB	192 GB HBM3e
Speicherbandbreite	ca. 1,64 TB/s	ca. 7,37 TB/s
Chips pro Host	8	höher, poolübergreifend
Maximale Pod-Größe	256 Chips	9.216 Chips
BF16-Spitzenleistung pro Pod	234,9 PFLOPs	deutlich höher (poolabhängig)
Primärer Einsatzzweck	Training und Inferenz, generalistisch	Inferenz-first, mit Trainingsunterstützung
Status Mitte 2026	Allgemein verfügbar seit 2024/2025	Allgemein verfügbar seit Ende 2025

Im Vergleich zu Nvidia-Hardware wie H100, H200 oder B200 positioniert Google Ironwood explizit als Alternative für das Ausliefern großer Modelle in eigenen Rechenzentren, ohne dass Nvidia-GPUs im kritischen Pfad stehen müssen. Wie sich diese Chips im Detail gegen Nvidias aktuelle Beschleuniger schlagen, haben wir bereits in unserem Vergleich von Nvidia B200 und H200 in Österreich aufgeschlüsselt. Für dieses Tutorial reicht die Einordnung: Wer bereits in JAX oder PyTorch entwickelt und Zugriff auf ein GCP-Konto hat, kann Ironwood ohne größere Code-Umstellung testen, weil Google die gleiche XLA-Kompilierungsschicht wie bei Trillium nutzt.

TPU Ironwood oder lokale GPU: Wann sich was lohnt

Nicht jedes Projekt braucht gleich einen Cloud-TPU-Pod. Für schnelle Iteration an einem einzelnen Modell, ohne Cloud-Abrechnung und ohne Wartezeit auf ein Kontingent, bleibt eine lokale GPU-Workstation für viele Entwickler die pragmatischere Wahl. Wir haben diesen Weg bereits ausführlich in unserem Tutorial zum Einrichten einer RTX 5090 für lokale KI beschrieben, ebenso im Beitrag zur Multi-GPU-Workstation für KI-Training. Beide Setups eignen sich gut für Modelle, die auf den verfügbaren VRAM einer einzelnen oder weniger Grafikkarten passen.

Sobald ein Modell oder Datensatz die Kapazität einer lokalen Workstation übersteigt, oder sobald ein Team im laufenden Betrieb regelmäßig sehr große Inferenz-Lasten bedienen muss, kippt die Rechnung zugunsten der Cloud. TPU-Pods lassen sich innerhalb weniger Minuten von einer einzelnen Slice auf mehrere Tausend Chips skalieren, ohne dass jemand neue Hardware bestellen, einbauen und verkabeln muss. Der Preis dafür ist Abhängigkeit von einem Cloud-Anbieter und laufende Kosten, die bei einer eigenen GPU-Workstation nach der Anschaffung entfallen. Eine pragmatische Faustregel aus der Praxis: lokale GPUs für Entwicklung, Debugging und kleine Modelle, TPU-Pods für das Training sehr großer Modelle und für Inferenz im Produktionsmaßstab.

In der Praxis kombinieren viele Teams beide Ansätze, statt sich strikt für einen Weg zu entscheiden. Ein typisches Muster: Entwicklung und erste Tests laufen auf einer lokalen GPU-Workstation, wo Iterationszyklen kurz sind und keine Cloud-Kosten anfallen. Sobald das Modell stabil läuft und auf einen größeren Datensatz skaliert werden soll, wandert der eigentliche Trainingslauf auf TPU Ironwood, wo die Rechenzeit pro investiertem Euro bei sehr großen Modellen oft günstiger ausfällt als beim Zukauf zusätzlicher lokaler GPU-Hardware.

Voraussetzungen: Konto, Tools und Versionen

Für dieses Tutorial brauchen Sie folgende Grundausstattung. Die Versionsangaben sind bewusst als Mindestanforderung formuliert, da Google die Tools laufend aktualisiert.

Ein Google-Cloud-Konto mit aktivierter Abrechnung (Billing Account)
Google Cloud SDK (gcloud CLI) in der jeweils aktuellen Version
Python 3.11 oder neuer auf Ihrem lokalen Rechner oder in Cloud Shell
pip in der aktuellen Version für die Installation von JAX, PyTorch/XLA und XPK
kubectl in der aktuellen Version, falls Sie TPU7x über Google Kubernetes Engine (GKE) statt Compute Engine nutzen
Ein Terminal mit SSH-Zugriff auf die TPU-VM (wird automatisch über gcloud bereitgestellt)
Grundkenntnisse in Bash und mindestens einem der Frameworks JAX oder PyTorch

Laut Google-Cloud-Dokumentation gilt als erste Voraussetzung: “Stellen Sie sicher, dass Sie über ein Google-Cloud-Projekt mit aktivierter Abrechnung verfügen.” Ohne aktive Abrechnung lässt sich keine TPU-Ressource reservieren, selbst im Rahmen eines kostenlosen Testkontos nicht. Prüfen Sie außerdem vorab Ihr TPU-Kontingent (Quota) in der gewünschten Region, dazu mehr in Schritt 6.

Kosten realistisch einplanen, bevor Sie starten

Bevor Sie die erste TPU-Ressource anlegen, legen Sie ein Budget-Limit in der Google-Cloud-Konsole fest. Ein einfacher Budget-Alert mit E-Mail-Benachrichtigung bei 50, 90 und 100 Prozent des geplanten Monatsbudgets reicht für den Einstieg aus und verhindert böse Überraschungen, falls eine TPU-VM versehentlich über das Wochenende weiterläuft. Rechnen Sie außerdem ein, dass die erste Trainings-Iteration wegen der XLA-Kompilierung des Rechengraphen deutlich länger dauert als alle folgenden Schritte, das ist normales Verhalten und kein Fehler.

Schritt 1 bis 3: Projekt, Abrechnung und API aktivieren

Legen Sie zuerst ein eigenes Projekt für Ihre TPU-Experimente an. Ein separates Projekt hilft später bei der Kostenkontrolle, weil Sie Ausgaben klar von anderen Workloads trennen können.

# Schritt 1: Neues Projekt anlegen
gcloud projects create mein-tpu-projekt --name="TPU Ironwood Test"

# Schritt 2: Projekt als aktiv setzen
gcloud config set project mein-tpu-projekt

# Schritt 3: Notwendige APIs aktivieren
gcloud services enable tpu.googleapis.com
gcloud services enable compute.googleapis.com
gcloud services enable container.googleapis.com

Der letzte Befehl aktiviert gleich drei APIs: die TPU-API selbst, die Compute-Engine-API für virtuelle Maschinen und die Container-API für den Fall, dass Sie später auf GKE umsteigen. Die Aktivierung dauert in der Regel wenige Sekunden, kann aber bei neuen Projekten bis zu einigen Minuten in Anspruch nehmen, bis alle Berechtigungen im Hintergrund propagiert sind.

Schritt 4 und 5: gcloud CLI installieren und Berechtigungen setzen

Falls die gcloud CLI noch nicht auf Ihrem System läuft, installieren Sie sie über den offiziellen Installer. Unter Linux und macOS funktioniert das über ein Shell-Skript, unter Windows über den Google-Cloud-SDK-Installer.

# Schritt 4: gcloud CLI installieren (Linux/macOS)
curl https://sdk.cloud.google.com | bash
exec -l $SHELL
gcloud init

# Schritt 5: Dienstkonto-Rolle für TPU-Verwaltung zuweisen
gcloud projects add-iam-policy-binding mein-tpu-projekt \
  --member="user:[email protected]" \
  --role="roles/tpu.admin"

Die Rolle roles/tpu.admin erlaubt das Erstellen, Löschen und Verwalten von TPU-Ressourcen. In produktiven Umgebungen sollten Sie stattdessen ein eigenes Dienstkonto mit möglichst engen Rechten anlegen, statt Ihr persönliches Google-Konto direkt zu berechtigen. Für dieses Tutorial reicht die einfache Variante, für CI/CD-Pipelines, die TPU-Ressourcen automatisiert anlegen oder löschen, empfiehlt sich zusätzlich Workload Identity Federation, damit keine langlebigen Schlüsseldateien für Dienstkonten in Build-Systemen gespeichert werden müssen.

Schritt 6 und 7: TPU-Kontingent beantragen und Region wählen

Neue Google-Cloud-Projekte starten standardmäßig mit einem TPU-Kontingent von null. Sie müssen also aktiv ein Kontingent beantragen, bevor Sie eine TPU7x-Ressource erstellen können. Öffnen Sie dazu in der Google-Cloud-Konsole den Bereich “IAM & Verwaltung” und dort “Kontingente”, filtern Sie nach “TPU” und stellen Sie eine Erhöhungsanfrage für die gewünschte Region. Beschreiben Sie in der Anfrage kurz den geplanten Anwendungsfall, etwa “Testtraining eines kleinen Sprachmodells auf einer v7-8-Slice”, denn Google prüft Kontingent-Anfragen für neue TPU-Generationen häufig manuell, gerade in den ersten Monaten nach der allgemeinen Verfügbarkeit.

Ironwood ist nicht in jeder Google-Cloud-Region verfügbar, da die flüssigkeitsgekühlten Pods spezielle Rechenzentrumsinfrastruktur voraussetzen. Prüfen Sie die aktuelle Regionsliste in der TPU7x-Dokumentation, bevor Sie ein Kontingent beantragen, denn eine Anfrage für eine Region ohne Ironwood-Kapazität führt nur zu unnötiger Wartezeit. Für erste Tests empfiehlt sich häufig eine kleinere TPU-Slice-Größe, etwa ein einzelner Chip oder ein kleiner Verbund, statt gleich einen vollen Pod zu reservieren.

Schritt 8: TPU7x-Ressource über GKE oder Compute Engine erstellen

Google Cloud bietet laut Dokumentation zwei Wege, um TPU7x zu nutzen: “Um TPU7x zu verwenden, können Sie Google Kubernetes Engine (GKE) oder Compute Engine verwenden.” Für ein erstes Experiment ist Compute Engine der direktere Weg, weil Sie ohne Kubernetes-Kenntnisse auskommen. Wer TPUs produktiv und in größerem Maßstab betreibt, fährt mit GKE meist besser, weil sich Node-Pools und Auto-Scaling darüber deutlich einfacher verwalten lassen.

# TPU-Ressource als "Queued Resource" über Compute Engine anfordern
gcloud compute tpus queued-resources create tpu-ironwood-test \
  --node-id=tpu-ironwood-node-1 \
  --project=mein-tpu-projekt \
  --zone=us-central2-b \
  --accelerator-type=v7-8 \
  --runtime-version=tpu-vm-v7-base \
  --best-effort

Der Parameter –best-effort sorgt dafür, dass die Anfrage in eine Warteschlange kommt, statt bei fehlender Kapazität sofort zu scheitern. Gerade bei einer frisch verfügbar gemachten Generation wie Ironwood kann die Kapazität in beliebten Regionen zeitweise knapp sein. Den Status der Anfrage prüfen Sie mit gcloud compute tpus queued-resources describe tpu-ironwood-test –zone=us-central2-b. Der Wert v7-8 im Parameter accelerator-type bezeichnet dabei die Chip-Generation (v7) und die Anzahl der Chips in der Slice (8). Für größere Experimente lässt sich dieser Wert auf entsprechend größere Slice-Konfigurationen ändern, sofern Ihr Kontingent das zulässt, wobei größere Slices in der Regel eine längere Wartezeit bis zur Bereitstellung mitbringen.

Schritt 9 und 10: XPK installieren und Cluster vorbereiten

Für Trainings-Workloads auf Ironwood empfiehlt Google das Kommandozeilen-Tool XPK (Accelerated Processing Kit). Es kapselt viele der manuellen Schritte, die sonst beim Verwalten von TPU-Pools über GKE anfallen, etwa das Anlegen von Node-Pools, das Zuweisen von Workloads zu freien Slices und das Einsammeln von Logs aus verteilten Trainingsläufen. In der offiziellen Trainings-Dokumentation lautet der erste konkrete Schritt schlicht: “Installieren Sie XPK.”

# Schritt 9: XPK installieren
pip install xpk

# Schritt 10: Cluster-Definition für TPU7x anlegen
xpk cluster create \
  --cluster=ironwood-cluster \
  --project=mein-tpu-projekt \
  --zone=us-central2-b \
  --tpu-type=v7-8 \
  --num-slices=1

XPK übernimmt beim Cluster-Aufbau automatisch die passende GKE-Node-Pool-Konfiguration für den gewählten TPU-Typ. Für erste Tests reicht num-slices=1, für verteiltes Training über mehrere Slices hinweg erhöhen Sie diesen Wert entsprechend Ihrem beantragten Kontingent. Intern legt XPK dafür einen eigenen GKE-Node-Pool mit den passenden Taints und Labels an, sodass Trainings-Workloads automatisch auf den richtigen TPU-Nodes landen, ohne dass Sie die Kubernetes-Konfiguration von Hand pflegen müssen. Das spart insbesondere beim ersten Setup viele Stunden im Vergleich zu einer vollständig manuellen GKE-Konfiguration.

Schritt 11: JAX-Umgebung auf der TPU einrichten

JAX gilt bei Google Cloud als bevorzugtes Framework für TPUs, weil es von Anfang an für die XLA-Kompilierung entwickelt wurde und Google selbst große Teile seiner internen Forschung darauf aufbaut. Die Cloud-TPU-Dokumentation weist JAX explizit als optimiertes Framework für Trillium und Ironwood aus. Verbinden Sie sich per SSH mit Ihrer TPU-VM und installieren Sie die TPU-Variante von JAX.

# Auf der TPU-VM einloggen
gcloud compute tpus tpu-vm ssh tpu-ironwood-node-1 --zone=us-central2-b

# JAX mit TPU-Unterstützung installieren
pip install -U "jax[tpu]" -f https://storage.googleapis.com/jax-releases/libtpu_releases.html

Testen Sie danach in einer Python-Shell, ob JAX Ihre TPU-Geräte korrekt erkennt.

import jax
print(jax.devices())
print(f"Anzahl erkannter TPU-Geräte: {jax.device_count()}")

Bei einer korrekt eingerichteten v7-8-Ressource sollte die Ausgabe acht TPU-Geräte auflisten, etwa in dieser Form:

[TpuDevice(id=0, process_index=0, coords=(0,0,0), core_on_chip=0), TpuDevice(id=1, ...), ...]
Anzahl erkannter TPU-Geräte: 8

Erscheint stattdessen eine leere Liste oder ein CPU-Gerät, hat JAX die TPU-Runtime nicht gefunden. Die häufigsten Ursachen dafür behandeln wir im Troubleshooting-Abschnitt weiter unten.

Schritt 12: PyTorch/XLA als Alternative konfigurieren

Wer lieber in PyTorch entwickelt, muss den Trainingscode nicht komplett umschreiben. PyTorch/XLA übersetzt PyTorch-Operationen auf dieselbe XLA-Schicht, die auch JAX unter der Haube nutzt. Die Installation läuft ähnlich unkompliziert.

# PyTorch/XLA mit TPU-Unterstützung installieren
pip install torch torch_xla[tpu] \
  -f https://storage.googleapis.com/libtpu-releases/index.html

python3 -c "import torch_xla.core.xla_model as xm; print(xm.xla_device())"

Der Aufruf xm.xla_device() sollte ein Gerät vom Typ xla:0 zurückgeben. Bestehender PyTorch-Code lässt sich in den meisten Fällen mit überschaubarem Aufwand anpassen: Tensoren und Modelle müssen explizit auf das XLA-Gerät verschoben werden, und für verteiltes Training über mehrere Chips kommt torch_xla.distributed statt des klassischen torch.distributed zum Einsatz. Wer den Speicherbedarf großer Modelle bereits von der GPU-Seite kennt, weiß auch, wie stark Preise und Verfügbarkeit von Speicherchips das Budget beeinflussen können, wie wir in unserem Beitrag zur DRAM- und NAND-Preisentwicklung 2026 beschrieben haben. Bei TPU-Pods übernimmt Google diese Beschaffung zwar für Sie, die Kalkulation über HBM-Kapazität pro Chip bleibt aber ein zentraler Faktor bei der Wahl der Slice-Größe.

Schritt 13: Erstes Trainings-Workload starten

Jetzt folgt der eigentliche Testlauf. Über XPK starten Sie ein Trainings-Workload direkt auf dem zuvor erstellten Cluster, ohne die YAML-Definitionen von Kubernetes von Hand schreiben zu müssen.

xpk workload create \
  --cluster=ironwood-cluster \
  --workload=erstes-training \
  --tpu-type=v7-8 \
  --num-slices=1 \
  --command="python3 train.py --epochs=3 --batch-size=64"

Den Fortschritt verfolgen Sie über xpk workload list –cluster=ironwood-cluster. Ein erfolgreicher Durchlauf für ein kleines Testmodell (in diesem Beispiel ein einfaches Transformer-Modell mit wenigen Millionen Parametern) liefert eine Log-Ausgabe ähnlich der folgenden:

Epoch 1/3 - loss: 2.41 - step_time: 0.087s
Epoch 2/3 - loss: 1.68 - step_time: 0.083s
Epoch 3/3 - loss: 1.22 - step_time: 0.084s
Training abgeschlossen. Checkpoint gespeichert unter gs://mein-bucket/checkpoints/

Die konkreten Zahlen hängen natürlich stark von Modellgröße, Datensatz und Batch-Größe ab. Entscheidend an diesem Punkt ist nicht die Loss-Kurve selbst, sondern dass step_time stabil bleibt und nicht während des Trainings ansteigt, was auf Speicher- oder Kommunikationsprobleme zwischen den Chips hindeuten würde. Prüfen Sie zusätzlich, ob der Checkpoint-Pfad im Cloud-Storage-Bucket tatsächlich beschreibbar ist, bevor Sie einen längeren Lauf starten. Ein häufiger, leicht zu übersehender Fehler ist ein Bucket, für den das verwendete Dienstkonto keine Schreibrechte besitzt, was Training und Checkpoint-Speicherung optisch erfolgreich aussehen lässt, während am Ende schlicht keine Datei im Bucket landet.

Preise und Kostenkontrolle bei TPU Ironwood

Google veröffentlicht die exakten Stundenpreise für TPU7x nicht pauschal, sondern regional gestaffelt über den offiziellen Preisrechner. Für belastbare, aktuelle Zahlen ist die offizielle TPU-Preisseite von Google Cloud die einzige verlässliche Quelle, weil sich Konditionen je nach Region und Vertragsmodell ändern. Verlassen Sie sich nicht auf Preisangaben aus älteren Blogartikeln oder Foren-Threads, da sich die Konditionen für eine neue Generation wie Ironwood in den ersten Monaten nach der allgemeinen Verfügbarkeit erfahrungsgemäß mehrfach anpassen. Was sich aber unabhängig vom exakten Preis planen lässt, ist die Wahl des passenden Abrechnungsmodells.

Modell	Charakteristik	Empfehlung
On-Demand	Flexibel buchbar, keine Vorabverpflichtung, volle Flexibilität bei Start und Stopp	Prototyping und kurze Experimente
Committed Use	Vertragliche Bindung über einen längeren Zeitraum gegen reduzierten Preis	Dauerhafte Produktions-Workloads
Spot / Preemptible	Deutlich günstiger, aber jederzeit mit kurzer Vorwarnung kündbar	Fehlertolerantes, unterbrechbares Batch-Training
Reservierung	Garantierte Kapazität für einen definierten Zeitraum	Große, zeitkritische Trainingsläufe

Für Teams, die noch experimentieren, ist die Kombination aus einer kleinen On-Demand-Slice für Debugging und einem separaten Spot-Kontingent für lange Trainingsläufe meist der wirtschaftlichste Einstieg. Behalten Sie zusätzlich das Budget-Alerting in der Google-Cloud-Konsole im Auge, denn eine vergessene, laufende TPU-Ressource verursacht Kosten auch dann, wenn kein aktives Training mehr läuft.

Ein häufiger Anfängerfehler bei der Kostenplanung: Nur die reine TPU-Rechenzeit einzukalkulieren und dabei Nebenkosten für Cloud Storage (Checkpoints, Trainingsdaten), ausgehenden Netzwerkverkehr und die begleitenden Compute-Engine- oder GKE-Ressourcen zu übersehen. Bei kleinen Testläufen fallen diese Posten kaum ins Gewicht, bei mehrwöchigem Training mit häufigen Checkpoints und großen Datensätzen können sie sich spürbar auf die Gesamtrechnung auswirken. Kalkulieren Sie diese Nebenkosten von Anfang an mit ein, statt sie erst bei der ersten Monatsrechnung zu entdecken.

Die häufigsten Fehler beim TPU-Setup

Aus der Praxis vieler TPU-Erstnutzer kristallisieren sich immer wieder dieselben Stolperfallen heraus, die sich meist innerhalb der ersten Woche zeigen und mit etwas Vorwissen vollständig vermeiden lassen. Diese fünf Punkte kosten am meisten Zeit, wenn man sie vorher nicht kennt.

Kontingent zu spät beantragt: Die Freigabe für ein TPU-Kontingent dauert oft mehrere Stunden bis Tage. Wer erst am Tag des geplanten Trainings danach fragt, verliert wertvolle Zeit.
Falsche Region gewählt: Nicht jede Google-Cloud-Region bietet Ironwood-Kapazität an. Eine Anfrage in der falschen Zone führt zu Fehlermeldungen oder endlosem Warten in der Queue.
Runtime-Version passt nicht zum Chip-Typ: Ironwood benötigt ein eigenes TPU-VM-Image. Wer versehentlich eine für Trillium gebaute Runtime-Version angibt, erhält beim Start der VM einen Kompatibilitätsfehler.
Vergessene, weiterlaufende Ressourcen: Eine TPU-VM, die nach Feierabend nicht gelöscht wird, verursacht über Nacht und am Wochenende weiter Kosten, auch ohne aktives Training.
JAX- und libtpu-Version passen nicht zusammen: JAX und die zugehörige libtpu-Bibliothek müssen aufeinander abgestimmt sein. Ein manuelles Downgrade der einen Komponente ohne die andere führt zu kryptischen Laufzeitfehlern.

Fehlerbehebung: Häufige Probleme und Lösungen

Auch bei sorgfältiger Vorbereitung tauchen beim ersten TPU-Setup fast immer Fehlermeldungen auf, meist an der Schnittstelle zwischen IAM-Berechtigungen, Kontingenten und Softwareversionen. Die folgende Tabelle deckt die Probleme ab, die in Foren und Support-Tickets am häufigsten auftauchen, sortiert grob nach der Reihenfolge, in der sie typischerweise im Setup-Prozess auftreten.

Fehlermeldung / Symptom	Wahrscheinliche Ursache	Lösung
RESOURCE_EXHAUSTED beim Erstellen der TPU	Kein oder zu geringes Kontingent in der Zone	Kontingent-Erhöhung beantragen oder –best-effort nutzen
jax.devices() zeigt nur CPU	libtpu wurde nicht korrekt geladen	JAX-TPU-Paket neu installieren, PJRT-Umgebungsvariable prüfen
Permission denied beim SSH-Zugriff	IAM-Rolle fehlt oder SSH-Key nicht propagiert	roles/tpu.admin zuweisen, gcloud compute config-ssh erneut ausführen
Queued Resource bleibt dauerhaft im Status WAITING_FOR_RESOURCES	Kapazitätsengpass in der gewählten Zone	Andere Region testen oder kleinere Slice-Größe wählen
ImportError bei torch_xla	Python- oder PyTorch-Version inkompatibel mit torch_xla-Build	Kompatibilitätsmatrix der PyTorch/XLA-Dokumentation prüfen
Trainingsschritt bricht mit OOM ab	Batch-Größe zu hoch für verfügbaren HBM	Batch-Größe reduzieren oder Gradient-Checkpointing aktivieren
xpk cluster create schlägt mit API-Fehler ab	container.googleapis.com nicht aktiviert	API wie in Schritt 3 beschrieben aktivieren
Sehr langsame erste Trainings-Iteration	XLA-Kompilierung des Rechengraphen beim ersten Aufruf	Normal bei erstem Schritt, keine Aktion nötig, ab Schritt 2 sollte die Zeit sinken

Bleibt ein Fehler nach diesen Schritten bestehen, lohnt sich ein Blick in die Release Notes der Cloud-TPU-Dokumentation, da Google Kompatibilitätshinweise zwischen JAX-, PyTorch- und libtpu-Versionen dort laufend aktualisiert. Notieren Sie sich bei jedem Fehler zusätzlich die exakte Runtime-Version Ihrer TPU-VM und die installierten Paketversionen von JAX, PyTorch und libtpu. Diese Angaben beschleunigen sowohl die eigene Fehlersuche als auch eine mögliche Support-Anfrage erheblich, weil die meisten TPU-Probleme letztlich auf eine Versions-Inkompatibilität zwischen genau diesen Komponenten zurückgehen.

Fortgeschrittene Tipps für Produktion und Skalierung

Sobald das erste Training zuverlässig läuft, stellt sich die Frage nach Skalierung und Stabilität im Dauerbetrieb. Fünf Punkte machen in der Praxis den größten Unterschied.

Automatisierte Checkpoints einplanen: Nutzen Sie für lange Trainingsläufe automatisierte Checkpoints in einem Cloud-Storage-Bucket, idealerweise alle 15 bis 30 Minuten, damit ein Spot-Abbruch nicht den gesamten Fortschritt kostet. Ein Checkpoint-Intervall, das zu groß gewählt ist, macht den Kostenvorteil von Spot-Ressourcen im Ernstfall wieder zunichte.
Fertige Trainings-Rezepte nutzen: Setzen Sie bei Multi-Slice-Training auf das von Google für Ironwood optimierte Trainings-Rezept, statt eine eigene Sharding-Strategie von Grund auf zu entwickeln. Die mitgelieferten Rezepte sind bereits auf die ICI/OCS/DCN-Topologie von Ironwood abgestimmt und sparen typischerweise Wochen an Tuning-Arbeit.
Monitoring von Anfang an aufsetzen: Überwachen Sie step_time und HBM-Auslastung über Cloud Monitoring, um Engpässe frühzeitig zu erkennen, bevor sie zu Trainingsabbrüchen führen. Ein plötzlicher Anstieg der step_time ist meist das erste sichtbare Anzeichen für ein Kommunikationsproblem zwischen Chips.
Projekte strikt trennen: Trennen Sie Entwicklungs- und Produktionsprojekte konsequent, damit ein Debugging-Skript nicht versehentlich Produktionskapazität blockiert oder ein vergessener Testlauf das Produktionsbudget belastet.
Abrechnungsmodell regelmäßig überprüfen: Prüfen Sie in Abständen von einigen Wochen, ob ein Wechsel auf Committed-Use-Konditionen sich angesichts des tatsächlichen Nutzungsmusters lohnt, sobald der Workload über die reine Prototyping-Phase hinausgeht und regelmäßig läuft.

Sicherheit: IAM, Dienstkonten und Netzwerkisolation

Für ein einmaliges Experiment reicht die in Schritt 5 gezeigte, einfache IAM-Berechtigung auf Ihr persönliches Konto aus. Sobald mehrere Personen im Team TPU-Ressourcen erstellen oder Trainingsläufe in einer Produktionsumgebung stattfinden, sollten Sie strenger vorgehen. Legen Sie ein eigenes Dienstkonto ausschließlich für TPU-Workloads an, weisen Sie ihm nur die konkret benötigten Rollen zu (roles/tpu.user statt roles/tpu.admin reicht für reine Trainingsjobs meist aus) und vermeiden Sie es, persönliche Nutzerkonten dauerhaft mit administrativen TPU-Rechten auszustatten.

# Eigenes Dienstkonto für TPU-Workloads anlegen
gcloud iam service-accounts create tpu-training-sa \
  --display-name="TPU Training Service Account"

# Eingeschränkte Rolle statt vollem Admin-Zugriff zuweisen
gcloud projects add-iam-policy-binding mein-tpu-projekt \
  --member="serviceAccount:[email protected]" \
  --role="roles/tpu.user"

Zusätzlich lohnt sich ein Blick auf die Netzwerkseite: TPU-VMs lassen sich in einem eigenen VPC-Subnetz ohne öffentliche IP-Adresse betreiben, wenn der Zugriff ausschließlich über Cloud Shell, ein Bastion-Host oder Identity-Aware Proxy erfolgt. Für Organisationen mit strengeren Compliance-Vorgaben bietet Google außerdem VPC Service Controls an, um TPU-Ressourcen und die zugehörigen Cloud-Storage-Buckets für Trainingsdaten und Checkpoints gegen unautorisierten Datenabfluss abzusichern. Diese Maßnahmen kosten beim Ersteinrichten etwas zusätzliche Zeit, verhindern aber genau die Art von offen erreichbaren Trainingsservern, die in der Vergangenheit bei anderen Cloud-Anbietern wiederholt zu ungewolltem Datenabfluss geführt hat.

Aktivieren Sie außerdem Cloud Audit Logs für die TPU-API, damit jede Erstellung, Löschung und Konfigurationsänderung einer TPU-Ressource nachvollziehbar protokolliert wird. Gerade in Teams mit mehreren Mitarbeitern, die Zugriff auf dasselbe Projekt haben, hilft ein durchsuchbares Audit-Log dabei, schnell zu klären, wer eine bestimmte Ressource erstellt oder eine teure Slice über Nacht laufen gelassen hat, statt im Nachhinein zu raten.

Komplettes Beispielprojekt: Kleines Transformer-Training auf TPU7x

Zum Abschluss ein kompaktes, lauffähiges Beispiel, das alle vorherigen Schritte zusammenführt. Die Datei train.py trainiert ein kleines Sprachmodell auf Basis von JAX und Flax, das Sie an einen eigenen Datensatz anpassen können.

# train.py – minimalistisches Beispiel für TPU7x
import jax
import jax.numpy as jnp
import optax
from flax import linen as nn

class KleinesTransformerModell(nn.Module):
    vocab_size: int = 8000
    dim: int = 256

    @nn.compact
    def __call__(self, x):
        x = nn.Embed(num_embeddings=self.vocab_size, features=self.dim)(x)
        x = nn.SelfAttention(num_heads=4)(x)
        x = nn.Dense(self.vocab_size)(x)
        return x

def main():
    print(f"Verfügbare TPU-Geräte: {jax.device_count()}")
    modell = KleinesTransformerModell()
    key = jax.random.PRNGKey(0)
    dummy_input = jnp.ones((8, 32), dtype=jnp.int32)
    params = modell.init(key, dummy_input)
    optimizer = optax.adamw(learning_rate=3e-4)
    opt_state = optimizer.init(params)
    print("Setup abgeschlossen, Training kann starten.")

if __name__ == "__main__":
    main()

Kombiniert mit dem xpk workload create-Befehl aus Schritt 13 ergibt sich ein vollständiger Ablauf: Projekt anlegen, Kontingent sichern, Cluster über XPK aufbauen, Trainingscode einreichen, Checkpoints in Cloud Storage ablegen. Wer sich zusätzlich für Googles eigene Chip-Strategie im Verhältnis zu Nvidias Roadmap interessiert, findet ergänzende Einordnung in unserem Artikel zu Nvidias Rubin-Generation im Vergleich zu Google TPU. Beide Wege haben ihre Berechtigung: TPU-Pods für Skalierung über einzelne Maschinen hinaus, lokale GPUs für schnelle Iteration ohne Cloud-Abrechnung.

Um das Beispielprojekt für ein echtes Vorhaben zu erweitern, ersetzen Sie zunächst den Dummy-Input durch einen echten Datensatz, etwa über die tf.data-API oder Hugging-Face-Datasets, und fügen Sie eine Trainingsschleife mit mehreren tausend statt nur drei Epochen hinzu. Für Modelle jenseits weniger hundert Millionen Parameter lohnt sich außerdem ein Blick auf Sharding-Strategien wie Fully Sharded Data Parallel, die Google in seinen offiziellen Trainings-Rezepten für Ironwood bereits vorkonfiguriert anbietet. Wer den Datensatz in einem Cloud-Storage-Bucket statt lokal auf der TPU-VM ablegt, profitiert zusätzlich von deutlich höherem Durchsatz beim Laden großer Trainingsdaten, weil die TPU-VM dann nicht durch lokale Festplatten-I/O ausgebremst wird.

FAQ: Häufige Fragen zu TPU Ironwood

Was unterscheidet TPU Ironwood von TPU Trillium?
Ironwood ist die siebte TPU-Generation und laut Google primär auf Inferenz großer Modelle ausgelegt, verfügt aber über deutlich mehr Speicher (192 GB HBM3e gegenüber rund 32 GB bei Trillium) und höhere Bandbreite. Trillium (TPU v6e) bleibt als generalistischer Trainings- und Inferenz-Chip im Angebot und ist für viele bestehende Workloads weiterhin die richtige Wahl, insbesondere wenn ein Modell bereits stabil darauf läuft und kein akuter Speicherengpass besteht.

Brauche ich zwingend GKE, um TPU7x zu nutzen?
Nein. Google Cloud erlaubt laut Dokumentation die Nutzung sowohl über GKE als auch direkt über Compute Engine. Für einzelne Experimente ist Compute Engine oft der einfachere Einstieg, weil Sie sich per SSH direkt auf der TPU-VM einloggen und Befehle testen können. Für produktive Multi-Node-Workloads eignet sich GKE meist besser, weil sich Node-Pools, Auto-Scaling und Neustarts nach Abstürzen dort deutlich einfacher automatisieren lassen als bei manuell verwalteten Compute-Engine-Ressourcen.

Läuft bestehender PyTorch-Code ohne Änderungen auf TPU?
Nicht vollständig unverändert. Mit PyTorch/XLA müssen Tensoren und Modelle explizit auf das XLA-Gerät verschoben werden, und für verteiltes Training kommt eine eigene Distributed-API zum Einsatz. Der Umbauaufwand ist in der Regel überschaubar, aber nicht null.

Ist Ironwood in jeder Google-Cloud-Region verfügbar?
Nein. Wegen der speziellen Flüssigkeitskühlung der Ironwood-Pods ist die Generation nur in ausgewählten Regionen buchbar. Prüfen Sie die aktuelle Regionsliste in der TPU7x-Dokumentation vor der Kontingent-Anfrage.

Was kostet eine TPU7x-Ressource pro Stunde?
Google veröffentlicht keine pauschalen, generation-übergreifenden Stundenpreise, weil diese je nach Region, Vertragsmodell (On-Demand, Committed Use, Spot) und Slice-Größe variieren. Die aktuellen Werte finden Sie ausschließlich über den offiziellen Google-Cloud-Preisrechner. Planen Sie bei einem ersten Test lieber mit einer kleinen Slice und kurzer Laufzeit, um ein Gefühl für die tatsächliche Abrechnung zu bekommen, bevor Sie größere Kontingente beantragen.

Kann ich Ironwood auch für kleine Projekte nutzen, oder lohnt sich das nur für Konzerne?
Auch kleine Teams können eine einzelne v7-8-Slice buchen, ohne gleich einen vollen 9.216-Chip-Pod zu reservieren. Für Prototyping reicht häufig eine kleine On-Demand-Slice, die sich nach dem Test sofort wieder löschen lässt.

Was passiert mit meinem Training bei einer Spot-Unterbrechung?
Spot-Ressourcen können mit kurzer Vorwarnung gekündigt werden. Ohne regelmäßige Checkpoints geht dabei der Trainingsfortschritt seit dem letzten gespeicherten Stand verloren. Automatisierte Checkpoints in Cloud Storage sind deshalb bei Spot-Nutzung Pflicht, nicht optional.

Lohnt sich der Umstieg von Nvidia-GPUs auf TPU Ironwood?
Das hängt stark vom Workload ab. Für sehr große, gut auf XLA optimierte Modelle und Inferenz im großen Maßstab kann Ironwood laut Googles eigenen Angaben deutliche Effizienzvorteile bringen, unter anderem bei der Energieeffizienz pro Rechenoperation. Für kleinere Teams mit bestehendem CUDA-Code kann der Umstellungsaufwand den Effizienzgewinn zunächst übersteigen, weil bestehende Trainingspipelines, Monitoring und Tooling angepasst werden müssen. Ein direkter Benchmark-Vergleich mit dem eigenen Modell, gerechnet über die tatsächlichen Cloud-Kosten und nicht nur über reine Rechenleistung, bleibt der zuverlässigste Test vor einer endgültigen Entscheidung.

TPU Ironwood einrichten: 12 Schritte, 40 Min [2026]