Ollama für Geschwindigkeit und Speicher optimieren

Ollama ist der schnellste Weg, ein lokales Modell zum Laufen zu bringen — ollama run llama3 und Sie servieren bereits. Unter der Haube umgibt es llama.cpp (und MLX auf Apple Silicon) und stellt eine Reihe von Umgebungsvariablen und Modellparametern bereit, die steuern, wie es Ihre Hardware nutzt. Die Standardwerte funktionieren für gelegentliche Nutzung, lassen aber erhebliche Leistung ungenutzt. Dieser Leitfaden behandelt jede wichtige Stellschraube und wie Sie sie für Ihre Workload setzen.

Zuletzt überprüft: 2026-10-14 — Ollama v0.33.2.

Apple Silicon verwendet MLX. Beginnend mit Ollama 0.19 ist das Standard-Backend auf Apple Silicon Apples MLX-Framework statt llama.cpp. MLX liefert erheblich schnellere Inferenz auf M-Series-Chips (siehe Apple Silicon and MLX optimization). Die meisten Umgebungsvariablen in diesem Leitfaden gelten für beide Backends; wo das Verhalten abweicht, wird es explizit hervorgehoben.

Kontextfenster-Abstimmung

Das Kontextfenster (num_ctx) steuert, wie viele Token das Modell in einer einzigen Anfrage verarbeiten kann — Ihr Prompt plus die generierte Antwort zusammen. Es ist der größte Treiber des Speicherverbrauchs nach den Modellgewichten selbst.

Wie Sie das Ollama-Kontextfenster erhöhen

Ollama verwendet standardmäßig ein 2048-Token-Kontextfenster. Die meisten modernen Modelle unterstützen 8K, 32K oder sogar 128K Token, aber Ollama nutzt standardmäßig nicht das Maximum des Modells — es verwendet 2048, um den Speicherverbrauch vorhersehbar zu halten. Setzen Sie es auf 3 Arten, von am spezifischsten bis am globalsten: Pro Anfrage (API):

curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3",
    "messages": [{"role": "user", "content": "Summarize this document..."}],
    "options": {
      "num_ctx": 32768
    }
  }'

In einem Modelfile (persistent pro Modell):

FROM llama3
PARAMETER num_ctx 32768

Dann bauen und starten Sie das benutzerdefinierte Modell:

ollama create llama3-32k -f Modelfile
ollama run llama3-32k

Global (alle Modelle, alle Anfragen):

# Linux (systemd)
sudo systemctl edit ollama.service
# Add: Environment="OLLAMA_CONTEXT_LENGTH=32768"
sudo systemctl daemon-reload && systemctl restart ollama

Windows

[System.Environment]::SetEnvironmentVariable("OLLAMA_CONTEXT_LENGTH", "32768", "User")
# Restart Ollama

macOS

launchctl setenv OLLAMA_CONTEXT_LENGTH 32768
# Restart Ollama

Kontextfenster-Speicherkosten

Der KV-Cache wächst linear mit der Kontextlänge. Die Formel:

KV cache memory = 2 × num_layers × hidden_dim × num_ctx × precision_bytes

Für ein 7B-Modell (32 Schichten, 4096 Hidden-Dimension) bei f16-Präzision:

Context length	KV cache memory
2,048 (default)	~1 GB
8,192	~4 GB
32,768	~16 GB
128,000	~64 GB

Setzen Sie num_ctx nur so hoch, wie Ihre Workload es tatsächlich braucht. Ein Coding-Agent, der 2K-Prompts sendet, profitiert nicht von einem 128K-Kontextfenster — er verschwendet nur 64 GB KV-Cache-Speicher, der andere Anfragen bedienen oder ein größeres Modell fassen könnte.

Flash Attention

Flash Attention ist das Nächste an einer kostenlosen Leistungsverbesserung, die Ollama bietet. Es überarbeitet, wie das Modell die Attention zwischen Token berechnet — statt die volle Attention-Matrix im Speicher zu materialisieren, berechnet es Attention in gekachelten Blöcken, die in schnellen SRAM passen. Das Ergebnis:

30-50% niedrigere Speichernutzung für den KV-Cache — der größte Gewinn bei langen Kontextlängen.
Schnellere Inferenz — besonders auf GPU, wo die gekachelte Berechnung gut auf Tensor-Cores abbildet.
Gleiche Ausgabequalität — Flash Attention ist mathematisch äquivalent zu Standard-Attention, keine Approximation.

Flash Attention in Ollama aktivieren

Setzen Sie die Umgebungsvariable:

# Linux (systemd)
sudo systemctl edit ollama.service
# Add: Environment="OLLAMA_FLASH_ATTENTION=1"
sudo systemctl daemon-reload && systemctl restart ollama

Windows

