NVIDIA H200 einrichten: 141 GB VRAM in 12 Schritten [2026]

Eine eigene NVIDIA H200 kaufen kann sich kaum jemand leisten, und das ist auch nicht nötig. Cloud-Anbieter vermieten die Hopper-GPU inzwischen stundenweise, und wer ein 70-Milliarden-Parameter-Modell selbst hosten will, kommt an genau dieser Karte kaum vorbei. Dieses Tutorial zeigt Schritt für Schritt, wie Sie eine H200-Instanz mieten, absichern, mit vLLM 0.31 bestücken und für echte Inferenz-Workloads produktionsreif machen. Am Ende steht eine funktionierende Chat-API, die Sie testen, benchmarken und skalieren können.

Die H200 ist technisch eine Weiterentwicklung der H100 mit mehr Speicher und mehr Bandbreite, aber im Alltag eines Entwicklers macht genau das den Unterschied: Ein 70B-Modell in BF16 passt oft erst mit dem größeren Speicherpuffer komfortabel auf eine einzelne Karte. Wer schon einmal versucht hat, ein großes Modell auf einer H100 mit 80 GB zu quetschen, weiß, wie knapp es werden kann. Mit 141 GB HBM3e hat die H200 deutlich mehr Spielraum, und genau darum geht es in dieser Anleitung.

Dieses Tutorial ist bewusst praxisnah aufgebaut: Jeder Schritt baut auf dem vorherigen auf, von der Instanzauswahl über die Treiberprüfung bis zur fertigen API. Sie brauchen kein eigenes Rechenzentrum und auch keine fünf- oder sechsstellige Investition in eigene GPU-Hardware, sondern mieten die Karte stundenweise bei einem der etablierten Cloud-Anbieter. Das macht die H200 auch für kleinere Teams, Agenturen oder einzelne Entwickler zugänglich, die ein größeres Modell nur für einen Lasttest, einen Proof of Concept oder einen begrenzten Produktionszeitraum brauchen.

Was ist die NVIDIA H200 und wofür eignet sie sich beim KI-Hosting

Die NVIDIA H200 basiert auf der Hopper-Architektur und ist technisch eine Speicher-Erweiterung der H100. Statt klassischem HBM3 setzt NVIDIA bei der H200 auf 141 GB HBM3e mit einer Bandbreite von 4,8 TB/s, dazu kommen 16.896 CUDA-Kerne und 528 Tensor Cores der vierten Generation. Die Karte gibt es als SXM-Modul mit bis zu 700 Watt TDP sowie als PCIe/NVL-Variante mit identischer Speicherausstattung, aber etwas geringerer Rechenleistung und niedrigerem Energiebedarf. Die NVLink-Bandbreite der SXM-Variante liegt bei 900 GB/s.

Bei den Tensor-Core-Werten nennt NVIDIA für FP8 rund 3.958 TFLOPS und für FP16 rund 1.979 TFLOPS, jeweils als Spitzenwert mit aktivierter Sparsity. Das sind Marketing-Peakwerte aus dem Datenblatt, keine garantierte Dauerlast. Für ein reales Inferenz-Setup zählt am Ende, wie viele Tokens pro Sekunde Ihr konkretes Modell mit Ihrer Quantisierung, Batch-Größe und Kontextlänge tatsächlich liefert, und das lässt sich nur mit einem eigenen Benchmark verlässlich bestimmen. Schritt 12 dieser Anleitung zeigt genau, wie das geht.

Für wen lohnt sich die H200 überhaupt? Immer dann, wenn ein Modell zu groß für Consumer-Karten wie die RTX 5090 ist, aber eine Multi-GPU-B200- oder GB200-Flotte wirtschaftlich übertrieben wäre. Typische Kandidaten sind 70B-Dense-Modelle in BF16 oder FP8, mittelgroße MoE-Modelle sowie Teams, die mehrere kleinere Modelle gleichzeitig auf einer Karte mit viel Speicherpuffer betreiben wollen. Wer stattdessen lokal auf eigener Hardware bleiben will, findet in unserem RTX-5090-Tutorial einen Einstieg für kleinere Modelle.

Konkret eignet sich dieses Setup zum Beispiel für ein internes Support-Chatbot-Backend auf Basis eines offenen 70B-Modells, für eine Retrieval-Augmented-Generation-Pipeline mit langem Kontextfenster, für Batch-Zusammenfassungen großer Dokumentenmengen über Nacht oder für die Evaluierung eines neuen Open-Weight-Modells, bevor eine langfristige Infrastrukturentscheidung getroffen wird. In allen vier Fällen zahlt sich die stundenweise Miete aus, weil die tatsächliche Nutzung entweder zeitlich begrenzt ist oder stark schwankt.

Ein weiterer Grund, warum gerade die H200 und nicht nur die neueste Generation im Zentrum dieses Tutorials steht: Verfügbarkeit. Während B200- und GB200-Kapazität bei vielen Anbietern noch knapp und teuer ist, hat sich die H200 seit ihrer breiten Marktverfügbarkeit als solide, gut dokumentierte Mittelklasse-Option für Inferenz etabliert. Treiber, Container-Images und Frameworks wie vLLM sind für die Hopper-Architektur inzwischen gut durchgetestet, was die Fehlersuche im Vergleich zu brandneuer Hardware deutlich erleichtert.

Voraussetzungen: Diese Hardware, Software und Accounts brauchen Sie

Bevor Sie starten, sollten folgende Punkte geklärt sein. Eine gemietete H200 bringt zwar den Treiber meist vorinstalliert mit, trotzdem lohnt sich die Kontrolle jeder einzelnen Komponente, denn Versionskonflikte zwischen Host-Treiber, CUDA-Runtime im Container und Framework-Build sind die häufigste Fehlerquelle in diesem Setup.

