Schnelle Modell-Vorlagen
Klicke auf ein Modell, um die Parameter automatisch auszufüllen. Passe Quantisierung und Kontextlänge unten an.
VRAM-Schätzer
Geschwindigkeitsschätzer
1008 GB/s × 0.55 ÷ 4.2 GB = ~131 tok/s
Die Offloading-Geschwindigkeitsklippe
Wenn ein Modell nicht in den VRAM passt, können Layer in den CPU-RAM oder sogar auf die Festplatte ausgelagert werden. Aber der Geschwindigkeitsverlust ist brutal:
Geschätzt mit Offloading: 131 tok/s (100% VRAM)
Smartes Offloading für MoE-Modelle
Mixture-of-Experts-Modelle sind einzigartig geeignet für Offloading, weil nur ein Bruchteil der Experten pro Token aktiviert wird. So holst du das Maximum raus:
Den Hot Path im VRAM behalten
Attention-Layer, das Router/Gate-Netzwerk und Shared Layers werden für jeden Token benötigt. Die müssen im VRAM bleiben. In llama.cpp nutze --ngl um zu steuern wie viele Layer auf der GPU liegen.
Inaktive Experten in CPU-RAM auslagern
Die meisten MoE-Modelle aktivieren 2-4 von 64+ Experten. Die inaktiven können im CPU-RAM liegen — sie werden während der Inferenz sowieso nicht gelesen.
Expert-Prefetching nutzen
Fortgeschrittene Runtimes (wie llama.cpp mit --override-kv) können vorhersagen, welche Experten der nächste Token braucht, und sie von CPU→GPU vorladen, während der aktuelle Token verarbeitet wird.
Beispiel: Qwen3.5-35B-A3B bei Q4
Gesamtgröße: ~18 GB. Aber nur ~3B Parameter sind pro Token aktiv. Mit smartem Offloading läuft das auf einer 12GB-GPU: Attention + aktive Experten im VRAM (~6 GB), Rest im RAM. Geschwindigkeit: fast gleich wie komplett im VRAM, weil inaktive Experten nicht gelesen werden.
💡 Kernaussage
Bei MoE-Modellen bestimmt VRAM, welche Modelle du STARTEN kannst. Bei Dense-Modellen bestimmt VRAM, wie SCHNELL sie laufen. Ein 35B MoE-Modell mit 3B aktiven Parametern auf einer 12GB-GPU kann schneller sein als ein 14B Dense-Modell auf der gleichen GPU.
Wie die Formeln funktionieren
VRAM-Formel
Jeder Parameter wird mit der durch Quantisierung bestimmten Bitanzahl gespeichert. FP16 nutzt 16 Bit (2 Byte) pro Parameter, Q4_K_M etwa 4,8 Bit. Durch 8 teilen, um Bits in Bytes umzurechnen.
KV-Cache-Formel
Bei der Generierung speichert jede Schicht einen Key- und Value-Vektor für jeden Token im Kontext. Bei längeren Kontexten kann der KV-Cache mehrere GB verbrauchen — deshalb kostet 32K Kontext deutlich mehr VRAM als 4K.
Geschwindigkeitsformel (Roofline-Modell)
LLM-Inferenz ist speicherbandbreitengebunden: Jeder Token erfordert das Lesen des gesamten Modells aus dem VRAM. Geschwindigkeit ≈ wie schnell die Modellgewichte gestreamt werden können. Bei MoE-Modellen werden nur aktive Parameter pro Token gelesen.
Wichtige Einschränkungen
- 1Dies sind Schätzungen. Der tatsächliche VRAM-Verbrauch hängt von der Inferenz-Engine (llama.cpp, vLLM, Ollama), Batch-Größe und Implementierungsdetails ab.
- 2Flash Attention und Paged KV-Cache können den Speicherverbrauch in der Praxis deutlich reduzieren.
- 3CPU-Offloading ermöglicht größere Modelle als der GPU-VRAM zulässt, allerdings auf Kosten deutlich langsamerer Geschwindigkeit.
- 4Die tatsächliche Geschwindigkeit hängt von der Rechenauslastung ab, nicht nur von der Bandbreite. Batched Inference, Speculative Decoding und Flash Attention ändern das Bild.
- 5K-Quant-Größen (Q4_K_M, Q5_K_M, etc.) variieren leicht je nach Modellarchitektur. Die Bits-pro-Parameter-Werte hier sind typische Durchschnittswerte.
Quantisierung →
Erfahre, wie Quantisierung die Modellgröße bei minimalem Qualitätsverlust reduziert.
Lokale Modellinferenz →
Vollständiger Leitfaden zum Ausführen von Modellen auf eigener Hardware.