[System.Environment]::SetEnvironmentVariable("OLLAMA_FLASH_ATTENTION", "1", "User")
# Restart Ollama

macOS

launchctl setenv OLLAMA_FLASH_ATTENTION 1
# Restart Ollama

Aktivieren Sie immer Flash Attention. Es gibt keinen Grund, es wegzulassen, außer Sie stoßen auf ein Kompatibilitätsproblem mit einem bestimmten Modell oder einer bestimmten Plattform. Es ist die Einstellung mit der höchsten Auswirkung in diesem Leitfaden.

Auf Apple Silicon mit dem MLX-Backend ist Flash Attention standardmäßig aktiviert und die Variable OLLAMA_FLASH_ATTENTION hat keinen Effekt — MLX verwendet immer optimierte Attention-Kernel.

GPU-Offload-Strategie

Ollama lädt automatisch Modellschichten auf Ihre GPU. Wenn das vollständige Modell in den VRAM passt, laufen alle Schichten auf der GPU für maximale Geschwindigkeit. Wenn der VRAM knapp ist, teilt Ollama Schichten zwischen GPU und CPU auf — die GPU führt aus, was sie kann, und der Rest fällt auf den System-RAM zurück.

Wie Ollama GPU-Schichten entscheidet

Ollamas GPU-Scheduling funktioniert in dieser Reihenfolge:

Vollständiges Offload — wenn die Modellgewichte + KV-Cache in den VRAM passen, gehen alle Schichten auf die GPU. Das ist die schnellste Konfiguration.
Partielles Offload — wenn das Modell nicht vollständig passt, legt Ollama so viele Schichten auf die GPU, wie der VRAM erlaubt, und führt den Rest auf der CPU aus. Die Leistung verschlechtert sich, weil jeder Forward-Pass für CPU-residente Schichten den PCIe-Bus überqueren muss.
Nur CPU — wenn keine GPU verfügbar ist oder der VRAM sogar für wenige Schichten zu klein ist, läuft das gesamte Modell auf der CPU.

GPU-Schichten steuern mit `num_gpu`

Der Parameter num_gpu setzt, wie viele Schichten auf die GPU ausgelagert werden. Setzen Sie ihn in einem Modelfile oder pro Anfrage:

Modelfile

FROM llama3
PARAMETER num_gpu 35

API

curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3",
    "messages": [{"role": "user", "content": "Hello"}],
    "options": {
      "num_gpu": 35
    }
  }'

`num_gpu` value	Behavior
`-1`	All layers on GPU (same as setting it to the total layer count)
`0`	No GPU offload — CPU only
`1` to `N`	Exactly that many layers on GPU, rest on CPU
Not set (default)	Ollama auto-detects based on available VRAM

Lassen Sie num_gpu ungesetzt und lassen Sie Ollama in den meisten Fällen automatisch erkennen. Setzen Sie ihn nur manuell, wenn Sie eine bestimmte Aufteilung erzwingen müssen — zum Beispiel, um VRAM für ein größeres Kontextfenster zu reservieren oder einige Schichten auf der CPU zu halten für ein Modell, das knapp passt.

VRAM-Budgetierung

Jede ausgelagerte Schicht verbraucht VRAM für sowohl Gewichte als auch KV-Cache. Eine grobe Schätzung:

VRAM per layer ≈ (parameters_per_layer × bytes_per_weight) + (KV_cache_per_layer × num_ctx)

Für ein 7B-Modell bei Q4_K_M (~4.5 Bits pro Gewicht, ~32 Schichten):

Component	Per layer	32 layers total
Weights	~0.19 GB	~6 GB
KV cache (f16, 8K ctx)	~0.13 GB	~4 GB
Total		~10 GB

Lassen Sie 1-2 GB VRAM-Spielraum für CUDA-Kontext und Overhead.

Wenn Sie num_ctx erhöhen, wächst der KV-Cache und kann Schichten aus dem VRAM drängen. Wenn Sie num_ctx 32768 setzen und Ollama plötzlich die Hälfte der Schichten auf die CPU auslagert, hat der KV-Cache Ihr VRAM-Budget aufgebraucht. Reduzieren Sie entweder num_ctx, verwenden Sie eine kleinere Quantisierung oder aktivieren Sie Flash Attention, um den KV-Cache zu verkleinern.

KV-Cache-Präzision

Der KV-Cache speichert Key- und Value-Tensoren für jedes Token in jeder aktiven Sequenz. Standardmäßig verwendet Ollama f16 (16-Bit-Gleitkommazahl). Sie können auf quantisierte Präzision wechseln, um den Speicherverbrauch auf Kosten einer kleinen Qualität zu reduzieren. Setzen Sie den Cache-Typ mit der Umgebungsvariable OLLAMA_KV_CACHE_TYPE:

# Linux (systemd)
sudo systemctl edit ollama.service
# Add: Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
sudo systemctl daemon-reload && systemctl restart ollama

Cache type	Memory per element	Quality	When to use
`f16` (default)	2 bytes	Baseline	Maximum quality; you have plenty of memory
`q8_0`	1 byte	Near-identical to f16	Best balance — halves KV cache memory with negligible quality loss
`q4_0`	0.5 bytes	Slight degradation	Tight memory; long context or many concurrent sequences

# Halve KV cache memory
OLLAMA_KV_CACHE_TYPE=q8_0

# Quarter KV cache memory
OLLAMA_KV_CACHE_TYPE=q4_0

Kombinieren Sie OLLAMA_KV_CACHE_TYPE=q8_0 mit OLLAMA_FLASH_ATTENTION=1 für den größten Speichergewinn. Flash Attention reduziert den KV-Cache-Footprint um 30-50%, und q8_0 halbiert ihn erneut — zusammen können sie den KV-Cache-Speicher um 60-75% im Vergleich zum Standard reduzieren.

q4_0-KV-Cache führt einen messbaren Qualitätsverlust bei Aufgaben ein, die auf präzise Attention über langen Kontext angewiesen sind — Needle-in-a-Haystack-Abfrage, Multi-Dokument-Zusammenfassung und lange Gespräche. Testen Sie Ihre spezifische Workload, bevor Sie sich für q4_0 entscheiden.

Thread-Konfiguration

Der Parameter num_thread steuert, wie viele CPU-Threads Ollama für Inferenz verwendet. Der richtige Wert hängt davon ab, wie viel Arbeit die CPU tatsächlich tut. Setzen Sie ihn in einem Modelfile oder pro Anfrage:

Modelfile

FROM llama3
PARAMETER num_thread 8

API

curl http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3",
    "messages": [{"role": "user", "content": "Hello"}],
    "options": {
      "num_thread": 8
    }
  }'

Sie können ihn auch global mit OLLAMA_NUM_THREADS setzen:

# Linux (systemd)
sudo systemctl edit ollama.service
# Add: Environment="OLLAMA_NUM_THREADS=8"
sudo systemctl daemon-reload && systemctl restart ollama

Scenario	Thread guidance
Full GPU offload (all layers on GPU)	`num_thread 2` to `num_thread 4` — the CPU handles orchestration and tokenization, not math
Partial GPU offload (some layers on CPU)	Set `num_thread` to the number of physical cores on your CPU — not hyperthreads
CPU-only (no GPU)	Set `num_thread` to the number of physical cores

Mehr Threads sind nicht immer schneller. Jenseits der Anzahl physischer Kerne konkurrieren Threads um Cache und Speicherbandbreite und können Inferenz verlangsamen. Im Zweifel, starten Sie mit der physischen Kernanzahl und benchmarken von dort.

Auf Apple Silicon ist Thread-Abstimmung weniger wichtig, da GPU und CPU sich einheitlichen Speicher teilen und das MLX-Backend das Scheduling übernimmt. Der Standard funktioniert normalerweise gut.

Batch-Größen-Abstimmung

Der Parameter num_batch steuert, wie viele Token Ollama auf einmal während der Prefill-Phase verarbeitet (Prompt-Aufnahme). Der Standard ist 512.

Modelfile

FROM llama3
PARAMETER num_batch 1024

Setting	Effect
`num_batch 512` (default)	Balanced for interactive chat with short prompts
`num_batch 1024`	Faster prefill for long prompts — roughly 50-100% faster time-to-first-token
`num_batch 2048`	Maximum throughput for document ingestion — up to 150% faster prefill
`num_batch 2048+`	Diminishing returns; higher memory usage without proportional speed gains

Für interaktiven Chat mit kurzen Prompts (unter 1K Token) ist der Standard num_batch 512 in Ordnung. Erhöhen Sie ihn nur, wenn Sie regelmäßig lange Dokumente aufnehmen und schnellere Time-to-First-Token wollen.

Größere Batch-Größen verbrauchen mehr VRAM während der Prompt-Aufnahme. Wenn Sie num_batch erhöhen und Out-of-Memory-Fehler erhalten, reduzieren Sie ihn oder senken Sie num_ctx.

Parallele Anfragen

OLLAMA_NUM_PARALLEL steuert, wie viele Anfragen ein einzelnes Modell gleichzeitig verarbeitet. Der Standard ist 1 — Ollama bearbeitet eine Anfrage nach der anderen pro geladenem Modell.

# Allow 4 parallel requests per model
OLLAMA_NUM_PARALLEL=4

Value	Behavior
`1` (default)	One request at a time — lowest latency per request
`2` to `4`	Multiple requests share the GPU — higher throughput, slightly higher per-request latency
`8+`	Maximum throughput for batch workloads — requires significant VRAM for KV cache

