Wie Ollama parallele Anfragen verarbeitet

Dieser Leitfaden erklärt, wie Ollama parallele Anfragen verarbeitet (Konkurrenz, Warteschlangen und Ressourcenlimits), und wie man dies mithilfe der Umgebungsvariable OLLAMA_NUM_PARALLEL (und verwandter Einstellungen) anpassen kann.

Für weitere Informationen zu Durchsatz, Latenz, VRAM und Benchmarks über verschiedene Laufzeitumgebungen und Hardware hinweg, siehe LLM-Leistung: Benchmarks, Flaschenhälse & Optimierung.

Mehrschrittige Agenten vervielfachen Wiederholungen, wenn das Sampling instabil ist; für die Auswahl der Standardwerte für Temperature, top_p und Penalties bei Qwen- und Gemma-Modellen siehe Agentische Inferenzparameter für Qwen und Gemma.

Verarbeitung paralleler Anfragen

• Parallele Verarbeitung: Ollama unterstützt die parallele Verarbeitung von Anfragen. Wenn das System ausreichend verfügbaren Speicher hat (RAM für CPU-Inferenz, VRAM für GPU-Inferenz), können mehrere Modelle gleichzeitig geladen werden, und jedes geladene Modell kann mehrere Anfragen parallel bearbeiten. Dies wird durch die Umgebungsvariable OLLAMA_NUM_PARALLEL gesteuert, die die maximale Anzahl an parallelen Anfragen festlegt, die ein Modell gleichzeitig verarbeiten kann. Standardmäßig ist dieser Wert auf 4 gesetzt (oder 1, je nach Speicherverfügbarkeit), kann aber angepasst werden.

• Batching: Wenn mehrere Anfragen für dasselbe Modell gleichzeitig eintreffen, bündelt Ollama diese und verarbeitet sie zusammen. Das bedeutet, dass beide Anfragen parallel bearbeitet werden und Nutzer gleichzeitig streamende Antworten erhalten. Der Server wartet nicht absichtlich darauf, ein Batch zu füllen; die Verarbeitung beginnt, sobald Anfragen verfügbar sind.

Warteschlangen und Limits

• Warteschlange: Wenn die Anzahl der gleichzeitigen Anfragen die konfigurierte Parallelität übersteigt (z. B. mehr als OLLAMA_NUM_PARALLEL Anfragen für ein Modell), werden zusätzliche Anfragen in eine Warteschlange gestellt. Die Warteschlange arbeitet nach dem Prinzip „First-In, First-Out“ (FIFO).

• Warteschlangenlimits: Die maximale Anzahl an Anfragen in der Warteschlange wird durch OLLAMA_MAX_QUEUE gesteuert (Standardwert: 512). Wenn die Warteschlange voll ist, erhalten neue Anfragen einen 503-Fehler, der darauf hinweist, dass der Server überlastet ist.

• Modell-Laden: Die Anzahl der verschiedenen Modelle, die gleichzeitig geladen werden können, wird durch OLLAMA_MAX_LOADED_MODELS gesteuert. Wenn eine Anfrage das Laden eines neuen Modells erfordert und der Speicher nicht ausreicht, lädt Ollama inaktive Modelle, um Platz zu schaffen, und die Anfrage wird in die Warteschlange gestellt, bis das Modell geladen ist.

Beispiel-Szenario

Wenn zwei Anfragen für dasselbe Modell gleichzeitig eintreffen und die Parallelität des Servers auf mindestens 2 gesetzt ist, werden beide Anfragen in einem Batch zusammen verarbeitet, und beide Nutzer erhalten Antworten gleichzeitig. Wenn die Parallelität auf 1 gesetzt ist, wird eine Anfrage sofort verarbeitet, und die andere wird in die Warteschlange gestellt, bis die erste abgeschlossen ist.

Wenn es sich um Anfragen für verschiedene Modelle handelt und genügend Speicher verfügbar ist, können beide Modelle geladen und die Anfragen parallel bearbeitet werden. Wenn nicht, muss möglicherweise ein Modell ausgeladen werden, und die Anfrage wird in die Warteschlange gestellt.

