NVIDIA GPUs für KI: Von CUDA zu Tensor Cores

In den vorherigen Teilen haben wir TPUs und Apple Silicon kennengelernt – spezialisierte Lösungen für spezifische Einsätze. NVIDIA verfolgt einen anderen Weg: maximale Flexibilität bei hoher Leistung. Das Ergebnis ist eine marktbeherrschende Stellung, die weit über technische Überlegenheit hinausgeht.

Warum GPUs für KI?

Grafikkarten wurden für ein Problem entwickelt, das überraschend ähnlich zu KI ist: Millionen von Pixeln parallel berechnen.

Die Parallele zur Grafikberechnung

Bei der 3D-Grafik:

• Jedes Pixel wird unabhängig berechnet
• Dieselbe Operation auf verschiedene Daten (SIMD)
• Hohe Bandbreite wichtiger als niedrige Latenz

Bei neuronalen Netzen:

• Jedes Neuron wird unabhängig berechnet
• Matrix-Multiplikationen sind massiv parallel
• Hohe Bandbreite wichtiger als niedrige Latenz

Die Architektur, die für Spiele optimiert wurde, eignet sich zufällig perfekt für KI.

Der CUDA-Moment

2006 veröffentlichte NVIDIA CUDA (Compute Unified Device Architecture) – eine Programmiersprache, die GPUs für allgemeine Berechnungen öffnete.

Vor CUDA musste man GPU-Programme als “Shader” tarnen – so tun, als würde man Grafik berechnen. Mit CUDA konnte man direkt:

__global__ void matrixMul(float* A, float* B, float* C, int N) {
    int row = blockIdx.y * blockDim.y + threadIdx.y;
    int col = blockIdx.x * blockDim.x + threadIdx.x;
    
    float sum = 0.0f;
    for (int k = 0; k < N; k++) {
        sum += A[row * N + k] * B[k * N + col];
    }
    C[row * N + col] = sum;
}

Das war der Startschuss für GPU-Computing – und NVIDIA hatte einen Vorsprung von Jahren.

Die GPU-Architektur

Streaming Multiprocessors (SMs)

Eine NVIDIA GPU besteht aus vielen Streaming Multiprocessors:

GPU
├── SM 0
│   ├── CUDA Cores (für FP32/INT32)
│   ├── Tensor Cores (für Matrix-Ops)
│   ├── Register File
│   ├── Shared Memory
│   └── L1 Cache
├── SM 1
│   └── ...
├── ...
├── L2 Cache (gemeinsam)
└── HBM (High Bandwidth Memory)

Die H100 hat 132 SMs mit jeweils:

• 128 CUDA Cores
• 4 Tensor Cores (4. Generation)
• 256 KB Register
• 256 KB Shared Memory / L1 Cache

CUDA Cores vs. CPU Cores

Ein CPU-Kern ist ein Schweizer Taschenmesser:

• Out-of-Order Execution
• Branch Prediction
• Große Caches
• Optimiert für komplexe, sequentielle Aufgaben

Ein CUDA Core ist ein Skalpell:

• In-Order Execution
• Kein Branch Prediction
• Minimale Caches
• Optimiert für einfache, parallele Aufgaben

Eine H100 hat 16.896 CUDA Cores. Jeder einzelne ist viel schwächer als ein CPU-Kern – aber zusammen sind sie unschlagbar bei parallelen Workloads.

SIMT: Single Instruction, Multiple Threads

NVIDIA nennt sein Programmiermodell SIMT. Threads werden in Gruppen von 32 (einem “Warp”) ausgeführt:

• Alle 32 Threads führen dieselbe Instruktion aus
• Jeder Thread hat eigene Register und Daten
• Bei Verzweigungen (if/else) werden beide Pfade nacheinander ausgeführt

Das bedeutet: Verzweigungen sind teuer. Code wie dieser ist problematisch:

if (threadIdx.x % 2 == 0) {
    // Pfad A
} else {
    // Pfad B
}

Halb der Warp wartet, während die andere Hälfte arbeitet. Für Matrix-Multiplikationen (keine Verzweigungen) ist das perfekt.

Tensor Cores: Der Game Changer

2017 führte NVIDIA mit der Volta-Architektur Tensor Cores ein – spezialisierte Einheiten für Matrix-Operationen.

Was Tensor Cores machen

Ein Tensor Core führt eine Matrix Multiply-Accumulate (MMA) Operation aus:

D = A × B + C

Wobei A, B, C, D kleine Matrizen sind (z.B. 4×4 oder 8×8).

Der Geschwindigkeitsvorteil

Operation	CUDA Cores	Tensor Cores	Speedup
FP32 Matrix-Mul	60 TFLOPS	-	Baseline
FP16 Matrix-Mul	120 TFLOPS	990 TFLOPS	8×
INT8 Matrix-Mul	-	1.980 TOPS	16×
FP8 Matrix-Mul	-	3.960 TFLOPS	33×