RAM und VRAM skalieren mit OLLAMA_NUM_PARALLEL. Jede parallele Anfrage benötigt ihren eigenen KV-Cache. Wenn Sie 4 parallele Anfragen mit num_ctx 8192 bedienen, benötigen Sie 4× den KV-Cache-Speicher im Vergleich zu einer einzelnen Anfrage.

Wann Sie parallele Anfragen erhöhen

Erhöhen Sie OLLAMA_NUM_PARALLEL, wenn:

Sie mehrere Benutzer oder Agenten vom selben Modell bedienen.
Sie Batch-Workloads ausführen, bei denen der Gesamtdurchsatz wichtiger ist als die Latenz einzelner Anfragen.
Sie VRAM-Spielraum haben und die GPU bei einzelnen Anfragen unterausgelastet ist.

Behalten Sie ihn bei 1, wenn:

Sie einen einzelnen Benutzer oder Agenten bedienen.
Sie niedrige Latenz dem Durchsatz vorziehen.
Der VRAM knapp ist.

Modell-Speicherverwaltung

Modelle geladen halten mit `OLLAMA_KEEP_ALIVE`

Standardmäßig entlädt Ollama ein Modell nach 5 Minuten Inaktivität aus dem Speicher. Die nächste Anfrage muss das Modell von der Festplatte neu laden, was je nach Modellgröße und Festplattengeschwindigkeit Sekunden bis Minuten dauert. Setzen Sie OLLAMA_KEEP_ALIVE, um zu steuern, wie lange Modelle geladen bleiben:

# Keep models loaded indefinitely
OLLAMA_KEEP_ALIVE=-1

# Keep models loaded for 1 hour
OLLAMA_KEEP_ALIVE=1h

# Unload models immediately after each request
OLLAMA_KEEP_ALIVE=0

Value	Behavior
`5m` (default)	Unload after 5 minutes of inactivity
`-1`	Keep loaded indefinitely — no reload penalty
`0`	Unload immediately after each request
Duration (`1h`, `30m`, `24h`)	Keep loaded for that duration after the last request

Für einen dedizierten Inferenz-Server, der dasselbe Modell den ganzen Tag ausführt, setzen Sie OLLAMA_KEEP_ALIVE=-1. Das Modell bleibt im Speicher und jede Anfrage bekommt sofortige Antwort ohne Kaltstart-Penalty.

Geladene Modelle begrenzen mit `OLLAMA_MAX_LOADED_MODELS`

Ollama kann mehrere Modelle gleichzeitig geladen halten. Der Standard ist 3 × (Anzahl der GPUs) oder 3 bei nur CPU. Wenn Sie viele Modelle bedienen und den Speicherverbrauch begrenzen wollen, senken Sie dies:

# Only keep 1 model loaded at a time
OLLAMA_MAX_LOADED_MODELS=1

Wenn das Limit erreicht ist und ein neues Modell angefordert wird, entlädt Ollama das am wenigsten kürzlich verwendete Modell, um Platz zu machen.

Apple Silicon und MLX-Optimierung

Beginnend mit Ollama 0.19 ist das Standard-Backend auf Apple Silicon Apples MLX-Framework. MLX ist für Apples einheitliche Speicherarchitektur optimiert und liefert erheblich schnellere Inferenz als llama.cpp auf M-Series-Chips.

Leistungsgewinne

Benchmarks aus Ollamas MLX-Optimierungs-Update vom Juni 2026:

Model	Quantization	Tokens/sec (MLX)
Gemma 4 12B	NVFP4	~55 tok/s
Gemma 4 12B	Q4_K_M	~46 tok/s
Llama 3.1 8B	Q4_K_M	~70-80 tok/s

MLX unterstützt auch NVFP4-Quantisierung auf Apple Silicon, die Near-BF16-Qualität mit 4-Bit-Speicher-Footprint liefert — halb so viel Qualitätsverlust wie Q4-Quantisierung.

Apple Silicon Optimierungstipps

Verwenden Sie MLX-optimierte Modelle. Wenn Sie ein Modell auf Apple Silicon ziehen, verwendet Ollama automatisch das MLX-Backend. Keine Konfiguration erforderlich.
Flash Attention ist immer eingeschaltet. MLX verwendet standardmäßig optimierte Attention-Kernel. Die Variable OLLAMA_FLASH_ATTENTION hat keinen Effekt.
Einheitlicher Speicher bedeutet vollständiges GPU-Offload. Apples Silicon-GPU kann auf den vollständigen RAM-Pool zugreifen, daher funktioniert -ngl 999 (alle Schichten auf GPU), solange Modell und KV-Cache in den einheitlichen Speicher passen.
Verwenden Sie OLLAMA_KV_CACHE_TYPE=q8_0, um Ihr Speicherbudget zu dehnen. Das Halbieren des KV-Cache ermöglicht das Ausführen größerer Modelle oder längerer Kontexte.
Setzen Sie OLLAMA_KEEP_ALIVE=-1 für immer-verfügbare Inferenz. Modelle bleiben im einheitlichen Speicher ohne Neu ladestrafen.