Zusammenfassungstabelle

Zusammenfassend lässt sich sagen, dass Ollama so konzipiert ist, mehrere gleichzeitige Anfragen effizient zu verarbeiten, vorausgesetzt, der Server ist für Konkurrenz konfiguriert und über ausreichende Ressourcen verfügt. Andernfalls werden die Anfragen in eine Warteschlange gestellt und nacheinander bearbeitet.

Wenn die Erhöhung von OLLAMA_NUM_PARALLEL die Latenz unter echtem Traffic nicht mehr stabil hält und die Warteschlange weiter wächst, ist dies eines der deutlicheren Signale, die man bei der Überlegung abwiegen sollte, auf einen dedizierten Serving-Engine zu wechseln. Von Ollama zu vLLM: Wann Sie Ihren lokalen LLM-Server migrieren sollten beschreibt diese Entscheidung im Detail, einschließlich Continuous Batching und PagedAttention als Mechanismen, die vLLM nutzt, um sicherzustellen, dass parallele Anfragen sich gegenseitig nicht beeinträchtigen.

Behandlung unzureichenden Speichers

Wenn Ollama auf unzureichenden Speicher stößt, um eingehende Anfragen zu verarbeiten, setzt es eine Kombination aus Warteschlangenmechanismen und Ressourcenmanagementstrategien ein, um die Stabilität zu gewährleisten:

Anfragen-Warteschlange

• Neue Anfragen werden in eine FIFO-Warteschlange (First-In, First-Out) gestellt, wenn Speicher nicht sofort allokiert werden kann.
• Die Größe der Warteschlange wird durch OLLAMA_MAX_QUEUE gesteuert (Standardwert: 512 Anfragen).
• Wenn die Warteschlange die Kapazität erreicht, erhalten neue Anfragen 503-Fehler („Server Overloaded“).

Modell-Verwaltung

• Aktive Modelle können aus dem Speicher ausgeladen werden, wenn sie inaktiv sind, um Ressourcen für wartende Anfragen freizugeben.
• Die Anzahl der gleichzeitig geladenen Modelle wird durch OLLAMA_MAX_LOADED_MODELS begrenzt (Standardwert: 3 × Anzahl der GPUs oder 3 für CPU).

Speicheroptimierung

• Versuche, Anfragen für dasselbe Modell in Batches zu verarbeiten, um die Speichereffizienz zu maximieren.
• Für GPU-Inferenz ist eine vollständige VRAM-Allokierung pro Modell erforderlich – partielle Loads werden nicht unterstützt.

Fehlerszenarien

Kritischer Speichermangel: Wenn selbst wartende Anfragen die verfügbaren Ressourcen übersteigen, kann Ollama:

• Auf die Festplatte auslagern (sehr starke Leistungseinbuße)
• „Out of memory“-Fehler zurückgeben
• In extremen Fällen die Modellinstanz zum Absturz bringen

Administrator sollten den Speicherverbrauch überwachen und diese Parameter auf der Grundlage ihrer Hardwarefähigkeiten anpassen. Die Behandlung unzureichenden Speichers wird entscheidend, wenn größere Modelle (7B+ Parameter) ausgeführt oder mehrere parallele Anfragen verarbeitet werden.

Ollama-Optimierungsstrategien

Aktivieren Sie die GPU-Beschleunigung mit export OLLAMA_CUDA=1 und setzen Sie die CPU-Threads über export OLLAMA_NUM_THREADS=84.

Hardware-Upgrades

• RAM: 32GB+ für 13B-Modelle, 64GB+ für 70B-Modelle
• Speicher: NVMe-SSDs für schnelleres Laden/Wechseln von Modellen
• GPU: NVIDIA RTX 3080/4090 mit 16GB+ VRAM für größere Modelle

Betriebsstrategien

• Anfragen bündeln (Batching): Verarbeiten Sie mehrere Abfragen gleichzeitig, um die Speicherkosten zu verteilen
• Automatisches Modell-Ausladen: Lässt Ollama inaktive Modelle aus dem Speicher entfernen
• Häufig genutzte Modelle cachen: Halten Sie gängige Modelle im Speicher resident