(Werte für H100 SXM)

Wie funktionieren sie?

Tensor Cores sind im Prinzip kleine Systolic Arrays (wie in TPUs), aber:

• Kleiner (4×4 statt 256×256)
• Flexibler programmierbar
• Integriert in die GPU-Architektur

Sie sind nicht “aufgepfropft”, sondern tief in die SM-Architektur integriert.

Transformer Engine

Mit der Hopper-Architektur (H100) kam die Transformer Engine:

• Automatischer Wechsel zwischen FP8 und FP16
• Optimiert für Attention-Berechnungen
• Dynamische Skalierung der Präzision

Das ermöglicht FP8-Training ohne manuelles Tuning – ein großer Schritt für die Benutzerfreundlichkeit.

Speicherhierarchie

Die Speicherarchitektur ist entscheidend für KI-Performance.

HBM: High Bandwidth Memory

Moderne KI-GPUs nutzen HBM – gestapelte Speicherchips direkt auf dem Package:

GPU	HBM-Generation	Kapazität	Bandbreite
A100	HBM2e	80 GB	2,0 TB/s
H100 SXM	HBM3	80 GB	3,35 TB/s
H200	HBM3e	141 GB	4,8 TB/s
B100	HBM3e	192 GB	8 TB/s*

*Angekündigt

Zum Vergleich: DDR5 RAM erreicht ~50 GB/s. HBM ist 60-160× schneller.

Cache-Hierarchie

Register (pro Thread)     : ~256 KB pro SM, schnellst
  ↓
Shared Memory / L1        : 256 KB pro SM, ~19 TB/s
  ↓
L2 Cache                  : 50 MB (H100), ~12 TB/s
  ↓
HBM                       : 80 GB, ~3,35 TB/s

Gute KI-Kernels maximieren die Nutzung von Registern und Shared Memory, um HBM-Zugriffe zu minimieren.

Das Roofline-Modell

Die Performance eines Kernels ist entweder:

Compute-bound: Mehr FLOPS würden helfen Memory-bound: Mehr Bandbreite würde helfen

Die meisten KI-Workloads sind memory-bound. Die Kunst ist, genug Berechnungen pro geladenem Byte zu machen.

Arithmetic Intensity = FLOPS / Bytes geladen

Matrix-Multiplikation hat hohe Arithmetic Intensity → gut für GPUs. Attention hat niedrige Arithmetic Intensity → oft memory-bound.

Multi-GPU und NVLink

Ein Modell wie GPT-4 passt nicht auf eine GPU. Multi-GPU-Systeme sind Standard.

NVLink

NVLink ist NVIDIAs proprietäre GPU-zu-GPU-Verbindung:

Generation	Bandbreite (bidirektional)
NVLink 3.0 (A100)	600 GB/s
NVLink 4.0 (H100)	900 GB/s
NVLink 5.0 (B100)	1.800 GB/s

Zum Vergleich: PCIe 5.0 x16 erreicht ~64 GB/s – NVLink ist 14-28× schneller.

NVSwitch

Für mehr als 2 GPUs verbindet NVSwitch alle GPUs in einem voll verbundenen Netzwerk:

    GPU 0 ←─→ GPU 1
      ↕   ╲ ╱   ↕
    GPU 2 ←─→ GPU 3
      ↕   ╱ ╲   ↕
    GPU 4 ←─→ GPU 5
      ↕   ╲ ╱   ↕
    GPU 6 ←─→ GPU 7

Ein DGX H100 System mit 8 GPUs erreicht so 900 GB/s zwischen beliebigen GPU-Paaren.

Skalierung über Server

Für Training über mehrere Server nutzt NVIDIA:

• InfiniBand: Bis zu 400 Gbit/s pro Port
• NVLink Network: NVLink über Kabel zwischen Servern

GPT-4 wurde vermutlich auf ~10.000+ GPUs trainiert, verbunden über mehrere Racks.

Das CUDA-Ökosystem

NVIDIAs wahrer Burggraben ist nicht die Hardware, sondern das Software-Ökosystem.

Bibliotheken

NVIDIA stellt optimierte Bibliotheken für alles:

• cuBLAS: Lineare Algebra
• cuDNN: Deep Learning Primitives
• cuFFT: Fourier-Transformation
• NCCL: Multi-GPU Kommunikation
• TensorRT: Inferenz-Optimierung

Diese Bibliotheken nutzen Hardware-Features, die Dritte nicht kennen.

Framework-Integration

Alle großen Frameworks sind für NVIDIA optimiert:

• PyTorch: CUDA-Backend, automatische Tensor Core Nutzung
• TensorFlow: XLA-Compiler für NVIDIA GPUs
• JAX: GPU-Beschleunigung out-of-the-box

