Ollama GPU-Scheduling und Ressourcenverwaltung: VRAM-Optimierung, Multi-GPU-Lastverteilung

Mit 8 GB VRAM haben Sie das 13B-Modell endlich geladen – und nach ein paar Inferenz-Läufen plötzlich der Fehler: „CUDA out of memory”.

Oder Sie haben zwei GPUs gekauft, voller Vorfreude endlich große Modelle zu fahren – und nvidia-smi zeigt: Nur eine Karte arbeitet, die andere liegt brach.

Am Anfang mit Ollama bin ich genau in diese Fallen gelaufen: zu wenig VRAM, Multi-GPU ungenutzt, Inferenzgeschwindigkeit mal schnell, mal langsam. Erst nach und nach wurde klar, wie Ollamas GPU-Scheduling funktioniert – vieles ist nicht „einstellen und fertig”, sondern erfordert Verständnis der Parameter dahinter.

In diesem Artikel fasse ich die Erfahrungen zusammen und helfe bei konkreten Problemen:

• 13B-Modell stabil auf 8 GB VRAM (ohne plötzliches OOM)
• Multi-GPU wirklich nutzen (vollständiges Lastverteilungs-Setup)
• Welche Parameter bei VRAM-Mangel zuerst anpassen (Prioritäten)
• Was GPU-Offloading bedeutet (llama.cpp-Mechanismus)

Voraussetzung: Der Artikel ist etwas technisch – Grundkenntnisse zu GPU, CUDA und Ollama-Basics sind hilfreich. Wenn Sie Ollama gerade erst entdecken, lesen Sie zuerst die früheren Teile der Serie (besonders Teil 6 zur Performance-Optimierung).

1. GPU-Speicherverwaltung: Parameter im Detail

Ollamas GPU-Scheduling steuert über Parameter, wie Modellschichten zwischen GPU und CPU verteilt werden. Wer diese Parameter kennt, versteht, warum trotz scheinbar ausreichendem VRAM Fehler auftreten oder die Inferenz langsamer wird.

1.1 Kernparameter im Überblick

Die wichtigsten Parameter in einer Tabelle:

Parameter	Wirkung	Standard	Wann anpassen
num_gpu	Anzahl Modellschichten auf der GPU	Auto-Erkennung	Bei VRAM-Mangel reduzieren
main_gpu	Index der Haupt-GPU	0	Bei Multi-GPU die gewünschte Karte wählen
low_vram	Low-VRAM-Modus	false	Unter 8 GB VRAM empfohlen
num_batch	Batch-Größe	512	Bei knappem VRAM auf 256 senken
num_ctx	Kontextlänge	4096	Kurze Dialoge: 2048 spart viel VRAM

num_gpu verwirrt oft: Es ist nicht die GPU-Anzahl, sondern wie viele Modellschichten auf der GPU rechnen.

Beispiel Llama 2 7B mit 32 Schichten: num_gpu: 32 → alle 32 Schichten auf der GPU. Bei VRAM-Mangel num_gpu: 20 → 20 Schichten GPU, 12 CPU – spürbar langsamer.

low_vram ist praktisch: Ollama spart VRAM, z. B. indem der KV-Cache im CPU-RAM statt im GPU-VRAM liegt. Etwas langsamer, aber stabiler.

1.2 VRAM-Zuweisungsablauf

Beim Modellladen läuft die VRAM-Zuweisung so ab:

1. VRAM prüfen: Freier GPU-Speicher ermitteln
2. Schichten berechnen: Aus Modellgröße und VRAM die GPU-Schichten ableiten
3. KV-Cache reservieren: Speicher für Inferenz-Cache (ebenfalls VRAM)
4. Inferenz starten: Dynamische VRAM-Nutzung mit Schwankungen

Entscheidend ist Schritt 2 – Ollama berechnet automatisch. Das reicht nicht immer, wenn der VRAM knapp passt (z. B. 8 GB für 13B). Dann num_gpu manuell setzen.

Aktuelle GPU-Offloading-Schichten anzeigen:

ollama run llama3 --verbose

In der Ausgabe erscheint z. B. llama_model_load: model loaded - layers: 40/40 on GPU – alle 40 Schichten auf der GPU.

