Lokale KI auf dem PC: wie viel VRAM du brauchst

Früher oder später landet jeder Forenthread zu lokaler KI bei derselben Frage: 12 oder 16 Gigabyte? Die ehrliche Antwort ist keine Einkaufsliste, sondern eine Rechnung, die auf einen Bierdeckel passt.

Kurzantwort

Wie viel VRAM braucht ein lokales Sprachmodell? Du addierst drei Posten: die Gewichte (Parameter × Bits pro Gewicht ÷ 8), den KV-Cache für den gewünschten Kontext und eine Reserve für die Laufzeitumgebung. VRAM ist der eigene Speicher der Grafikkarte. Der Kontext ist der Text, den ein Modell auf einmal berücksichtigen kann, gezählt in Tokens, den Wortstücken, die ein Modell liest und schreibt. Ein Modell mit 8 Milliarden Parametern im Format Q4_K_M belegt rund 5 GB, und 8.192 Tokens Kontext kommen mit etwa 1,2 GB dazu [17][18][19]. Mit 1 GB Reserve reichen 8 GB VRAM gerade so, 12 GB lassen Luft für mehr Kontext. Passt ein Modell nicht, verschieben Ollama und llama.cpp einen Teil in den Arbeitsspeicher. Das läuft, aber jedes erzeugte Token dauert dann länger [2][13]. Alle Angaben gelten mit Stand 25.10.2026. Geschwindigkeiten nennen wir keine, weil wir für diesen Guide keine gemessen haben.

So funktioniert’s

