Niemand spricht über RAM. Jeder Local-LLM-Ärger ist ein RAM-Problem.

Betrete irgendeinen Thread zu lokalen LLMs, und gestritten wird über GPUs. VRAM-Benchmarks, 24-GB-Karten, CUDA gegen ROCm, ob die 3060 noch die Volkskarte ist. Währenddessen sitzt die Zahl, die wirklich entscheidet, ob dein Modell läuft, im anderen Steckplatz — ohne Benchmark, ohne Marketing: wie viel RAM die Maschine hat.

VRAM verkauft den Traum. RAM entscheidet, ob das Modell überhaupt bootet — und wie viel Kontext überlebt, wenn es läuft.

Ich habe es beim Schreiben dieses Beitrags auf der Kiste vor mir getestet: ein Ryzen-Desktop mit 32 GB RAM und einer GeForce RTX 3060 mit 12 GB VRAM. llama3.1:8b gezogen — die Download-Seite sagt 4,9 GB. Sieh dir an, was er wirklich belegt hat:

Das ganze Argument steht in diesem einen Screen. Ein „4,9-GB-Modell” hat 7,0 GB reserviert, bevor es einen einzigen Prompt beantwortet hat — eine Kontext-Steuer von 43 % — und sich 7.963 von 12.288 MiB VRAM gesichert. Die Gewichte waren nie das Budget. Der Kontext war es.

Wo die zusätzlichen Gigabytes herkommen

Die Memory-Notes von llama.cpp erklären die Rechnung, die Download-Seiten auslassen: Gesamtspeicher = Modellgewichte + KV-Cache + Compute-Buffer. Nur der erste Term ist konstant. Der KV-Cache wächst linear mit der Kontextlänge, der Compute-Buffer mit der Batch-Größe. Ollama verpackt llama.cpp, also gilt dasselbe Gesetz — deshalb meldete ollama ps 7,0 GB für ein 4,9-GB-Tag bei 32.000 Token Fenster, alles resident auf der GPU.

Ein quantisiertes Modell ist kein Kompromiss. Es ist das Eingeständnis, dass Speicher immer das eigentliche Budget war.

Deshalb existiert die GGUF-Quantisierungsleiter überhaupt. Q4 ist keine Religion; es ist das, was die Speicherrechnung in Hardware landen lässt, die Leute besitzen. Und deshalb ähneln sich zwei „identische” 8B-Setups in nichts: gleiches Modell, andere Kontextlänge, andere Maschinen.

Die Tabelle, die niemand vor dem Kauf ausfüllt

Drei Modellklassen, beide Speichertypen, eine 12-GB-Karte und 32 GB RAM — die Konfiguration, die tausende Entwickler wirklich haben:

Modellklasse (Q4)	Download	Geladen + 32k Ctx	Auf 12 GB VRAM	Auf 32 GB RAM
7–8B (llama3.1:8b)	4,9 GB	7,0 GB (gemessen)	100 % GPU, ~8 GiB belegt	kaum bemerkt
13–14B (qwen2.5:14b)	9,0 GB	~12 GB	Offload beginnt	fein
27–32B (gemma3:27b)	17 GB	~20 GB und mehr	CPU schleppt die Gewichte	der einzige Grund, warum es läuft

Lies die letzten beiden Zeilen noch einmal. Allein auf VRAM ist ein 14B bei echtem Kontext schon ein Split-Offload-Job, und ein 27B ist unmöglich. Auf 32 GB RAM sind beide bloß langsam. Dieser Unterschied — zwischen unmöglich und langsam — ist der gesamte praktische Unterschied zwischen VRAM und RAM. Passt es in den VRAM, ist es schnell. Passt es in den RAM, funktioniert es. Passt es in keins von beiden, swapst du auf NVMe und die Zeit verliert ihre Bedeutung.

Offload läuft über PCIe, und die Ollama-FAQ sagt beim Preis klar, wie es ist: Layer, die nicht auf die GPU passen, laufen auf der CPU, und der Durchsatz bricht ein, sobald der GPU-Anteil schrumpft. Niemand wählt diesen Trade-off bewusst. Er passiert lautlos, Layer für Layer, und das Symptom ist nur: „Lokale Modelle sind überbewertet.”

Das ehrliche Register

Was beim Schreiben kaputtging oder überraschte, der Reihe nach:

1. Die 43-%-Zahl selbst. Ich erwartete, dass das 8B-Modell „etwa seine Dateigröße” belegt. Es reservierte 7,0 GB gegen 4,9 GB Download. Wenn mich das überrascht hat, überrascht es jeden, der Datenblätter liest statt ps.
2. Die Screenshot-Session. Meine erste Aufnahme erwischte das falsche Fenster. Die zweite klappte, das ist die oben. Belege sind ein Arbeitsablauf, keine Stimmung — und ein Pull → Capture → ollama rm-Zyklus hält die Platte ehrlich.
3. Was nicht kaputtging: Die GPU lief nie über. 8B bei 32k Kontext auf 12 GB ist wirklich bequem. Die Karte ist in Ordnung. Falsch kalibriert ist der Diskurs um die Karte.

Nichts davon heißt, dass GPUs egal sind — die 100-%-GPU-Zeile in der Aufnahme ist der Grund, warum sich Generierung sofort anfühlte. Es heißt nur: Die GPU ist die zweite Frage. Die Entscheidung zwischen Ollama und llama.cpp kommt, nachdem du weißt, was hineinpasst — nicht davor.

Die Faustregel, die bleiben darf

RAM-Bedarf = Modelldatei + KV-Cache für deinen echten Kontext + 4 GB, um ein Computer zu bleiben. Für 7–8B in Q4 sind 16 GB bequem. Für 14B–32B hören 32 GB auf, Luxus zu sein, und werden zum Punkt. Kauf VRAM für das Tempo, das du beim Kontext willst, den du nutzt; kauf RAM für alles, was du jemals laden wirst.

Ein Blick auf ollama ps, und die Datenblatt-Religion endet leise.

Also, zwei Fragen. Wenn du deine nächste Maschine zusammenstellst: Kaufst du VRAM für die Benchmarks, die du posten wirst — oder RAM für die Modelle, die du wirklich laufen lässt? Und ganz ehrlich: Wie viele der Modelle, die du um 2 Uhr nachts gezogen hast, hast du vor dem Frühstück gelöscht? Ich heute Nacht, mitten im Beitrag. Sag mir in den Kommentaren, dass ich nicht der Einzige bin — und auf welcher Seite der RAM/VRAM-Linie dein Build steht.