• Ein Account bei einem GPU-Cloud-Anbieter mit H200-Verfügbarkeit (z. B. RunPod, Spheron oder CoreWeave)
• Eine hinterlegte Zahlungsmethode, da H200-Instanzen nach Stunden abgerechnet werden
• SSH-Client lokal (unter Windows z. B. über WSL oder PuTTY)
• Docker mit NVIDIA Container Toolkit auf der Instanz (bei den meisten Anbietern vorinstalliert, siehe Schritt 5)
• Python 3.10 oder neuer für die vLLM-Umgebung
• vLLM 0.31.0 (aktuelle Version, Stand Oktober 2026) oder neuer
• Ein Hugging-Face-Account mit Zugriffstoken, falls Sie ein gated Modell wie Llama 3.1 laden möchten
• Mindestens 150 GB freier Festplattenspeicher für Modellgewichte, Cache und Logs

Die Python-Version ist kein Detail, das Sie überspringen sollten: vLLM 0.31.0 setzt auf aktuelle Paketabhängigkeiten auf, die mit sehr alten Python-Interpretern nicht zuverlässig funktionieren. Prüfen Sie deshalb vor der Installation mit python3 --version, welche Version auf der gemieteten Instanz vorinstalliert ist, und legen Sie bei Bedarf über pyenv oder das Paketmanagement Ihrer Distribution eine passende Version an, statt sich auf das System-Python blind zu verlassen.

Zur TensorRT-LLM-Alternative: NVIDIA pflegt das Framework aktiv weiter, allerdings ließ sich zum Redaktionsschluss keine zuverlässig verifizierte aktuelle Versionsnummer für Oktober 2026 bestätigen. Prüfen Sie die tatsächlich installierte Version deshalb immer direkt vor dem produktiven Einsatz selbst, zum Beispiel mit pip index versions tensorrt-llm. Dieses Tutorial konzentriert sich bewusst auf vLLM, weil dessen Versionsstand öffentlich und aktuell nachvollziehbar ist. Das bedeutet nicht, dass TensorRT-LLM die schlechtere Wahl ist, nur dass sich der genaue Versionsstand und die zugehörigen Release-Notes für diesen Artikel nicht mit derselben Verlässlichkeit belegen ließen wie bei vLLM. Wer bereits Erfahrung mit NVIDIA-eigenen Inferenz-Toolchains hat, kann die hier gezeigten Schritte sinngemäß übertragen, muss aber die Kompatibilitätsmatrix aus Treiber, CUDA-Version und Framework-Build jeweils selbst gegen die aktuelle Dokumentation prüfen.

NVIDIA H200 im Datenblatt: Die wichtigsten Spezifikationen

Die folgende Tabelle fasst die offiziellen Eckdaten der H200 SXM zusammen. Die PCIe/NVL-Variante teilt sich Speicherkapazität und Bandbreite, hat aber weniger aktive Kerne und einen niedrigeren Energiebedarf.

Spezifikation	Wert (H200 SXM)
Architektur	NVIDIA Hopper
GPU-Speicher	141 GB HBM3e
Speicherbandbreite	4,8 TB/s
CUDA-Kerne	16.896
Tensor Cores	528 (4. Generation)
FP8-Tensor-Leistung (Peak, Sparsity)	ca. 3.958 TFLOPS
FP16-Tensor-Leistung (Peak, Sparsity)	ca. 1.979 TFLOPS
NVLink-Bandbreite	900 GB/s
TDP	700 W

Wichtig für die Einordnung: Die TFLOPS-Werte in den Zeilen sechs und sieben sind Sparsity-Spitzenwerte aus dem NVIDIA-Datenblatt. In der Praxis erreichen reale Inferenz-Workloads diese Zahlen nicht, da Sparsity-Beschleunigung nur bei bestimmten Matrizenstrukturen greift und reale Modelle, Batchgrößen und Sequenzlängen die effektive Auslastung bestimmen. Im direkten Vergleich zur H100 bleibt die reine Rechenleistung der H200 weitgehend gleich, der entscheidende Unterschied liegt im Speicher: 141 GB statt 80 GB HBM-Kapazität und 4,8 TB/s statt der niedrigeren Bandbreite der H100. Für speicherhungrige Workloads wie lange Kontextfenster oder mehrere gleichzeitig geladene Modelle macht genau dieser Unterschied den Umstieg von H100 auf H200 oft lohnender als eine reine Leistungssteigerung es tun würde.

Schritt 1 bis 2: Cloud-Anbieter vergleichen und H200-Instanz starten

Schritt 1: Anbieter auswählen. H200-Kapazität wird nicht überall gleich angeboten. Manche Anbieter listen reine Spot-Preise, die jederzeit zurückgefordert werden können, andere bieten dedizierte Kapazität mit Mindestlaufzeit. Prüfen Sie vor der Buchung immer Preis, Region, Verfügbarkeit und Billing-Modus gemeinsam, denn ein H200-Preis ist keine feste Zahl, sondern hängt stark von diesen Faktoren ab. Anbieter wie Spheron und RunPod veröffentlichen ihre aktuellen Stundenpreise direkt auf der Produktseite, was den Vergleich erleichtert. Den genauen Preisvergleich finden Sie weiter unten in diesem Artikel.

Schritt 2: Instanz bestellen. Wählen Sie im Dashboard des Anbieters eine H200-SXM- oder H200-NVL-Instanz mit vorinstalliertem Ubuntu-Image und NVIDIA-Treiber. Fast alle Anbieter bieten ein Deploy-Formular, in dem Sie Region, Festplattengröße (mindestens 150 GB empfohlen) und SSH-Key hinterlegen. Nach dem Start dauert es üblicherweise wenige Minuten, bis die Instanz erreichbar ist.

Schritt 3 bis 4: Server absichern und GPU-Status verifizieren

Schritt 3: Per SSH verbinden. Verbinden Sie sich mit dem vom Anbieter bereitgestellten Befehl, üblicherweise mit Ihrem hinterlegten Key:

ssh -i ~/.ssh/id_ed25519 ubuntu@<INSTANZ-IP>

