Bevor man ein Modell zum lokalen Ausführen herunterlädt, stellt sich die Frage, ob es in den Speicher passt. Die Schätzung besteht aus drei Summanden, verglichen mit dem, was der Rechner dem Modell tatsächlich geben kann:
need = weights + KV cache + overhead
fits if need <= 0.8 × usable memory
Die Zahlen unten folgen der Schätzung, die der Browser für lokale Modelle in der Desktop-App osFoundry verwendet, abgeglichen mit dem, was die App für ein 16-GB-M3-MacBook anzeigt.
Gewichte
Die Gewichte ergeben sich aus der Parameterzahl mal den Bytes pro Gewicht, und diese Bytes hängen von der Quantisierung ab:
| Quant | Bytes pro Gewicht |
|---|---|
| FP16 / BF16 | 2.0 |
| Q8_0 | 1.0 |
| Q6_K | 0.82 |
| Q5_K_M | 0.69 |
| Q4_K_M | 0.56 |
| Q3_K_M | 0.44 |
| Q2_K | 0.31 |
Q4_K_M liegt bei 0.56 statt 0.5, weil K-Quants für jeden kleinen Gewichtsblock eine Skalierung mitspeichern. Das ergibt etwa 4.5 Bit pro Gewicht.
Für ein 14B-Modell in Q4_K_M: 14 × 10⁹ × 0.56 = 7.84 × 10⁹ Bytes, also etwa 7.3 GiB.
Wenn du den Namen der Quantisierung nicht kennst, nimm FP16 an. Das ist die pessimistische Wahl, du entscheidest also nie, dass etwas passt, obwohl es nicht passt.
KV-Cache
Bei der Generierung hält das Modell Keys und Values für jedes Token im Kontext vor. Die Größe ist:
2 × layers × kv_heads × head_dim × context_tokens × bytes_per_element
Qwen2.5 14B hat 48 Layer, 8 KV-Heads (es nutzt Grouped-Query Attention) und eine Head-Dimension von 128. Mit einem FP16-Cache:
- 4K Kontext: 2 × 48 × 8 × 128 × 4096 × 2 Bytes = 768 MiB
- 32K Kontext: 6 GiB
Der Cache wächst linear mit der Kontextlänge. Ein Modell, das bei 4K locker passt, kann bei 32K also nicht mehr passen. Schätzungen ohne Angabe der Kontextlänge sind kaum zu gebrauchen; die im Screenshot geht von 4K aus.
Overhead
llama.cpp braucht außerdem Compute-Puffer und Arbeitsspeicher. Als grober Richtwert gelten 10 % der Gewichte plus etwa 200 MB. Beim 14B-Modell sind das rund 0.9 GB.
Addiert man Gewichte, Cache und Overhead, landet ein 14B-Modell in Q4_K_M im Bereich von 8 bis 9 GB. Die App zeigt 8.4 GB.
Nutzbarer Speicher
Hier liegen die meisten falsch.
- Dedizierte GPU: Der VRAM der Karte ist die Obergrenze. Bei einer Karte mit 12 GB sind es 12 GB, egal wie viel Arbeitsspeicher das System hat.
- Apple Silicon: Der Speicher ist einheitlich (Unified Memory), aber die GPU kann ihn nicht komplett nutzen, und das Betriebssystem braucht seinen Anteil. 75 % des gesamten RAM anzusetzen ist ein brauchbarer Richtwert, bei 16 GB also etwa 12 GB.
Dann vergleicht man:
- need ≤ 80 % des nutzbaren Speichers: passt, mit Luft für das Betriebssystem und andere Apps
- 80 % bis 100 %: knapp; es lädt, aber schließe vorher andere Apps
- über 100 %: es lagert auf die Festplatte aus und wird unbrauchbar langsam
Auf dem 16-GB-Mac ergibt das: Q4_K_M 8.4 GB (70 %, passt), Q5_K_M 10.4 GB (87 %, knapp), Q6_K 12.3 GB und Q8_0 14.9 GB (zu groß).
Über mehrere Modelle in Q4_K_M angewandt, liegt die Grenze auf dieser Maschine zwischen 20B (11.9 GB, knapp) und 27B (15.9 GB, zu groß).
Die Geschwindigkeit folgt derselben Zahl
Für jedes erzeugte Token muss jedes Gewicht einmal aus dem Speicher gelesen werden. Die Obergrenze der Generierungsgeschwindigkeit ist deshalb die Speicherbandbreite geteilt durch die Modellgröße. Ein Basis-M3 hat etwa 100 GB/s, ein Modell mit 8.4 GB schafft also höchstens rund 12 Token pro Sekunde, ein 8B-Modell mit 4.9 GB rund 20. Reale Werte liegen darunter, aber das Verhältnis zwischen den Modellen stimmt ziemlich gut.
Die Größenschätzung beantwortet also zwei Fragen auf einmal: ob das Modell überhaupt lädt und wie schnell es ungefähr schreibt, wenn es läuft.



Top comments (0)