So behandelt Ollama parallele Anfragen

Dieses руководство erklärt, wie Ollama parallele Anfragen verarbeitet (Konnektivität, Warteschlangen und Ressourcenlimits) und wie man dies über die Umgebungsvariable OLLAMA_NUM_PARALLEL (und verwandte Parameter) einstellt.

Direktlinks: Was ist OLLAMA_NUM_PARALLEL? · Schnelle Tune-Up-Rezepte · Wie das Queuing funktioniert · Fehlerbehebung · Verwandt: Ollama CLI Befehle Spickzettel

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

Multi-Step-Agenten vermehren Retries, wenn das Sampling instabil ist; für Standardeinstellungen von Temperature, top_p und Strafen bei Modellen der Qwen- und Gemma-Klasse, siehe Agentische Inferenzparameter für Qwen und Gemma.

Verarbeitung paralleler Anfragen

• Parallele Verarbeitung: Ollama unterstützt die parallele Verarbeitung von Anfragen. Wenn das System über ausreichend verfügbaren Speicher verfügt (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 definiert, die jedes Modell gleichzeitig verarbeiten kann. Standardmäßig ist dieser Wert auf 4 gesetzt (oder auf 1, abhängig von der Speichererhältlichkeit), kann aber angepasst werden.

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

Queuing und Limits

• Queuing: Wenn die Anzahl gleichzeitiger Anfragen das konfigurierte Parallelitätsniveau ü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-Prinzip (FIFO).

• Warteschlangenlimits: Die maximale Anzahl gequeuter Anfragen 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.

• 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 unzureichend ist, wird Ollama inaktive Modelle entladen, um Platz zu schaffen, 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 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 in die Warteschlange gestellt, bis die erste abgeschlossen ist.

Wenn die verschiedenen Modelle betreffen und genügend Speicher vorhanden 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 so konzipiert, dass es mehrere gleichzeitige Anfragen effizient verarbeitet, vorausgesetzt, der Server ist für Konnektivität konfiguriert und über ausreichende Ressourcen verfügt. Andernfalls werden die Anfragen in eine Warteschlange gestellt und der Reihe nach verarbeitet.

Wenn das Erhöhen von OLLAMA_NUM_PARALLEL die Latenz nicht mehr stabil hält und die Warteschlange unter echtem Verkehr weiter wächst, ist dies eines der klareren Signale, die für einen Wechsel zu einem spezialisierten Serving-Engine abgewogen werden sollten. Ollama zu vLLM: Wann Sie Ihren lokalen LLM-Server migrieren sollten beleuchtet diese Entscheidung, einschließlich Continuous Batching und PagedAttention als Mechanismen, die vLLM verwendet, um sicherzustellen, dass sich parallele Anfragen nicht gegenseitig verschlechtern.

Umgang mit unzureichendem Speicher

Wenn Ollama unzureichenden Speicher zur Bearbeitung eingehender Anfragen feststellt, wendet es eine Kombination aus Queuing-Mechanismen und Ressourcenmanagement-Strategien an, um die Stabilität zu gewährleisten:

Anfragen-Queuing

• 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 die Kapazität erreicht, erhalten neue Anfragen 503 “Server Überlastet” Fehler.

Modellverwaltung

• Aktive Modelle können aus dem Speicher entladen werden, wenn sie inaktiv werden, um Ressourcen für gequeute Anfragen freizugeben.
• Die Anzahl gleichzeitig geladener 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 eine vollständige VRAM-Allokierung pro Modell benötigt - teilweise Laden wird nicht unterstützt.

Fehlszenarien

Kritischer Speicherausschöpfung: Wenn selbst gequeute Anfragen die verfügbaren Ressourcen überschreiten, kann Ollama:

• Auf Disk paginieren (Leistungsabfall drastisch)
• “Speicher ausgegangen” Fehler zurückgeben
• In extremen Fällen die Modellinstanz abstürzen lassen

Administratoren sollten die Speichernutzung überwachen und diese Parameter basierend auf ihren Hardware-Fähigkeiten anpassen. Der Umgang mit unzureichendem Speicher 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 CPU-Threads mit 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/Swappen von Modellen
• GPU: NVIDIA RTX 3080/4090 mit 16GB+ VRAM für größere Modelle

Operative Strategien

• Anfragen bündeln: Verarbeiten Sie mehrere Abfragen gleichzeitig, um die Speicher-Overhead zu amortisieren
• Automatische Modell-Entladung: Ermöglicht es Ollama, inaktive Modelle aus dem Speicher zu entfernen
• Häufig verwendete Modelle cachen: Halten Sie gängige Modelle im Speicher

Überwachung & Fehlerbehebung

• Verwenden Sie nvidia-smi (GPU) und htop (CPU/RAM), um Engpässe zu identifizieren
• Bei Speicherfehlern:
• Wechsel zu quantisierten Modellen
• Reduzierung paralleler Anfragen
• Erhöhung des Swap-Bereichs

Beispiel-Optimierungsworkflow:

### 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 erhalten bleibt, was insbesondere nützlich ist, wenn mehrere Modelle ausgeführt oder ein hohes Anfragesvolumen bearbeitet 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 weitgehend, ob sie parallel ablaufen oder in einer Warteschlange enden.

• Höhere Werte können den Durchsatz erhöhen, wenn Sie ausreichend 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.

Speicher skaliert spezifisch mit OLLAMA_NUM_PARALLEL * OLLAMA_CONTEXT_LENGTH: vier parallele Slots bei einer 32K-Kontexteinstellung reservieren KV-Cache, als wäre eine einzelne 128K-Sequenz geladen, noch bevor eine Anfrage sie verwendet. Auf einer 16-GB-GPU ist diese Budgetberechnung oft wichtiger als das Queuing-Verhalten — siehe KV Cache auf 16-GB-GPUs für das vollständige VRAM-Budget und warum OLLAMA_NUM_PARALLEL=1 normalerweise der richtige Ausgangspunkt für eine einzelne Long-Context-Session 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 sie schrittweise, während Sie überwachen:

• GPU-VRAM-Nutzung (OOM / Eviction)
• CPU-Nutzung und Load Average
• p95-Latenz Ihrer typischen Anfragen
• Fehlerquote / Timeouts

Wenn Sie eine bestimmte Seite für CLI-Nutzung optimieren, siehe den Abschnitt Ollama CLI im Spickzettel, einschließlich Befehlsbeispielen für ollama serve, ollama ps und ollama run.

Schnelle Tune-Up-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 Reserven haben)
• Berücksichtigen Sie Anfrage-Batching auf der Client-Ebene
• Stellen Sie ausreichendes VRAM und CPU-Threads sicher