Schritt 4: GPU-Status prüfen. Bevor Sie irgendetwas installieren, verifizieren Sie, dass die Instanz tatsächlich eine vollwertige H200 mit rund 141 GB Speicher liefert und nicht etwa ein kleineres Kontingent oder eine andere Karte:

nvidia-smi --query-gpu=name,driver_version,memory.total --format=csv

Die Ausgabe sollte in etwa so aussehen:

name, driver_version, memory.total [MiB]
NVIDIA H200, 580.XX.XX, 143771 MiB

Zeigt die Ausgabe eine H100, eine partitionierte H200 oder deutlich weniger Speicher als erwartet, ist die gemietete Ressource nicht die volle H200, die Sie bezahlt haben. Melden Sie das umgehend beim Support des Anbieters, statt das Setup fortzusetzen.

Schritt 5 bis 6: Docker und NVIDIA Container Toolkit einrichten

Schritt 5: Container-Zugriff testen. Die meisten Images für vLLM laufen am stabilsten in einem Container mit exakt abgestimmter CUDA-Runtime. Prüfen Sie zuerst, ob Docker die GPU überhaupt sieht:

docker run --rm --gpus all \
  nvidia/cuda:12.8.1-runtime-ubuntu24.04 \
  nvidia-smi

Schritt 6: Laufzeit-Konfiguration prüfen. Erscheint statt der GPU-Ausgabe ein Fehler, ist meist der NVIDIA Container Toolkit nicht korrekt registriert. Kontrollieren Sie die Docker-Runtime:

docker info | grep -i runtime

Mischen Sie an dieser Stelle nicht wahllos Host-CUDA-Bibliotheken mit Container-Bibliotheken, indem Sie LD_LIBRARY_PATH manuell umbiegen. Nutzen Sie stattdessen ein offiziell getestetes NVIDIA-Framework-Image, das zur installierten Treiberversion passt.

Schritt 7 bis 8: Python-Umgebung und vLLM 0.31 installieren

Schritt 7: Virtuelle Umgebung anlegen. Arbeiten Sie nie direkt im System-Python, um Versionskonflikte zu vermeiden:

python3 -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip

Schritt 8: vLLM installieren. Die aktuelle vLLM-Version zum Zeitpunkt dieses Artikels ist 0.31.0, veröffentlicht am 5. Oktober 2026 laut offizieller GitHub-Release-Liste und PyPI-Metadaten. Pinnen Sie die Version für reproduzierbare Deployments immer explizit:

pip install vllm==0.31.0

Halten Sie die gepinnte Version zusätzlich in einer requirements-Datei fest, damit jedes Deployment exakt denselben Stand nutzt:

echo "vllm==0.31.0" >> requirements.txt
pip install -r requirements.txt

NVIDIA selbst veröffentlicht parallel eigene, für seine GPUs abgestimmte vLLM-Container-Releases über die offiziellen Framework-Release-Notes, zuletzt mit einem Eintrag für Ende September/Anfang Oktober 2026. Wer lieber ein von NVIDIA getestetes Image statt der reinen PyPI-Installation nutzen möchte, findet dort die jeweils aktuelle Paarung aus CUDA-Runtime, Treiber und vLLM-Build.

Schritt 9 bis 10: Modell laden und vLLM-Server starten

Schritt 9: Hugging-Face-Zugang einrichten. Für gated Modelle wie Llama 3.1 benötigen Sie ein Token:

huggingface-cli login
# alternativ per Umgebungsvariable:
export HF_TOKEN='ihr_token_hier'

Prüfen Sie vor dem Download den verfügbaren Speicherplatz, 70B-Modelle in BF16 belegen schnell 130 bis 150 GB:

df -h
du -sh ~/.cache/huggingface

Schritt 10: vLLM-Server starten. Mit folgendem Befehl startet vLLM einen OpenAI-kompatiblen API-Server für ein 70B-Modell auf einer einzelnen H200:

vllm serve meta-llama/Meta-Llama-3.1-70B-Instruct \
  --tensor-parallel-size 1 \
  --dtype bfloat16 \
  --gpu-memory-utilization 0.90 \
  --max-model-len 8192 \
  --port 8000

Beim ersten Start lädt vLLM die Gewichte vom Hugging-Face-Hub, baut den KV-Cache auf und meldet nach einigen Minuten, dass der Server unter Port 8000 bereit ist. Lassen Sie den Prozess in einer tmux– oder screen-Session laufen, damit er einen SSH-Verbindungsabbruch überlebt.

Schritt 11 bis 12: API testen und Durchsatz benchmarken

Schritt 11: Erste Anfrage senden. Testen Sie den laufenden Server mit einem einfachen Chat-Request:

curl http://127.0.0.1:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "meta-llama/Meta-Llama-3.1-70B-Instruct",
    "messages": [{"role": "user", "content": "Erklaere HBM3e in zwei Saetzen."}]
  }'

Eine gekürzte Beispielantwort sieht so aus:

{
  "id": "chatcmpl-...",
  "object": "chat.completion",
  "choices": [{
    "message": {"role": "assistant", "content": "HBM3e ist ..."},
    "finish_reason": "stop"
  }],
  "usage": {"prompt_tokens": 14, "completion_tokens": 62, "total_tokens": 76}
}

Entscheidend an dieser Stelle ist nicht nur, dass überhaupt eine Antwort kommt, sondern das finish_reason-Feld und die Werte im usage-Objekt. Ein finish_reason von "length" statt "stop" würde bedeuten, dass die Antwort durch --max-model-len abgeschnitten wurde, nicht weil das Modell inhaltlich fertig war. Die Token-Zahlen im usage-Objekt sind außerdem die Basis für jede spätere Kostenschätzung, da die Abrechnung der GPU-Zeit letztlich über genau diese Durchsatzwerte in Relation zum Stundenpreis gesetzt wird.