Überwachung & Fehlerbehebung

• Verwenden Sie nvidia-smi (GPU) und htop (CPU/RAM), um Flaschenhälse zu identifizieren
• Bei Speicherfehlern:
• Auf quantisierte Modelle umsteigen
• Anzahl der parallelen Anfragen reduzieren
• Swap-Bereich vergrößern

Beispiel für einen Optimierungsvorgang:

### Quantisiertes Modell mit GPU-Beschleunigung verwenden
export OLLAMA_CUDA=1
ollama run llama2:7b-q4_0 --context-size 2048

### Geladene Modelle und parallele Anfragen begrenzen
export OLLAMA_MAX_LOADED_MODELS=2
export OLLAMA_NUM_PARALLEL=4

Diese Anpassungen können den Speicherverbrauch um 30–60 % reduzieren, während die Antwortqualität beibehalten wird. Dies ist besonders vorteilhaft, wenn mehrere Modelle ausgeführt oder ein hoher Anfrageaufkommen verarbeitet wird.

Umgebungsvariable OLLAMA_NUM_PARALLEL

OLLAMA_NUM_PARALLEL steuert, wie viele Anfragen Ollama parallel ausführt. Wenn Sie mehrere Anfragen an denselben Ollama-Server senden, bestimmt diese Einstellung maßgeblich, ob diese konkurrenzfähig ausgeführt oder in eine Warteschlange gestellt werden.

• Höhere Werte können den Durchsatz erhöhen, wenn genügend CPU/GPU/VRAM verfügbar ist, aber können auch die Latenz und den Speicherdruck erhöhen.
• Niedrigere Werte reduzieren Kontention und können die Stabilität verbessern, aber Anfragen werden häufiger in die Warteschlange gestellt.

Der Speicherbedarf skaliert spezifisch mit OLLAMA_NUM_PARALLEL * OLLAMA_CONTEXT_LENGTH: Vier parallele Slots bei einer Kontexteinstellung von 32K reservieren KV-Cache-Speicher, als wäre eine einzige 128K-Sequenz geladen, selbst wenn noch keine Anfrage dies nutzt. Bei einer 16-GB-GPU ist diese Budgetberechnung oft wichtiger als das Warteschlangenverhalten – siehe KV Cache auf 16-GB-GPUs für das vollständige VRAM-Budget und warum OLLAMA_NUM_PARALLEL=1 normalerweise der richtige Startpunkt für eine einzelne lange Kontext-Sitzung ist.

So setzen Sie OLLAMA_NUM_PARALLEL

Linux / macOS (systemd-Dienst oder Shell):

export OLLAMA_NUM_PARALLEL=2
ollama serve

Einmalige Ausführung (Präfix nur für diesen Befehl):

OLLAMA_NUM_PARALLEL=2 ollama serve

Docker (Beispiel):

docker run --rm -e OLLAMA_NUM_PARALLEL=2 -p 11434:11434 ollama/ollama

So wählen Sie einen Wert

Beginnen Sie mit 1–2 für eine einzelne GPU / begrenztes VRAM und erhöhen Sie schrittweise, während Sie Folgendes überwachen:

• GPU-VRAM-Auslastung (OOM / Evictions)
• CPU-Auslastung und Lastdurchschnitt
• p95-Latenz Ihrer typischen Anfragen
• Fehlerrate / Timeouts

Wenn Sie eine bestimmte Seite für CLI-Nutzung optimieren möchten, siehe den Abschnitt Ollama CLI im Spickzettel, plus Befehlsbeispiele für ollama serve, ollama ps und ollama run.

Schnelle Tuning-Rezepte

Stabilität zuerst

• OLLAMA_NUM_PARALLEL=1
• Verwenden Sie kleinere / quantisierte Modelle
• Bevorzugen Sie kürzere Kontextgrößen

Durchsatz zuerst

• OLLAMA_NUM_PARALLEL=2 (oder höher, wenn Sie Spielraum haben)
• Berücksichtigen Sie Batch-Verarbeitung auf der Client-Ebene
• Stellen Sie ausreichendes VRAM und genügend CPU-Threads sicher

