Wenn ein Kunde fragt „welche GPU für ein lokales LLM", meint er meist eine einzige Frage: Passt das Modell, das ich nutzen will, rein? Die Antwort hängt von drei Zahlen ab — Größe der Modellgewichte, Größe des KV-Cache beim gewählten Kontext und der Overhead des Frameworks. Alle drei lassen sich im Voraus berechnen. Trotzdem läuft die Mehrzahl der Hardware-Entscheidungen auf Schätzungen hinaus, mit dem Ergebnis: entweder ein unnötig teurer Server oder einer, der nicht ausreicht.
Dieser Artikel liefert konkrete Zahlen: wie viel VRAM ein 7B-, 13B-, 34B- und 70B-Modell bei verschiedenen Quantisierungsformaten tatsächlich belegt, was auf eine 24-GB- / 48-GB- / 80-GB-Karte passt, und wann Multi-GPU sinnvoll ist.
Grundformel: Modellgewichte
Die einfachste VRAM-Schätzung für die Gewichte allein:
VRAM (GB) ≈ (Parameteranzahl in Milliarden × Bittiefe) / 8Beispiele: - 7B-Modell, FP16 (16 Bit): 7 × 16 / 8 = 14 GB (in der Praxis mit Overhead ~16–18 GB) - 7B-Modell, Q4_K_M (4 Bit): 7 × 4 / 8 = 3,5 GB — in der Praxis wegen Overhead etwa 5–7 GB - 70B-Modell, FP16: 70 × 16 / 8 = 140 GB - 70B-Modell, Q4_K_M: 70 × 4 / 8 = 35 GB — in der Praxis etwa 38–40 GB
Die Gewichtsformel ist nur der Ausgangspunkt. Darüber hinaus kommen stets KV-Cache, Overhead des Serving-Frameworks und bei Quantisierung zusätzlich Dequantisierungs-Buffer hinzu.
Was ist der KV-Cache und warum ist er wichtig
Während der Inferenz generiert das Modell Token für Token. Um für jedes neue Token nicht die gesamte Sequenz neu berechnen zu müssen, speichert es Zwischenergebnisse — sogenannte Key-Value-Paare für jede Attention-Schicht. Diese Zwischenergebnisse bilden den KV-Cache.
Der KV-Cache wächst linear mit der Sequenzlänge. Bei produktiven Deployments mit parallelen Requests wird er schnell genauso problematisch wie die Gewichte selbst.
Orientierungswerte für den KV-Cache-Bedarf gängiger Modelle:
- 7B-Modell, 8K Kontext, 1 paralleler Request: ~1–2 GB
- 7B-Modell, 32K Kontext, 4 parallele Requests: ~8–16 GB
- 70B-Modell, 32K Kontext, 1 Request: ~8–12 GB
- 70B-Modell, 128K Kontext, 1 Request: ~40 GB
Die genauen Zahlen hängen von der Anzahl der Attention-Schichten, der Anzahl der Heads und Gruppen ab (moderne Modelle verwenden Grouped Query Attention, GQA, das den KV-Cache im Vergleich zum älteren Multi-Head Attention dramatisch reduziert). Jedes Modell hat einen anderen Multiplikator — überprüfen Sie die Konfigurationsdatei des Modells (config.json im HuggingFace-Repository), bevor Sie Hardware auswählen.
Praktische Konsequenz: Wenn Sie lange Kontexte oder mehr parallele Nutzer planen, entscheidet der KV-Cache genauso wie die Gewichte. Das ist kein technisches Detail — es ist die primäre Ursache für OOM-Fehler beim Deployment.
Was auf 24 GB passt (RTX 4090, L4)
24 GB ist der häufigste Tier für On-prem-Entwicklungs- und kleinere Produktions-Deployments.
Was problemlos passt: - 7B FP16 — Gewichte ~16–18 GB, Rest für KV-Cache (~6 GB) reicht für mittlere Kontexte (8–16K) mit wenigen parallelen Requests - 7B Q8_0 — Gewichte ~8–9 GB, KV-Cache hat auch bei 32K Kontext ausreichend Platz - 13B Q4_K_M — Gewichte ~8 GB, KV-Cache bei 8K mit viel Spielraum - 13B Q8_0 — Gewichte ~14 GB, enger, passt aber bei kürzeren Kontexten
Was nicht passt: - 13B FP16 — Gewichte ~26 GB, überschreitet die Kapazität - 34B in jedem gängigen Format — selbst bei Q4 passen Gewichte (~17–20 GB) + KV-Cache bei realer Arbeitslast nicht in 24 GB
Für eine 24-GB-Karte ist Q4_K_M bei 13B-Modellen praktisch Standard; bei 7B haben Sie die Freiheit, je nach benötigtem Kontext Q8 oder FP16 zu wählen.
Was auf 48 GB passt (RTX 6000 Ada, A40, L40S)
48 GB eröffnet sinnvollen Spielraum für größere Modelle.
Was gut funktioniert: - 13B FP16 — passt problemlos, Rest für KV-Cache reicht bei 16–32K Kontext - 34B Q4_K_M — Gewichte ~17–20 GB, ausreichend für produktiven KV-Cache - 34B Q8_0 — Gewichte ~30–34 GB, eng, aber bei kürzeren Kontexten funktional - 70B Q4_K_M — Gewichte ~38–40 GB, Rest für KV-Cache (~6–10 GB) begrenzt auf kurze Kontexte (4–8K) oder 1 parallelen Request
Was nicht ideal ist: - 70B FP16 — 140 GB, dreifache Kapazität - 70B Q8_0 — ~70–75 GB, überschreitet immer noch
Eine 48-GB-Karte kann ein 70B-Modell in Q4_K_M bedienen, aber mit eingeschränktem Kontext. Für die meisten B2B-Use-Cases — RAG über Dokumente, Klassifizierung, strukturierte Extraktion — reicht ein kürzerer Kontext (bis 8K) aus.
Was auf 80 GB passt (A100, H100, H200)
80 GB ist der Tier, auf dem die meisten Produktions-Deployments von 70B-Modellen ohne Kompromisse laufen.
- 70B FP16 — Gewichte ~140 GB, passt auch hier nicht. Sie brauchen mindestens zwei Karten.
- 70B Q8_0 — Gewichte ~70–75 GB, passt rein, es bleiben ~5–10 GB für KV-Cache — begrenzt auf sehr kurze Kontexte oder 1 Request
- 70B Q4_K_M — Gewichte ~38–40 GB, Rest ~38–40 GB für KV-Cache — komfortabel für 32K Kontext, 2–4 parallele Requests
- 34B FP16 — Gewichte ~54–68 GB, passt mit ordentlichem KV-Cache-Spielraum
Auf einem H100 80GB mit 70B Q4_K_M und vLLM oder SGLang erhalten Sie produktionsfähiges Serving mit einem Durchsatz, der für Dutzende paralleler Nutzer geeignet ist.
Quantisierung: wo man spart ohne Qualitätsverlust
Quantisierung reduziert die Präzision der Gewichte (von FP16/BF16 auf INT8, INT4 usw.) gegen einen kleineren VRAM-Footprint und schnellere Inferenz. Die Frage ist nicht „ob quantisieren" — sondern wo Qualität verloren geht und wo nicht.
Orientierungswerte zur Qualitätserhaltung gegenüber FP16:
- Q8_0 (GGUF): ~98–99 % — kaum unterscheidbar. Standardwahl, wenn ausreichend VRAM vorhanden ist.
- Q4_K_M (GGUF): ~92–95 % — der Sweet Spot. Die meisten B2B-Use-Cases (RAG, Klassifizierung, Extraktion, Dokumentenanalyse) werden keinen Unterschied bemerken.
- AWQ 4-bit: ~93–96 % — geringfügig besser für Textkohärenz und Code. Erfordert NVIDIA-GPU, integriert sich sauber mit
vLLM. - GPTQ 4-bit: ~90–93 % — maximaler Durchsatz auf dem NVIDIA-Stack, etwas niedrigere Qualität als AWQ.
- Q2 (GGUF): deutliche Degradierung — spürbar bei komplexem Reasoning, langen Generierungen, mehrsprachigen Texten.
Der Perplexitätsunterschied zwischen Q4 und BF16 liegt über Benchmarks hinweg unter 6 %. Für die meisten industriellen Use-Cases ist das vernachlässigbar. Qualitätsverluste treten auf, wenn das Modell präzises mehrstufiges Reasoning benötigt oder lange zusammenhängende Texte generiert — dort verliert Q4 manchmal den Faden gegenüber Q8.
Detaillierte Informationen zu Quantisierungsformaten, ihren Unterschieden und Anwendungsfällen finden Sie in der Übersicht zu GGUF-, AWQ- und GPTQ-Quantisierung.
Multi-GPU: wann und wie
Wenn das Modell auf eine Karte nicht passt, haben Sie zwei Möglichkeiten: quantisieren oder GPU hinzufügen. Manchmal brauchen Sie beides.
Tensor Parallelism — das Modell wird schichtweise (oder nach Attention-Heads) auf mehrere GPUs aufgeteilt. vLLM und SGLang beherrschen das nativ. Mit zwei A100 80GB erhalten Sie effektiv 160 GB VRAM und können 70B FP16 bedienen.
Pipeline Parallelism — verschiedene Modellblöcke laufen sequenziell auf verschiedenen GPUs. Weniger effizient als Tensor Parallelism (Idle-Zeit beim Übergang zwischen Karten), funktioniert aber auch auf Karten ohne NVLink.
Praktische Empfehlungen: - 2× RTX 4090 (2× 24 GB = 48 GB): 34B Q4_K_M komfortabel, 70B Q4_K_M knapp — passt rein, KV-Cache eingeschränkt - 2× A100 80 GB (2× 80 GB = 160 GB): 70B FP16 ohne Kompromisse, 70B Q8_0 mit reichlich KV-Cache - NVLink zwischen den Karten reduziert den Kommunikations-Overhead bei Tensor Parallelism deutlich — für Produktions-Deployments Karten mit NVLink-Unterstützung bevorzugen (A100, H100, RTX 6000 Ada)
Die meisten Consumer-GPUs (RTX 4090) haben kein NVLink — sie kommunizieren über PCIe, was die Latenz bei Multi-GPU-Aufteilung erhöht. Für Entwicklungszwecke reicht das aus, für Produktion mit niedrigen Latenzen zahlt sich die Investition in Workstation-Class-GPUs aus.
Overhead des Serving-Frameworks
Über Gewichte und KV-Cache hinaus kommt der Overhead der Serving-Lösung selbst. vLLM verwendet PagedAttention — verwaltet den KV-Cache in Seiten wie ein Betriebssystem den Arbeitsspeicher, was Fragmentierung von typischerweise 60–80 % Verschwendung auf unter 4 % reduziert. Planen Sie dennoch zusätzlich ein:
- `vLLM`-Overhead: typischerweise 1–3 GB extra für Aktivierungs-Buffer, Prefetch und Scheduling
- `SGLang`-Overhead: vergleichbar mit vLLM, zusätzlich RadixAttention-Baum für Prefix-Caching
Faustformel: Kalkulieren Sie ~10–15 % Reserve über den geschätzten Gewichten + KV-Cache. Für eine 24-GB-Karte bedeutet das: auf ~20–22 GB effektive Auslastung zielen, nicht auf 24 GB.
Im Gegensatz zu Produktions-Frameworks verwendet Ollama unter der Haube llama.cpp — exzellent für den Entwickler-Desktop und Single-User-Experimente, aber nicht für parallele Requests ausgelegt. Bei 8 parallelen Nutzern ist vLLM deutlich schneller (ca. 2–3×). Mehr zu den Unterschieden zwischen Serving-Lösungen finden Sie im Vergleich vLLM vs. SGLang vs. Ollama.
Praktische Referenz: was wofür
Zusammenfassung für gängige Szenarien:
Entwickler-Workstation, Einzelnutzer: - 7B–13B-Modelle, kurzer Kontext → 1× RTX 4090 (24 GB) mit Q4_K_M oder Q8_0 - 34B-Modell → 2× RTX 4090 oder 1× RTX 6000 Ada (48 GB) mit Q4_K_M
Produktionsserver, 5–20 parallele Nutzer: - 7B FP16 oder Q8_0 → 1× A40 oder L40S (48 GB) - 13B–34B Q4_K_M → 1× A40 oder L40S - 70B Q4_K_M mit kurzem Kontext → 1× A100 80 GB oder H100 80 GB - 70B Q4_K_M mit langem Kontext, höherer Durchsatz → 2× A100 oder 2× H100
On-prem Enterprise, regulierte Branche: - Qualität ohne Kompromisse → 70B Q8_0 oder FP16 → 2× H100 80 GB (NVLink) - Wenn On-prem für Ihren Use-Case aus DSGVO- und Kostensicht sinnvoll ist, lesen Sie auch On-prem LLM für regulierte Branchen
Für jede dieser Entscheidungen gilt: Rechenkapazität ist nur eine Seite der Gleichung. Genauso wichtig ist, was Sie vom Modell erwarten — und was das Modell leisten könnte, wenn es auf Ihre Daten richtig fine-tuned wäre. Wann eine größere GPU sinnvoller ist und wann stattdessen ein kleineres, fine-getuntes Modell, behandelt der Artikel kleines fine-getuntes vs. großes Basismodell.
Häufige Fragen
Passt ein 70B-Modell auf eine RTX 4090?
Nicht sinnvoll. Die RTX 4090 hat 24 GB VRAM. Die Gewichte eines 70B-Modells in Q4_K_M belegen etwa 38–40 GB — das ist fast das Doppelte der Kapazität. Für die Inferenz eines 70B-Modells benötigen Sie entweder zwei Karten (2× 24 GB über PCIe-Tensor-Parallelism) oder eine 48-GB-Karte, auf der das Modell nur mit eingeschränktem Kontext läuft.
Was ist der Unterschied zwischen GPU-VRAM und System-RAM bei der Inferenz?
Das Modell muss in den GPU-VRAM geladen werden — System-RAM kann ihn bei der GPU-Inferenz nicht ersetzen. CPU-Inferenz (über llama.cpp ohne GPU) funktioniert aus dem System-RAM, ist aber um Größenordnungen langsamer. Einige Lösungen (z. B. llama.cpp mit partiellem Offloading) laden einen Teil der Schichten in den VRAM und belassen den Rest im RAM — praktisch nutzbar für Entwicklungsexperimente, nicht für Produktion.
Wie viel VRAM verbraucht ein langer Kontext zusätzlich?
Das hängt vom Modell ab. Orientierungswert: Bei einem 7B-Modell kommen pro 8K Token Kontext ~1–2 GB KV-Cache hinzu. Bei einem 70B-Modell sind es ~5–10 GB pro 8K Token. Moderne Modelle mit Grouped Query Attention (GQA) sind deutlich sparsamer als ältere. Überprüfen Sie vor dem Hardware-Kauf den Parameter num_key_value_heads in der Konfigurationsdatei des Zielmodells.
Ist Q4_K_M-Quantisierung für Firmendokumente und RAG ausreichend?
In den meisten Fällen ja. Für RAG über Firmendokumentation (Informationsextraktion, Kategorisierung, Zusammenfassung) ist der Unterschied zwischen Q4_K_M und FP16 in der Praxis kaum messbar. Degradierung tritt bei komplexem mehrstufigen Reasoning oder bei der Generierung langer zusammenhängender Texte auf. Im Zweifelsfall: testen Sie den konkreten Use-Case mit Q4_K_M und vergleichen Sie mit Q8_0 — das Ergebnis wird Sie in der Regel überraschen.
Wann ist Multi-GPU besser als eine einzelne größere Karte?
Eine einzelne größere Karte ist in der Regel die bessere Wahl, wenn sie existiert (geringerer Kommunikations-Overhead, einfachere Verwaltung). Multi-GPU ist sinnvoll, wenn: (1) das Modell auf keine einzelne Karte passt, auch nicht bei aggressiver Quantisierung, (2) Sie Redundanz für High-Availability benötigen, oder (3) Sie eine große Anzahl paralleler Requests bedienen wollen und Durchsatz die primäre Metrik ist.
*Die Wahl der richtigen GPU für lokale Inferenz ist auf den ersten Blick eine technische Frage — in Wirklichkeit ist es eine architektonische Entscheidung, die Kosten, Kontextfenster, Anzahl paralleler Nutzer und Systemverfügbarkeit beeinflusst. In MP Industrial Solutions begleiten wir Unternehmen vom Ziel-Use-Case über die Modellauswahl bis zur konkreten Hardware-Empfehlung — inklusive TCO-Kalkulation gegenüber Cloud-API. Wenn Sie sich auf Ihr erstes On-prem-Deployment vorbereiten oder Ihren bestehenden Server neu bewerten, schauen wir uns Ihre Zahlen gerne an.*