“Mir geht VRAM aus, wenn zwei Anfragen eintreffen”

• Reduzieren Sie OLLAMA_NUM_PARALLEL
• Verwenden Sie ein aggressiver quantisiertes Modell
• Reduzieren Sie Kontextlänge / max tokens

Fehlerbehebung

Symptome dafür, dass OLLAMA_NUM_PARALLEL zu hoch ist

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

Symptome dafür, dass OLLAMA_NUM_PARALLEL zu niedrig ist

• CPU/GPU ist unterausgelastet
• Queuing-Verzögerungen dominieren die Gesamtarbeitszeit

Tipp: Wenn Sie auch Ihren Client kontrollieren, fügen Sie Retries mit Jitter und Keep-Alive-Verbindungen hinzu. Viele “Ollama ist langsam”-Probleme sind tatsächlich Queuing + Verbindungs-Overhead.

Ollama: Anfragent-Batching vs. Parallele Ausführung

Batching in Ollama bezieht sich auf die Praxis, mehrere eingehende Anfragen zu gruppieren und sie als 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 zu einem Batch zusammenfassen und gemeinsam verarbeiten, sofern 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 nutzen kann.

Batching ist besonders effektiv, wenn die Anfragen in Größe und Komplexität ähnlich sind, da dies eine bessere Hardware-Auslastung 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:

• Multi-Modell-Laden: Wenn genügend Speicher verfügbar ist, können mehrere Modelle geladen und gleichzeitig Anfragen 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) gequeut, bis OLLAMA_MAX_QUEUE erreicht ist.

Fazit

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

Für weitere Benchmarks, Konnektivitäts-Einstellungen und Leistungsanweisungen, schauen Sie in unseren LLM Performance: Benchmarks, Engpässe & Optimierung Hub.

Nützliche Links

• Ollama-Befehle Spickzettel
• LLM-Leistungsvergleich - Ollama auf 16GB VRAM GPU
• Ollama-Modelle auf anderes Laufwerk oder in anderes Verzeichnis verschieben
• Wie Ollama Intel-CPU-Leistungs- und Effizienzkerne verwendet
• Ollama zu vLLM: Wann Sie Ihren lokalen LLM-Server migrieren sollten