Ollama Parallelverarbeitung: NUM_PARALLEL und MAX_QUEUE

Was passiert mit der zweiten Ollama-Anfrage, während die erste generiert wird

Die Parallelverarbeitung in Ollama wird durch drei Umgebungsvariablen gesteuert. Standardmäßig verarbeitet ein geladenes Modell jeweils eine Anfrage. Die zweite Anfrage wird nicht abgewiesen und erhält auch keine unvollständige Antwort. Sie wartet in einer Warteschlange, bis ein Slot frei ist, und wird anschließend mit normaler Geschwindigkeit verarbeitet.

Für eine eingehende Anfrage gibt es drei mögliche Ergebnisse. Sie startet sofort in einem freien Slot. Sie wartet in der Warteschlange. Oder die Warteschlange ist bereits voll, und der Server weist die Anfrage mit HTTP 503 zurück. Welches Ergebnis eintritt, wird durch OLLAMA_NUM_PARALLEL, OLLAMA_MAX_QUEUE und OLLAMA_MAX_LOADED_MODELS bestimmt.

Die Standardeinstellung ist sicher. Sie erklärt auch, warum ein zweiter Benutzer meldet, dass der Server „hängt“, obwohl kein Fehler vorliegt. Das Hinzufügen von Slots erfordert eine Änderung in zwei Zeilen. Kritisch ist der Speicherbedarf. Jeder parallele Slot benötigt einen eigenen Key/Value-Cache (KV-Cache). Dabei handelt es sich um den Speicherbereich, in dem ein Modell die bereits verarbeiteten Tokens vorhält. Wenn Sie Slots hinzufügen, ohne den VRAM (Videospeicher der GPU) zu erweitern, wird aus einer langsamen Antwort ein fehlgeschlagener Ladevorgang.

Wof OLLAMA_NUM_PARALLEL, OLLAMA_MAX_LOADED_MODELS und OLLAMA_MAX_QUEUE jeweils gesteuert werden

Dies sind die Standardwerte aktueller Ollama-Releases im August 2026. Prüfen Sie Ihre Werte, statt dieser Zahl zu vertrauen. Verwenden Sie dazu die weiter unten gezeigte Logzeile.

• OLLAMA_NUM_PARALLEL gibt an, wie viele Anfragen ein geladenes Modell gleichzeitig verarbeitet. Der Standardwert ist 1. Die Anfragen werden daher nacheinander verarbeitet.
• OLLAMA_MAX_LOADED_MODELS gibt an, wie viele verschiedene Modelle gleichzeitig im Speicher bleiben. Der Standardwert ist 0. In diesem Fall wählt Ollama den Wert selbst: drei Modelle pro GPU und drei Modelle auf einem Rechner ohne GPU.
• OLLAMA_MAX_QUEUE gibt an, wie viele Anfragen warten dürfen. Der Standardwert ist 512. Die Anfrage, die eintrifft, wenn die Warteschlange voll ist, wird sofort abgewiesen.

Der maximale Speicherbedarf ergibt sich aus dem Produkt der ersten beiden Werte. Zwei geladene Modelle mit jeweils vier Slots entsprechen acht gleichzeitig reservierten KV-Cache-Slots. Ollama versucht, diesen Bedarf bereitzustellen. Auf einem Rechner mit nur einer GPU ist es meist besser, ein Modell im Speicher zu halten und ihm mehrere Slots zu geben. Die Berechnung bleibt dadurch überschaubar.

Warum jeder parallele Slot VRAM kostet

Wenn Ollama ein Modell lädt, startet es einen separaten Runner-Prozess. Zwei der dabei übergebenen Argumente sind hier relevant: -c ist der gesamte Kontext, für den der Runner einen KV-Cache reserviert, und -np ist die Anzahl der parallelen Sequenzen. Ollama setzt -c auf Ihre Kontextlänge pro Anfrage multipliziert mit der Anzahl der Slots. Der Runner teilt diese Gesamtsumme anschließend gleichmäßig auf die Slots auf. Dadurch erhält jede Anfrage weiterhin die von Ihnen festgelegte Kontextlänge.

