Ollama Performance-Optimierung: Quantisierung, Batching und Speicher-Tuning

Aktualisiert am 2026-06-08: Umgebungsvariablen anhand der offiziellen Ollama-Doku geprüft — GPU-Layer werden über die Modelloption num_gpu gesetzt (es gibt kein OLLAMA_GPU_LAYERS); VRAM mit OLLAMA_GPU_OVERHEAD (Bytes) reservieren; KV-Cache-Quantisierung über OLLAMA_KV_CACHE_TYPE. Benchmarks sind Richtwerte und variieren je nach Version und Hardware.

Ihr 14B-Modell läuft – aber nur mit 10 tokens/s? Oder bricht es mit OOM ab? Die GPU-Lüfter heulen, der Bildschirm wird schwarz.

Kennen Sie das: llama3 8B heruntergeladen, ollama run – und der VRAM reicht nicht. Entweder Abbruch mit Fehler oder Tempo wie eine Schnecke. Mit einer Q4-Quantisierung geht es dann – aber wie viel Qualität ist wirklich weg?

Am Anfang mit Ollama habe ich genau diese Fallen getroffen: 8 GB VRAM und ein 14B-Modell – „läuft doch, wenn es startet“. Ergebnis: CUDA out of memory oder Token für Token.

Das Problem ist selten die Hardware. Die Konfiguration stimmt nicht.

Hier geht es um drei Hebel: Quantisierung, Batching und Speicher-Tuning. Wer die versteht, holt aus dem lokalen LLM oft mindestens das Doppelte an tokens/s – messbar, nicht Marketing-„Verdopplung“.

1. Quantisierung – Qualität und Tempo von Q4 bis FP16

1.1 Was ist Quantisierung? Warum GGUF Standard ist

Kurz gesagt: Quantisierung macht das Modell kleiner.

Große Modelle liegen oft als FP16 (16-Bit-Float) vor. Ein 7B-Modell braucht so allein ~14 GB VRAM. Statt 16 Bit pro Parameter nur 4 Bit? Theoretisch ~3,5 GB. Weniger Bits → weniger Speicher, schnellere Inferenz.

Preis: Genauigkeit. Wie 4K auf 720p – Details fehlen, in vielen Szenarien reicht es.

GGUF ist Standard, weil es praktisch ist: vom llama.cpp-Team, mit Memory-Mapping (mmap). Nicht alles muss auf einmal in den RAM – 16 GB System-RAM können ein 13B-Modell tragen, was klassische Formate nicht schaffen.

1.2 Q4_0, Q4_K_M, Q5_K_M, Q8_0 im Vergleich

Q4_0, Q4_1, Q4_K_M, Q5_K_M, Q8_0 – welche wählen?

Quantisierung	Kompression	Speicher (7B)	Qualitätsverlust	Einsatz
Q4_0	ca. 4,5×	ca. 4,0 GB	größer	knappster VRAM, Qualität sekundär
Q4_K_M	ca. 4,5×	ca. 4,7 GB	sehr gering	Preis-Leistung, Alltag
Q5_K_M	ca. 3,5×	ca. 5,8 GB	minimal	Qualität zuerst, VRAM reicht
Q8_0	ca. 2×	ca. 7,2 GB	fast keiner	beste Qualität, viel VRAM
FP16	1×	ca. 14 GB	keiner	Forschung, starke GPU

Q4_K_M ist die Standardempfehlung – kaum spürbarer Unterschied zu FP16 im Alltags-Chat. Q5_K_M, wenn VRAM locker ist. Q8_0 lohnt sich eher ab 24 GB VRAM – dann oft lieber größeres Modell.

1.3 Entscheidungsbaum

Schritt 1: VRAM

• ≤ 8 GB: meist Q4_K_M, 7B knapp, 14B mit CPU-Offload
• 12–16 GB: 14B mit Q4_K_M, 7B mit Q5_K_M möglich
• ≥ 24 GB: Q5_K_M oder Q8_0, auch 70B denkbar

Schritt 2: Anforderung

• Chat, Code: Q4_K_M
• Übersetzung, Text mit hoher Qualität: Q5_K_M
• Forschung, Benchmarks: Q8_0 oder FP16

Orientierung:

• 7B Q4_K_M: ~4,7 GB VRAM
• 14B Q4_K_M: ~9 GB VRAM
• 70B Q4_K_M: ~40 GB VRAM

Tipp: mit Q4_K_M starten. Wirkt die Antwort schwach → Q5_K_M. „Verlustfrei“ ist oft Placebo.

1.4 Bestimmte Quantisierung laden

Ollama lädt standardmäßig Q4_K_M.

# Standard Q4_K_M
ollama run llama3

# Q5
ollama run llama3:70b-q5

# Q8
ollama run llama3:70b-q8

Nicht jedes Modell hat alle Tags. Ollama-Modellbibliothek oder:

# Lokale Modelle
ollama list

# Details inkl. Quantisierung
ollama show llama3 --modelfile