1. Drei Posten teilen sich den Speicher. Zuerst die Gewichte, die gelernten Zahlen in der Modelldatei. llama.cpp lädt sie vollständig, deshalb sind Speicher- und Plattenbedarf laut Doku gleich [7]. Dann der KV-Cache: Er hält Zwischenergebnisse für jedes Token im Kontext und wächst deshalb mit der Kontextlänge [13]. Der dritte Posten ist der Rest, also Puffer der Laufzeitumgebung und, wenn die Karte auch deinen Monitor betreibt, der Desktop. Dafür veröffentlicht niemand eine feste Zahl. Die automatische Anpassung von llama.cpp versucht standardmäßig, je GPU 1.024 MiB frei zu halten [8]. Diesen Wert nehmen wir als Planungsreserve. Er ist ein Zielwert, kein gemessener Mehrbedarf.
2. Gewichte: Parameter × Bits ÷ 8. „8B“ steht für 8 Milliarden Parameter. In 16-Bit-Genauigkeit belegt jeder davon 2 Byte, deshalb setzt NVIDIA ein Modell mit 7 Milliarden Parametern mit rund 14 GB an [13]. Quantisierung speichert die Gewichte mit weniger Bits. Die Tabelle von llama.cpp für Llama 3.1 8B zeigt den Effekt: 14,96 GiB bei F16, 7,95 GiB bei Q8_0 und 4,58 GiB bei Q4_K_M [7]. Die Formel hält dem Vergleich mit echten Dateien stand. Qwen3-8B hat 8,2 Milliarden Parameter [17]. Mit den 4,89 Bits pro Gewicht, die llama.cpp für Q4_K_M angibt, ergeben 8,2 Milliarden × 4,89 ÷ 8 rund 5,0 GB, und die offizielle Q4_K_M-Datei von Qwen wiegt 5,03 GB [7][19].
3. Was Namen wie Q4_K_M verraten. GGUF ist das Modellformat von llama.cpp, und Hugging Face führt Ollama unter den Programmen, die es nutzen [11]. Die Typnamen beschreiben, wie die Gewichte gespeichert sind. Q8_0 legt Blöcke aus 32 Gewichten mit je 8 Bit ab. Die K-Quants Q6_K, Q5_K und Q4_K fassen Gewichte in Superblöcken zusammen und kommen auf 6,5625, 5,5 und 4,5 Bits pro Gewicht [11]. Eine Datei mit dem Etikett Q4_K_M liegt im Schnitt über ihrem Typ: llama.cpp nennt für Llama 3.1 8B 4,89 Bits pro Gewicht, für Q4_K_S 4,67 [7]. Teile einer solchen Datei nutzen also mehr Bits, als der Name vermuten lässt. Rechne deshalb mit dem Durchschnitt aus der Tabelle, nicht mit dem Nennwert des Typs.
4. Weniger Bits kosten Genauigkeit. Quantisierung senkt die Genauigkeit der gespeicherten Gewichte, das ist der Preis für die kleinere Datei. Wie viel Qualität dabei verloren geht, hängt von Modell und Aufgabe ab. Die Tabelle von llama.cpp nennt Größen und Geschwindigkeiten, aber kein Qualitätsmaß [7]. Die offiziellen GGUF-Dateien von Qwen reichen von Q4_K_M bis Q8_0 [19]. Unser Vorschlag: Probier zwei oder drei Stufen aus diesem Bereich mit deinen eigenen Prompts aus, bevor du dich festlegst.
5. Der KV-Cache, der vergessene Posten. Während ein Modell schreibt, behält es für jedes Token seines Kontexts in jeder Schicht einen Schlüssel und einen Wert. NVIDIA gibt die Größe pro Token mit 2 × Schichten × (Köpfe × Kopfdimension) × Bytes pro Wert an [13]. Viele aktuelle Modelle nutzen Grouped-Query Attention (GQA), die weniger Schlüssel- und Wert-Köpfe speichert und den Cache dadurch verkleinert [13]. Deshalb nimmst du aus der config.json des Modells die Zahl der Schlüssel-Wert-Köpfe (KV-Köpfe), nicht die der Attention-Köpfe: num_hidden_layers, num_key_value_heads und head_dim. Qwen3-8B hat zum Beispiel 36 Schichten, 8 KV-Köpfe und die Kopfdimension 128 [18]. Bei 2 Byte pro Wert (f16) sind das 2 × 36 × 8 × 128 × 2 = 147.456 Byte pro Token, also 1,21 GB für 8.192 Tokens und 4,83 GB für 32.768 Tokens. Die Formel passt für klassische Transformer-Modelle wie dieses. Bei anderen Bauarten verlass dich auf den Speicherwert, den deine Laufzeitumgebung anzeigt.
6. Kontextlänge: den Standard prüfen. Mit Stand 25.10.2026 legt die Ollama-Doku den Standardkontext nach VRAM fest: 4k Tokens unter 24 GiB, 32k von 24 bis 48 GiB und 256k ab 48 GiB [2]. Die FAQ nennt dagegen noch 4.096 Tokens als Standard [3]; prüf also mit ollama ps, was du tatsächlich bekommen hast (siehe unten). Für Agenten, Websuche und Programmierwerkzeuge empfiehlt Ollama mindestens 64.000 Tokens [2]. Du änderst die Länge mit dem Schieberegler in der App, mit der Umgebungsvariable OLLAMA_CONTEXT_LENGTH oder pro Anfrage mit num_ctx [2][3]. Der Server von llama.cpp übernimmt die Kontextgröße aus dem Modell, solange du keine setzt [8]. Seine Fit-Option, standardmäßig an, passt nicht gesetzte Werte an, bis alles in den Speicher passt, geht beim Kontext aber nicht unter 4.096 Tokens [8].
7. Ein kleinerer Cache. Beide Programme können den Cache mit weniger Bits speichern. In Ollama braucht OLLAMA_KV_CACHE_TYPE=q8_0 etwa die Hälfte des Speichers von f16, dem Standard, bei sehr kleinem Genauigkeitsverlust; q4_0 braucht etwa ein Viertel, bei kleinem bis mittlerem Verlust [3]. Das funktioniert mit eingeschalteter Flash Attention, die Ollama automatisch nutzt, wenn Backend und Geräte sie unterstützen, und die Einstellung gilt für alle Modelle zugleich [3]. In llama.cpp legen --cache-type-k und --cache-type-v die Typen fest; Standard ist f16 [8].
8. Wenn das Modell nicht passt. Beide Programme können ein Modell auf VRAM und Arbeitsspeicher aufteilen [3][9]. ollama ps zeigt dann eine Aufteilung wie 48%/52% CPU/GPU statt 100% GPU [3]. In llama.cpp legt -ngl fest, wie viele Schichten in den VRAM kommen [8]. Das Erzeugen von Text ist speichergebunden: Das Tempo bestimmt, wie schnell Daten aus dem Speicher kommen, nicht die Rechenleistung [13]. Jede Schicht im Arbeitsspeicher kostet deshalb bei jedem Token Zeit, und Ollama empfiehlt für die beste Leistung, nichts auf die CPU auszulagern [2]. Der ausgelagerte Teil braucht außerdem freien Arbeitsspeicher; die Grundlagen stehen auf unserer Seite zu RAM.
9. NVIDIA, AMD, Apple oder nur der Prozessor. Ollama unterstützt NVIDIA-Karten ab Compute Capability 5.0 mit Treiber 550 oder neuer; Karten mit Compute Capability 5.0 bis 6.2 brauchen Treiber 570 oder neuer [1]. AMD-Karten brauchen unter Linux den Treiber ROCm v7, und die Liste enthält Modelle der Serien Radeon RX 9000, 7000 und 6000 [1]. Unter Windows nennt Ollamas ROCm-Liste nur sieben Modelle der Radeon RX 7000 und die Radeon PRO W7500 bis W7900 [1]. Vulkan bringt Unterstützung für weitere GPUs unter Windows und Linux und ist standardmäßig aktiv, wenn sein Backend installiert ist [1]. Auf Apple-Geräten nutzt Ollama Metal [1]. Auf einem Mac mit Apple-Chip teilen sich Prozessor und GPU den Arbeitsspeicher [27], und Metal meldet für jedes Gerät, wie viel Speicher die GPU belegen kann, ohne Leistung zu verlieren (recommendedMaxWorkingSetSize) [14]. Plane also mit diesem Wert, nicht mit dem gesamten Arbeitsspeicher. Ohne GPU nutzt llama.cpp auf x86-Prozessoren AVX, AVX2, AVX-512 und AMX und auf Apple-Chips ARM NEON [9]. Unsere Einschätzung: Für kleine Modelle geht das, aber weil die Textausgabe speichergebunden ist, rechne mit weniger Tokens pro Sekunde als auf einer Grafikkarte, und miss sie [13].
10. Mixture-of-Experts-Modelle zählen voll. Manche Modelle nutzen pro Token nur einen Teil ihrer Gewichte. Qwen3-30B-A3B hat 30,5 Milliarden Parameter, davon 3,3 Milliarden aktiv [22]. Für den Speicher zählt die Gesamtzahl, denn alle Experten müssen geladen sein [12]. Die offizielle Q4_K_M-Datei wiegt entsprechend 18,6 GB [24]. Der Vorteil laut Hugging Face: Der Rechenaufwand pro Token ähnelt dem eines deutlich kleineren Modells [12].
11. Lokal bleibt lokal, wenn du es zulässt. Laut Ollama sieht der Anbieter deine Prompts und Daten nicht, wenn du Modelle lokal betreibst [3]. Die Cloud-Modelle laufen dagegen auf Ollamas Servern; in App und CLI tragen sie Namen wie gemma4:cloud und verlangen eine Anmeldung [5]. Soll nichts deinen Rechner verlassen, setz OLLAMA_NO_CLOUD=1 oder disable_ollama_cloud in ~/.ollama/server.json [3]. Der lokale Server lauscht auf 127.0.0.1, Port 11434 [3]. Laut Ollama-Doku braucht diese lokale Schnittstelle keine Authentifizierung [28], also lass sie dort. In Docker heißt das: 127.0.0.1 in die Portfreigabe schreiben; das Beispiel der Doku gibt schlicht 11434:11434 frei [6].

