GPU Sizing LLM: H100 vs L40S vs A100 2026

Pexon Consulting | 10 Min. Lesezeit | 15.07.2026

TL;DR

GPU Sizing für LLM-Inference heißt: erst VRAM-Bedarf ausrechnen, dann GPU wählen. Faustformel: Parameter mal 2 Byte (FP16) plus KV-Cache plus 15 Prozent Overhead. Ein Llama 3.1 70B braucht in FP16 rund 140 GB, passt nicht auf eine einzelne H100 (80 GB). Wir bei Pexon sizen zwischen L40S, A100 und H100 nach Modellgröße, Batch und Kontext.

Die kurze Antwort: welche GPU für welche Modellgröße

Die kurze Antwort lautet: bis 13B-Modelle in FP16 reicht eine L40S, für 34B in FP8 oder 70B quantisiert nimmst du eine A100 oder zwei L40S, ab 70B in voller Präzision brauchst du zwei H100 oder H200 mit NVLink. Der Fehler, den wir am häufigsten sehen: Teams kaufen H100-Kapazität für Modelle, die auf einer L40S für ein Drittel des Preises laufen würden.

Die GPU-Wahl hängt an genau drei Größen: dem VRAM, den das Modell plus KV-Cache belegt, der Speicherbandbreite (die bei kleinen Batches den Durchsatz limitiert) und dem Preis pro Stunde. Alles andere ist Detail.

Hier die grobe Zuordnung, wie wir sie in Projekten anwenden:

Die Tabelle zeigt Gewichte ohne KV-Cache. Bei langem Kontext oder hoher Batch-Größe kommt der KV-Cache dazu, und der frisst mehr als die meisten denken. Dazu gleich die Formel.

Die VRAM-Faustformel: so rechnest du den Bedarf

Der VRAM-Bedarf setzt sich aus drei Blöcken zusammen: Modellgewichte, KV-Cache und Overhead. Die Gewichte sind der einfache Teil, Parameter mal Byte pro Parameter. In FP16 sind das 2 Byte, in FP8 ein Byte, in INT4 ein halbes. Ein 70B-Modell in FP16: 70 Milliarden mal 2 Byte gleich 140 GB. Der KV-Cache ist der Block, den Teams unterschätzen, weil er mit Kontextlänge und Batch-Größe wächst.

Hier die Formel als lauffähiges Python-Snippet, das wir in unseren Sizing-Sessions nutzen:

# VRAM-Bedarf für LLM-Inference schätzen (Llama 3.1 70B Beispiel)
# Ausgabe in GB. Deckt Gewichte + KV-Cache + Overhead ab.

def vram_bedarf_gb(params_mrd, bytes_pro_param, num_layers,
                   num_kv_heads, head_dim, seq_len, batch_size):
    # Gewichte: Parameter mal Byte pro Parameter
    gewichte = params_mrd * 1e9 * bytes_pro_param

    # KV-Cache: 2 (Key + Value) mal Layer mal KV-Heads mal Head-Dim
    # mal Kontextlänge mal Batch mal 2 Byte (FP16-Cache)
    kv_cache = 2 * num_layers * num_kv_heads * head_dim 
               * seq_len * batch_size * 2

    # 15 Prozent Overhead für Aktivierungen, CUDA-Kontext, Framework
    zwischensumme = gewichte + kv_cache
    gesamt = zwischensumme * 1.15

    return round(gesamt / 1e9, 1)

# Llama 3.1 70B: 80 Layer, 8 KV-Heads (GQA), Head-Dim 128
# 8K Kontext, Batch 8, FP16-Gewichte (2 Byte)
print(vram_bedarf_gb(70, 2, 80, 8, 128, 8192, 8))
# Ergebnis: ca. 185 GB, also zwei H100 mit NVLink nötig

Wichtig: Llama 3.1 70B nutzt Grouped-Query-Attention mit nur 8 KV-Heads statt 64. Das reduziert den KV-Cache um Faktor 8 gegenüber klassischer Multi-Head-Attention. Bei 8K Kontext und Batch 8 landet der Cache bei rund 10 GB, bei 128K Kontext allein schon bei etwa 40 GB. Wer lange Kontexte fährt, sollte den Cache also nicht als Rundungsfehler behandeln.