Schritt 12: Durchsatz messen. Verzichten Sie bewusst auf fremde, pauschale Tokens-pro-Sekunde-Angaben aus dem Netz, denn der tatsächliche Durchsatz hängt stark von Modell, Quantisierung, Prompt-Länge, Antwortlänge, Nebenläufigkeit und KV-Cache-Konfiguration ab. Messen Sie Ihr eigenes Setup stattdessen direkt mit dem integrierten vLLM-Benchmark-Werkzeug:

vllm bench serve \
  --backend openai-chat \
  --base-url http://127.0.0.1:8000 \
  --endpoint /v1/chat/completions \
  --model meta-llama/Meta-Llama-3.1-70B-Instruct \
  --num-prompts 100

Notieren Sie aus dem Ergebnis mindestens diese Werte, bevor Sie Kapazität planen oder mit anderen Setups vergleichen: Output-Token-Durchsatz, Gesamt-Token-Durchsatz, mediane Inter-Token-Latenz, P95-Latenz, Nebenläufigkeit, Eingabelänge, Ausgabelänge, Datentyp, Quantisierung und Tensor-Parallelism-Grad. Nur mit dieser vollständigen Konfiguration ist ein Benchmark später reproduzierbar und mit anderen Teams vergleichbar.

Mehrere H200-GPUs verbinden: Tensor-Parallelism und NVLink nutzen

Für größere Modelle oder höhere Nebenläufigkeit reicht eine einzelne H200 oft nicht aus. vLLM unterstützt Tensor-Parallelism über mehrere GPUs hinweg, die SXM-Variante der H200 nutzt dafür NVLink mit 900 GB/s Bandbreite zwischen den Karten. Der Start unterscheidet sich nur durch einen Parameter:

vllm serve meta-llama/Meta-Llama-3.1-70B-Instruct \
  --tensor-parallel-size 2 \
  --dtype bfloat16 \
  --gpu-memory-utilization 0.90 \
  --max-model-len 8192 \
  --port 8000

Prüfen Sie vor dem Start die Topologie, damit Sie wissen, ob die GPUs tatsächlich über NVLink statt über den langsameren PCIe-Bus kommunizieren:

nvidia-smi topo -m

Mehr GPUs bedeuten nicht automatisch linear mehr Durchsatz. Kommunikationsoverhead zwischen den Karten, insbesondere bei schlechter Topologie oder deaktiviertem NVLink, kann den Gewinn deutlich schmälern. Wer eine ganze Workstation mit mehreren Karten plant statt gemieteter Cloud-Instanzen, findet dazu in unserem Multi-GPU-Workstation-Tutorial weiterführende Hinweise zur Hardware-Auswahl.

Wann lohnen sich zwei statt einer Karte konkret? Zwei typische Auslöser: Erstens, wenn der KV-Cache bei hoher Nebenläufigkeit (viele parallele Nutzeranfragen) regelmäßig knapp wird, obwohl das Modell selbst gut in 141 GB passt. Zweitens, wenn Sie bewusst eine längere maximale Kontextlänge als die in diesem Tutorial genutzten 8.192 Tokens anbieten wollen, etwa für lange Dokumente oder ausführliche Chat-Verläufe. In beiden Fällen ist der Umweg über eine zweite H200 mit Tensor-Parallelism meist günstiger, als ein kleineres Modell zu wählen und dafür Qualität zu verlieren.

Testen Sie den Umstieg auf zwei Karten aber immer mit demselben Benchmark-Befehl wie zuvor, bevor Sie ihn fest einplanen. Nur so sehen Sie, ob sich die höheren Kosten pro Stunde tatsächlich in mehr Durchsatz oder niedrigerer Latenz niederschlagen, statt sich auf eine pauschale Erwartung zu verlassen.

H200-Cloud oder eigene Hardware: Wann sich Mieten wirklich lohnt

Bevor Sie Geld für Stunden auf einer gemieteten H200 ausgeben, lohnt sich ein kurzer Realitätscheck gegen die Alternative: eigene Hardware. Für kleinere Modelle bis etwa 30 bis 40 Milliarden Parameter in Quantisierung reicht häufig bereits eine einzelne RTX 5090 mit 32 GB VRAM, wie unser separates RTX-5090-Tutorial für lokale KI im Detail zeigt. Für ein 70B-Modell in BF16 oder für den gleichzeitigen Betrieb mehrerer mittelgroßer Modelle wird eine Consumer-Karte dagegen schnell zum Flaschenhals, und genau an dieser Grenze beginnt der wirtschaftliche Vorteil der H200.

Die Rechnung ist denkbar einfach: Eine H200-Karte kostet im Einkauf ein Vielfaches einer Consumer-GPU und braucht zusätzlich passende Server-Infrastruktur, Kühlung und Stromversorgung für bis zu 700 Watt TDP pro Karte. Für einen kurzen Lasttest, eine saisonale Spitze oder ein Projekt mit unklarer Laufzeit ist das Mieten fast immer günstiger als der Kauf. Erst bei einer durchgehenden, mehrjährigen Auslastung einer einzelnen Karte kippt die Rechnung tendenziell in Richtung Eigenbesitz, und selbst dann sprechen Abschreibung, Wartung und das Risiko schnell veraltender Hardware häufig weiterhin für die Cloud-Variante.

Ein Mittelweg, den viele Teams unterschätzen: Mehrere kleine, kurzzeitige H200-Mietphasen für Lasttests und Kapazitätsplanung, kombiniert mit einer kleineren, dauerhaft laufenden Consumer- oder Workstation-GPU für Entwicklung und Staging. So fallen die hohen Stundenpreise nur dann an, wenn tatsächlich produktionsnahe Last simuliert werden muss, während die tägliche Entwicklungsarbeit auf günstigerer Hardware läuft.

Preisvergleich: Was kostet eine H200-Stunde wirklich