Was wohin passt: vier Modelle im Vergleich

Hier die Rechnung für eine Modellfamilie, mit den offiziellen Q4_K_M-Dateien und einem f16-Cache. Schichten und Köpfe stammen aus der config.json des jeweiligen Modells, die Dateigrößen aus den offiziellen Downloadlisten, und alle vier Modelle haben die Kopfdimension 128 [18][20][23][25]. Die Summen sind unsere Rechnung, keine Messung.

Als VRAM-Größen gelesen (unsere Lesart): Mit 8 GB passt nur das 8B-Modell, bei 8.192 Tokens und knapp. 12 GB nehmen das 8B-Modell mit 32.768 Tokens auf (10,9 GB) oder das 14B-Modell mit 8.192 Tokens. 16 GB fassen das 14B-Modell bei 32.768 Tokens nur gerade so (15,4 GB). Mit 24 GB passt das Mixture-of-Experts-Modell sogar bei 32.768 Tokens (22,9 GB), das dichte 32B-Modell bei 8.192 Tokens. Hugging Face gibt Dateigrößen in GB an (10⁹ Byte), die Tabelle von llama.cpp und viele Werkzeuge rechnen dagegen in GiB (2³⁰ Byte), pro Einheit etwa 7 % mehr [16]. Diese Tabelle nutzt durchgehend GB.

Für Byte, unser KI-Maskottchen, rechnen wir genauso: Sein Sprachmodell hat 9 Milliarden Parameter und läuft mit 4 Bit quantisiert unter llama.cpp auf einem separaten Laptop in unserem Netz, wie unsere Seite zu LLMs beschreibt. Eine Messung von diesem Rechner enthält dieser Guide nicht.

Messen statt schätzen

Lade das Modell und schau, was Ollama meldet. ollama ps zeigt für jedes geladene Modell die Größe, die Aufteilung zwischen Prozessor und Grafikkarte, den reservierten Kontext und wie lange es im Speicher bleibt [2][3]. So sieht das Beispiel aus der Ollama-Doku aus:

NAME             ID              SIZE      PROCESSOR    CONTEXT    UNTIL
gemma4:latest    c6eb396dbd59    9.6 GB    100% GPU     131072     2 minutes from now

