Ollama-Optimierung: Umgebungs-Variablen, die wirklich zählen

Ollama auf Debian mit einer RTX 3090 zu betreiben und dabei ein maximales Kontextfenster für einen Agenten herauszuquetschen - das klingt einfacher als es ist. Der Teufel steckt in einer Handvoll Umgebungsvariablen und Modelfile-Parametern, die Ollama standardmäßig verschweigt, und deren Zusammenspiel darüber entscheidet, ob das Modell wirklich auf der GPU läuft oder sich still und heimlich auf die CPU schleicht.

Das Modell: gemma4:26b auf der RTX 3090

gemma4:latest ist seit dem 2. April 2026 verfügbar und zieht standardmäßig das gemma4:e4b-it-q4_K_M-Modell - eine kleinere Variante, bei der nur rund 4 Milliarden Token aktiv sind. Das macht es erschreckend effizient. Das Medium-Modell unterstützt nativ ein Kontextfenster von 256K Token (konkret: 262.144 Token = 256 x 1.024).

Eine 24-GB-GPU wie die RTX 3090 oder 4090 kann das 26B A4B bei Q4-Quantisierung mit dem vollen 256K-Kontextfenster betreiben - mit Platz zum Atmen. Das ist ungewöhnlich für ein Modell dieser Qualitätsstufe.

# Modell herunterladen (zieht e4b-it-q4_K_M als Default)
ollama pull gemma4

# Oder explizit die MoE-Variante
ollama pull gemma4:26b

Der aktuelle Stand der geladenen Modelle lässt sich jederzeit überprüfen:

ollama ps

Das stille Problem: Ollamas Standard-Kontextfenster

Bevor irgendetwas anderes konfiguriert wird, sollte man das wohl größte Missverständnis im Ollama-Ökosystem kennen: Ollamas Standard-Kontextfenster beträgt 4.096 Token - unabhängig davon, was das Modell theoretisch unterstützt. Wenn das kumulative Token-Limit überschritten wird, wirft Ollama keinen Fehler. Es lässt still die ältesten Nachrichten fallen.