Wenn Sie plattformübergreifende Portabilität benötigen oder dieselbe Konfiguration auf NVIDIA GPU und Mac ausführen wollen, können Sie Ollama zwingen, das llama.cpp-Backend auf Apple Silicon zu verwenden. Kontaktieren Sie den Ollama-Support oder überprüfen Sie deren Dokumentation für die Umgebungsvariable, um die Backend-Auswahl zu überschreiben.

Beispielkonfigurationen

Mac Studio M2 Ultra — 128 GB einheitlicher Speicher

# Environment variables
OLLAMA_FLASH_ATTENTION=1
OLLAMA_KV_CACHE_TYPE=q8_0
OLLAMA_KEEP_ALIVE=-1
OLLAMA_NUM_PARALLEL=4

Modelfile

FROM llama3.1:70b-q4_K_M
PARAMETER num_ctx 32768
PARAMETER num_batch 1024

Diese Konfiguration betreibt ein 70B-Q4-Modell mit einem 32K-Kontextfenster. Der 128-GB-Pool einheitlichen Speichers verarbeitet die ~40 GB Modellgewichte, ~16 GB KV-Cache bei q8_0 und lässt Spielraum für 4 parallele Anfragen. MLX liefert maximalen Durchsatz auf Apple Silicon.

NVIDIA RTX 4090 — 24 GB VRAM

# Environment variables
OLLAMA_FLASH_ATTENTION=1
OLLAMA_KV_CACHE_TYPE=q8_0
OLLAMA_KEEP_ALIVE=-1
OLLAMA_NUM_PARALLEL=2
OLLAMA_NUM_THREADS=4

Modelfile

FROM llama3.1:8b-q4_K_M
PARAMETER num_ctx 16384
PARAMETER num_batch 1024

Diese Konfiguration betreibt ein 8B-Q4-Modell mit einem 16K-Kontextfenster. Der 24-GB-VRAM verarbeitet die ~5 GB Modellgewichte, ~4 GB KV-Cache bei q8_0 mit Flash Attention und lässt Spielraum für 2 parallele Anfragen. Die 4 CPU-Threads verarbeiten Orchestrierung und Tokenisierung.

Multi-GPU-Server — 4× RTX 4090 (96 GB Gesamt-VRAM)

# Environment variables
OLLAMA_FLASH_ATTENTION=1
OLLAMA_KV_CACHE_TYPE=q8_0
OLLAMA_KEEP_ALIVE=-1
OLLAMA_NUM_PARALLEL=8
OLLAMA_NUM_THREADS=8

Modelfile

FROM llama3.1:70b-q4_K_M
PARAMETER num_ctx 8192
PARAMETER num_batch 2048

Diese Konfiguration betreibt ein 70B-Q4-Modell über 4 GPUs. Ollama verteilt Schichten automatisch über alle verfügbaren GPUs. Der 96-GB-Gesamt-VRAM verarbeitet die ~40 GB Modellgewichte, ~16 GB KV-Cache und lässt Spielraum für 8 parallele Anfragen. Die große Batch-Größe maximiert den Durchsatz für Batch-Workloads.

Nur-CPU-Server — 64 GB RAM, keine GPU

# Environment variables
OLLAMA_KEEP_ALIVE=-1
OLLAMA_NUM_PARALLEL=1
OLLAMA_NUM_THREADS=16

Modelfile

FROM llama3.1:8b-q4_K_M
PARAMETER num_ctx 8192
PARAMETER num_batch 512
PARAMETER num_gpu 0

Diese Konfiguration betreibt ein 8B-Q4-Modell vollständig auf CPU. Die 16 Threads entsprechen der physischen Kernanzahl. Die kleine Batch-Größe und einzelne parallele Anfrage halten den Speicherverbrauch handhabbar. Erwarten Sie 5-10 tok/s — nutzbar für interaktiven Chat, aber nicht für Batch-Workloads.

Hochdurchsatz-Batchverarbeitung — RTX 4090

# Environment variables
OLLAMA_FLASH_ATTENTION=1
OLLAMA_KV_CACHE_TYPE=q4_0
OLLAMA_KEEP_ALIVE=-1
OLLAMA_NUM_PARALLEL=8
OLLAMA_NUM_THREADS=4

Modelfile

FROM llama3.1:8b-q4_K_M
PARAMETER num_ctx 4096
PARAMETER num_batch 2048