Eigenes Quantisieren mit llama.cpp ist möglich – hier nicht vertieft.

2. Batching – Durchsatz +50 bis 150 %

2.1 Warum Batching hilft

Analog Supermarkt-Kasse: ein Kunde nach dem anderen ist langsam; mehrere Warenketten parallel nutzen die Kasse besser.

Bei der GPU wartet die Recheneinheit oft auf Speicher – ein Token pro Schritt = Leerlauf. Mehrere Tokens im Batch = höhere Auslastung.

Batching erhöht den Durchsatz, nicht zwingend die Latenz eines einzelnen Requests. Allein zu Hause merken Sie wenig; bei API mit vielen parallelen Anfragen kann der Durchsatz stark steigen.

2.2 Parameter num_batch

num_batch ist der zentrale Batching-Parameter, Standard 512.

Größer → mehr GPU-Auslastung und Durchsatz, aber +20–40 % VRAM.

VRAM	num_batch	Effekt
knapp	512 (Default)	sicher, GPU evtl. unterausgelastet
mittel	1024	Durchsatz +50–80 %
großzügig	2048	Durchsatz +100–150 %

Praxis: RTX 3080 (10 GB), 7B Q4_K_M → num_batch 1024 stabil; 2048 gelegentlich OOM. RTX 4090, 14B → 2048 unkritisch.

2.3 num_ctx und KV Cache

num_ctx = Kontextfenster, Default 2048. Größerer Kontext → mehr KV-Cache.

Der Cache speichert frühere Berechnungen, damit nichts doppelt gerechnet wird.

Grobe Formel:

KV Cache ≈ 2 × Layer × Hidden × num_ctx × Bytes pro Wert

Beispiele:

• 7B, num_ctx=4096: +~1–2 GB
• 14B, num_ctx=8192: +~3–4 GB

Bei 32K/128K explodiert oft der Cache, nicht nur die Modellgewichte. llama3 unterstützt 128K – so groß setzen Sie selten; 4096 oder 8192 reichen meist.

2.4 Batching in der Praxis

Variante 1: Modelfile

FROM llama3

PARAMETER num_batch 1024
PARAMETER num_ctx 4096
PARAMETER num_keep 128

ollama create my-llama3 -f Modelfile
ollama run my-llama3

Variante 2: API options

curl http://localhost:11434/api/generate -d '{
  "model": "llama3",
  "prompt": "Erkläre Quantencomputing",
  "options": {
    "num_batch": 1024,
    "num_ctx": 4096
  }
}'

Benchmark (RTX 3080, 7B Q4_K_M):

num_batch	Durchsatz (tokens/s)	VRAM
512	45	5,2 GB
1024	72	6,1 GB
2048	98	7,4 GB

512 → 1024: +60 % Durchsatz, <1 GB mehr VRAM – lohnt sich oft.

3. Speicher-Tuning – drei Strategien gegen OOM

3.1 GPU-Speicher in Ollama

Ollama prüft automatisch: passt das Modell in den VRAM? Ja → alles auf GPU. Nein → Teile auf die CPU (Offload).

Trotzdem Grenzfälle und OOM. num_gpu: wie viele Layer auf der GPU (-1 = auto). z. B. num_gpu: 20 → nur 20 Layer auf GPU, Rest CPU.

3.2 Strategie 1: Quantisierung senken

Einfachster Weg bei OOM:

Q8_0 → Q5_K_M → Q4_K_M → Q4_0

Pro Stufe ~20–25 % weniger VRAM.

Beispiel: 14B Q5_K_M ~11 GB → OOM → Q4_K_M ~9 GB (−18 % VRAM), im Chat oft kaum spürbar.

8 GB VRAM: 7B Q4_K_M ok; 14B Q4_K_M mit langem Kontext OOM → 14B Q4_0 als Kompromiss.

3.3 Strategie 2: CPU-Offload

num_gpu begrenzt GPU-Layer. 32 Layer, num_gpu: 24 → 8 Layer auf CPU.

CPU ist oft >10× langsamer – aber besser als gar nicht laufen.

FROM llama3
PARAMETER num_gpu 24

curl http://localhost:11434/api/generate -d '{
  "model": "llama3",
  "prompt": "Hallo",
  "options": {
    "num_gpu": 24
  }
}'

Hybrid (14B Q4_K_M, RTX 3080 10 GB + i7-12700K):

num_gpu	Speed	VRAM
40 (volle GPU)	OOM	12 GB
30	18 tokens/s	9,2 GB
20	12 tokens/s	6,5 GB
0 (nur CPU)	4 tokens/s	0,5 GB

num_gpu: 30 ist oft ein guter Kompromiss.

3.4 Strategie 3: KV-Cache optimieren

Flash Attention

export OLLAMA_FLASH_ATTENTION=1

# Docker
docker run -e OLLAMA_FLASH_ATTENTION=1 ollama/ollama

KV-Cache oft −30 bis −50 % VRAM – stark empfohlen.

num_ctx verkleinern

PARAMETER num_ctx 2048