1.3 llama.cpp-Backend

Ollama nutzt llama.cpp als Inferenz-Engine. Wer dessen GPU-Offloading-Logik versteht, weiß, warum Parameter manchmal wenig bewirken.

GPU-Offloading-Entscheidung

llama.cpp rechnet ungefähr so:

Verfügbarer VRAM = GPU-Gesamt-VRAM − Systemreserve (einige hundert MB)
Größe pro Schicht = Modellparameter / Schichtanzahl
Schichten auf GPU = min(Gesamtschichten, verfügbarer VRAM / Größe pro Schicht)

Die Falle: Nur Modellspeicher, kein KV-Cache. Der KV-Cache wächst mit der Dialoglänge – daher lädt das Modell, aber nach einigen Läufen bricht der Speicher weg.

Hybride Rechenarchitektur

GPU und CPU arbeiten nicht strikt getrennt:

• GPU: Matrixoperationen, Attention (rechenintensiv)
• CPU: Embedding, Normalisierung (weniger rechenintensiv)
• Datentransfer: Overhead zwischen GPU und CPU

Bei partiellem Offloading muss jede Schicht das Ergebnis ans nächste Gerät – deshalb wird partielles GPU-Offloading deutlich langsamer.

mmap-Speicherabbildung

llama.cpp lädt Modelldateien standardmäßig per mmap:

• Nicht das ganze Modell auf einmal in den Speicher – OS lädt bei Bedarf
• Mehrere Prozesse können Speicher teilen
• Geringerer Speicherverbrauch

mmap deaktivieren (falls nötig) in der Modelfile:

PARAMETER use_mmap false

2. Multi-GPU-Konfiguration: Lastverteilung in der Praxis

Mit zwei oder mehr GPUs ist die Frage: Wie nutzt Ollama sie wirklich?

Zuerst die Enttäuschung: Ollama unterstützt kein Model Parallelism. Ein Modell lässt sich nicht halb auf GPU 0, halb auf GPU 1 rechnen – jede Instanz bindet an eine GPU.

Multi-GPU nutzen Sie so:

1. Verschiedene Modelle: GPU 0 llama3, GPU 1 mistral
2. Mehrere Instanzen desselben Modells: Lastverteilung für höheren Durchsatz

2.1 Ein-Instanz Multi-GPU (Grenzen und Setup)

Mehrere GPUs sichtbar machen – einfachste Variante:

# Ollama nur GPU 0 und GPU 1 nutzen lassen
CUDA_VISIBLE_DEVICES=0,1 ollama serve

Problem: Ollama legt das Modell standardmäßig auf GPU 0, GPU 1 bleibt idle. Mit main_gpu die Haupt-GPU wählen:

# Modelfile
FROM llama3
PARAMETER main_gpu 1  # Haupt-GPU = GPU 1

Ehrlich gesagt: begrenzter Nutzen – Sie wechseln nur die Karte, nutzen aber nicht beide parallel.

2.2 Multi-Instanz-Lastverteilung (empfohlen)

Volle Multi-GPU-Nutzung: mehrere Ollama-Instanzen, je eine GPU pro Instanz, Lastverteiler davor.

┌─────────┐
│ Client  │  Inferenz-Anfrage
└────┬────┘
     │
┌────▼────────────────────┐
│ Nginx (Load Balancer)   │  least_conn
│ Port: 8080              │
└────┬─────────┬──────────┘
     │         │
┌────▼───┐ ┌──▼────┐
│Ollama 1│ │Ollama 2│
│GPU 0   │ │GPU 1   │  Je Instanz eine GPU
│Port    │ │Port    │
│11434   │ │11435   │
└────────┘ └────────┘

Schritt 1: Mehrere Ollama-Instanzen starten

# Instanz 1 – GPU 0, Port 11434
CUDA_VISIBLE_DEVICES=0 OLLAMA_HOST=127.0.0.1:11434 ollama serve &

# Instanz 2 – GPU 1, Port 11435
CUDA_VISIBLE_DEVICES=1 OLLAMA_HOST=127.0.0.1:11435 ollama serve &