Der Mietpreis einer H200 schwankt je nach Anbieter, Region, Kapazitätstyp und Vertragsdauer erheblich. Die folgende Tabelle zeigt reale, im Oktober 2026 veröffentlichte Preispunkte verschiedener Anbieter. Prüfen Sie vor jeder Buchung den aktuellen Stand direkt auf der jeweiligen Anbieterseite, da sich Preise kurzfristig ändern können.

Anbieter	Preis pro Stunde	Kapazitätstyp
Spheron	3,32 $	Spot (jederzeit kündbar)
Spheron	4,80 $	Dediziert, direkt buchbar
RunPod	3,59 $	Community Cloud
RunPod	5,29 $	Secure Cloud
CoreWeave	ca. 6,31 $	On-Demand (vergleichbarer Listenpreis)

Ein breiterer Aggregator-Vergleich listet H200-Kapazität über 19 verschiedene Anbieter hinweg mit Einstiegspreisen ab unter einem Dollar pro Stunde für stark rabattierte Spot-Kapazität, während eine andere Analyse für durchgehenden 24/7-Betrieb über einen Monat je nach Anbieter zwischen rund 2.621 und 7.738 US-Dollar ausweist, ein Faktor von fast drei zwischen dem günstigsten und teuersten geprüften Angebot. Für ein produktives Setup gilt deshalb: Immer Preis, Region, Instanztyp und Abrechnungsmodus gemeinsam dokumentieren, bevor Sie Kosten über mehrere Anbieter hinweg vergleichen, denn eine isolierte Dollarzahl ohne diesen Kontext ist wenig aussagekräftig.

Für Teams in Österreich kommt ein weiterer Punkt dazu, der in reinen Preisvergleichen gern untergeht: die Region der Instanz. Viele Anbieter bieten H200-Kapazität sowohl in US- als auch in EU-Rechenzentren an, oft zu unterschiedlichen Preisen. Wer mit personenbezogenen Daten arbeitet oder aus Datenschutzgründen eine Verarbeitung innerhalb der EU bevorzugt, sollte die Region beim Deploy-Formular aus Schritt 2 bewusst auswählen und nicht dem Standardwert des Anbieters überlassen, auch wenn das mitunter einen leicht höheren Stundenpreis bedeutet.

H200 vs. B200 vs. GB200 NVL72: Lohnt sich der Umstieg

Seit 2026 lassen sich auch Karten mieten, die neuer als die H200 sind, etwa B200- und GB200-Systeme, und erste Software-Unterstützung für NVIDIA-Vera-Rubin-Systeme taucht bereits in Ankündigungen auf. Grundsätzlich bieten diese neueren Generationen mehr Speicher und mehr Rechenleistung pro Karte, vor allem wenn sie als Multi-GPU-NVLink-System wie GB200 NVL72 gemietet werden, allerdings zu einem deutlich höheren Preis als eine einzelne H200. Belastbare, einheitlich verifizierte Oktober-2026-Stundenpreise für B200, GB200 oder B300 ließen sich in der Recherche zu diesem Artikel nicht konsistent über mehrere unabhängige Quellen bestätigen, weshalb wir hier bewusst keine konkrete Dollarzahl nennen. Unseren bestehenden Vergleich zwischen B200 und H200 in einem österreichischen GPU-Cluster finden Sie in einem separaten Artikel auf shattered.io.

Interessant für die Software-Seite: Das vLLM-Projekt kündigte Anfang Oktober 2026 Unterstützung für NVIDIA-Vera-Rubin-NVL72-Systeme an und nennt dabei einen 7,8-fachen Durchsatzvorteil gegenüber einem GB200-NVL72-System, allerdings ausschließlich in einer spezifischen AgentX-Evaluierung. Diese Zahl ist kein allgemeiner Maßstab für jedes Modell oder jede Workload und sollte nicht unreflektiert auf andere Szenarien übertragen werden. Für die meisten Teams, die ein einzelnes 70B-Modell hosten wollen, bleibt eine einzelne H200 oder ein Zweier-NVLink-Paar wirtschaftlich sinnvoller als der Einstieg in eine komplette GB200-Flotte.

Praktisch heißt das: Prüfen Sie zuerst, ob Ihr Modell überhaupt in 141 GB passt und ob eine oder zwei H200-Karten für Ihre erwartete Nebenläufigkeit reichen. Erst wenn Sie im eigenen Benchmark an eine harte Kapazitätsgrenze stoßen, lohnt sich der Blick auf die nächste Hardware-Generation.

Ein weiterer Aspekt, der bei der Entscheidung oft zu kurz kommt: Software-Reife. Die H200 läuft seit längerer Zeit produktiv bei zahlreichen Anbietern, entsprechend ausgereift sind Treiber, Container-Images und Framework-Support. Bei brandneuer Hardware wie B200, GB200 oder den ersten Vera-Rubin-Systemen ist dagegen damit zu rechnen, dass einzelne Kernel-Optimierungen, Quantisierungs-Pfade oder Multi-Node-Features noch nachgezogen werden. Für ein Team, das primär stabilen Produktionsbetrieb statt Bestenlisten-Performance sucht, ist dieser Reifegrad oft wichtiger als ein paar Prozentpunkte zusätzlicher theoretischer Rechenleistung.

Komplettes Beispielprojekt: Eigene Chat-API mit Llama-3.1-70B

Nach den zwölf Schritten haben Sie bereits einen funktionierenden, manuell gestarteten vLLM-Server. Für ein reproduzierbares, neu startbares Deployment lohnt sich zusätzlich ein kleines Docker-Compose-Setup, das alle bisherigen Parameter an einem Ort bündelt und bei einem Neustart der Instanz mit einem einzigen Befehl wieder hochfährt, statt jeden Schritt händisch zu wiederholen. Legen Sie dazu folgende Datei an:

# docker-compose.yml
services:
  vllm-server:
    image: vllm/vllm-openai:v0.31.0
    runtime: nvidia
    environment:
      - HF_TOKEN=${HF_TOKEN}
      - NCCL_IB_DISABLE=1
    ports:
      - "8000:8000"
    volumes:
      - ./cache:/root/.cache/huggingface
    command: >
      --model meta-llama/Meta-Llama-3.1-70B-Instruct
      --tensor-parallel-size 1
      --dtype bfloat16
      --gpu-memory-utilization 0.90
      --max-model-len 8192
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]

Starten Sie den Stack anschließend mit:

export HF_TOKEN='ihr_token_hier'
docker compose up -d
docker compose logs -f vllm-server

Dieses Setup startet den vLLM-Server containerisiert, bindet den Hugging-Face-Cache persistent ein, damit Modellgewichte bei einem Neustart nicht erneut heruntergeladen werden müssen, und deaktiviert InfiniBand-spezifische NCCL-Features für den Single-Node-Betrieb. Für einen Mehrknoten-Betrieb mit echtem InfiniBand entfernen Sie die NCCL_IB_DISABLE-Zeile wieder, nachdem Sie die Netzwerkanbindung des Anbieters geprüft haben. Ergänzen Sie den Stack bei Bedarf um einen Reverse-Proxy mit TLS-Terminierung und eine einfache Authentifizierung, bevor Sie den Port 8000 öffentlich erreichbar machen, wie im Abschnitt zur Absicherung der API weiter unten beschrieben.

Damit ist das Projekt vollständig: eine gemietete H200-Instanz mit verifiziertem Treiber, ein containerisiertes vLLM-Deployment mit gepinnter Version, ein getestetes 70B-Modell hinter einer OpenAI-kompatiblen API und ein eigener Benchmark Ihrer tatsächlichen Durchsatzwerte. Von hier aus lässt sich der Stack beliebig erweitern, etwa um ein zweites Modell auf derselben Karte, ein Monitoring-Dashboard oder eine Anbindung an eine bestehende Anwendung.

Häufige Fallen beim H200-Setup

Diese Stolperfallen tauchen in der Praxis immer wieder auf, meist weil Annahmen aus dem H100- oder Consumer-GPU-Umfeld unreflektiert übernommen werden. Wer die folgenden Punkte vor dem ersten produktiven Deployment einmal bewusst durchgeht, erspart sich im Schnitt die meisten der teuren, schwer nachvollziehbaren Fehler, die sich erst nach Stunden im Betrieb zeigen.

• H100-Annahmen 1:1 übernehmen: Die H200 teilt sich die Hopper-Architektur mit der H100, aber Treiber-Matrix, Container-Image und CUDA-Runtime sollten trotzdem für jedes Setup einzeln gegen die offizielle Kompatibilitätsliste geprüft werden, statt alte H100-Konfigurationen blind zu übernehmen.
• vLLM-Version nicht pinnen: Wer pip install vllm ohne Versionsangabe nutzt, bekommt bei jedem Neuaufbau potenziell eine andere Version mit anderem Verhalten. Das macht Benchmarks und Fehlersuche fast unmöglich nachvollziehbar.
• Spot-Kapazität für Produktion nutzen: Spot-Instanzen wie bei Spheron oder RunPod Community Cloud können jederzeit zurückgefordert werden. Für produktive Dienste ohne Failover ist das ein vermeidbares Risiko.
• Datenblatt-TFLOPS mit realem Durchsatz verwechseln: Die Sparsity-Peakwerte aus dem Datenblatt sagen wenig über die Tokens pro Sekunde Ihres konkreten Modells aus. Nur ein eigener Benchmark mit vllm bench serve liefert belastbare Zahlen.
• Netzwerk- und Egress-Kosten ignorieren: Beim Vergleich mehrerer Anbieter wird oft nur der GPU-Stundenpreis verglichen, während Datenübertragung, Speicher und IP-Adressen separat abgerechnet werden können.
• Mehrere GPUs ohne Topologie-Check verbinden: Tensor-Parallelism über mehrere Karten bringt nur dann den erwarteten Geschwindigkeitsvorteil, wenn die Karten tatsächlich über NVLink statt über einen langsameren PCIe-Pfad kommunizieren.
• Die API ungeschützt im Internet exponieren: Ein vLLM-Server ohne vorgeschalteten Reverse-Proxy und ohne Authentifizierung ist für jeden erreichbar, der die IP-Adresse kennt. Das kann sowohl zu unerwarteten Kosten als auch zu einem Datenschutzproblem werden, wenn über die API sensible Inhalte verarbeitet werden.

Troubleshooting: Die häufigsten Fehlermeldungen und Lösungen

Die folgende Tabelle sammelt die Fehlerbilder, die beim H200-Setup mit vLLM am häufigsten gemeldet werden, zusammen mit der jeweils ersten sinnvollen Diagnosemaßnahme.

Fehlerbild	Wahrscheinliche Ursache	Erste Maßnahme
CUDA out of memory	Zu lange Kontextlänge, zu großer KV-Cache oder ungewollt BF16 statt Quantisierung geladen	--gpu-memory-utilization, --max-model-len und --max-num-seqs reduzieren
CUDA driver version is insufficient	Host-Treiber zu alt für die CUDA-Runtime im Container	nvidia-smi auf Host und im Container getrennt prüfen
No kernel image is available for execution	Framework-Build passt nicht zur installierten CUDA-Version	Offizielles, getestetes NVIDIA-Framework-Image statt eigenem Mix verwenden
Could not select device driver with capabilities gpu	NVIDIA Container Toolkit nicht korrekt registriert	docker info | grep -i runtime prüfen, Toolkit neu installieren
NCCL-Fehler beim Multi-GPU-Start	Falsche Tensor-Parallelism-Größe, blockiertes Inter-GPU-Netzwerk oder NCCL-Versionskonflikt	NCCL_DEBUG=INFO setzen, Topologie mit nvidia-smi topo -m prüfen
Hängender Download bei gated Modellen	Fehlendes oder abgelaufenes Hugging-Face-Token	huggingface-cli login erneut ausführen oder HF_TOKEN neu setzen
Download bricht wegen Speicherplatz ab	Festplatte zu klein für 70B-Gewichte plus Cache	df -h und du -sh ~/.cache/huggingface prüfen, Volume vergrößern
nvidia-smi zeigt weniger als 141 GB	Instanz ist keine vollwertige H200 oder nur partitioniert	Beim Anbieter-Support reklamieren, bevor weitere Zeit investiert wird
API antwortet nicht auf Port 8000	Server noch beim Laden der Gewichte oder Port durch Firewall blockiert	Server-Logs mit docker compose logs -f prüfen, Firewall-Regeln kontrollieren