Das ist die gesamte Einschränkung. Deshalb ist Parallelität nicht kostenlos. Wenn Sie von einem Slot auf vier Slots erhöhen, wird bei gleicher Kontextlänge pro Anfrage der vierfache KV-Cache benötigt. Zwischen den Slots wird nichts gemeinsam genutzt. Der Anteil eines inaktiven Slots wird auch nicht an einen ausgelasteten Slot verliehen, weil die Aufteilung beim Start des Runners festgelegt wird.

Sie können die tatsächlichen Werte auslesen, statt nur die Werte zu betrachten, die Sie setzen wollten:

journalctl -u ollama --no-pager -n 500 | grep "starting llama-server"

Diese Zeile enthält die vollständige Runner-Befehlszeile einschließlich -c und -np. Wenn -np nach dem Setzen der Variable den Wert 1 hat, erreicht die Einstellung den Server nicht. Der nächste Abschnitt erklärt, warum.

Wenn die Modellgewichte zusammen mit diesem KV-Cache nicht in den VRAM passen, verschiebt Ollama einige Layer in den Arbeitsspeicher des Systems. Diese Layer werden dann auf der CPU ausgeführt. CPU-Layer sind deutlich langsamer als GPU-Layer. Dadurch wird jede Anfrage langsamer, auch die einzelne Anfrage, mit der Sie begonnen haben. Eine höhere Parallelität kann den Durchsatz daher verringern, statt ihn zu erhöhen.

ollama ps

Die Spalte PROCESSOR enthält den Wert 100% GPU, wenn alles vollständig in den VRAM passt. Eine Aufteilung wie 35%/65% CPU/GPU bedeutet, dass ein Teil des Modells auf der CPU ausgeführt wird. Die Spalte SIZE enthält den KV-Cache. Sie wächst daher, wenn Sie die Anzahl der Slots erhöhen und das Modell neu laden. Erhöhen Sie OLLAMA_NUM_PARALLEL, starten Sie den Dienst neu, senden Sie eine Anfrage und führen Sie ollama ps erneut aus. So messen Sie die Speicherkosten Ihrer Änderung, statt sie zu schätzen.

Kontextlänge und Slot-Anzahl werden miteinander multipliziert. Deshalb müssen Sie beide Werte gemeinsam festlegen. Ein großer Kontext mit vier Slots entspricht vier großen Kontexten. Wenn Sie außerdem das Kontextfenster num_ctx für Ihr Modell anpassen, ändern Sie jeweils nur einen der beiden Werte. Andernfalls wissen Sie nicht, welcher Wert den VRAM gefüllt hat.

So setzen Sie diese Variablen dauerhaft über einen Reboot hinweg

Unter Linux läuft Ollama als systemd-Dienst. Wenn Sie export OLLAMA_NUM_PARALLEL=4 in Ihrer Shell ausführen, hat das keine Auswirkungen, weil systemd den Dienst mit einer eigenen Umgebung startet und Ihre Shell nicht sieht. Verwenden Sie stattdessen eine Drop-in-Datei.

sudo systemctl edit ollama.service

Fügen Sie dies im geöffneten Editor ein:

[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_MAX_QUEUE=32"

Laden Sie anschließend die Konfiguration neu und starten Sie den Dienst neu:

sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl show ollama --property=Environment

systemctl show zeigt an, welche Werte systemd an den Prozess übergibt. Fehlt Ihre Variable dort, wurde die Drop-in-Datei nicht gespeichert oder daemon-reload nicht ausgeführt. Prüfen Sie die Einstellung zusätzlich direkt auf dem Server:

journalctl -u ollama --no-pager | grep "server config" | tail -1

Ollama protokolliert seine vollständige Umgebung beim Start in einer Zeile mit der Meldung server config. Diese Zuordnung ist maßgeblich. Damit lässt sich am schnellsten klären, ob eine Variable wirksam wurde.

Ein bereits geladenes Modell behält die Slot-Anzahl, mit der es gestartet wurde, weil dieser Wert beim Start im Runner-Prozess festgelegt wird. Der obige Neustart entlädt alle Modelle. Die nächste Anfrage lädt das Modell daher mit der neuen Einstellung erneut und verursacht die Ladezeit einmalig. Wie lange ein Modell danach im Speicher bleibt, wird separat gesteuert. Das wird unter ein Ollama-Modell zwischen Anfragen geladen halten beschrieben.

So sehen bediente, eingereihte und abgewiesene Anfragen auf dem Client aus

Senden Sie mehrere Anfragen gleichzeitig und messen Sie deren Dauer. Dadurch werden acht Streaming-Anfragen parallel ausgeführt. Für jede Anfrage werden Status und Zeitwerte ausgegeben:

for i in $(seq 1 8); do
  curl -s -o /dev/null \
    -w "req$i http=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n" \
    http://127.0.0.1:11434/api/generate \
    -d '{"model":"llama3.2:3b","prompt":"Explain what a KV cache is.","stream":true}' &
done
wait

ttfb bezeichnet die Zeit bis zum ersten Byte des Streams. Sie entspricht annähernd der Zeit bis zum ersten Token (TTFT), weil der erste gestreamte Chunk das erste Token enthält.

Parallel bedient. Jede Anfrage meldet einen ähnlichen Wert für ttfb, und total steigt bei allen Anfragen gleichzeitig. Die GPU wird zwischen den laufenden Slots aufgeteilt. Daher dauert jede Antwort länger als bei einer einzelnen Anfrage, während dennoch mehr Antworten pro Minute abgeschlossen werden. Dies ist der Betriebsmodus, den Sie mit einer Erhöhung von OLLAMA_NUM_PARALLEL erreichen.

Eingereiht. Die ersten Anfragen werden schnell beantwortet. Bei den späteren Anfragen ist ttfb deutlich erhöht, anschließend läuft die Generierung normal ab. Die Wartezeit entsteht durch die Warteschlange, nicht durch das Modell. Ein Benutzer sieht im Chatfenster zunächst eine lange leere Pause. Danach wird der Text mit voller Geschwindigkeit ausgegeben. Dieses Muster – langsamer Start und anschließend schnelle Ausgabe – weist auf eine Warteschlange und nicht auf eine überlastete GPU hin.

Abgewiesen. Der Client erhält http=503 fast sofort. Der Antworttext lautet:

{"error":"server busy, please try again.  maximum pending requests exceeded"}

Diese Meldung bedeutet, dass die Warteschlange beim Eintreffen der Anfrage voll war. Sie sagt nichts über den VRAM und nichts über das Modell aus.

Eine wichtige Einschränkung: Ollama veröffentlicht keine Warteschlangentiefe. ollama ps und der Endpunkt /api/ps melden die geladenen Modelle, nicht die wartenden Anfragen. Daher messen Sie die Warteschlange auf der Client-Seite, indem Sie die Zeit bis zum ersten Byte beobachten. Alternativ zählen Sie die 503-Antworten an der vorgeschalteten Komponente.

Warum ein kleinerer MAX_QUEUE-Wert oft die bessere Einstellung ist

Eine Warteschlange mit 512 Einträgen klingt großzügig. Bei nur einem Slot ist sie jedoch nahezu nutzlos. Anfrage 300 wartet hinter 299 vollständig abgearbeiteten Generierungen. Das dauert bestenfalls mehrere Minuten. Jeder HTTP-Client gibt vorher auf. Der Aufrufer erhält dann einen clientseitigen Timeout. Dieser liefert weder Informationen zur Ursache noch einen sinnvollen Auslöser für Ihre Überwachung.

Setzen Sie die Warteschlangengröße ungefähr auf die Anzahl der Anfragen, die Ihr Server innerhalb des Client-Timeouts abarbeiten kann. Überläufe führen dann stattdessen sofort zu einem 503. Ein 503 ist hilfreich: Ein Reverse Proxy kann die Anfrage erneut versuchen, ein Client kann die Anfragen verlangsamen, ein Dashboard kann die Fehler zählen und ein Administrator kann die Meldung lesen. Ermitteln Sie den Wert anhand Ihrer eigenen Messungen. Wenn eine Generierung etwa zehn Sekunden dauert und Ihr Client sechzig Sekunden wartet, können pro Slot ungefähr sechs Anfragen innerhalb dieses Zeitraums abgearbeitet werden. Eine deutlich tiefere Warteschlange führt dann nur zu Timeouts.

Wann Sie eine Queue vor Ollama setzen sollten

Die integrierte Queue arbeitet nach dem FIFO-Prinzip (First In, First Out) und weiß nicht, wer die Anfrage stellt. Für eine Anwendung, die mit einem Server kommuniziert, reicht das aus. Zusätzliche Infrastruktur würde nur weitere Fehlerquellen schaffen. Setzen Sie eine Komponente davor, sobald eine der folgenden Bedingungen erfüllt ist.

• Sie benötigen Prioritäten. Ein interaktiver Chat sollte nicht hinter einem Batch-Auftrag zur Zusammenfassung warten. Ollamas Queue unterstützt keine Prioritäten. Batch-Aufträge müssen daher außerhalb der Queue zurückgehalten und langsam zugeführt werden.
• Sie benötigen Fairness. Ein einzelner Client kann die Queue vollständig füllen. Alle anderen Clients erhalten dann 503.
• Die Aufträge müssen einen Neustart überstehen. Die Queue liegt im Arbeitsspeicher des Servers. Wenn Sie Ollama neu starten, gehen alle wartenden Anfragen verloren.
• Sie benötigen echte Wiederholungsversuche mit Backoff, die an einer später überprüfbaren Stelle protokolliert werden.

Die einfache Variante ist ein Reverse Proxy. In nginx begrenzt limit_conn die Anzahl gleichzeitiger Verbindungen und limit_req die Eingangsrate pro Client. Überläufe werden dann am Proxy abgewiesen und erreichen die Queue von Ollama nicht. Die aufwendige Variante ist eine Job-Queue mit Datenbank vor einem Worker, der Ollama aufruft. Diese Variante benötigen Sie, sobald Anfragen einen Prozessneustart überstehen müssen. Die Auslegung für realen Datenverkehr ist ein eigenes Thema: die Planung eines selbst gehosteten LLM für mehrere gleichzeitige Benutzer behandelt die Berechnung. Ollama auf einem VPS ausführen beschreibt die grundlegende Installation, von der diese Variablen ausgehen.

Wenn die ehrliche Antwort ein anderer Server ist

Es gibt eine Grenze, die Sie nicht durch Anpassungen überwinden können. Ollama teilt den KV-Cache beim Laden des Modells in gleich große, feste Slots auf. Der Speicher eines inaktiven Slots kann nicht von einem ausgelasteten Slot verwendet werden. Die Anzahl der Slots lässt sich nicht ändern, ohne das Modell zu entladen. Dieses Design eignet sich gut für eine Person, ein kleines Team oder einen Coding-Agenten.

Server, die für viele gleichzeitige Benutzer ausgelegt sind, arbeiten anders. Sie weisen den KV-Cache bei Bedarf in kleinen Seiten zu und fügen neu eintreffende Anfragen einem bereits laufenden Batch hinzu. Dadurch folgt die Speichernutzung dem tatsächlichen Bedarf statt einer festen Aufteilung. Wenn Ihr Ziel eine große Zahl gleichzeitiger Benutzer auf einer GPU ist, ist dieser Architekturunterschied wichtiger als jeder Wert von OLLAMA_NUM_PARALLEL. Der Vergleich zwischen Ollama und vLLM ist der richtige Ausgangspunkt für diese Entscheidung. Wechseln Sie jedoch nicht grundsätzlich: Ein anderer Server verursacht mehr Betriebsaufwand. Wenn Ihr Datenverkehr auf wenige Personen beschränkt ist, ist das integrierte Verhalten die richtige Lösung.

Eigene Verarbeitungsgeschwindigkeit und Zeit bis zum ersten Token messen

Angaben zu veröffentlichten Tokens pro Sekunde stammen von der GPU, dem Modell, der Quantisierung und der Kontextlänge sowie vom Prompt einer anderen Person. Nichts davon entspricht Ihrer Umgebung. Betrachten Sie solche Werte daher nur als groben Hinweis und messen Sie das System, auf dem der Dienst tatsächlich läuft.

Ollama gibt Zeitmessungen im abschließenden JSON-Objekt jeder Antwort zurück. eval_count ist die Anzahl der generierten Tokens und eval_duration die für deren Generierung benötigte Zeit in Nanosekunden.

sudo apt install -y jq
curl -s http://127.0.0.1:11434/api/generate \
  -d '{"model":"llama3.2:3b","prompt":"Explain what a KV cache is.","stream":false}' \
  | jq '{prompt_eval_count, eval_count, eval_duration, tokens_per_second: (.eval_count / (.eval_duration / 1000000000))}'

Führen Sie den Befehl zunächst mit einem Slot und anschließend mit der tatsächlich erwarteten Parallelität aus. Vergleichen Sie dann die beiden Werte, die für die Benutzerzufriedenheit entscheidend sind: die Zeit bis zum ersten Token und die Tokens pro Sekunde und Anfrage. Der Durchsatz pro Anfrage sinkt immer, wenn weitere Slots hinzugefügt werden. Entscheidend ist, ob er stärker sinkt, als Ihre Benutzer akzeptieren. Tokens pro Sekunde bei einem lokalen LLM messen beschreibt die Methode ausführlicher. Der Artikel zeigt auch, wie der Prompt zwischen den Durchläufen unverändert bleibt.

Ein öffentlicher Endpunkt mit einer großzügigen Warteschlange ist ein Ziel für Denial-of-Service-Angriffe

Mit OLLAMA_HOST=0.0.0.0:11434 wird die API an allen Schnittstellen bereitgestellt. Ollama verfügt über keine integrierte Authentifizierung. Ein offener Endpunkt mit der Standardwarteschlange akzeptiert 512 wartende Anfragen von jedem, der ihn findet. Ein Angreifer kann diese Warteschlange nahezu ohne Aufwand füllen: lange Prompts, keine Anmeldung, keine Ratenbegrenzung und keine Kosten. Ihre eigenen Benutzer erhalten dann 503-Antworten oder müssen lange warten. Die Maschine ist währenddessen vollständig ausgelastet.

Lassen Sie den Listener an loopback gebunden und greifen Sie über einen SSH-Tunnel oder ein privates Netzwerk darauf zu. Alternativ können Sie eine Authentifizierung und eine Ratenbegrenzung davor schalten. Einen Ollama-API-Endpunkt absichern behandelt beide Möglichkeiten. Passen Sie die Warteschlange erst danach an. Die Länge der Warteschlange ist eine Kapazitätseinstellung und schützt nichts.

FAQ

Warum wartet meine zweite Ollama-Anfrage, bis die erste abgeschlossen ist?

Weil OLLAMA_NUM_PARALLEL standardmäßig auf 1 gesetzt ist. Ein geladenes Modell verarbeitet dadurch jeweils nur eine Anfrage. Die übrigen Anfragen warten in Reihenfolge. Die wartende Anfrage hält ihre HTTP-Verbindung offen und sendet keine Bytes, bis ein Slot frei wird. Auf Clientseite sieht das genauso aus wie ein langsames Modell. Entscheidend ist der zeitliche Verlauf: Eine lange Pause und anschließend Text mit voller Geschwindigkeit weisen auf eine Warteschlange hin. Ein langsames, ab dem ersten Token gleichmäßiges Eintreffen weist auf ein langsames Modell hin. Erhöhen Sie die Anzahl der Slots mit einem systemd-Drop-in und starten Sie den Dienst neu.

Was bedeutet „server busy, please try again. maximum pending requests exceeded“?

Das ist der von Ollama zurückgegebene Überlauffehler der Warteschlange mit dem HTTP-Status 503. Die Anzahl der bereits wartenden Anfragen hat OLLAMA_MAX_QUEUE erreicht. Dieser Wert ist standardmäßig 512. Deshalb wurde die neueste Anfrage abgewiesen, statt sie zur Warteschlange hinzuzufügen. Es handelt sich weder um einen Speicherfehler noch um einen Modellfehler. Eine größere Warteschlange sorgt nur dafür, dass Aufrufer vor derselben Ablehnung länger warten. Die eigentlichen Lösungen sind mehr Slots, sofern der VRAM dafür ausreicht, eine geringere Eingangslast oder eine vorgeschaltete Warteschlange, die Anfragen erneut senden und priorisieren kann.

Wird Ollama durch einen höheren Wert für OLLAMA_NUM_PARALLEL schneller?

Nein. Dadurch können mehr Anfragen gleichzeitig ausgeführt werden. Jede dieser Anfragen ist jedoch langsamer als bei alleiniger Ausführung, weil sie sich eine GPU teilen. Außerdem vervielfacht sich der KV-Cache, da Ollama den Runner mit einem Gesamtkontext aus Kontextlänge multipliziert mit der Anzahl der Slots startet. Passt das Ergebnis nicht mehr in den VRAM, verschiebt Ollama Layer auf die CPU. Dadurch wird jede Anfrage langsamer, auch eine einzelne ohne Konkurrenz. Prüfen Sie nach der Änderung ollama ps und bestätigen Sie, dass die Spalte PROCESSOR weiterhin 100% GPU anzeigt.

Muss ich Ollama nach der Änderung dieser Variablen neu starten?

Ja. Der Server liest sie beim Start ein. Ein laufendes Modell behält die Slot-Anzahl, die beim Start in seinen Runner-Prozess übernommen wurde. Bearbeiten Sie das Drop-in mit sudo systemctl edit ollama.service. Führen Sie anschließend sudo systemctl daemon-reload und sudo systemctl restart ollama aus. Bestätigen Sie die Änderung mit systemctl show ollama --property=Environment. Prüfen Sie danach die Zeile server config in journalctl -u ollama. Sie listet die Umgebung auf, die der Server tatsächlich geladen hat.

Wie viele parallele Slots sollte ich einstellen?

Beginnen Sie mit 1 und erhöhen Sie den Wert jeweils um einen Schritt. Starten Sie Ollama nach jedem Schritt neu. Senden Sie anschließend eine Anfrage, um das Modell zu laden, und führen Sie ollama ps aus. Beenden Sie den Vorgang beim letzten Wert, bei dem PROCESSOR weiterhin 100% GPU anzeigt und die Spalte SIZE noch ausreichend Reserven für den längsten von Ihnen bereitgestellten Kontext lässt. Messen Sie bei dieser Einstellung unter der tatsächlichen Parallelität die Zeit bis zum ersten Token und die Token pro Sekunde. Verringern Sie den Wert um einen Schritt, wenn die Geschwindigkeit pro Anfrage unter das für Ihre Benutzer akzeptable Niveau gefallen ist.