Wie Ollama parallele Anfragen verarbeitet

Dieser Leitfaden erklärt, wie Ollama parallele Anfragen handhabt (Konnektheit, Warteschlangen und Ressourcengrenzen) und wie Sie dies mit der OLLAMA_NUM_PARALLEL-Umgebungsvariablen (und verwandten Parametern) optimieren können.

Schnelllinks: Was ist OLLAMA_NUM_PARALLEL? · Schnelle Optimierungsvorschläge · Wie Warteschlangen funktionieren · Problembehebung · Verwandt: Ollama CLI-Befehle Cheat Sheet

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

Multi-Step-Agenten multiplizieren Wiederholungsversuche, wenn das Sampling instabil ist; für Standardwerte für Temperatur, top_p und Penalty bei Modellen der Qwen- und Gemma-Klasse, siehe Agenten-Inferenzparameter für Qwen und Gemma.

Behandlung paralleler Anfragen

• Parallelverarbeitung: Ollama unterstützt die gleichzeitige Verarbeitung von Anfragen. Wenn das System genügend 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 paralleler Anfragen festlegt, die jedes Modell gleichzeitig verarbeiten kann. Standardmäßig ist dies auf 4 eingestellt (oder 1, abhängig von der Speicher可用性), kann aber angepasst werden.

• Batches: Wenn mehrere Anfragen für dasselbe Modell gleichzeitig eintreffen, fasst Ollama sie zusammen und verarbeitet sie gemeinsam. Das bedeutet, dass beide Anfragen parallel bearbeitet werden und die Benutzer die Antworten gleichzeitig gestreamt zurückbekommen. Der Server wartet nicht absichtlich darauf, einen Batch zu füllen; die Verarbeitung beginnt, sobald Anfragen verfügbar sind.

Warteschlangen und Grenzen

• Warteschlangen: Wenn die Anzahl der gleichzeitigen Anfragen die konfigurierte Parallelität überschreitet (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 First-In, First-Out (FIFO)-Prinzip.

• Warteschlangengrenzen: Die maximale Anzahl von Anfragen in der Warteschlange wird durch OLLAMA_MAX_QUEUE gesteuert (Standard: 512). Wenn die Warteschlange voll ist, erhalten neue Anfragen einen 503-Fehler, der anzeigt, dass der Server überlastet ist.

• Modelldownload: 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 unzureichend ist, lädt Ollama inaktive Modelle, um Platz zu machen, und die Anfrage wird in die Warteschlange gestellt, bis das Modell geladen ist.

Beispielszenario

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

Wenn die Anfragen für verschiedene Modelle sind 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 entladen werden, und die Anfrage wird in die Warteschlange gestellt.

Zusammenfassungstabelle

Zusammenfassend ist Ollama darauf ausgelegt, mehrere gleichzeitige Anfragen effizient zu handhaben, vorausgesetzt, der Server ist für Konnektivität konfiguriert und hat ausreichende Ressourcen. Andernfalls werden Anfragen in eine Warteschlange gestellt und der Reihe nach verarbeitet.

Wenn die Erhöhung von OLLAMA_NUM_PARALLEL die Latenz nicht mehr stabil hält und die Warteschlange unter echtem Verkehr weiter wächst, ist dies eines der klarsten Signale, das gegen einen Wechsel zu einem spezialisierten Serving-Engine abgewogen werden sollte. Ollama zu vLLM: Wann Sie Ihren lokalen LLM-Server migrieren sollten geht auf diese Entscheidung ein, einschließlich Continuous Batching und PagedAttention als Mechanismen, die vLLM verwendet, um sicherzustellen, dass gleichzeitige Anfragen sich nicht gegenseitig beeinträchtigen.

Behandlung unzureichenden Speichers

Wenn Ollama auf unzureichenden Speicher stößt, um eingehende Anfragen zu handhaben, verwendet es eine Kombination aus Warteschlangenmechanismen und Ressourcenmanagementstrategien, um die Stabilität aufrechtzuerhalten:

Anfrage-Warteschlange

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

Model-Management

• Aktive Modelle können aus dem Speicher entladen werden, wenn sie inaktiv werden, um Ressourcen für Anfragen in der Warteschlange freizugeben.
• Die Anzahl der gleichzeitig geladenen Modelle ist durch OLLAMA_MAX_LOADED_MODELS begrenzt (Standard: 3×GPU-Anzahl oder 3 für CPU).

Speicheroptimierung

• Versuche, Anfragen für dasselbe Modell zu batchen, um die Speichereffizienz zu maximieren.
• Für GPU-Inferenz wird vollständige VRAM-Allokation pro Modell erforderlich – partielle Loads werden nicht unterstützt.

Fehlerszenarien

Kritische Speichererschöpfung: Wenn sogar Anfragen in der Warteschlange die verfügbaren Ressourcen überschreiten, kann Ollama:

• Auf die Festplatte auslagern (was die Leistung stark beeinträchtigt)
• “Out of memory”-Fehler zurückgeben
• Im Extremfall die Modellinstanz zum Absturz bringen

Administratoren sollten die Speicherverwendung überwachen und diese Parameter basierend auf ihren Hardwarefähigkeiten anpassen. Die Handhabung unzureichenden Speichers wird entscheidend, wenn größere Modelle (7B+ Parameter) ausgeführt oder mehrere gleichzeitige Anfragen verarbeitet werden.

Ollama-Optimierungsstrategien

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

Hardware-Verbesserungen

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

Operationale Strategien

• Batch-Anfragen: Verarbeiten Sie mehrere Abfragen gleichzeitig, um den Speicher-Overhead zu amortisieren
• Automatisches Entladen von Modellen: Lässt Ollama inaktive Modelle aus dem Speicher entfernen
• Caching häufig verwendeter Modelle: Halten Sie gängige Modelle im Speicher

Überwachung & Problembehebung

• Verwenden Sie nvidia-smi (GPU) und htop (CPU/RAM), um Engpässe zu identifizieren
• Bei Speicherfehlern:
• Upgrade auf quantisierte Modelle
• Reduzieren Sie gleichzeitige Anfragen
• Erhöhen Sie den Swap-Speicher

Beispiel für einen Optimierungsworkflow:

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

### Begrenzen Sie geladene Modelle und parallele Anfragen
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 erhalten bleibt, was besonders vorteilhaft ist, wenn mehrere Modelle ausgeführt oder hohe Anfragevolumen bearbeitet werden.

OLLAMA_NUM_PARALLEL-Umgebungsvariable

OLLAMA_NUM_PARALLEL steuert, wie viele Anfragen Ollama parallel ausführt. Wenn Sie mehrere Anfragen an denselben Ollama-Server senden, entscheidet diese Einstellung weitgehend, ob sie gleichzeitig ausgeführt oder in eine Warteschlange gestellt werden.

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

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

Wie man einen Wert wählt

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

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

Wenn Sie eine bestimmte Seite für die CLI-Nutzung optimieren, sehen Sie sich den Ollama CLI-Abschnitt im Cheat Sheet an, sowie Befehlsbeispiele für ollama serve, ollama ps und ollama run.

Schnelle Optimierungsvorschläge

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 Kapazität haben)
• Erwägen Sie Request-Batching auf der Client-Ebene
• Stellen Sie ausreichendes VRAM und CPU-Threads sicher