Ein gemeinsames Muster hinter fast allen neun Fehlerbildern: Die Ursache liegt selten in der H200-Hardware selbst, sondern fast immer in einer Versionsinkompatibilität zwischen Host-Treiber, Container-Image, Framework-Build oder Netzwerk-Konfiguration. Wer bei jedem Fehler zuerst nvidia-smi auf Host und im Container getrennt prüft und erst danach tiefer in Logs und Umgebungsvariablen einsteigt, findet die Ursache in den meisten Fällen innerhalb weniger Minuten statt Stunden.

Fortgeschrittene Tipps für den Produktionsbetrieb

Sobald das Grundsetup läuft, lohnen sich einige Optimierungen, die über die reine Inbetriebnahme hinausgehen.

Quantisierung gezielt einsetzen: Statt BF16 für das gesamte Modell zu nutzen, kann FP8-Quantisierung den Speicherbedarf senken und mehr Spielraum für größere Batches oder längere Kontexte schaffen. Testen Sie vor dem produktiven Einsatz aber immer die Qualität der Modellausgaben, denn Quantisierung ist kein Freifahrtschein ohne Qualitätsverlust.

Laufende GPU-Last beobachten: Lassen Sie während eines Lasttests parallel ein Monitoring-Fenster offen, um Speicherdruck frühzeitig zu erkennen, bevor ein Out-of-Memory-Fehler den laufenden Dienst beendet:

watch -n 1 nvidia-smi

Checkpoints und Persistenz einplanen: Wer auf Spot-Kapazität setzt, sollte Modellgewichte und Caches auf einem persistenten Volume halten, damit ein unerwarteter Reclaim der Instanz nicht zu einem kompletten Neustart samt erneutem Download führt.

Kapazitätsplanung über Benchmarks statt Bauchgefühl: Führen Sie vllm bench serve mit realistischer Nebenläufigkeit und realistischen Prompt-Längen aus Ihrem tatsächlichen Anwendungsfall aus, nicht mit künstlich kurzen Testprompts. Nur so lässt sich abschätzen, wie viele gleichzeitige Nutzer eine einzelne H200 tatsächlich bedienen kann.

Software-Matrix dokumentieren: Halten Sie GPU-Modell, Treiberversion, CUDA-Runtime, Container-Image, vLLM-Version, PyTorch-Version, NCCL-Version und Modell-Revision schriftlich fest. Das erspart bei jedem Debugging-Vorgang Monate später wertvolle Zeit.

Aufmerksamkeits-Kernel aktuell halten: vLLM nutzt je nach Version und Hardware unterschiedliche FlashAttention- oder FlashInfer-Kernel für die Aufmerksamkeitsberechnung. Ein veralteter Kernel kann unnötig viel Speicher binden oder langsamer laufen als nötig. Prüfen Sie nach jedem vLLM-Update das Changelog auf Kernel-bezogene Änderungen, bevor Sie einen bestehenden Produktions-Benchmark als weiterhin gültig annehmen.

Autoscaling realistisch einplanen: Da eine H200-Instanz pro Stunde abgerechnet wird, lohnt sich bei stark schwankender Last eine Trennung zwischen einer dauerhaft laufenden Basiskapazität und zusätzlichen, bei Bedarf hochgefahrenen Instanzen. Der Start einer neuen Instanz inklusive Modell-Download dauert jedoch mehrere Minuten, weshalb reines Autoscaling nach Anfragevolumen für sehr kurzfristige Lastspitzen ungeeignet ist und besser mit einer kleinen, immer verfügbaren Pufferkapazität kombiniert wird.

Kostenkontrolle: So vermeiden Sie böse Überraschungen auf der Rechnung

H200-Instanzen werden pro Stunde abgerechnet, auch wenn der Server nur im Leerlauf läuft. Ein vergessener Testserver kann über ein Wochenende schnell dreistellige Dollarbeträge verursachen. Richten Sie deshalb, wo der Anbieter es unterstützt, automatische Abschaltungen oder Budget-Alarme ein, und prüfen Sie regelmäßig das Dashboard auf laufende Instanzen. Gerade bei Spot-Kapazität lohnt sich außerdem ein Blick auf die Reclaim-Historie des Anbieters, bevor Sie einen längeren Trainings- oder Benchmark-Lauf darauf aufbauen.

Ein weiterer Punkt, der in Preisvergleichen oft untergeht: Dedizierte Kapazität ist zwar teurer pro Stunde, aber planbarer. Wer production-kritische APIs betreibt, sollte diesen Aufschlag eher als Versicherung gegen einen plötzlichen Kapazitätsverlust verstehen als als reine Mehrkosten.

Legen Sie sich außerdem früh eine einfache Kostenregel zurecht, etwa ein festes Tagesbudget pro Umgebung (Entwicklung, Staging, Produktion) und eine Eskalationsregel, wer benachrichtigt wird, wenn dieses Budget überschritten wird. Gerade in kleineren Teams ohne dediziertes FinOps-Tooling ist eine solche einfache, schriftlich festgehaltene Regel oft wirksamer als ein kompliziertes Dashboard, das am Ende niemand regelmäßig prüft.

Die API absichern, bevor sie öffentlich erreichbar ist

