Technische Zusammenfassung: Noch vor zwei Jahren lagen offene Sprachmodelle (Open-Weights) 12 bis 18 Monate hinter proprietären US-Clouds zurück. Der Durchbruch von Fine-Grained Sparse Mixture-of-Experts (MoE) (in Qwen3, DeepSeek-V3/R1, Llama 4) und Multi-Head Latent Attention (MLA) hat die Physik der lokalen Inferenz grundlegend verändert: Ein Modell mit 235B oder 671B Gesamtparametern aktiviert pro Token lediglich 22B bis 37B Parameter und erreicht mit FP8-Quantisierung über 90 Token pro Sekunde auf eigener, DSGVO-konformer Infrastruktur.
1. Dichte Transformer (Dense) vs. Sparse Mixture-of-Experts (MoE)
In einem klassischen dichten Modell (z. B. Llama-3-70B) muss jede Feed-Forward-Schicht (FFN) bei jedem generierten Wort 100 % ihrer Gewichte berechnen. Bei Fine-Grained Sparse MoE wird die FFN-Schicht in N = 256 spezialisierte Mikro-Experten aufgeteilt (ein Experte für SQL-Syntax, einer für Steuerrecht, einer für Finanzmathematik). Ein schlanker Router aktiviert pro Token nur K = 8 Experten plus einen gemeinsamen Shared Expert:
- Gesamtwissen im Speicher (Total Parameters): 235 Mrd. (Qwen3-235B-A22B) bzw. 671 Mrd. (DeepSeek-V3).
- Aktive Rechenlast pro Token (Active Parameters): nur 22 Mrd. bzw. 37 Mrd. Parameter!
- Auxiliary-Loss-Free Load Balancing: Dynamische Bias-Anpassung (
γ) verhindert den früher üblichen Routing Collapse ohne Qualitätsverlust.
2. VRAM-Mathematik und der MLA-Durchbruch (Multi-Head Latent Attention)
Der größte Engpass beim lokalen Betrieb ist nicht das Modellgewicht selbst, sondern der KV-Cache, der mit der Anzahl gleichzeitiger Nutzer (B) und der Kontextlänge (S) wächst:
KV_MHA = 2 × L × n_heads × d_head × precision_bytes
Multi-Head Latent Attention (MLA) projiziert Key- und Value-Matrizen in einen komprimierten latenten Vektor (c_t^KV ∈ ℝ^d_c). Dadurch sinkt der VRAM-Bedarf pro Token von ~512 KB (klassisch) bzw. 128 KB (GQA) auf nur noch 34–70 KB pro Token — was eine 6-mal höhere gleichzeitige Nutzerzahl auf derselben GPU ermöglicht.
3. FP8-, AWQ- und GGUF-Quantisierung im Benchmark-Vergleich
| Modell & Gewichtsformat | VRAM-Bedarf (Gewichte + 64k Kontext) | Durchsatz (vLLM / SGLang, batch=16) | TTFT-Latenz (4k Prompt) | Qualitätserhalt (vs. BF16) |
|---|---|---|---|---|
| Qwen3-32B (Dense, AWQ 4-bit) | ~24 GB (1× RTX 4090 / RTX 5090 / L40S) | 640 tok/s | 0,19 s | 99,1 % |
| Llama-3.3-70B (Dense, FP8 E4M3) | ~80 GB (1× H100 80GB oder 2× L40S 48GB) | 510 tok/s | 0,28 s | 99,8 % |
| Qwen3-235B-A22B (MoE, AWQ/FP8) | ~135 GB (2× H100 / 2× H200 / 4× L40S) | 1.120 tok/s | 0,22 s | 99,6 % |
4. Produktive vLLM / SGLang-Konfiguration mit RadixAttention
# Produktiver Start von vLLM mit nativem FP8 KV-Cache, Prefix-Caching und Tool-Calling:
vllm serve Qwen/Qwen3-32B-Instruct-FP8 \
--tensor-parallel-size 2 \
--quantization fp8 \
--kv-cache-dtype fp8_e4m3 \
--enable-prefix-caching \
--enable-auto-tool-choice \
--tool-call-parser hermes \
--max-model-len 65536 \
--gpu-memory-utilization 0.925. Wann eigene Open-Weights-Modelle im DACH-Mittelstand gegen Cloud-APIs gewinnen
- Strenge DSGVO-, NIS2-, DORA- und Geheimhaltungsanforderungen (NDA): Wenn Verträge, Konstruktionsdaten oder Margenkalkulationen das eigene Rechenzentrum oder die deutsche Private Cloud (z. B. Hetzner / Open Telekom Cloud) unter keinen Umständen verlassen dürfen.
- Hohes Belegvolumen (E-Rechnung, OCR, CMR-Frachtbriefe): Ab 15–20 Mio. Token täglich amortisiert sich ein dedizierter GPU-Server innerhalb von 3 bis 5 Monaten gegenüber Cloud-API-Gebühren.
- Hybride Architektur: Ein lokales 32B/MoE-Modell übernimmt die blitzschnelle DLP-Anonymisierung und Klassifizierung vor Ort, bevor anonymisierte Teilaufgaben an Cloud-Modelle gesendet werden.