Zum Inhalt

// 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:

  1. OCR erforderlich ist für gescannte PDFs oder Bilddateien
  2. Reranking-Performance kritisch ist und die CPU zu langsam
  3. 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_think an 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