Ziel ist 100% GPU. Taucht ein CPU-Anteil auf, verkleinere den Kontext oder nimm eine kleinere Quantisierung oder ein kleineres Modell.

Für die Geschwindigkeit liefert die API von Ollama zu jeder Antwort Nutzungsfelder, beim Streamen im letzten Teil: eval_count ist die Zahl der erzeugten Tokens, eval_duration die Zeit dafür in Nanosekunden [4]. Tokens pro Sekunde = eval_count ÷ eval_duration × 1.000.000.000. Eine Anfrage wie die aus der Ollama-FAQ genügt; ersetz llama3.2 durch dein Modell [3]:

curl http://localhost:11434/api/generate -d '{
  "model": "llama3.2",
  "prompt": "Why is the sky blue?",
  "options": {
    "num_ctx": 4096
  }
}'

Zur Veranschaulichung der Rechnung: Die Beispielantwort in der Ollama-Doku nennt 18 Tokens in 52.479.709 Nanosekunden, also etwa 343 Tokens pro Sekunde [4]. Dieses Beispiel stammt von unbekannter Hardware und sagt nichts über deinen PC. Mit llama.cpp misst llama-bench standardmäßig die Prompt-Verarbeitung (pp 512) und die Textausgabe (tg 128), wiederholt jeden Test fünfmal und meldet den Mittelwert mit Standardabweichung [10]. Notier zu jedem Ergebnis Datum, Modelldatei, Quantisierung, Kontext und Treiberversion.

Für den Strom misst du den ganzen PC an der Steckdose mit einem Energiemessgerät, einmal im Leerlauf und einmal, während das Modell schreibt. Ollama hält ein Modell standardmäßig 5 Minuten nach der letzten Anfrage im Speicher [3]; warte also, bis ollama ps es nicht mehr anzeigt, bevor du den Leerlauf misst. Auf NVIDIA-Karten zeigt nvidia-smi zusätzlich Leistungsaufnahme und Speicherbelegung der Karte; -d POWER,MEMORY beschränkt die Ausgabe auf diese Werte, und -l 1 wiederholt sie jede Sekunde [15]:

nvidia-smi -q -d POWER,MEMORY -l 1

Der Wert der Karte lässt Prozessor, RAM und die Verluste des Netzteils weg; für die Kosten zählt deshalb das Messgerät an der Steckdose. Die Rechnung kennst du aus unserem Guide zu Stromkosten: kWh = Watt × Stunden ÷ 1.000, Kosten = kWh × dein Arbeitspreis. Angenommene Werte, keine Messung: 300 W an der Steckdose für zwei Stunden am Tag ergeben 0,6 kWh pro Tag und 219 kWh im Jahr, also 87,60 € beim Beispielpreis von 0,40 € pro kWh aus diesem Guide.

Vor dem Kauf

Eine bestimmte Karte empfehlen wir nicht; diese Kriterien entscheiden. Erstens die Modelle und der Kontext, die du wirklich nutzen willst: die Summe aus der Tabelle oder aus deiner eigenen Rechnung, plus Reserve. Zweitens die Unterstützung genau deiner Karte und deines Betriebssystems in Ollamas Liste, besonders bei AMD unter Windows [1]. Drittens Netzteil, Stecker und Platz im Gehäuse; unser Guide zum Grafikkarten-Upgrade zeigt, wie du das prüfst. Viertens der Preis pro Gigabyte VRAM am Kauftag, notiert mit Datum. Preise nennen wir keine.

Prüfliste

• Schlag Schichten, KV-Köpfe und Kopfdimension in der config.json des Modells nach.
• Berechne die Gewichte als Parameter × Bits pro Gewicht ÷ 8, mit dem Durchschnitt aus der Tabelle von llama.cpp.
• Addiere den KV-Cache für deine Kontextlänge und eine Reserve von etwa 1 GB.
• Setz die Kontextlänge ausdrücklich, statt dich auf den Standard zu verlassen.
• Führ ollama ps aus und prüf, ob unter PROCESSOR 100% GPU steht.
• Miss die Tokens pro Sekunde aus eval_count und eval_duration und notier das Datum.
• Miss den Strom an der Steckdose im Leerlauf und unter Last und rechne die Kosten mit deinem Arbeitspreis aus.
• Setz OLLAMA_NO_CLOUD=1, wenn nichts deinen PC verlassen soll, und lass Port 11434 auf 127.0.0.1.
• Prüf vor dem Kauf einer Karte die Herstellerliste in Ollamas GPU-Doku.

Passt dazu: Large Language Model / LLM; Grafikkarte aufrüsten: Netzteil, Platz, Stecker; Arbeitsspeicher / RAM; Homelab-Stromkosten korrekt berechnen; Container und OCI.