🧠 Warum 7B in 4-Bit keine 7 GB sind
Eine 24-GB-Karte, ein 32B-Modell in Q4_K_M, und vLLM bricht nach dem Laden der Gewichte mit „No available memory for the cache blocks" ab. Die Gewichte waren es nicht: 19,9 GiB sind genau das, was 32,76 Milliarden Parameter mit 4,85 Bit pro Gewicht belegen. Gefehlt hat der Rest — der Speicher, den das Modell erst im Betrieb braucht.
Drei Posten, ein Budget
Gewichte stehen nach dem Laden fest. KV-Cache wächst mit Kontextlänge mal Sequenzzahl und ist bei jedem Token, den ein Request anhängt, einen Schritt größer. Overhead ist alles, was vLLM für Aktivierungen, CUDA-Graphs und den CUDA-Kontext reserviert, bevor der erste Request ankommt. Wer nur Posten eins rechnet, plant systematisch zu knapp — und zwar umso knapper, je länger die Kontexte werden.
Die KV-Cache-Formel
KV-Cache pro Token = 2 × Layer × KV-Heads × Head-Dim × Byte pro Element. Die Zwei steht für Key und Value, und der Faktor geht über alle Layer, weil jede Schicht ihren eigenen Cache hält. Llama 3.1 8B hat 32 Layer, 8 KV-Heads und Head-Dim 128: 2 × 32 × 8 × 128 × 2 Byte = 131.072 Byte, also 128 KiB pro Token. Bei 8.192 Tokens ist das 1 GiB pro Sequenz — während die Gewichte in Q4_K_M nur 4,5 GiB belegen.
Deshalb kippt die Rechnung so plötzlich. Llama 3.3 70B liegt bei 320 KiB pro Token: 8k Kontext sind 2,5 GiB pro Sequenz, 32k sind 10 GiB. Bei 70B-Modellen mit wenigen KV-Heads ist der Cache damit der Posten, der über die Hardware entscheidet — nicht das Modell.
Bits pro Gewicht sind keine Rundungsfrage
Zwischen BF16 und Q4_K_M liegen Faktor 3,3, zwischen Q4_K_M und Q3_K_M immer noch 20 Prozent. Die k-Quanten von llama.cpp tragen Skalen und Minima als Fp16 mit, deshalb sind es 4,85 statt 4 Bit. GPTQ und AWQ mit Gruppenbreite 128 landen bei 4,25 Bit — 4 Bit pro Gewicht plus 2 × 16 Bit Skale und Zero pro Gruppe. Wer mit „4 Bit = 0,5 Byte" rechnet, unterschätzt jedes Modell um sechs Prozent.
Bei MoE zählt der Speicher für alle Experten
Mixtral 8×7B hat 46,7 Milliarden Parameter, nutzt pro Token aber nur zwei von acht Experten. Für den Durchsatz ist das ein Geschenk, für den VRAM nicht: Alle Experten müssen geladen sein, sonst lässt sich nicht routen. gpt-oss-120b bringt es auf 116,8 Milliarden Parameter — in nativem MXFP4 sind das noch 58 GiB Gewichte, die sich nicht wegquantisieren lassen. Rechne bei MoE immer mit der Gesamtzahl, nicht mit den aktiven Parametern.
Was vLLM aus dem Budget macht
vLLM reserviert gpu_memory_utilization des Karten-Speichers — standardmäßig 0,9, im aktuellen main-Zweig 0,92 —, zieht Gewichte und Overhead ab und gibt den Rest als PagedAttention-Blöcke für den KV-Cache aus. Im Log steht danach „GPU KV cache size: N tokens" und „Maximum concurrency for 8,192 tokens per request: M×". Genau diese beiden Zeilen rechnet dieser Rechner vorher aus, damit du nicht erst nach dem Modell-Download merkst, dass es nicht passt.
Drei Stellschrauben gibt es: --max-model-len begrenzt den Kontext pro Request, --max-num-seqs die Parallelität, und --kv-cache-dtype fp8 halbiert den Cache pro Token. FP8 im KV-Cache kostet messbar Qualität, bei den meisten Chat-Workloads aber weniger, als ein zweiter Server kostet. Wenn die Gewichte allein schon nicht passen, hilft nur --tensor-parallel-size: Bei TP=2 liegt die Hälfte der Gewichte und des Caches auf jeder Karte.
Praxisbeispiel: 8B auf einer RTX 4090
Llama 3.1 8B in Q4_K_M, 8k Kontext, 8 gleichzeitige Sequenzen, eine RTX 4090 mit 24 GiB und 90 Prozent Auslastung: 4,53 GiB Gewichte, 8 GiB KV-Cache, 1,5 GiB Overhead ergeben 14,03 GiB von 21,6 nutzbaren — 7,57 GiB bleiben frei, genug für 15 parallele 8k-Requests. Dieselbe Karte mit 32k Kontext und acht Sequenzen braucht 32 GiB KV-Cache und scheitert. Wer den Kontext braucht, halbiert ihn nicht, sondern nimmt FP8 im KV-Cache: dann sind es 16 GiB und es passt wieder.
AMD und Intel Arc: dieselbe Rechnung, ein anderer Treiber
Die Formel kennt keinen Hersteller. Radeon-Karten laufen unter ROCm (vLLM unterstützt das offiziell), Intel Arc über das XPU-Backend von PyTorch — der KV-Cache braucht pro Token dieselben Bytes. Was sich ändert, ist der Overhead: Unter ROCm sind 2 bis 3 GiB pro Karte realistischer als 1,5, und eine Arc mit 12 GiB teilt sich das VRAM mit dem Desktop. Trag den Wert aus dem Log ein, dann stimmt die Rechnung auch dort. Die Familien im Dropdown stehen in der Reihenfolge ihrer Beliebtheit auf Hugging Face; alle Modelle bleiben unter 130 Milliarden Parametern, weil darüber ohne Tensor-Parallelismus nichts mehr sinnvoll auf eine Karte geht.
Häufige Fragen
Warum weicht das Ergebnis von dem ab, was vLLM im Log ausgibt?
Weil vLLM den Overhead nicht schätzt, sondern ihn beim Start mit einem Dummy-Batch ausmisst — und der hängt von Modell, Batch-Größe und CUDA-Graph-Konfiguration ab. Trag den Wert ein, den das Log als Differenz zwischen reserviertem Speicher und Gewichten ausweist; dann stimmen die Zahlen bis auf die Block-Rundung.
Zählt der Rechner die Embedding-Schicht und den LM-Head mit?
Ja, weil die Parameterzahl die vollständige safetensors-Summe ist. Bei Quantisierungsschemata, die Embedding und LM-Head in BF16 lassen — bei GPTQ und AWQ üblich —, liegt die Rechnung deshalb leicht zu niedrig. Der Fehler bleibt bei aktuellen Modellen unter einem Prozent.
Was ist mit Gemma 3 und gpt-oss, die Sliding-Window-Attention nutzen?
Bei diesen Modellen ist der tatsächliche KV-Cache kleiner als die lineare Formel sagt, weil nur ein Teil der Layer den ganzen Kontext hält. Die Formel liefert dort eine Obergrenze — gut für die Hardware-Entscheidung, schlecht für die exakte Zahl der Sequenzen.
Reicht CPU-RAM plus Swap nicht auch?
Für llama.cpp mit Offloading ja, für vLLM praktisch nein: PagedAttention braucht die Blöcke im Kartenspeicher, und ein Modell, das pro Token über PCIe wandert, verliert genau den Vorteil, für den du vLLM nimmst. Wenn die Gewichte nicht in den VRAM passen, ist das eine Hardware-Frage, keine Einstellungsfrage.
Wie viele Sequenzen soll ich ansetzen?
Für einen einzelnen Nutzer reicht 1 bis 4. Ab etwa 8 parallelen Sequenzen lohnt sich Continuous Batching, ab 32 wird der KV-Cache in der Regel zum Engpass. Der Rechner zeigt beides: ob die gewählte Zahl passt und wie viele tatsächlich hineinpassen.
Quellen & Weiterlesen
Architekturwerte aus den config.json der Modelle (Llama 3.1 8B, Llama 3.3 70B, Qwen3 8B/32B, Gemma 3 27B, Mistral Nemo 12B, Mistral Small 3.2 24B, Mixtral 8×7B, gpt-oss-20b/120b) und Parameterzahlen aus den safetensors-Metadaten auf Hugging Face. Formel und Standardwerte nach der vLLM-Dokumentation (PagedAttention, Engine Arguments: gpu_memory_utilization, max_model_len, max_num_seqs, kv_cache_dtype) sowie dem llama.cpp-Quantisierungsverzeichnis. Weiter im Portfolio: Kapazitäts-Umrechner, Stromkosten-Rechner, IOPS-Rechner.
⚡ Weiter zum Stromkosten-Rechner — oder zur Kapazität.