Diese Konfiguration maximiert den Durchsatz für Offline-Batch-Workloads. Der q4_0-KV-Cache viertelt den Speicherverbrauch, was 8 parallele Anfragen in 24 GB VRAM ermöglicht. Die große Batch-Größe beschleunigt die Prompt-Aufnahme. Der kurze 4K-Kontext hält den KV-Cache klein. Erwarten Sie 200-300 Gesamt-Token pro Sekunde über alle parallelen Anfragen.

Latenzarmes interaktives Serving — RTX 4090

# Environment variables
OLLAMA_FLASH_ATTENTION=1
OLLAMA_KV_CACHE_TYPE=q8_0
OLLAMA_KEEP_ALIVE=-1
OLLAMA_NUM_PARALLEL=1
OLLAMA_NUM_THREADS=4

Modelfile

FROM llama3.1:8b-q4_K_M
PARAMETER num_ctx 8192
PARAMETER num_batch 512

Diese Konfiguration minimiert die Latenz für interaktiven Chat. Einzelne parallele Anfrage, q8_0-KV-Cache für Qualität und moderate Batch-Größe. Erwarten Sie Time-to-First-Token unter 500ms und 50-70 tok/s Decode-Geschwindigkeit.

Häufige Fehler und wie Sie sie vermeiden

Fehler 1: num_ctx zu hoch setzen

Problem: Sie setzen num_ctx 128000 „nur für den Fall”, aber Ihre Prompts sind unter 2K Token. Sie haben gerade 64 GB KV-Cache-Speicher verschwendet. Lösung: Setzen Sie num_ctx passend zu Ihrer tatsächlichen Workload. Wenn Ihre Prompts unter 4K Token sind, verwenden Sie num_ctx 4096 oder num_ctx 8192. Sie können es später für bestimmte Anfragen über die API immer erhöhen.

Fehler 2: Flash Attention vergessen

Problem: Sie verwenden 30-50% mehr VRAM als nötig, weil Flash Attention nicht aktiviert ist. Lösung: Setzen Sie immer OLLAMA_FLASH_ATTENTION=1. Es gibt keinen Nachteil auf unterstützter Hardware.

Fehler 3: Modell-Entladen nicht steuern

Problem: Sie starten Ihre Anfrage nach einer 10-minütigen Pause neu, und die erste Anfrage dauert 30 Sekunden, weil Ollama das Modell von der Festplatte neu geladen hat. Lösung: Setzen Sie OLLAMA_KEEP_ALIVE=-1 für immer-verfügbare Inferenz. Das Modell bleibt im Speicher und jede Anfrage bekommt sofortige Antwort.

Fehler 4: Zu viele Threads auf GPU verwenden

Problem: Sie setzen num_thread 32 auf einer 32-Thread-CPU, aber alle Schichten sind auf der GPU. Die zusätzlichen Threads konkurrieren um Cache und verlangsamen die Orchestrierung. Lösung: Wenn alle Schichten auf der GPU sind, verwenden Sie num_thread 2 bis num_thread 4. Die CPU verarbeitet nur Orchestrierung und Tokenisierung, nicht Inferenz-Mathematik.

Fehler 5: KV-Cache-Präzision ignorieren

Problem: Ihr VRAM geht zur Neige und Ollama lagert Schichten auf die CPU aus, aber Sie haben nie bedacht, dass der KV-Cache 2× mehr Speicher als nötig verwendet. Lösung: Setzen Sie OLLAMA_KV_CACHE_TYPE=q8_0, um den KV-Cache-Speicher zu halbieren. Das ist die beste Balance aus Qualität und Speichereinsparung.

Fehler 6: OLLAMA_NUM_PARALLEL zu hoch setzen

Problem: Sie setzen OLLAMA_NUM_PARALLEL=16 auf einer 24-GB-GPU, und jetzt hat jede Anfrage nur 1.5 GB KV-Cache. Anfragen schlagen fehl oder die Qualität verschlechtert sich. Lösung: Berechnen Sie Ihr KV-Cache-Budget: (VRAM - model_weights) / num_parallel. Wenn das weniger als 1 GB pro Anfrage übrig lässt, reduzieren Sie num_parallel oder senken Sie num_ctx.

Fehlerbehebung

Ollama ist nach dem Start langsam

Ursache: Das Modell wurde entladen und musste von der Festplatte neu geladen werden. Lösung: Setzen Sie OLLAMA_KEEP_ALIVE=-1, um das Modell unbegrenzt geladen zu halten.

Out-of-Memory-Fehler

Ursache: Das Modell + KV-Cache überschreitet den verfügbaren VRAM oder RAM. Lösung: Reduzieren Sie num_ctx, aktivieren Sie OLLAMA_FLASH_ATTENTION=1, setzen Sie OLLAMA_KV_CACHE_TYPE=q8_0 oder verwenden Sie eine kleinere Quantisierung.