Hinweis: Standard-Datenverzeichnis ~/.ollama – beide Instanzen teilen Modellspeicher. mmap erlaubt das problemlos.

Schritt 2: Nginx-Lastverteilung

# /etc/nginx/conf.d/ollama.conf
upstream ollama_cluster {
    least_conn;  # Wenigste Verbindungen zuerst
    server 127.0.0.1:11434;
    server 127.0.0.1:11435;
}

server {
    listen 8080;

    location / {
        proxy_pass http://ollama_cluster;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;

        # Streaming-Unterstützung
        proxy_buffering off;
        proxy_cache off;
    }
}

least_conn: Neue Anfragen gehen an die Instanz mit den wenigsten aktiven Verbindungen – gleichmäßigere GPU-Last.

Schritt 3: Client-Aufruf

Client verbindet sich mit Nginx:

# Über Nginx (automatische Verteilung)
curl http://localhost:8080/api/generate -d '{
  "model": "llama3",
  "prompt": "Hallo"
}'

Oder Standard-Host des Ollama-Clients ändern:

export OLLAMA_HOST=http://localhost:8080
ollama run llama3

2.3 Lastverteilungsstrategien im Vergleich

Strategie	Prinzip	Einsatz
Round-Robin (Standard)	Der Reihe nach an Instanzen	Einfache Setups, gleiche Modellgrößen
least_conn	An die freieste Instanz	Empfohlen für Inferenz
IP Hash	Gleiche IP → gleiche Instanz	Session-Persistenz

Inferenz: Laufzeiten variieren stark. Round-Robin kann eine Instanz überlasten. least_conn vermeidet das.

Für Failover bei instabiler Instanz:

upstream ollama_cluster {
    least_conn;
    server 127.0.0.1:11434 max_fails=3 fail_timeout=30s;
    server 127.0.0.1:11435 max_fails=3 fail_timeout=30s;
}

Nach 3 Fehlversuchen wird die Instanz 30 Sekunden aus dem Cluster genommen.

3. VRAM-Optimierung: Quantisierung, Kontext, Batch

Bei VRAM-Mangel gilt die Priorität: Quantisierung > Kontextlänge > Batch > GPU-Schichten.

Quantisierung wirkt am stärksten – Q4 spart gegenüber FP16 ca. 75 % VRAM. GPU-Schichten reduzieren spart VRAM, verschiebt aber Rechenlast auf die CPU.

3.1 Quantisierungsstufen

Quantisierung speichert Parameter mit weniger Bits. FP16 = 16 Bit, Q4 = 4 Bit. Weniger Bits, etwas Genauigkeitsverlust – in der Praxis ca. 2–3 % bei Q4, für die meisten Szenarien akzeptabel.

Quantisierung	VRAM (relativ FP16)	Genauigkeitsverlust	Einsatz
Q4_K_M	ca. 25 %	2–3 %	Empfohlen: Balance Performance/Qualität
Q5_K_M	ca. 33 %	1–2 %	Etwas höhere Genauigkeit
Q8_0	ca. 50 %	0,5 %	Nahe Original
FP16	100 %	Keiner	Forschung, Benchmarks

Referenz Llama 2 13B:

• FP16: ca. 26 GB VRAM
• Q4_K_M: ca. 8 GB VRAM
• Q8_0: ca. 13 GB VRAM

8 GB für 13B Q4 passt knapp – KV-Cache braucht zusätzlich Platz, daher OOM-Risiko bei Inferenz.

Tipp: Alltag → Q4_K_M. Übersetzung, Code → Q5_K_M oder Q8_0.

Ollama lädt standardmäßig Q4. Andere Stufen über Modell-Suffix:

# Q4 (Standard)
ollama pull llama3

# Q8
ollama pull llama3:8b-q8_0

3.2 Kontextlängen-Optimierung

Der KV-Cache speichert Dialoghistorie – VRAM hängt direkt an der Kontextlänge.

Schätzformel (vereinfacht):

KV-Cache-VRAM ≈ num_ctx × num_layers × hidden_dim × 2 bytes

Beispiel Llama 2 7B:

• num_layers = 32
• hidden_dim = 4096
• num_ctx = 4096