Unsere Empfehlung: rechne den KV-Cache für deine reale Batch-Größe und Kontextlänge durch, bevor du bestellst. Der Unterschied zwischen 8K und 128K Kontext entscheidet, ob ein 70B-Modell auf zwei GPUs passt oder auf vier.

H100 vs L40S vs A100: die Trade-offs im Detail

Die drei GPUs bedienen unterschiedliche Punkte im Preis-Leistungs-Feld, und keine ist pauschal die beste Wahl. Die H100 hat mit 3.350 GB/s HBM3 die höchste Bandbreite (siehe NVIDIA H100 Datenblatt) und gewinnt bei großen Modellen und hohem Durchsatz. Die A100 liegt mit 2.039 GB/s HBM2e dazwischen und schlägt die L40S bei kleinen Batches, weil Inference dort speicherbandbreiten-limitiert ist. Die L40S nutzt günstigen GDDR6 mit nur 864 GB/s, gewinnt aber bei den Kosten pro Token.

Der zentrale Trade-off zwischen L40S und A100: FP8 auf der Ada-Lovelace-Architektur der L40S gleicht einen Teil des Bandbreiten-Nachteils aus. Ab Batch 8 zieht die L40S in FP8 an der A100 vorbei, weil sie die größere Attention-Matrix schneller rechnet. Bei Batch 1 und langem Kontext gewinnt die A100 durch ihre Bandbreite. Die H100 erreicht mit TensorRT-LLM 250 bis 300 Token pro Sekunde bei Llama 70B, gegenüber rund 130 auf der A100. Das ist der Faktor, für den du den Aufpreis zahlst.

Unsere klare Empfehlung: Wenn du Kosten pro Token minimierst und mit Batching arbeiten kannst, ist die L40S der wirtschaftlichste Weg. Wenn du niedrige Latenz bei Batch 1 brauchst, nimm A100. H100 nur, wenn Durchsatz oder Modellgröße es erzwingen. H100-Kapazität für ein 13B-Modell zu buchen, ist Geldverschwendung.

Wann sich H200 oder B200 lohnen und wann nicht

Die H200 lohnt sich, sobald ein 70B-Modell in voller Präzision auf eine einzelne GPU passen soll. Mit 141 GB HBM3e und 4.800 GB/s Bandbreite läuft sie bei speicher-gebundenen Long-Context-Inferenz-Jobs rund 1,4-mal schneller als die H100 und kostet mit einem Median um 3,95 USD pro Stunde kaum mehr. Der praktische Vorteil ist die Ersparnis an NVLink-Komplexität: ein 70B-Modell auf einer H200 statt zwei H100 spart Multi-GPU-Kommunikations-Overhead.

Die B200 mit 192 GB HBM3e und Blackwell-Architektur liefert das 2- bis 2,5-fache des H200-Durchsatzes, aber die Preise pendeln noch zwischen 7 und 12 USD pro Stunde, und die Software-Reife hinkt hinterher. Für die meisten produktiven Inference-Workloads raten wir aktuell davon ab: Du zahlst einen Aufpreis für Kapazität, die dein Framework-Stack oft noch nicht sauber ausnutzt. Die H200-Verfügbarkeit verbessert sich im zweiten Halbjahr 2026, weil Labore auf Blackwell wechseln und H200-Kapazität freimachen.

Das kennt ihr vermutlich aus eigenen Evaluierungen: Die neueste GPU ist selten die wirtschaftlichste. Wir sehen bei unseren Kunden, dass die Kombination aus richtig quantisiertem Modell und mittlerer GPU fast immer günstiger fährt als das Top-Modell in FP16.

On-Premise oder Cloud: der Verfügbarkeits-Faktor

Die Sizing-Rechnung ändert sich, sobald Verfügbarkeit und Datensouveränität ins Spiel kommen. In der Cloud ist die GPU-Wahl eine Preisfrage pro Stunde. On-Premise wird sie zur Kapitalentscheidung, und dann zählt, wie lange die Hardware im Feld bleibt und wie gut du sie auslastest. Wer regulierte Daten verarbeitet und nicht in die Cloud darf, muss ohnehin lokal sizen.