Bei einer RTX 3090 mit gemma4:26b setzt Ollama den VRAM-basierten Standard-Kontext auf 32.768 Token (wie in den Logs von GitHub Issue #15634 zu sehen). Das ist deutlich besser als 4.096, aber für einen Hermes-Agenten mit langen Kontexten noch weit vom Maximum entfernt.

Ältere Guides und Community-Posts verwenden OLLAMA_NUM_CTX - das war der Variablenname in früheren Ollama-Versionen. OLLAMA_CONTEXT_LENGTH ist der aktuelle offizielle Name.

Die drei Wege, den Kontext zu setzen, und wann welcher sinnvoll ist:

Systemweite Optimierung über systemctl edit ollama.service

Der komfortabelste Weg, Ollama dauerhaft zu konfigurieren, ist der systemd-Override:

sudo systemctl edit ollama.service

Dieser Befehl öffnet einen Editor und legt die Datei /etc/systemd/system/ollama.service.d/override.conf an. Hier die optimierte Konfiguration für eine RTX 3090 mit gemma4:26b und einem Hermes-Agenten:

[Service]
# --- Kontext ---
# Standard-Kontext für alle Modelle auf diesem Server.
# Für Agenten: mindestens 65.000 Token empfohlen.
# num_ctx im Modelfile hat Vorrang und überschreibt diesen Wert.
Environment="OLLAMA_CONTEXT_LENGTH=65536"

# --- GPU & VRAM ---
# VRAM-Reserve für GPU-Betriebssystem-Overhead (in Bytes).
# Verhindert OOM-Crashes beim Laden großer Kontexte.
# Empfehlung für RTX 3090: ca. 512 MB bis 1 GB.
Environment="OLLAMA_GPU_OVERHEAD=536870912"

# --- KV-Cache-Quantisierung ---
# Aktiviert Flash Attention (Voraussetzung für KV-Cache-Quantisierung).
# ACHTUNG: Bei gemma4:26b auf RTX 3090 kann dies bei großem Kontext
# ungewollt CPU-Offloading auslösen. Nach dem Restart mit 'ollama ps'
# prüfen, ob 100% GPU genutzt wird!
Environment="OLLAMA_FLASH_ATTENTION=1"

# q8_0: Halbiert den KV-Cache-VRAM bei minimalem Qualitätsverlust.
# Offizielle Empfehlung von Ollama (nach f16).
# q4_0 spart noch mehr, kostet aber messbar Präzision - ungünstig für Agenten.
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"

# --- Modell im Speicher halten ---
# -1 = Modell nie aus dem VRAM entladen.
# Sinnvoll für einen dedizierten Agenten-Server.
# Auf Mehrbenutzer-Systemen besser auf "1h" oder "30m" setzen.
Environment="OLLAMA_KEEP_ALIVE=-1"

# --- Parallelität ---
# Für einen einzelnen Agenten: 1 parallele Anfrage ist optimal.
# Kein VRAM-Overhead für zusätzliche Parallel-Slots.
Environment="OLLAMA_NUM_PARALLEL=1"

# --- Nur ein Modell laden ---
# Verhindert, dass andere Modelle gleichzeitig in den VRAM geladen werden.
Environment="OLLAMA_MAX_LOADED_MODELS=1"

# Maximale Wartezeit beim Laden großer Modelle mit großem Kontext.
Environment="OLLAMA_LOAD_TIMEOUT=10m"

Nach dem Speichern:

sudo systemctl daemon-reload
sudo systemctl restart ollama

Der aktuelle Konfigurations-Status lässt sich jederzeit so prüfen:

sudo journalctl -u ollama -n 50 | grep "server config"

Die Ausgabe zeigt alle aktiven Umgebungsvariablen auf einen Blick:

msg="server config" env="map[OLLAMA_CONTEXT_LENGTH:65536 OLLAMA_FLASH_ATTENTION:true OLLAMA_KV_CACHE_TYPE:q8_0 ...]"

Flash Attention und der KV-Cache: Der Teufel liegt im Detail

Für ein gutes Verständnis der Konfiguration lohnt sich ein kurzer Blick unter die Haube - denn hier liegt der häufigste Fehler begraben.

Was ist der KV-Cache? Jedes Transformer-Modell berechnet für jeden Token sogenannte Key- und Value-Matrizen. Um diese nicht bei jedem neuen Token neu berechnen zu müssen, werden sie im KV-Cache zwischengespeichert. Das Problem: Der KV-Cache wächst nahezu linear mit der Kontextlänge und wird bei langen Kontexten zum dominierenden VRAM-Verbraucher. Bei einem Standard-f16-KV-Cache mit 256K Token kann das schnell die Hälfte des verfügbaren VRAMs der 3090 auffressen.

Was macht Flash Attention? Flash Attention ist ein Feature der meisten modernen Modelle, das den Speicherbedarf bei wachsender Kontextgröße signifikant reduzieren kann. Die KV-Cache-Quantisierung ist nur möglich, wenn Flash Attention aktiviert ist.

Warum q8_0 statt q4_0? Bei q8_0 werden die KV-Cache-Werte 8-Bit-quantisiert - das entspricht ungefähr der Hälfte des Speicherbedarfs von f16 bei einem sehr kleinen Präzisionsverlust, der typischerweise keinen wahrnehmbaren Einfluss auf die Modellqualität hat. Dies ist die offizielle Empfehlung.

q4_0 halbiert den Speicherbedarf nochmals, aber auf Kosten messbarer Präzisionsverluste - für einen präzisionsempfindlichen Agenten keine gute Wahl.

Der Flash-Attention-Fallstrick bei gemma4:26b auf der RTX 3090: Wie in GitHub Issue #15634 dokumentiert, kann OLLAMA_FLASH_ATTENTION=1 in Kombination mit gemma4:26b und einem großen Kontext dazu führen, dass Ollama das Modell auf GPU+CPU verteilt - obwohl es ohne Flash Attention vollständig im GPU-VRAM Platz findet. Das Ergebnis ist eine drastisch reduzierte Inferenzgeschwindigkeit. Deshalb ist es nach jeder Konfigurationsänderung Pflicht:

ollama ps

Die Ausgabe muss 100% GPU zeigen:

NAME             ID           SIZE     PROCESSOR    CONTEXT
gemma4:26b       abc123def    23 GB    100% GPU     229376

Steht dort GPU+CPU, muss der Kontext reduziert oder Flash Attention vorübergehend deaktiviert werden.

Das maximale Kontextfenster empirisch ermitteln

Theoretische VRAM-Berechnungen sind ein guter Ausgangspunkt, aber die tatsächlichen Werte hängen von Faktoren ab, die sich kaum vorhersagen lassen: VRAM-Fragmentierung, interne Ollama-Puffer, Aktivierungen außerhalb des KV-Cache. Die zuverlässigste Methode ist deshalb das empirische Vorgehen: schrittweise erhöhen und mit ollama ps messen.

# Modelfile anpassen, neu laden, messen:
ollama create mm_tool_use -f Modelfile
ollama ps

Die Ausgabe zeigt den tatsächlich allokierten VRAM und ob 100% GPU gehalten wird. Bricht Ollama mit 500 Internal Server Error: memory layout cannot be allocated ab, war der Wert zu hoch - eine Stufe zurück ist dann das reale Maximum.

Ergebnis auf einer RTX 3090 mit gemma4:26b und q8_0-KV-Cache:

229.376 Token laufen stabil mit 1 GB Headroom. Das entspricht 87% des nativen 256K-Kontextfensters von gemma4:26b - auf einer einzelnen Consumer-GPU.

Warum nicht 262.144 (256K)? Bei 229.376 Token belegt der KV-Cache empirisch etwa 6 GB (23 GB gesamt minus ~17 GB Gewichte). Für 262.144 Token wären ca. 6,9 GB KV-Cache nötig, was den verfügbaren Headroom von ~1 GB überschreitet. 229.376 ist damit das praktische Maximum für diese Konfiguration.

Die nativen Architekturwerte von gemma4:26b lassen sich direkt abfragen:

ollama show gemma4:26b --verbose 2>&1 | grep -E "layers|heads|head_dim|context"
# context length      262144
# gemma4.attention.shared_kv_layers    0
# gemma4.context_length                262144

shared_kv_layers 0 bedeutet: kein KV-Sharing, jede Schicht hält ihren eigenen Cache. Das ist relevant für die VRAM-Kalkulation.

Das Modelfile: Parameter, die wirklich zählen

Ein Modelfile backt die gewünschten Parameter dauerhaft in eine benannte Modell-Variante - perfekt für den Hermes-Agenten, der diese Variante einfach per Name referenziert.

nano Gemma4AgentModelfile

# Ollama Modelfile - Gemma4 Hermes Agent / M. Meister
FROM gemma4:26b

# Gemma 4 nutzt sein eigenes Turn-Format.
# <start_of_turn> / <end_of_turn> sind die nativen Delimiter.
TEMPLATE """{{ if .System }}<start_of_turn>system
{{ .System }}<end_of_turn>
{{ end }}{{ if .Prompt }}<start_of_turn>user
{{ .Prompt }}<end_of_turn>
{{ end }}<start_of_turn>model
{{ .Response }}"""

# Empirisch ermitteltes Maximum für RTX 3090 + q8_0 KV-Cache.
# Getestet: 23 GB VRAM, 100% GPU, stabil.
PARAMETER num_ctx 229376

# num_keep: Token aus dem Kontext, die niemals verdrängt werden.
# Schützt System-Prompt und initiale Instruktionen vor Silent Truncation.
PARAMETER num_keep 512

# num_batch: Tokens, die parallel beim Prompt-Processing verarbeitet werden.
# 512 ist ein konservativer, stabiler Wert für lange Kontexte.
PARAMETER num_batch 512

# Temperatur niedrig für Agentenaufgaben.
PARAMETER temperature 0.4

# Verhindert Endlosschleifen in langen Antworten.
PARAMETER repeat_penalty 1.05

# Maximale Antwortlänge (-1 = unbegrenzt). Für Agenten meist sinnvoll.
PARAMETER num_predict -1

# Gemma 4 Stop-Tokens. Kein "\n\n" - würde mehrzeiliges JSON abschneiden.
PARAMETER stop "<end_of_turn>"
PARAMETER stop "<eos>"

PARAMETER num_gpu 999

Modell erstellen und testen:

ollama create gemma4-agent -f Gemma4AgentModelfile
ollama run gemma4-agent "Welchen Kontext habe ich?"

Anschließend direkt den tatsächlichen Kontext verifizieren:

ollama ps
# NAME            SIZE     PROCESSOR    CONTEXT
# gemma4-agent    23 GB    100% GPU     229376

Vergessene und unbekannte Stellschrauben

Hier folgen die Parameter, die in keinem Standard-Tutorial auftauchen - aber einen echten Unterschied machen.

OLLAMA_GPU_OVERHEAD - Der stille VRAM-Puffer

Diese Variable reserviert einen fixen VRAM-Block für GPU-Systemoperationen und verhindert OOM-Fehler beim Laden des Modells. Ohne diesen Puffer kann Ollama beim Laden des Modells plus KV-Cache in VRAM-Engpässe laufen. Für die RTX 3090 empfehlen sich 512 MB bis 1 GB:

# 512 MB in Bytes
OLLAMA_GPU_OVERHEAD=536870912
# 1 GB in Bytes
OLLAMA_GPU_OVERHEAD=1073741824

OLLAMA_LOAD_TIMEOUT - Der Ladegedulds-Parameter

OLLAMA_LOAD_TIMEOUT steuert die maximale Wartezeit für die Stall-Erkennung beim Modell-Laden. Null oder negative Werte werden als unendlich interpretiert. Standard ist 5 Minuten. Bei einem 17-GB-Modell mit großem Kontextfenster kann das Laden auf manchen Systemen die Standard-Timeout-Zeit überschreiten:

Environment="OLLAMA_LOAD_TIMEOUT=10m"

OLLAMA_CONTEXT_LENGTH vs. num_ctx im Modelfile - Prioritäten verstehen

Beide Parameter setzen das Kontextfenster, aber mit unterschiedlicher Priorität: num_ctx im Modelfile hat Vorrang vor OLLAMA_CONTEXT_LENGTH. Das Modelfile ist also die letzte Instanz. OLLAMA_CONTEXT_LENGTH dient als serverweiter Fallback für Modelle, die keinen eigenen Wert im Modelfile haben.

OLLAMA_MULTIUSER_CACHE - Das Insider-Feature

OLLAMA_MULTIUSER_CACHE optimiert das Prompt-Caching für Mehrbenutzer-Szenarien. Für einen Solo-Agenten ist das weniger relevant, aber in einer Umgebung, in der mehrere Prozesse das gleiche Ollama-Backend nutzen, kann es die Wiederverwendung gecacheter Präfixe verbessern.

OLLAMA_DEBUG - Das Diagnosewerkzeug

Das Aktivieren von Debug-Logging gibt Einblick in tatsächliche VRAM-Belegung und GPU-Schichtverteilung:

Environment="OLLAMA_DEBUG=1"

Nach dem Restart sind die Logs unter journalctl -u ollama -f sehr gesprächig - und zeigen genau, welche Schichten des Modells wirklich auf der GPU liegen.

CUDA_VISIBLE_DEVICES - Die GPU explizit benennen

Auf Systemen mit mehreren GPUs oder wenn Ollama die falsche GPU erwischt:

Environment="CUDA_VISIBLE_DEVICES=0"

OLLAMA_NEW_ENGINE - Das kommende Backend

OLLAMA_NEW_ENGINE aktiviert die neue Ollama-Engine. Diese ist seit Version 0.6.x schrittweise im Rollout und bringt Performance-Verbesserungen, kann aber bei manchen Modellen noch Überraschungen mitbringen. Ein Testlauf lohnt sich:

# Auf eigene Gefahr - nach Aktivierung immer mit 'ollama ps' verifizieren
Environment="OLLAMA_NEW_ENGINE=1"

Der vollständige VRAM-Plan für die RTX 3090

Die theoretischen Schätzungen in der Literatur weichen oft deutlich von den Messwerten ab - hier zeigt sich der Vorteil des empirischen Ansatzes. Die q8_0-Quantisierung des KV-Cache macht erheblich mehr Spielraum als erwartet.

Die finale Konfiguration auf einen Blick

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=65536"
Environment="OLLAMA_GPU_OVERHEAD=536870912"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_LOAD_TIMEOUT=10m"

sudo systemctl daemon-reload && sudo systemctl restart ollama

Das Modelfile für meinen Hermes-Agenten:

FROM gemma4:26b

PARAMETER num_ctx 229376
PARAMETER num_keep 512
PARAMETER num_batch 512
PARAMETER temperature 0.4
PARAMETER repeat_penalty 1.05
PARAMETER num_predict -1
PARAMETER stop "<end_of_turn>"
PARAMETER stop "<eos>"
PARAMETER num_gpu 999

ollama create gemma4-hermes -f Gemma4AgentModelfile
# Verifikation: 100% GPU und Kontext-Wert prüfen
ollama ps

Fazit

Ollama ist ein mächtiges Werkzeug, das mit wenigen gezielten Konfigurationsänderungen vom gemütlichen Chatbot zum ernstzunehmenden Agenten-Backend wird. Das Zusammenspiel aus OLLAMA_FLASH_ATTENTION, OLLAMA_KV_CACHE_TYPE=q8_0 und einem wohlkalibrierten num_ctx entscheidet darüber, ob das Modell wirklich im GPU-VRAM arbeitet - oder sich still auf die CPU schleicht.

Entgegen theoretischer Schätzungen, die 128K als Maximum für die RTX 3090 nahelegen, läuft gemma4:26b mit q8_0-KV-Cache empirisch stabil bei 229.376 Token - 87% des nativen 256K-Kontextfensters, vollständig auf der GPU. Das ist das tatsächliche Maximum für diese Konfiguration, und es übertrifft, was die meisten Anleitungen für möglich halten.