→ KV-Cache ca. 2 GB. Bei ctx=8192 → ca. 4 GB. Kontext verdoppeln, KV-Cache verdoppelt sich.

Optimierung:

1. Kurze Dialoge: num_ctx: 2048

   • Halbiert KV-Cache-VRAM
   • Für Q&A und einfache Aufgaben ausreichend

2. Lange Dokumente: Nicht ctx=16000+, sondern Chunking

   • Dokument in Stücke, schrittweise verarbeiten
   • Stabiler und kontrollierbarer

In der Modelfile:

FROM llama3
PARAMETER num_ctx 2048  # Kontextlänge reduzieren

Missverständnis: Kleineres ctx verschlechtert nicht automatisch die Ausgabe – ctx begrenzt nur, wie viel Historie das Modell „erinnert”. Bei wenigen Runden ist 2048 wie 4096.

3.3 Batch und Parallelität

num_batch: wie viele Tokens auf einmal verarbeitet werden. Standard 512.

Größerer Batch → effizientere Parallelität, höherer VRAM-Peak.

Bei knappem VRAM Batch senken:

FROM llama3
PARAMETER num_batch 256  # Von 512 auf 256

Praxis: 512 → 256 senkt Peak-VRAM ca. 20 %. Etwas langsamer, aber weniger dramatisch als weniger GPU-Schichten.

Parallele Anfragen

Ollama verarbeitet standardmäßig seriell. Mehrere gleichzeitige Anfragen warten in der Queue.

Mehr Durchsatz:

1. Multi-Instanz: Multi-GPU-Lastverteilung – jede Instanz unabhängig
2. Queue-System: Anwendungsschicht (z. B. Redis Queue)

Ohne Multi-GPU eignet sich Variante 2:

import redis
from queue import Queue

# Redis als Queue
r = redis.Redis()
r.lpush('ollama_queue', request_data)

# Worker holt Anfragen
request = r.rpop('ollama_queue')
ollama.generate(request)

4. Praxis-Szenarien: drei reale Fälle

4.1 Szenario 1: 13B stabil auf 8 GB VRAM

Problem

RTX 3060 (8 GB), Llama 2 13B Q4 – Modell ca. 8 GB, passt knapp. Nach wenigen Läufen OOM – KV-Cache sprengt den Speicher.

Lösung

KV-Cache reduzieren + Peak-VRAM senken:

FROM llama2:13b-q4

PARAMETER num_gpu 30      # 13B hat 40 Schichten, 30 auf GPU
PARAMETER low_vram true   # KV-Cache im CPU-RAM
PARAMETER num_ctx 2048    # Kontext halbiert → KV-Cache halbiert
PARAMETER num_batch 256   # Kleinerer Batch, niedrigerer Peak

Kombiniert: stabile Nutzung ca. 6 GB, 2 GB Puffer.

Ergebnis

• VRAM: ca. 8 GB → ca. 6 GB (stabil)
• Inferenz: ca. 8 Tokens/s (langsamer als volle GPU, schneller als reine CPU)
• Stabilität: kein OOM mehr

10 Schichten auf der CPU + GPU-CPU-Transfer kosten Speed – aber nutzbar statt Absturz.

4.2 Szenario 2: Dual-GPU-Lastverteilung für Durchsatz

Problem

Zwei RTX 3090 (je 24 GB), Ollama-API für externe Nutzer. Ein-Instanz = serielle Verarbeitung, Queue in Spitzenzeiten. nvidia-smi: eine Karte 70 %+, die andere ~20 %.

Lösung

Multi-Instanz + Nginx – Startskript:

#!/bin/bash
# start_ollama_cluster.sh

# Instanz 1 – GPU 0
CUDA_VISIBLE_DEVICES=0 \
OLLAMA_HOST=127.0.0.1:11434 \
OLLAMA_MODELS=/home/user/.ollama \
nohup ollama serve > ollama1.log 2>&1 &

# Instanz 2 – GPU 1
CUDA_VISIBLE_DEVICES=1 \
OLLAMA_HOST=127.0.0.1:11435 \
OLLAMA_MODELS=/home/user/.ollama \
nohup ollama serve > ollama2.log 2>&1 &

