Licensed to be used in conjunction with basebox, only.
// installation
LLM-Empfehlungen (Sizing-Referenz)
Gilt für
Produkt: Server · Zielgruppe: Platform Operator
Kurzreferenz zur Modellauswahl anhand der verfügbaren GPU-Hardware.
Sizing-Orientierung, keine Produktdokumentation
Diese Seite beantwortet „Welches Modell passt auf diese GPU?" – eine Sizing-Frage. Die Produktdokumentation hält Kompatibilität, getestete Modelle, Empfehlungen und Benchmarks bewusst auseinander; siehe Modelle & Inferenz. Die Werte hier sind Richtwerte und ersetzen keinen Test auf der Zielhardware.
Methodik
Hinweis: Diese Liste ersetzt keine Prüfung und Verifikation auf der Zielhardware.
Systemanforderungen
Die Inferenz-Engine (vLLM) benötigt:
- NVIDIA-GPU mit Compute Capability 7.0+ (Volta-Architektur oder neuer)
- NVIDIA-Treiber:
- Linux: Version 575.51.03 oder neuer
- Windows: Version 576.02 oder neuer
- Die Treiberanforderung ergibt sich aus der CUDA-12.9-Kompatibilität
Hardware-Klassen
| Klasse | Beispiel-GPUs | Gesamt-VRAM | Typische Nutzung |
|---|---|---|---|
| Enterprise | 4x H100 | 320 GB | RAG mit hohem Volumen, viele gleichzeitige Nutzer |
| Professional | 4x L40S | 192 GB | Mittlere RAG-Workloads, Teamnutzung |
| Workstation | 2x RTX 4090 | 48 GB | Leichtes RAG, Einzelnutzer-Szenarien |
| Entry | 1x L4 oder 1x 24GB GPU | 24 GB | Tests, geringes Volumen |
Empfohlene Modelle nach Hardware
TP (Tensor-Parallelismus): Verteilt Modellschichten auf mehrere GPUs. TP=2 nutzt 2 GPUs, TP=4 nutzt 4 GPUs. Höheres TP erhöht den verfügbaren VRAM für Kontext und Parallelität. Einschränkungen unter GPU-Zuteilung.
4x H100 (320 GB VRAM)
Am besten für: RAG mit hohem Volumen, große Kontextfenster, Produktiv-Workloads.
| Modell | Quantisierung | Kontext | Gleichzeitige Nutzer | HuggingFace |
|---|---|---|---|---|
| GPT-OSS 120B (TP=4) | MXFP4 | 128k | 15-20 | Link |
| GPT-OSS 120B (TP=2) | MXFP4 | 32-64k | 8-12 | Link |
| Llama 3.3 70B Instruct | FP8 | 65k | 10-12 | Link |
| Llama 3.3 70B Instruct | FP8 | 32k | 20-25 | Link |
| Qwen2.5 72B Instruct | Int8 | 65k | 10-12 | Link |
| DeepSeek R1 Distill 70B | FP8 | 32k | 10-12 | Link |
Hinweise:
- Empfohlen: GPT-OSS 120B mit TP=4 für den vollen 128k-Kontext; die MoE-Architektur (117B gesamt, 5,1B aktiv) liefert schnelle Inferenz
- GPT-OSS 120B mit TP=2 lässt 2 GPUs für Whisper/RAG frei, reduziert aber den maximalen Kontext
- Llama 3.3 70B FP8 ist eine solide Alternative, falls die GPT-OSS-Kompatibilität ein Thema ist
- FP8/Int8 erhält die Qualität bei halbiertem Speicher gegenüber FP16; wo der VRAM reicht, AWQ vorziehen
- Qwen2.5 72B zeigte im Test schnellere Antwortzeiten als Llama 3.3 70B
4x L40S (192 GB VRAM)
Am besten für: Teamnutzung, mittlere RAG-Workloads.
| Modell | Quantisierung | Kontext | Gleichzeitige Nutzer | HuggingFace |
|---|---|---|---|---|
| GPT-OSS 120B (TP=4) | AWQ | 32-64k | 5-8 | Link |
| Llama 3.3 70B Instruct | FP8 | 65k | 5-6 | Link |
| Llama 3.3 70B Instruct | FP8 | 32k | 10-12 | Link |
| Qwen2.5 72B Instruct | Int8 | 32k | 5-6 | Link |
| Qwen 3 32B | BNB-4bit | 32k | 8-10 | Link |
Hinweise:
- Empfohlen: GPT-OSS 120B AWQ mit TP=4; benötigt alle 4 GPUs (passt nicht auf eine einzelne L40S)
- Llama 3.3 70B FP8 ist eine solide Alternative mit höherer Parallelität bei 65k Kontext
- Qwen 3 32B benötigt das Suffix
/no_think, um den Thinking-Modus abzuschalten - Die L40S hat weniger VRAM je GPU (48GB statt 80GB), was den Kontext gegenüber der H100 begrenzt
2x RTX 4090 (48 GB VRAM)
Am besten für: Einzelnutzer, leichtes RAG, Entwicklung.
| Modell | Quantisierung | Kontext | Gleichzeitige Nutzer | HuggingFace |
|---|---|---|---|---|
| GPT-OSS 20B | MXFP4 | 64k | 2-3 | Link |
| Llama 3.1 8B Instruct | FP8 | 128k | 1-2 | Link |
| DeepSeek R1 Distill 8B | AWQ | 32k | 1-2 | Link |
| Mistral 7B Instruct v0.3 | FP16 | 32k | 1-2 | Link |
Hinweise:
- Empfohlen: GPT-OSS 20B für die beste Qualität; das MoE-Modell (21B gesamt, 3,6B aktiv) passt mit MXFP4 in ~16GB und lässt Platz für 64k Kontext
- 8B-Modelle sind Alternativen, wenn längerer Kontext (128k) wichtiger ist als Qualität
- DeepSeek R1 erfordert die Behandlung von Thinking-Tokens im Backend
1x L4 / 24 GB GPU
Am besten für: Tests, Vorführungen, Einzelnutzer mit geringem Volumen.
| Modell | Quantisierung | Kontext | Gleichzeitige Nutzer | HuggingFace |
|---|---|---|---|---|
| GPT-OSS 20B | MXFP4 | 32k | 1 | Link |
| Qwen3 4B Instruct | FP16 | 30k | 1 | Link |
| Llama 3.1 8B Instruct | FP8 | 32k | 1 | Link |
| Mistral 7B Instruct v0.3 | FP8 | 16k | 1 | Link |
Hinweise:
- Empfohlen: GPT-OSS 20B für die beste Qualität auf 24GB-Hardware; MoE mit nur 3,6B aktiven Parametern; passt mit MXFP4 in 16GB
- Qwen3 4B ist eine Alternative mit dem besten Durchsatz (23 Tokens/Sek.), wenn Geschwindigkeit vor Qualität geht
- Praktisch maximaler Kontext rund 30k Tokens
Schnellauswahl
| Ihre Situation | Empfohlenes Modell |
|---|---|
| Enterprise (4x H100) | GPT-OSS 120B MXFP4, TP=2 oder TP=4 |
| Professional (4x L40S) | GPT-OSS 120B AWQ oder Llama 3.3 70B FP8 |
| Workstation (2x RTX 4090) | GPT-OSS 20B MXFP4, TP=2 |
| Entry (1x 24GB GPU) | GPT-OSS 20B MXFP4 |
| Schnellere Antwortzeiten | Qwen2.5 72B Int8 auf 4x H100 |
| Minimale Hardware, Tests | Qwen3 4B Instruct |
| Reasoning-Fähigkeiten benötigt | DeepSeek R1 Distill (8B oder 70B) |
VRAM-Bedarf (Referenz)
Ungefährer VRAM je Modell (nur Inferenz, ohne KV-Cache-Overhead):
| Modell | FP16 | FP8/Int8 | Int4/AWQ/MXFP4 |
|---|---|---|---|
| GPT-OSS 120B (MoE) | ~240 GB | ~120 GB | ~60 GB |
| 70-72B | ~140 GB | ~70 GB | ~35 GB |
| 34B | ~68 GB | ~34 GB | ~18 GB |
| 32B | ~64 GB | ~32 GB | ~16 GB |
| GPT-OSS 20B (MoE) | ~42 GB | ~22 GB | ~16 GB |
| 13B | ~26 GB | ~13 GB | ~7 GB |
| 8B | ~16 GB | ~8 GB | ~4 GB |
| 7B | ~14 GB | ~7 GB | ~4 GB |
| 4B | ~8 GB | ~4 GB | ~2 GB |
Hinweis: GPT-OSS-Modelle nutzen eine Mixture-of-Experts-Architektur (MoE) mit deutlich weniger aktiven Parametern (3,6B beim 20B, 5,1B beim 120B), was zu schnellerer Inferenz als bei dichten Modellen ähnlicher Gesamtgröße führt.
Die Kontextlänge erhöht den Speicherbedarf erheblich. Längere Kontexte benötigen zusätzlichen VRAM für den KV-Cache.
Kontextgröße vs. gleichzeitige Nutzer
Zwischen Kontextfenster und Anzahl gleichzeitiger Nutzer besteht ein direkter Zielkonflikt:
- Der KV-Cache wächst mit dem Kontext: Jedes Token im Kontext braucht Speicher für den Key-Value-Cache. Ein 65k-Kontext nutzt etwa 4x so viel KV-Cache-Speicher wie ein 16k-Kontext.
- Gleichzeitige Anfragen vervielfachen den Speicher: Jeder gleichzeitige Nutzer braucht eine eigene KV-Cache-Zuteilung.
- Praktische Formel:
Verfügbarer VRAM = Modellgewichte + (Kontextgröße × gleichzeitige Nutzer × KV-Cache je Token)
Beispiel für Llama 3.3 70B FP8 auf 4x H100 (320 GB):
| Kontext | Max. gleichzeitige Nutzer | Anwendungsfall |
|---|---|---|
| 65k | 10-12 | RAG über große Dokumente |
| 32k | 20-25 | Standard-RAG, Teamnutzung |
| 16k | 40-50 | Kurze Anfragen, hohe Parallelität |
Empfehlung: Bei RAG-Workloads Kontextgröße vor Anzahl gleichzeitiger Nutzer priorisieren. Ein 65k-Kontext erlaubt größere Dokumente und mehr abgerufene Chunks und verbessert die Antwortqualität.
KV-Cache-Optimierung: Die meisten Inferenz-Engines unterstützen KV-Cache-Quantisierung, die die Kapazität an gleichzeitigen Nutzern bei geringem Qualitätsverlust etwa verdoppeln kann. Die Schätzungen oben gehen vom Standard-KV-Cache (FP16) aus.
GPU-Zuteilung
Der basebox-Stack umfasst mehrere GPU-fähige Komponenten:
| Komponente | GPU-Nutzung | Zweck |
|---|---|---|
| LLM-Server (vLLM) | Hoher VRAM, latenzempfindlich | Textgenerierung, Chat |
| Audio-Server (Whisper) | Geringer VRAM (~8GB) | Audiotranskription |
| RAG-Server | Geringe bis mittlere GPU-Nutzung | Embedding, Reranking, OCR |
Einschränkungen des Tensor-Parallelismus
Die GPU-Zuteilung für das LLM hängt von den Tensor-Parallelismus-Anforderungen (TP) des Modells ab:
- TP muss die Attention-Heads gleichmäßig teilen – z. B. unterstützt GPT-OSS 120B (64 Heads) TP=1, 2, 4, 8, aber nicht TP=3
- GPT-OSS 120B: TP=2 als Minimum empfohlen; Datenparallelismus nicht unterstützt (siehe Bekannte Probleme)
- 70B-Modelle: TP=2 oder TP=4 üblich
Das heißt, nicht alle GPUs werden zwangsläufig für das LLM genutzt. Verbleibende GPUs können Whisper und RAG ausführen.
Beispiel: 4x H100 mit GPT-OSS 120B
| GPUs | Dienst | Hinweise |
|---|---|---|
| 0, 1 | LLM (TP=2) | GPT-OSS 120B mit Tensor-Parallelismus |
| 2 | Whisper + RAG | Gemeinsame GPU für Hilfsdienste |
| 3 | Ungenutzt | Verfügbar für spätere Skalierung |
Standard: LLM + Whisper auf gemeinsamer GPU
Nutzt das LLM alle verfügbaren GPUs, teilt Whisper sich eine GPU mit dieser Speicheraufteilung:
| Dienst | GPU-Speicher | ~Nutzung (80GB-GPU) |
|---|---|---|
| LLM | 85% | 68 GB |
| Whisper | 10% | 8 GB |
| Puffer | 5% | 4 GB |
Wann GPU für RAG
RAG läuft standardmäßig auf der CPU, unterstützt aber GPU-Beschleunigung. Aktivieren Sie den GPU-Modus für RAG, wenn:
- OCR erforderlich ist für gescannte PDFs oder Bilddateien
- Reranking-Performance kritisch ist und die CPU zu langsam
- GPUs frei sind aufgrund von TP-Einschränkungen (wie im 4x-H100-Beispiel oben)
Bekannte Probleme
- Llama 3.3 70B AWQ: Kann hohe Perplexität zeigen; Repetition Penalty und Temperature anpassen
- DeepSeek-R1-Modelle: Das Backend muss Thinking-Tokens aus den Antworten filtern
- Qwen 3 32B: Nur BNB-4bit funktioniert mit vLLM;
/no_thinkan Nutzer-Prompts anhängen - GPT-OSS 120B: Funktioniert mit Datenparallelismus nicht zuverlässig (erzeugt fehlerhafte Ausgabe); stattdessen Tensor-Parallelismus verwenden
- GPT-OSS-Modelle: Benötigen vLLM 0.10.1+; der Reasoning-Parser muss für die korrekte Behandlung von Reasoning-Tokens konfiguriert sein
- GGUF-Modelle: vLLM bietet experimentelle GGUF-Unterstützung mit Einschränkungen (nur Einzeldatei, ggf. inkompatibel mit einigen Funktionen); für den Produktivbetrieb native Quantisierungsformate (FP8, AWQ, GPTQ) vorziehen