„Ich bin an meinem VRAM-Limit, wenn zwei Anfragen eintreffen“

• Reduzieren Sie OLLAMA_NUM_PARALLEL
• Verwenden Sie ein aggressiver quantisiertes Modell
• Reduzieren Sie die Kontextlänge / maximale Token-Zahl

Fehlerbehebung

Symptome, dass OLLAMA_NUM_PARALLEL zu hoch ist

• Anfragen schlagen unter Last intermittierend fehl
• GPU-OOM / Modell-Ausladen tritt häufig auf
• Latenzspitzen, wenn die zweite Anfrage eintrifft

Symptome, dass OLLAMA_NUM_PARALLEL zu niedrig ist

• CPU/GPU ist unterausgelastet
• Warteschlangenverzögerungen dominieren die Gesamtantwortzeit

Tipp: Wenn Sie auch Ihren Client steuern, fügen Sie Wiederholungen mit Jitter und Keep-Alive-Verbindungen hinzu. Viele „Ollama ist langsam“-Probleme sind in Wahrheit Warteschlangen + Verbindungs-Overhead.

Ollama: Batch-Verarbeitung vs. Parallele Ausführung

Batching in Ollama bezieht sich auf die Praxis, mehrere eingehende Anfragen zu gruppieren und sie als eine Einheit zu verarbeiten. Dies ermöglicht eine effizientere Nutzung der Rechenressourcen, insbesondere auf Hardware, die von parallelisierten Operationen profitiert (wie GPUs).

Wenn mehrere Anfragen für dasselbe Modell gleichzeitig eintreffen, kann Ollama sie in einem Batch zusammen verarbeiten, wenn der Speicher dies zulässt. Dies erhöht den Durchsatz und kann die Latenz für jede einzelne Anfrage reduzieren, da das Modell optimierte Matrixoperationen über das Batch nutzen kann.

Batching ist besonders effektiv, wenn die Anfragen in Größe und Komplexität ähnlich sind, da dies eine bessere Hardwareauslastung ermöglicht.

Parallele Ausführung in Ollama bedeutet, mehrere Anfragen gleichzeitig zu bearbeiten, entweder für dasselbe Modell oder für verschiedene Modelle, abhängig vom verfügbaren Speicher und der Konfiguration.

Ollama unterstützt zwei Ebenen der Parallelität:

• Laden mehrerer Modelle: Wenn genügend Speicher verfügbar ist, können mehrere Modelle geladen und Anfragen gleichzeitig bedienen werden.
• Parallele Anfragen pro Modell: Jedes geladene Modell kann mehrere Anfragen parallel verarbeiten, gesteuert durch die Einstellung OLLAMA_NUM_PARALLEL (Standardwert ist 1 oder 4, je nach Speicher).

Wenn Anfragen das Parallelitätslimit überschreiten, werden sie in eine Warteschlange (FIFO) gestellt, bis zu OLLAMA_MAX_QUEUE.

Fazit

Ollama nutzt sowohl Batching als auch parallele Ausführung, um mehrere Anfragen effizient zu verarbeiten. Batching gruppiert Anfragen für die gleichzeitige Verarbeitung, während die parallele Ausführung es mehreren Anfragen (oder Modellen) ermöglicht, gleichzeitig zu laufen. Beide Methoden hängen vom Systemspeicher ab und sind für optimale Leistung konfigurierbar.

Für weitere Benchmarks, Konkurrenz-Tuning und Leistungsrichtlinien, schauen Sie sich unser LLM-Leistung: Benchmarks, Flaschenhälse & Optimierung-Hub an.

Nützliche Links

• Ollama-Befehlsspickzettel
• LLM-Leistungsvergleich - Ollama auf 16GB VRAM GPU
• Ollama-Modelle auf anderes Laufwerk oder Ordner verschieben
• Wie Ollama Intel-CPU-Performance- und Effizienzkerne nutzt
• Von Ollama zu vLLM: Wann Sie Ihren lokalen LLM-Server migrieren sollten