Die Integration ist so tief, dass “GPU” und “NVIDIA” oft synonym verwendet werden.

Tooling

• Nsight: Profiling und Debugging
• CUDA-GDB: GPU-Debugging
• Compute Sanitizer: Memory-Error-Erkennung

Kein anderer Hersteller bietet vergleichbare Entwicklertools.

H100 vs. A100: Die Evolution

Die H100 (Hopper) vs. A100 (Ampere) zeigt die Entwicklungsrichtung:

Aspekt	A100	H100	Verbesserung
CUDA Cores	6.912	16.896	2,4×
Tensor Cores	432	528	1,2×
FP16 TFLOPS	312	990	3,2×
FP8 TFLOPS	-	3.960	Neu
HBM Bandbreite	2,0 TB/s	3,35 TB/s	1,7×
NVLink	600 GB/s	900 GB/s	1,5×
TDP	400W	700W	1,75×

Die größten Sprünge: FP8-Support und deutlich mehr Tensor Core Performance.

Kosten und Verfügbarkeit

Hardware-Kosten

GPU	Listenpreis	Cloud-Preis/Stunde
RTX 4090	~1.600€	~0,50€
A100 80GB	~15.000€	~2-3€
H100 SXM	~30.000€+	~3-5€

Die Cloud-Preise variieren stark je nach Anbieter und Verfügbarkeit.

Das Verfügbarkeitsproblem

H100-GPUs sind chronisch ausverkauft. Wartezeiten von 6-12 Monaten sind normal. Das hat zu einem Markt geführt, in dem:

• Cloud-Kapazitäten sofort ausgebucht sind
• GPU-Reservierungen Jahre im Voraus gebucht werden
• Startups nach GPU-Zugang statt Funding suchen

Alternativen zu NVIDIA

AMD MI300X

AMDs Antwort auf die H100:

• 192 GB HBM3 (mehr als H100)
• Konkurrenzfähige TFLOPS
• ROCm statt CUDA (weniger ausgereift)

Das Hardware-Problem ist gelöst, das Software-Problem nicht.

Intel Gaudi

Intels KI-Beschleuniger:

• Gute Preis-Leistung
• Fokus auf Inferenz
• Kleineres Ökosystem

Google TPU

Wie in Teil 3 beschrieben:

• Nur über Google Cloud
• Andere Programmiermodelle (JAX/XLA)
• Sehr effizient für bestimmte Workloads

Der Ökosystem-Vorteil

All diese Alternativen kämpfen gegen CUDAs 18-jährigen Vorsprung:

• Millionen Zeilen optimierter Code
• Tausende trainierte Entwickler
• Tiefe Framework-Integration
• Umfangreiches Tooling

Hardware wechseln heißt oft: Code neu schreiben, Teams umschulen, Workflows ändern.

Für Entwickler und Unternehmen

Wann welche GPU?

RTX 4090 (Consumer)

• Entwicklung und Prototyping
• Finetuning kleiner Modelle
• Inferenz bis ~13B Parameter

A100 (Datacenter, vorherige Gen)

• Gute Verfügbarkeit
• Ausreichend für viele Workloads
• Geringere Kosten als H100

H100 (Datacenter, aktuell)

• Großes Modelltraining
• Höchste Inferenz-Durchsatz
• Wenn Geld keine Rolle spielt

Cloud vs. On-Premise

Cloud-Vorteile:

• Keine Vorabkosten
• Skaliert nach Bedarf
• Neueste Hardware verfügbar

On-Premise-Vorteile:

• Bei hoher Auslastung günstiger
• Volle Kontrolle
• Keine Abhängigkeit

Faustregel: Ab ~50% Auslastung lohnt sich On-Premise.

Ausblick: Blackwell und darüber hinaus

Die B100 (Blackwell) bringt:

• 2× mehr Transistoren
• Deutlich mehr HBM
• NVLink 5.0 mit 1,8 TB/s
• Neue Tensor Core Generation

Der Trend: Mehr Speicher, mehr Bandbreite, mehr Tensor-Performance. Die Grenzen des Moore’schen Gesetzes werden durch Spezialisierung und Packaging-Innovationen (Chiplets, 3D-Stacking) umgangen.

NVIDIA bleibt der Standard – nicht weil die Hardware unschlagbar ist, sondern weil das Ökosystem alternativlos ist. Für die absehbare Zukunft bedeutet “KI entwickeln” in den meisten Fällen “auf NVIDIA entwickeln”.

Quellen

• NVIDIA H100 Tensor Core GPU Architecture
• CUDA C++ Programming Guide
• cuDNN Developer Guide
• NVIDIA DGX Systems
• Dissecting the NVIDIA Hopper GPU Architecture (Chips and Cheese)