# Modell auf beiden Instanzen vorladen
sleep 5
curl http://127.0.0.1:11434/api/pull -d '{"name": "llama3"}'
curl http://127.0.0.1:11435/api/pull -d '{"name": "llama3"}'

echo "Ollama cluster started on ports 11434 and 11435"

Nginx mit least_conn für gleichmäßige Verteilung.

Ergebnis

• Gesamtdurchsatz: ca. +80 % (parallel statt seriell)
• GPU-Auslastung: im Schnitt 40 % → 80 % (beide Karten aktiv)
• Latenz in Spitzen: ca. −50 % (keine lange Queue)

Praxis: 100 Anfragen – Ein-Instanz ~10 Min., Dual-Instanz etwas über 5 Min.

4.3 Szenario 3: Automatische VRAM-Anpassung

Problem

Verschiedene Modellgrößen – bei jedem Wechsel manuell GPU-Schichten anpassen. Vergessen → Absturz. Automatisieren?

Lösung

Skript wählt Modelfile-Konfiguration nach freiem VRAM:

#!/bin/bash
# auto_offload.sh - Automatische GPU-Offloading-Konfiguration

# Freier GPU-VRAM (MB)
GPU_MEM_FREE=$(nvidia-smi --query-gpu=memory.free --format=csv,noheader,nounits | head -1)

# Modellgrößen-Referenz (MB)
declare -A MODEL_SIZES
MODEL_SIZES["llama3:8b-q4"]=5000
MODEL_SIZES["llama3:70b-q4"]=40000
MODEL_SIZES["mistral:7b-q4"]=4500

MODEL_NAME=$1

if [ -z "$MODEL_NAME" ]; then
    echo "Usage: $0 <model_name>"
    exit 1
fi

MODEL_SIZE=${MODEL_SIZES[$MODEL_NAME]}

if [ -z "$MODEL_SIZE" ]; then
    echo "Unknown model size for $MODEL_NAME"
    exit 1
fi

# Genug VRAM für volle GPU?
if [ $GPU_MEM_FREE -gt $MODEL_SIZE ]; then
    echo "Using full GPU offloading (enough memory)"
    cat > /tmp/modelfile_temp <<EOF
FROM $MODEL_NAME
PARAMETER num_gpu -1  # -1 = volle GPU
PARAMETER low_vram false
EOF
else
    # Partielle GPU – Verhältnis berechnen
    OFFLOAD_RATIO=$((GPU_MEM_FREE * 100 / MODEL_SIZE))
    echo "Using partial GPU offloading ($OFFLOAD_RATIO%)"
    cat > /tmp/modelfile_temp <<EOF
FROM $MODEL_NAME
PARAMETER num_gpu $OFFLOAD_RATIO
PARAMETER low_vram true
PARAMETER num_ctx 2048
EOF
fi

ollama create "${MODEL_NAME}-auto" -f /tmp/modelfile_temp
echo "Created ${MODEL_NAME}-auto with auto config"

Nutzung:

./auto_offload.sh llama3:70b-q4

Ergebnis

• Automatische Anpassung an VRAM
• Weniger Konfigurationsfehler
• Modellwechsel ohne manuelle Parameter

Erweiterbar: Monitoring, automatischer Wechsel in low_vram, nächtliches Vorladen per Cron.

5. Best Practices, Monitoring, Troubleshooting

5.1 Empfohlene Konfiguration nach VRAM

VRAM	Empfohlenes Modell	Quantisierung	GPU-Schichten	Weitere Parameter
6 GB	7B	Q4	Teilweise (~50 %)	low_vram=true, ctx=2048
8 GB	7B	Q4	Volle GPU	ctx=2048 (sicher)
8 GB	13B	Q4	Teilweise (~75 %)	low_vram=true, ctx=2048, batch=256
12 GB	13B	Q4	Volle GPU	ctx=4096 möglich
16 GB	13B	Q8 oder Q5	Volle GPU	ctx=4096
16 GB	70B	Q4	Teilweise (~50 %)	low_vram=true
24 GB	70B	Q4	Volle GPU	ctx=4096 möglich
48 GB (Dual)	70B	Q4	Volle GPU	Multi-Instanz-Lastverteilung