Für On-Premise-Inference von 70B-Modellen ist die L40S oft die pragmatischste Wahl: zwei Karten in FP8, kein NVLink-Zwang, deutlich günstiger in der Anschaffung als H100. Für hohen Durchsatz mit vielen parallelen Nutzern führt an H100 oder H200 kein Weg vorbei. Wenn die Daten das Land nicht verlassen dürfen, sizen wir den kompletten souverän gehosteten AI-Stack in Deutschland inklusive GPU-Layer. Welche Inference-Engine du dann fährst, entscheidet mit über die reale Auslastung, dazu haben wir den Vergleich SGLang gegen vLLM auf GPU-Kosten geschrieben.

Ein Punkt, den wir immer prüfen: die reale Batch-Größe im Betrieb. Ein Modell, das im Benchmark bei Batch 32 glänzt, läuft im Produktivbetrieb oft bei Batch 1 bis 4, und dann kippt die GPU-Rechnung zugunsten der bandbreiten-starken A100 oder H100. Sizing nach Benchmark-Zahlen statt nach echtem Traffic-Profil ist der teuerste Fehler in diesem Feld.

Häufig gestellte Fragen

Was kostet eine GPU für LLM-Inference im Monat?

Das hängt an GPU-Typ und Auslastung. In der Cloud bei Dauerbetrieb (24/7) landest du bei einer L40S bei etwa 680-1.470 USD pro Monat, bei einer H100 bei rund 2.800 USD. On-Premise ist die Anschaffung höher, rechnet sich aber ab etwa 60 bis 70 Prozent Auslastung gegenüber der Cloud. Wir rechnen das im Sizing pro Use-Case durch, weil die Auslastung der entscheidende Hebel ist.

H100 vs L40S: welche GPU ist besser für LLM-Inference?

Kommt auf die Metrik an. Die H100 liefert mit 250-300 Token pro Sekunde bei Llama 70B rund den doppelten Durchsatz der L40S und hat mehr VRAM. Die L40S gewinnt bei den Kosten pro Token, besonders mit FP8 und Batching. Für Durchsatz und große Modelle: H100. Für maximale Wirtschaftlichkeit: L40S.

Wie viel VRAM braucht ein Llama 3.1 70B Modell?

In FP16 belegen die Gewichte rund 140 GB, das passt nicht auf eine einzelne 80-GB-GPU. Mit KV-Cache und Overhead sind es im Produktivbetrieb schnell über 180 GB, also zwei H100 oder H200 mit NVLink. In FP8 halbiert sich der Bedarf auf etwa 70 GB, dann reicht eine A100 80 GB oder zwei L40S.

Reicht eine L40S für 70B-Modelle?

Nicht in voller Präzision. Eine einzelne L40S mit 48 GB trägt ein 70B-Modell nicht. Mit zwei L40S und FP8-Quantisierung geht es (rund 70 GB Gewichte), das ist für On-Premise-Setups mit moderatem Durchsatz eine wirtschaftliche Option. Für hohen Durchsatz bei 70B ist die L40S aber nicht die richtige Wahl.

Wie berechne ich den KV-Cache für die GPU-Auswahl?

Formel: 2 mal Layer mal KV-Heads mal Head-Dimension mal Kontextlänge mal Batch-Größe mal 2 Byte. Bei Modellen mit Grouped-Query-Attention wie Llama 3.1 70B (8 KV-Heads) ist der Cache achtmal kleiner als bei klassischer Multi-Head-Attention. Rechne ihn für deine reale Kontextlänge durch, bei 128K Kontext sind es allein 40 GB.

Nächster Schritt

Wenn ihr gerade zwischen L40S, A100 und H100 abwägt, macht es keinen Sinn, das im Blindflug zu bestellen. Wir rechnen euer Modell, euren Kontext und euer Traffic-Profil durch und sagen euch, welche GPU-Klasse ihr wirklich braucht.

Verwandte Themen