GPU wird nicht verwendet

Ursache: Ollama hat die GPU nicht erkannt, oder der VRAM ist zu klein für sogar wenige Schichten. Lösung: Prüfen Sie ollama ps, um zu sehen, ob Schichten auf der GPU sind. Stellen Sie für NVIDIA-GPUs sicher, dass die NVIDIA-Treiber und das CUDA-Toolkit installiert sind. Stellen Sie für AMD-GPUs sicher, dass ROCm installiert ist.

Langsame CPU-Inferenz

Ursache: Zu viele Threads oder Schichten zwischen GPU und CPU aufgeteilt. Lösung: Setzen Sie num_thread auf die physische Kernanzahl. Lagern Sie wenn möglich mehr Schichten auf die GPU aus mit num_gpu. Verwenden Sie eine kleinere Quantisierung (Q4_K_M oder Q5_K_M), um mehr Schichten auf die GPU zu bekommen.

Nächste Schritte

Ollama remote access

Machen Sie Ihr Ollama-Modell für Teamkollegen und Agenten über Tokios zugänglich — ohne Ports zu öffnen oder OLLAMA_HOST=0.0.0.0 zu setzen.

Hardware reference

Vergleichen Sie Hardware-Plattformen für lokale LLM-Inferenz — Spezifikationen, Modellkapazität und Empfehlungen.

Model fit finder

Finden Sie, welche Modelle auf Ihrer Hardware laufen, oder welche Hardware Ihr Zielmodell ausführen kann.

Test your deployment

Messen Sie Latenz und Durchsatz nach der Optimierung, um die Verbesserung zu bestätigen.

Häufig gestellte Fragen

What is the best Ollama configuration for fast inference?

Aktivieren Sie Flash Attention (OLLAMA_FLASH_ATTENTION=1), setzen Sie das Kontextfenster auf das, was Ihre Aufgabe tatsächlich braucht (nicht das Modellmaximum), verwenden Sie quantisierten KV-Cache (OLLAMA_KV_CACHE_TYPE=q8_0 oder q4_0) für lange Kontexte und stellen Sie sicher, dass Ihr Modell vollständig auf der GPU ausgelagert ist. Siehe die Abschnitte oben für die genauen Befehle.

How do I reduce Ollama memory usage?

Die 3 größten Hebel: (1) num_ctx senken — Speicher skaliert linear mit der Kontextlänge, (2) den KV-Cache mit OLLAMA_KV_CACHE_TYPE=q4_0 für bis zu 75% KV-Einsparung quantisieren, (3) eine kleinere Quantisierung der Modellgewichte verwenden (z.B. Q4_0 statt Q8_0). Flash Attention spart auch 30-50% an Attention-Speicher.

Does Ollama use MLX on Mac?

Ja — beginnend mit Ollama 0.19 ist das Standard-Backend auf Apple Silicon Apples MLX-Framework, nicht llama.cpp. MLX liefert erheblich schnellere Inferenz auf M-Series-Chips (55-80 tok/s auf M2 Ultra vs 25-40 tok/s mit llama.cpp). Die Variable OLLAMA_FLASH_ATTENTION hat keinen Effekt auf MLX, weil MLX immer optimierte Attention-Kernel verwendet.

How many parallel requests can Ollama handle?

Setzen Sie OLLAMA_NUM_PARALLEL (Standard 1). Jeder parallele Slot fügt ungefähr 20-30% Speicher-Overhead für KV-Cache hinzu. Für ein 7B-Modell bei Q4 mit 8K Kontext passen 4 parallele Slots bequem in 8 GB VRAM. Für größere Modelle oder längere Kontexte, starten Sie mit 2 und messen Sie.

Why is Ollama slow to load my model?

Die Modellladezeit wird dominiert vom Lesen der Gewichte von der Festplatte und ihrem Transfer auf die GPU. Verwenden Sie eine NVMe-SSD (nicht HDD), setzen Sie OLLAMA_KEEP_ALIVE, um das Modell zwischen Anfragen warm zu halten, und setzen Sie OLLAMA_MAX_LOADED_MODELS, um Entladen und Neuladen zu vermeiden. Auf Apple Silicon laden NVFP4-Modelle schneller, weil die Gewichte kleiner sind.

What GPU offload settings should I use?

Standardmäßig wählt Ollama automatisch aus, wie viele Schichten auf die GPU ausgelagert werden. Für maximale Geschwindigkeit setzen Sie num_gpu auf die Gesamtschichtanzahl des Modells (vollständig auslagern). Wenn Ihnen der VRAM ausgeht, reduzieren Sie num_ctx vor num_gpu — das Modell vollständig auf der GPU zu halten ist fast immer schneller als partielles Offload.

Quellen