Der vLLM-Server aus Schritt 10 lauscht standardmäßig ohne Authentifizierung auf Port 8000. Das ist für lokale Tests völlig in Ordnung, aber sobald die Instanz eine öffentliche IP-Adresse hat, sollte dieser Port niemals ungeschützt ins Internet zeigen. Jeder, der die Adresse kennt oder findet, könnte sonst auf Ihre Kosten Inferenz-Anfragen stellen oder im schlimmsten Fall sensible Prompts und Antworten mitlesen, falls die Verbindung unverschlüsselt läuft.

Zwei Maßnahmen sind hier Pflicht statt Kür. Erstens: Firewall-Regeln auf der Instanz so setzen, dass Port 8000 nur aus dem eigenen Netzwerk oder über eine VPN-Verbindung erreichbar ist, nicht aus dem offenen Internet. Zweitens: Einen Reverse-Proxy mit TLS-Terminierung und einer einfachen Token-Prüfung vorschalten, statt vLLM direkt zu exponieren. So verschlüsseln Sie die Verbindung zwischen Client und Server, statt Anfragen und Modellantworten unverschlüsselt über das Internet zu schicken, und verhindern gleichzeitig, dass Unbefugte den Endpunkt überhaupt erreichen können. Ein minimaler Nginx-Baustein für die Token-Prüfung sieht so aus:

location /v1/ {
    if ($http_authorization != "Bearer IHR_GEHEIMES_TOKEN") {
        return 401;
    }
    proxy_pass http://127.0.0.1:8000;
}

Für produktive Deployments reicht ein einzelnes statisches Token meist nicht aus. Planen Sie stattdessen ein echtes API-Gateway mit Rate Limiting pro Nutzer ein, damit ein einzelner fehlerhafter Client nicht die gesamte H200 mit Anfragen blockieren kann und Ihnen eine unerwartet hohe Stundenrechnung verursacht. Loggen Sie zusätzlich Anfragevolumen und Fehlerraten getrennt vom eigentlichen Modell-Output, damit Sie Missbrauch oder einen fehlerhaften Client schnell erkennen, ohne sensible Prompt-Inhalte dauerhaft zu speichern.

Noch ein praktischer Hinweis zum Umgang mit Zugangsdaten: Sowohl das Hugging-Face-Token aus Schritt 9 als auch ein eigenes API-Token für den Reverse-Proxy sollten niemals direkt im Docker-Compose-File oder im Shell-Verlauf landen. Nutzen Sie stattdessen eine separate, nicht versionierte .env-Datei oder den Secrets-Mechanismus Ihres Cloud-Anbieters, und schließen Sie diese Datei explizit in .gitignore aus, falls Sie das Projekt in einem Repository versionieren.

Häufig gestellte Fragen zur NVIDIA H200

Wie viel Speicher hat die NVIDIA H200 genau?
Die H200 verfügt über 141 GB HBM3e-Speicher mit einer Bandbreite von 4,8 TB/s, unabhängig davon, ob Sie die SXM- oder die PCIe/NVL-Variante mieten. Das sind rund 61 GB mehr als bei der H100 mit 80 GB, was in der Praxis oft über den Unterschied zwischen knappem Mitschwimmen und komfortablem Betrieb eines großen Modells entscheidet.

Reicht eine einzelne H200 für ein 70B-Modell?
In der Regel ja, solange Sie BF16 oder eine Quantisierung mit moderater Kontextlänge nutzen. Bei sehr langen Kontexten oder hoher Nebenläufigkeit kann der KV-Cache knapp werden, dann hilft Tensor-Parallelism über zwei Karten.

Was kostet eine H200-Instanz pro Stunde?
Im Oktober 2026 lagen verifizierte Preispunkte zwischen rund 3,32 US-Dollar für Spot-Kapazität bei Spheron und rund 6,31 US-Dollar für On-Demand-Kapazität bei CoreWeave. Prüfen Sie den aktuellen Preis vor jeder Buchung direkt beim Anbieter.

Brauche ich vLLM oder TensorRT-LLM?
vLLM ist einfacher einzurichten, gut dokumentiert und wird sehr aktiv weiterentwickelt, zuletzt mit Version 0.31.0 Anfang Oktober 2026. TensorRT-LLM kann in manchen Szenarien mehr Performance aus der Hardware holen, erfordert aber mehr Einarbeitung. Für den Einstieg ist vLLM die pragmatischere Wahl.

Lohnt sich B200 oder GB200 statt H200?
Nur wenn Sie im eigenen Benchmark tatsächlich an eine Kapazitätsgrenze der H200 stoßen. Neuere Karten bieten mehr Speicher und Rechenleistung, kosten aber auch deutlich mehr, und verlässliche Oktober-2026-Preise waren zum Redaktionsschluss nicht einheitlich verifizierbar.

Welcher NVIDIA-Treiber wird für die H200 benötigt?
Es gibt keine einzelne feste Mindestversion, die für jedes Setup gilt. Nutzen Sie den vom Anbieter vorinstallierten, getesteten Treiber und prüfen Sie Kompatibilität mit nvidia-smi sowie nvcc --version, statt eine Version aus einer Anleitung blind zu übernehmen.

Was mache ich bei einem Out-of-Memory-Fehler?
Reduzieren Sie zuerst --max-model-len und --max-num-seqs, prüfen Sie dann --gpu-memory-utilization, und erwägen Sie bei weiterhin knappem Speicher Tensor-Parallelism über eine zweite Karte oder eine Quantisierung des Modells. Beobachten Sie dabei parallel mit watch -n 1 nvidia-smi, welcher Parameter den größten Effekt auf den freien Speicher hat, statt mehrere Einstellungen gleichzeitig zu ändern.

Kann ich die H200 auch für Training statt nur Inferenz nutzen?
Technisch ja, dieses Tutorial konzentriert sich aber bewusst auf Inferenz-Workloads mit vLLM, da das der häufigste Anwendungsfall für gemietete Einzelkarten-Instanzen ist. Für Training sind andere Speicher- und Checkpoint-Strategien nötig.