Speicherbudget mit sichtbaren Annahmen
Gewichte verwenden alle Parameter, auch sämtliche MoE-Experten. Der KV-Speicher verwendet KV-Heads statt der Hidden-Dimension. Die Rechnung gilt für normale MHA/GQA/MQA-Caches. MLA, hybride rekurrente Schichten und die Runtime-Allokation brauchen modellspezifische Messungen.
Die Q-Stufen sind beispielhafte Speicherbudgets: Bits × Overhead. Echte GGUF-Dateien mischen verschiedene Tensorformate. Verwende für die Hardware-Auswahl möglichst die gemessene Dateigröße.
- Gewichte
- 3.75 GiB
- KV-Cache
- 1.00 GiB
- Runtime-Reserve (GiB)
- 1.00 GiB
- Gesamt inkl. Reserve
- 5.75 GiB
Innerhalb dieses Budgets (24 GiB)
GiB = 2³⁰ Bytes; GB = 10⁹ Bytes. Gemeinsamer Speicher muss auch das Betriebssystem aufnehmen. Die Reserve ist eine veränderbare Annahme und kein gemessener Runtime-Verbrauch.
KV bytes = 2 × layers × KV heads × head dimension × tokens × batch × dtype bytesWarum die Speichergröße keine Geschwindigkeit vorhersagt
Ob ein Modell in den Speicher passt, prüft nur die Kapazität. Die Decode-Zeit hängt zusätzlich von aktiven Gewichten, KV-Verkehr, Rechenleistung, Kernels, Batchgröße und Platzierung ab. Es gibt keinen universellen GPU-Effizienzfaktor. Miss Prefill und Decode getrennt mit dem konkreten Modell und der Runtime.
Smartes Offloading für MoE-Modelle
Expert-Routing ändert sich pro Token. Derzeit inaktive Gewichte können später gebraucht werden. Experten auf der CPU reduzieren den VRAM-Bedarf, benötigen aber CPU-Rechnung oder Transfers. Das ist nicht kostenlos.
llama.cpp bietet --cpu-moe und --n-cpu-moe für Expertengewichte auf der CPU sowie --gpu-layers für die Schichtplatzierung. --override-kv verändert Modellmetadaten. Es aktiviert keine Expertenvorhersage oder Vorabladen.