Ollama FAQ — offizielle Dokumentation zu Umgebungsvariablen und Konfiguration
Ollama Modelfile reference — Parametersyntax und gültige Werte
Ollama MLX performance update — Benchmarks und Optimierungen für Apple Silicon vom Juni 2026
Ollama GPU scheduling deep dive — VRAM-Verwaltung und Multi-GPU-Verhalten
Ollama performance tuning: batching, KV cache, and OOM — num_batch-Benchmarks und Speicherberechnungen
Ollama environment variables: complete reference — geprüft gegen die Quelle v0.32.5

Nach dem Ändern der Ollama-Konfiguration registrieren Sie Ihre Tokios-Deployment erneut, damit der Connector den neuen Upstream-Endpunkt übernimmt. Siehe Register Model.

​Kontextfenster-Abstimmung

​Wie Sie das Ollama-Kontextfenster erhöhen

​Kontextfenster-Speicherkosten

​Flash Attention

​Flash Attention in Ollama aktivieren

​GPU-Offload-Strategie

​Wie Ollama GPU-Schichten entscheidet

​GPU-Schichten steuern mit num_gpu

​VRAM-Budgetierung

​KV-Cache-Präzision

​Thread-Konfiguration

​Batch-Größen-Abstimmung

​Parallele Anfragen

​Wann Sie parallele Anfragen erhöhen

​Modell-Speicherverwaltung

​Modelle geladen halten mit OLLAMA_KEEP_ALIVE

​Geladene Modelle begrenzen mit OLLAMA_MAX_LOADED_MODELS

​Apple Silicon und MLX-Optimierung

​Leistungsgewinne

​Apple Silicon Optimierungstipps

​Beispielkonfigurationen

​Mac Studio M2 Ultra — 128 GB einheitlicher Speicher

​NVIDIA RTX 4090 — 24 GB VRAM

​Multi-GPU-Server — 4× RTX 4090 (96 GB Gesamt-VRAM)

​Nur-CPU-Server — 64 GB RAM, keine GPU

​Hochdurchsatz-Batchverarbeitung — RTX 4090

​Latenzarmes interaktives Serving — RTX 4090

​Häufige Fehler und wie Sie sie vermeiden

​Fehler 1: num_ctx zu hoch setzen

​Fehler 2: Flash Attention vergessen

​Fehler 3: Modell-Entladen nicht steuern

​Fehler 4: Zu viele Threads auf GPU verwenden

​Fehler 5: KV-Cache-Präzision ignorieren

​Fehler 6: OLLAMA_NUM_PARALLEL zu hoch setzen

​Fehlerbehebung

​Ollama ist nach dem Start langsam

​Out-of-Memory-Fehler

​GPU wird nicht verwendet

​Langsame CPU-Inferenz

​Nächste Schritte

Ollama remote access

Hardware reference

Model fit finder

Test your deployment

​Häufig gestellte Fragen

​Quellen

Kontextfenster-Abstimmung

Wie Sie das Ollama-Kontextfenster erhöhen

Kontextfenster-Speicherkosten

Flash Attention

Flash Attention in Ollama aktivieren

GPU-Offload-Strategie

Wie Ollama GPU-Schichten entscheidet

GPU-Schichten steuern mit `num_gpu`

VRAM-Budgetierung

KV-Cache-Präzision

Thread-Konfiguration

Batch-Größen-Abstimmung

Parallele Anfragen

Wann Sie parallele Anfragen erhöhen

Modell-Speicherverwaltung

Modelle geladen halten mit `OLLAMA_KEEP_ALIVE`

Geladene Modelle begrenzen mit `OLLAMA_MAX_LOADED_MODELS`

Apple Silicon und MLX-Optimierung

Leistungsgewinne

Apple Silicon Optimierungstipps

Beispielkonfigurationen

Mac Studio M2 Ultra — 128 GB einheitlicher Speicher

NVIDIA RTX 4090 — 24 GB VRAM

Multi-GPU-Server — 4× RTX 4090 (96 GB Gesamt-VRAM)

Nur-CPU-Server — 64 GB RAM, keine GPU

Hochdurchsatz-Batchverarbeitung — RTX 4090

Latenzarmes interaktives Serving — RTX 4090

Häufige Fehler und wie Sie sie vermeiden

Fehler 1: num_ctx zu hoch setzen

Fehler 2: Flash Attention vergessen

Fehler 3: Modell-Entladen nicht steuern

Fehler 4: Zu viele Threads auf GPU verwenden

Fehler 5: KV-Cache-Präzision ignorieren

Fehler 6: OLLAMA_NUM_PARALLEL zu hoch setzen

Fehlerbehebung

Ollama ist nach dem Start langsam

Out-of-Memory-Fehler

GPU wird nicht verwendet

Langsame CPU-Inferenz

Nächste Schritte

Häufig gestellte Fragen

Quellen