Konservative Schätzungen – KV-Cache und Systemreserve einrechnen. Bei langen Dialogen lieber vorsichtiger.

5.2 VRAM-Monitoring

nvidia-smi Echtzeit

# Jede Sekunde aktualisieren
nvidia-smi -l 1

# Nur Speichernutzung
nvidia-smi --query-gpu=memory.used,memory.free --format=csv -l 1

Während der Inferenz beobachten, wie der VRAM steigt.

Ollama verbose

ollama run llama3 --verbose

Zeigt u. a.:

• GPU-Offloading-Schichten
• Modellspeicher
• mmap-Status
• KV-Cache-Zuweisung

GPU offloading: 40/40 layers → Modell vollständig auf GPU.

Monitoring-Skript

#!/bin/bash
# monitor_gpu.sh

LOG_FILE="gpu_memory.log"

while true; do
    TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')
    GPU_MEM=$(nvidia-smi --query-gpu=memory.used,memory.free --format=csv,noheader)
    echo "$TIMESTAMP $GPU_MEM" >> $LOG_FILE
    sleep 5
done

Im Hintergrund für historische Daten.

5.3 Häufige Probleme

Problem 1: OOM bei Inferenz

1. nvidia-smi – VRAM wirklich voll?
2. Konfiguration prüfen:
   • Quantisierung Q4?
   • ctx zu groß? → 2048
   • batch zu groß? → 256
   • Alle Schichten auf GPU? → reduzieren
3. Wenn nicht reicht: low_vram=true

Priorität: Quantisierung > ctx > batch > GPU-Schichten > low_vram

Problem 2: Langsame Inferenz

GPU-Offloading prüfen:

ollama run your_model --verbose | grep "GPU offloading"

GPU offloading: 20/40 layers → Hälfte auf CPU, langsamer ist normal.

Lösung: weniger aggressive Quantisierung (Q4 → Q8) oder mehr VRAM. Sonst Geschwindigkeit akzeptieren.

Problem 3: Instabiler VRAM

Schwankungen meist durch wachsenden KV-Cache.

Lösung: ctx begrenzen oder Dialoghistorie in der App kürzen (z. B. nur letzte 10 Runden).

Problem 4: Multi-GPU, aber nur eine Karte aktiv

Nginx prüfen:

curl http://localhost:8080/api/tags

Ungleiche Auslastung? Mögliche Ursachen:

• least_conn nicht gesetzt
• Eine Instanz defekt (Logs prüfen)
• Modell nur auf einer Instanz geladen

Zusammenfassung

Die Kernpunkte:

1. VRAM knapp → zuerst quantisieren: Q4 spart 75 % gegenüber FP16, wenig Qualitätsverlust
2. KV-Cache im Blick: Kontextlänge treibt VRAM – lange Dialoge = mehr Druck
3. Multi-GPU braucht Lastverteilung: Ein-Instanz-Multi-GPU reicht selten – Multi-Instanz + Nginx
4. llama.cpp verstehen: GPU-Offloading ist Schicht-Rechnen mit Transfer-Overhead

Direkt nutzbare Konfigurationen:

Stabil auf 8 GB VRAM:

PARAMETER num_gpu 30
PARAMETER low_vram true
PARAMETER num_ctx 2048
PARAMETER num_batch 256

Dual-GPU-Cluster starten:

CUDA_VISIBLE_DEVICES=0 OLLAMA_HOST=127.0.0.1:11434 ollama serve &
CUDA_VISIBLE_DEVICES=1 OLLAMA_HOST=127.0.0.1:11435 ollama serve &

Weiter in der Serie: Teil 6 behandelt Quantisierung und Batch-Grundlagen – dieser Artikel vertieft die GPU-Richtung. Teil 8: Multi-Modell-Parallel-Deployment für komplexere Multi-GPU-Szenarien.

Fragen? Ollama GitHub Discussions – viele Praxisfälle sind dort diskutiert. Oder Kommentar unter dem Artikel – ich antworte, wenn ich es sehe.

---