Ollama GPU- und Leistungsoptimierung

Wenn ein Modell langsam läuft, lassen sich Hinweise auf neun von zehn Ursachen in einer einzigen Zeile von ollama ps finden. Dieses Kapitel geht von Methoden zur Fehlerbehebung über Hardwareunterstützung und Multi-GPU-Zuweisung bis hin zu zwei erweiterten Schaltern: Flash Attention und KV-Cache-Quantisierung.

Es gibt nur ein Ziel: das Beste aus Ihrer GPU herauszuholen.

---

Der erste Schritt ist immer: Bestätigen Sie, wo das Modell ausgeführt wird

Die erste Aktion ist in der PROCESSOR-Spalte. Sie sagt dir direkt, dass die Modellgewichte geladen sind.

$ ollama ps
NAME             ID            SIZE      PROCESSOR    CONTEXT    UNTIL
qwen3.5:27b      a8b2c9d3e4f5  20.4GB    52%/48%      CPU/GPU    4 minutes from now

Die drei Formen entsprechen völlig unterschiedlichen Situationen:

PROCESSOR zeigt	Bedeutung	Geschwindigkeitserwartung
100% GPU	Alle Gewichte in VRAM geladen	Volle GPU-Geschwindigkeit
100% CPU	VRAM kann es überhaupt nicht fassen, reine Speicherinferenz	Ein bis zwei Größenordnungen langsamer
52%/48% CPU/GPU	Unzureichender VRAM, Gewichte werden aufgeteilt	Spürbarer Rückgang, Flaschenhals bei der geräteübergreifenden Übertragung

Es ist intuitiver, sich das zusammen mit der Generierungsgeschwindigkeit anzusehen: eval_count / eval_duration * 10^9 am Ende der API-Antwort ergibt token/s (siehe den späteren Teil des API-Kapitels zur Verwendung). Verwende diese Zahl als quantitativen Maßstab für jede Optimierung.

Wenn du auf ein langsames Modell stößt, folge dem folgenden Entscheidungspfad:

---

GPU-Beschleunigungsunterstützung nach Plattform

Ollama unterstützt vier wichtige Beschleunigungs-Backends, und die Installation des richtigen Treibers ist Voraussetzung.

Plattform	Backend	Voraussetzung
NVIDIA	CUDA	Compute Capability 5.0+, Treiber 550+ (alte Karten mit 5.0~6.2 erfordern 570+)
AMD（Linux）	ROCm v7	Erfordert den ROCm-v7-Treiber; alte Treiber können einen Discovery-Timeout verursachen und auf die CPU zurückfallen
AMD（Windows）	ROCm v7 / Vulkan	ROCm v7 oder HIP7-Treiber-Stack; einige Modelle der RX-6000-Serie verwenden Vulkan als Fallback
Apple Silicon	Metal	Funktioniert out of the box, keine Konfiguration erforderlich
Intel / Andere	Vulkan	Ergänzendes Backend standardmäßig aktiviert, deckt ältere AMD-Karten und Intel-GPUs ab

Um Fehler zu beheben, ob die GPU erkannt wird, sind Discovery-Einträge in den Logs am überzeugendsten; NVIDIA-Nutzer können auch docker run --gpus all ubuntu nvidia-smi verwenden, um Passthrough in Container-Szenarien zu überprüfen.

Um Ollama auf bestimmte GPUs zu beschränken oder den reinen CPU-Modus zu erzwingen, hat jedes Backend entsprechende Schalter:

---

Multi-GPU-Lastverteilung

Die Allokationsstrategie auf Multi-GPU-Maschinen ist automatisch, mit nur einer Regel: eine einzelne GPU bevorzugen und nur aufteilen, wenn es nicht passt.

Wenn das Modell vollständig in eine einzelne Karte passt, wählt Ollama eine aus, um es zu laden – Single-GPU vermeidet PCIe-übergreifende Datenübertragung und ist normalerweise die optimale Lösung für den Durchsatz.

Wenn eine einzelne GPU das Modell nicht aufnehmen kann, wird es auf alle verfügbaren GPUs aufgeteilt; an diesem Punkt müssen Sie außerdem Reserven für KV-Cache und Kontext einplanen. Das ist auch ein häufiger Grund, warum Modelle mit vielen Parametern "aufgeteilt werden, obwohl der gesamte VRAM ausreichend erscheint."

Beim Mischen mehrerer AMD-GPUs unter Linux können bestimmte Treiberversionen verstümmelte Ausgabe erzeugen. Diese Probleme sind in der offiziellen AMD-Dokumentation zu bekannten Multi-GPU-Problemen dokumentiert; priorisieren Sie die Aktualisierung des ROCm-Treibers.

---

Optimierungsspielraum bei der CPU-Inferenz

Es kann ohne eine dedizierte GPU laufen, aber es gibt mehrere Punkte, bei denen es sich lohnt, noch etwas herauszuholen.

Ollama wird mit mehreren CPU-Inferenzbibliotheken geliefert, mit folgender Leistungsrangfolge: cpu_avx2 > cpu_avx > cpu. Standardmäßig wird automatisch ausgewählt; bei fehlgeschlagener Autoerkennung kann man sie erzwingen:

Zwei zusätzliche Fakten: Die macOS-Rosetta-Übersetzungsumgebung kann nur die grundlegende cpu-Bibliothek verwenden; die Thread-Anzahl wird durch num_thread in den Optionen gesteuert, standardmäßig die Anzahl der physischen Kerne. Eine blinde Erhöhung kann aufgrund von Hyper-Threading-Konkurrenz tatsächlich zu einer Verlangsamung führen.

Der versteckte Hauptfaktor bei der CPU-Inferenz ist die Kontextlänge: Beim selben Modell ist der Unterschied der CPU-Inferenzgeschwindigkeit zwischen 4K- und 32K-Kontext sehr deutlich. Wenn man Modelle für CPU-Szenarien konfiguriert, sollte man num_ctx nicht leichtfertig sehr groß einstellen.

---

Flash Attention und KV-Cache-Quantisierung

Diese beiden sind die wichtigsten VRAM-Optimierungen für Langkontext-Szenarien. Sie zielen nicht auf Modellgewichte ab, sondern auf den KV-Cache, der mit dem Kontext wächst.

Neuere Versionen von Ollama aktivieren Flash Attention automatisch, wenn das Backend es unterstützt, und man kann es auch über Umgebungsvariablen erzwingen ein-/auszuschalten:

KV-Cache-Typ	VRAM-Nutzung	Auswirkung auf die Qualität	Empfehlung
f16 (Standard)	Baseline	Verlustfrei	Standard beibehalten, wenn VRAM reichlich vorhanden ist
q8_0	Etwa die Hälfte	Nahezu nicht wahrnehmbar	Empfohlene Wahl für Long-Context-Szenarien
q4_0	Etwa ein Viertel	Unter langem Kontext wahrnehmbar	Nur berücksichtigen, wenn VRAM-Einsparungen maximiert werden sollen

Zwei Punkte zu beachten: Der KV-Cache-Typ ist eine globale Konfiguration, die für alle geladenen Modelle gilt; die Auswirkung der Quantisierung auf die Qualität variiert je nach Modell, und einige Modelle mit hohen GQA-Strukturen sind empfindlicher. Nach der Umstellung wird empfohlen, mit Prompts mit festem Seed zu vergleichen und zu verifizieren.

---

Qualitätskompromiss zwischen Quantisierungsgenauigkeit und Geschwindigkeit

Das Kapitel zur Modellauswahl behandelte die Größenvorteile der Quantisierung; hier ergänzen wir einige Schlussfolgerungen aus Geschwindigkeitssicht.

Precision	Size	Geschwindigkeit	Qualität	Anwendbarkeit
q8_0	Etwa die Hälfte von fp16	Nahe an fp16	Nahezu verlustfrei	Bevorzugte Wahl, wenn VRAM reichlich vorhanden ist
q4_K_M	Etwa ein Viertel von fp16	Normalerweise schneller	Leichte Verringerung	Standardstufe für lokale Bereitstellung
q4_K_S und niedriger	Kleiner	Nicht unbedingt schneller	Deutlichere Verringerung	Extreme VRAM-Einsparungen

Ein kontraintuitiver Punkt: Eine niedrigere Quantisierung ist nicht unbedingt schneller. Die Inferenzgeschwindigkeit wird durch die Speicherbandbreite begrenzt, und einige Low-Bit-Formate erfordern zusätzliche Dequantisierungsberechnungen. In der Praxis können sie gleich schnell oder sogar langsamer sein. Schauen Sie bei der Wahl einer Quantisierungsstufe nicht nur auf die Zahlen.

Empfohlene Vergleichsmethode: Fixieren Sie den Seed und verwenden Sie denselben Satz an Prompts; vergleichen Sie die Ausgabe und Token/s von zwei Quantisierungsstufen bei einer Temperatur von 0.3 und betrachten Sie Qualität und Geschwindigkeit gemeinsam.

---

Optimierung von Nebenläufigkeit und Durchsatz

Nachdem die Optimierung einzelner Anfragen ihr Limit erreicht hat, besteht der nächste Schritt darin, den Dienst Nebenläufigkeit verarbeiten zu lassen.

Die zentrale Variable ist OLLAMA_NUM_PARALLEL (Anzahl paralleler Anfragen pro Modell). Die Kosten müssen bedacht werden: Parallele Verarbeitung vervielfacht den Kontext-Cache, und der erforderliche VRAM entspricht ungefähr diesem Wert multipliziert mit dem KV-Speicher für die Kontextlänge. Eine zu große Einstellung kann das Modell aus der GPU verdrängen.

Serverseitige Warteschlangen werden durch OLLAMA_MAX_QUEUE gesteuert, Standard 512. Bei Überschreitung wird direkt 503 zurückgegeben, und der Client muss es erneut versuchen.

Die Vorgehensweise zur Optimierung des Durchsatzes:

Schritt 1: Optimierung für einzelne Anfragen (Spezifikationen, Quantisierung, FA und KV-Cache), um die Geschwindigkeit eines einzelnen Streams zu bestätigen.

Schritt 2: NUM_PARALLEL schrittweise erhöhen und auf jeder Stufe mit ollama ps bestätigen, dass es weiterhin 100 % GPU ist, und beobachten, ob der Gesamtdurchsatz steigt.

Schritt 3: Wenn 503-Warteschlangen oder gemischte Aufteilung auftreten, eine Stufe zurückgehen – das ist die rote Linie beim VRAM.

Weitere Erweiterungen