Die Frage klingt einfach: Ist eine TPU schneller als eine GPU? Für die Praxis ist sie zu grob. Googles Tensor Processing Unit, kurz TPU, ist ein spezialisierter ASIC für tensorlastige Machine-Learning-Systeme [2]. NVIDIAs H100 SXM ist dagegen eine Rechenzentrums-GPU, deren öffentliche Spezifikation FP64, FP32, TF32 Tensor Core, BF16/FP16, FP8 und INT8 abdeckt [
10].
Damit ist die eigentliche Frage nicht: Wer gewinnt immer? Sondern: Welcher Beschleuniger passt zu Ihrem Modell, Ihrem Software-Stack, Ihrer gewünschten Präzision, Ihrem Speicherbedarf und Ihrer Betriebsumgebung?
Als konkrete Bezugspunkte nutzt dieser Vergleich NVIDIA H100 SXM und Google-Cloud-A3-VMs als GPU-Seite sowie TPU v5e, v5p und v6e als TPU-Seite [1][
10][
11].
Kurzentscheidung
- Google TPU ist naheliegend, wenn es um weitgehend reines Deep Learning geht, das Modell gut auf TPU-Ausführung abbildbar ist und Ihr Team TPU-orientierte Skalierung beherrscht. Die öffentlichen JAX-Skalierungsunterlagen führen für TPU v5e, v5p und v6e unter anderem Pod-Topologien, HBM pro Chip, Bandbreite sowie BF16- und INT8-Werte auf [
11].
- NVIDIA H100 GPU ist meist der sicherere Standard, wenn Sie breitere numerische Unterstützung, gemischte Workloads oder geringeres Migrationsrisiko aus einem bestehenden GPU-Stack benötigen. NVIDIA listet für H100 SXM FP64, FP32, TF32 Tensor Core, BF16/FP16 Tensor Core, FP8 Tensor Core und INT8 Tensor Core sowie 80 GB HBM3 und 3,35 TB/s Speicherbandbreite [
10].
- Beides benchmarken, wenn Kosten den Ausschlag geben. Peak-FLOPS, Chip-Stundenpreise und Herstellerangaben ersetzen keinen Test mit Ihrem eigenen Modell, Ihrer Batch-Größe und Ihrem Ziel für Training oder Inferenz.
TPU: Spezialist. H100: flexibler Allrounder mit KI-Fokus
TPUs sind auf Tensorverarbeitung in Machine-Learning-Systemen zugeschnitten [2]. Genau daraus entsteht ihr Vorteil: Wenn Compiler-Pfad, Tensorformen, Batching und Sharding TPU-freundlich sind, kann die Hardware sehr effizient ausgelastet werden.
Die H100 geht breiter vor. Sie ist durch Tensor Cores stark auf KI optimiert, bleibt aber eine allgemeinere GPU-Plattform. Die öffentliche H100-SXM-Tabelle enthält neben niedrigeren Tensor-Core-Präzisionen auch klassische FP64- und FP32-Angaben [10]. Das zählt besonders dann, wenn derselbe Beschleunigerpool nicht nur eine Modellfamilie, sondern Forschung, Training, Inferenz, numerische Experimente oder mehrere Teams bedienen soll.
Öffentliche Spezifikationen: hilfreich, aber kein Benchmark
Rohdaten zeigen die Richtung, liefern aber keinen fairen Eins-zu-eins-Vergleich. TPU- und GPU-Tabellen nutzen unterschiedliche Präzisionsmodi, Systemannahmen und Skalierungswege. Ein BF16-Wert auf dem Papier sagt wenig darüber, ob Ihr Modell speichergebunden ist, ob der Compiler die Operationen gut abbildet oder ob die Verteilung über viele Chips effizient läuft.
| Beschleuniger | Öffentlicher Speicherwert | Öffentliche Bandbreite | Öffentliche Rechenwerte | So sollte man es lesen |
|---|---|---|---|---|
| TPU v5e | 16 GB HBM pro Chip | 8,1 × 10^11 Byte/s pro Chip | 1,97 × 10^14 BF16 FLOP/s pro Chip; 3,94 × 10^14 INT8 FLOP/s pro Chip | TPU-Option mit weniger HBM pro Chip als v5p oder v6e in der JAX-Tabelle; Speicherfit genau prüfen [ |
| TPU v5p | 96 GB HBM pro Chip | 2,8 × 10^12 Byte/s pro Chip | 4,59 × 10^14 BF16 FLOP/s pro Chip; 9,18 × 10^14 INT8 FLOP/s pro Chip | Höchster HBM-pro-Chip-Wert unter v5e, v5p und v6e in der JAX-Tabelle [ |
| TPU v6e | 32 GB HBM pro Chip | 1,6 × 10^12 Byte/s pro Chip | 9,20 × 10^14 BF16 FLOP/s pro Chip; 1,84 × 10^15 INT8 FLOP/s pro Chip | Höchster gelisteter BF16- und INT8-Durchsatz pro Chip unter diesen TPU-Zeilen [ |
| NVIDIA H100 SXM | 80 GB HBM3 | 3,35 TB/s | 67 TFLOPS FP32; 989 TFLOPS TF32 Tensor Core; 1.979 TFLOPS BF16/FP16 Tensor Core; 3.958 TFLOPS FP8 Tensor Core; 3.958 TOPS INT8 Tensor Core | Breite Präzisionsabdeckung, hohe Speicherbandbreite und ein allgemeineres Beschleunigerprofil [ |
Google Cloud dokumentiert außerdem A3-Maschinentypen mit 1, 2, 4 oder 8 angebundenen H100-GPUs und 80 GB HBM3 pro GPU [1]. In Materialien zum AI Hypercomputer beschreibt Google Cloud sowohl TPUs als auch A3-VMs mit H100-GPUs als Teil desselben KI-Infrastrukturportfolios [
18]. In der Praxis heißt das: Die Wahl lautet nicht immer Google TPU gegen GPU in einer anderen Cloud. Beides kann im selben Google-Cloud-Kontext relevant sein.
Wann Google TPUs besonders sinnvoll sind
Eine TPU ist dann stark, wenn ihre Spezialisierung zum Vorteil und nicht zur Einschränkung wird. Setzen Sie TPUs weit oben auf die Shortlist, wenn:
- Ihr Job aus Deep-Learning-Training oder Inferenz besteht und von großen Tensoroperationen dominiert wird [
2];
- Modellformen, Batch-Größen und Sharding-Muster relativ stabil sind und auf TPU-Auslastung optimiert werden können;
- Ihr Team bereit ist, TPU-orientierte Skalierungspraktiken zu nutzen; die JAX-Dokumentation behandelt Pod-Größe, Host-Größe, HBM-Kapazität, Bandbreite sowie BF16- und INT8-Durchsatz als zentrale Planungsgrößen [
11];
- Google Cloud ohnehin die vorgesehene Betriebsumgebung ist;
- das Geschäftsziel eine gemessene Kosten-Leistungs-Optimierung für wenige klar definierte Modelle ist – nicht maximale Portabilität über viele Workloads.
TPUs können sehr attraktiv sein, wenn der Workload die Chips gut auslastet und keine teuren Umbauten erzwingt. Das ist aber ein Ergebnis des konkreten Workloads, keine universelle Eigenschaft. Google hat selbst Performance-per-Dollar-Material für GPUs und TPUs bei KI-Inferenz veröffentlicht; auch das unterstreicht, dass Serving-Ökonomie vom Modell und Setup abhängt und nicht von einer einzigen globalen Rangliste [16].
Wann NVIDIA H100 GPUs die bessere Wahl sind
Die H100 ist meist stärker, wenn Flexibilität wichtiger ist als maximale Spezialisierung. Sie passt besonders gut, wenn:
- Sie höhere Präzisionsmodi wie FP64 oder FP32 ebenso benötigen wie niedrigere Tensor-Core-Modi; die H100-SXM-Tabelle enthält FP64, FP32, TF32, BF16, FP16, FP8 und INT8 [
10];
- Ihre Codebasis bereits auf GPU-Kernels, GPU-Bibliotheken oder GPU-orientiertes Monitoring und Deployment setzt;
- derselbe Hardwarepool mehrere Workload-Typen bedienen muss, statt nur eine eng definierte Modellfamilie;
- Sie H100-VM-Formen in Google Cloud nutzen möchten; A3-Maschinentypen sind mit 1, 2, 4 oder 8 angebundenen H100-GPUs dokumentiert [
1];
- Migrationsrisiko wichtiger ist als ein theoretischer Effizienzgewinn auf Chipebene.
Das stärkste Argument für H100 ist also nicht, dass eine einzelne GPU in jedem Benchmark eine einzelne TPU schlägt. Es ist die breitere Einsatzfähigkeit, wenn Anforderungen sich ändern.
Kosten: Chip-Stundenpreise allein führen schnell in die Irre
Preisvergleiche wirken verführerisch präzise, sind aber oft brüchig. Ein Drittvergleich nannte etwa 1,20 US-Dollar pro Chip-Stunde für Google Cloud TPU v5e und etwa 12,84 US-Dollar pro Stunde für eine 80-GB-H100-GPU in einem Azure-ND-H100-v5-Beispiel [4]. Das ist cloudübergreifend und nicht offiziell; es taugt daher höchstens als grobe Orientierung, nicht als Beweis, dass TPU immer günstiger ist.
Besser ist ein Kostenvergleich auf Systemebene:
- Nützlicher Durchsatz: Trainingsschritte pro Sekunde, Samples pro Sekunde, Tokens pro Sekunde oder Latenz bei Ihrer Ziel-Batch-Größe.
- Präzisionsmodus: FP8, BF16, FP16, TF32, FP32, FP64 und INT8 sind nicht austauschbar [
10][
11].
- Speicherkapazität und Bandbreite: Große Modelle, lange Kontexte und Batch-Größe können den Engpass weg von Peak-Compute verschieben [
10][
11].
- Skalierungsverhalten: TPU-Pod-Topologie und H100-VM-Konfiguration beeinflussen Design und Effizienz von verteiltem Training und Serving [
1][
11].
- Auslastung: Unbenutzte Beschleuniger sind teuer, selbst wenn der Stundenpreis gut aussieht.
- Engineering-Kosten: Portierung, Compiler-Anpassungen, Debugging, Monitoring und Deployment-Änderungen können Chip-Stundenersparnisse auffressen.
Die praxisnahe Kennzahl lautet daher: Kosten pro nützlichem Output – pro Trainingsschritt, pro konvergiertem Modell, pro Inferenz-Token oder pro erreichtem Latenzziel.
Entscheidungsmatrix
| Priorität | Besserer Ausgangspunkt | Warum |
|---|---|---|
| TPU-freundliches Deep Learning auf Google Cloud | Google TPU | Die öffentlichen TPU-Unterlagen betonen Pod-Skalierung, HBM, Bandbreite sowie BF16- und INT8-Durchsatz für Modellskalierung [ |
| Breite Präzisionsunterstützung | NVIDIA H100 GPU | H100 SXM listet FP64, FP32, TF32 Tensor Core, BF16/FP16 Tensor Core, FP8 Tensor Core und INT8 Tensor Core [ |
| Google-Cloud-Deployment mit Wahlfreiheit | Beide benchmarken | Google Cloud dokumentiert A3-H100-Maschinentypen und positioniert zugleich TPUs und H100-A3-VMs im KI-Infrastrukturportfolio [ |
| Niedrigste Inferenzkosten | Beide benchmarken | Google hat Performance-per-Dollar-Analysen für KI-Inferenz veröffentlicht; Drittwerte zu Chip-Stunden sind nur richtungsweisend und teils cloudübergreifend [ |
| Bestehender GPU-first-Produktionsstack | NVIDIA H100 GPU | Geringeres Migrationsrisiko kann mehr zählen als ein theoretischer Effizienzvorteil eines anderen Beschleunigers. |
Fazit
Behandeln Sie TPU als stärker spezialisierten KI-Beschleuniger und H100 als flexiblere Beschleunigerplattform. Wenn Ihr Modell TPU-freundlich ist, stark von Deep Learning geprägt wird und ohnehin in Google Cloud laufen soll, kann eine TPU die bessere Kosten-Leistungs-Wette sein. Wenn Sie breite numerische Modi, gemischte Workloads, GPU-orientierte Betriebskontinuität oder geringeres Migrationsrisiko brauchen, sind NVIDIA-H100-GPUs meist der sicherere Standard [10][
11].
Die belastbare Antwort liefert am Ende nur ein Workload-spezifischer Benchmark: Messen Sie Durchsatz, Speicherverhalten, Auslastung, Gesamtkosten und Engineering-Aufwand mit genau dem Modell, das Sie trainieren oder ausliefern wollen.