“Mir läuft VRAM weg, wenn zwei Anfragen eintreffen”

• Reduzieren Sie OLLAMA_NUM_PARALLEL
• Verwenden Sie ein aggressiver quantisiertes Modell
• Reduzieren Sie Kontextlänge / Max Tokens

Problembehebung

Symptome, dass OLLAMA_NUM_PARALLEL zu hoch ist

• Anfragen schlagen intermittierend unter Last fehl
• GPU OOM / Modellentladung passiert häufig
• Latenzspikes, 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 kontrollieren, fügen Sie Wiederholungen mit Jitter und Keep-Alive-Verbindungen hinzu. Viele “Ollama ist langsam”-Probleme sind eigentlich Warteschlange + Verbindungsoverhead.

Ollama: Batch-Anfragen vs. parallele Ausführung

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

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

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

Parallele Ausführung in Ollama bedeutet, mehrere Anfragen zur gleichen Zeit zu handhaben, 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:

• Mehrere Modell-Ladevorgänge: Wenn genügend Speicher verfügbar ist, können mehrere Modelle geladen werden und Anfragen gleichzeitig bedienen.
• Parallele Anfragen pro Modell: Jedes geladene Modell kann mehrere Anfragen parallel verarbeiten, gesteuert durch die OLLAMA_NUM_PARALLEL-Einstellung (Standard ist 1 oder 4, abhängig vom Speicher).

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

Fazit

Ollama nutzt sowohl Batching als auch parallele Ausführung, um mehrere Anfragen effizient zu verarbeiten. Batching fasst Anfragen für die gleichzeitige Verarbeitung zusammen, während parallele Ausführung mehrere Anfragen (oder Modelle) gleichzeitig laufen lässt. Beide Methoden hängen vom Systemspeicher ab und sind konfigurierbar für optimale Leistung.

Für weitere Benchmarks, Konnektivitätsoptimierung und Leistungshinweise, schauen Sie in unser LLM-Leistung: Benchmarks, Engpässe & Optimierung-Hub.

Nützliche Links

• Ollama-Befehle Cheat Sheet
• LLM-Leistungsvergleich - Ollama auf 16GB VRAM GPU
• Ollama-Modelle auf anderes Laufwerk oder Ordner verschieben
• Wie Ollama Intel-CPU-Leistung und effiziente Kerne nutzt
• Ollama zu vLLM: Wann Sie Ihren lokalen LLM-Server migrieren sollten