DEV Community

Cover image for Wie viel Speicher braucht ein lokales LLM?

Wie viel Speicher braucht ein lokales LLM?

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
Enter fullscreen mode Exit fullscreen mode

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.

Schätzungen pro Quantisierung für Qwen2.5 14B auf einem Mac mit 16 GB

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
Enter fullscreen mode Exit fullscreen mode

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ß).

Dieselbe Schätzung für eine Liste von Modellen

Ü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.

14B und 8B beim selben Prompt

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)