num_keep – System-Prompt vor dem Sliding-Window schützen:

PARAMETER num_keep 128

3.5 OOM-Checkliste

Schritt 1: VRAM

nvidia-smi

Schritt 2: Modellparameter

ollama show llama3 --modelfile

num_ctx, num_batch zu groß?

Schritt 3: schrittweise senken

• num_batch: 1024 → 512
• num_ctx: 4096 → 2048
• Quantisierung: Q5_K_M → Q4_K_M

Schritt 4: CPU-Offload – num_gpu ~70–80 % der Layer

Schritt 5: nur CPU

# Reines CPU per Modelloption num_gpu=0 erzwingen (API oder Modelfile)
curl http://localhost:11434/api/generate -d '{"model":"llama3","prompt":"hallo","options":{"num_gpu":0}}'

~1/10 der GPU-Geschwindigkeit – für Gelegenheits- oder Batch-Nutzung ok.

4. Benchmarks und Hardware

4.1 Inferenzgeschwindigkeit

NVIDIA (7B Q4_K_M)

GPU	VRAM	tokens/s	Hinweis
RTX 3060	12 GB	52	Preis-Leistung
RTX 3080	10 GB	68	stabil
RTX 3090	24 GB	95	14B Q4 möglich
RTX 4070 Ti	12 GB	78	neue Architektur
RTX 4090	24 GB	120	High-End

NVIDIA (14B Q4_K_M)

GPU	VRAM	tokens/s	Hinweis
RTX 3060	12 GB	28	knapp
RTX 3080	10 GB	OOM	Offload nötig
RTX 3090	24 GB	55	komfortabel
RTX 4090	24 GB	72	sehr schnell

Apple Silicon (Metal)

Gerät	RAM	7B tokens/s	14B tokens/s
M2 Air 8 GB	8 GB	35	OOM
M2 Pro 16 GB	16 GB	48	22
M2 Max 32 GB	32 GB	58	32
M2 Ultra 64 GB	64 GB	65	45

Unified Memory hilft; Spitzen-Throughput oft unter Top-NVIDIA.

Nur CPU

CPU	RAM	7B tokens/s	14B tokens/s
i7-12700K	32 GB	6	3
Ryzen 9 7950X	64 GB	8	4
M2 Max (CPU only)	32 GB	12	6

Für Echtzeit-Chat ungeeignet; Batch ok.

4.2 Batching und Durchsatz

RTX 3080, 7B Q4_K_M, viele parallele Requests

num_batch	Latenz/Request	Durchsatz	VRAM
512	22 ms/token	45 tokens/s	5,2 GB
1024	22 ms/token	72 tokens/s	6,1 GB
2048	22 ms/token	98 tokens/s	7,4 GB

• Latenz pro Request fast gleich
• Durchsatz bei 2048 vs. 512: +118 %
• Kosten: +2,2 GB VRAM

4.3 Umgebungsvariablen

# Flash Attention (empfohlen)
export OLLAMA_FLASH_ATTENTION=1

# KV-Cache-Quantisierung: f16(Default)/q8_0(~halb)/q4_0(~viertel), braucht Flash Attention
export OLLAMA_KV_CACHE_TYPE=q8_0

# VRAM für System/andere Apps reservieren (Bytes, Default 0)
export OLLAMA_GPU_OVERHEAD=1073741824  # 1 GB reservieren

# Modell im Speicher halten
export OLLAMA_KEEP_ALIVE=24h

# Standard-Kontextlänge (überschreibt Modell-Default)
export OLLAMA_CONTEXT_LENGTH=4096

# Warteschlange
export OLLAMA_MAX_QUEUE=512

# Debug
export OLLAMA_DEBUG=1

Docker Compose

version: '3'
services:
  ollama:
    image: ollama/ollama
    container_name: ollama
    restart: unless-stopped
    environment:
      - OLLAMA_FLASH_ATTENTION=1
      - OLLAMA_KEEP_ALIVE=24h
      - OLLAMA_MAX_QUEUE=512
    volumes:
      - ollama_data:/root/.ollama
    ports:
      - "11434:11434"
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]

volumes:
  ollama_data:

docker-compose up -d

Weiterführend

• Ollama GPU-Beschleunigung: vollständige Konfiguration
• Lokale Embeddings und RAG mit Ollama
• Llama 70B: Hardware-Leitfaden für lokale Modelle

Fazit

Drei Schritte:

1. Quantisierung – VRAM prüfen, Q4_K_M als Default, bei Spielraum Q5_K_M.

2. Batching – VRAM übrig? num_batch 1024 oder 2048 – Durchsatz oft verdoppelt.

3. OOM – Flash Attention, kleineres num_ctx, CPU-Offload – der Reihe nach.

Optimierung ist iterativ: Hardware, Modellgröße und Use Case unterscheiden sich. Erst lauffähige Quantisierung, dann Batching, dann Env-Vars.

Konkrete Fehler oder Modell-Tags: Ollama-Docs und Community – oft praxisnäher als Theorie allein.