Ollama Parallelität: NUM_PARALLEL und MAX_QUEUE

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

Die Parallelität von 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. Welche Situation 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, der Server sei „hängengeblieben“, obwohl kein Fehler vorliegt. Das Hinzufügen weiterer Slots erfordert zwei Zeilen. Problematisch ist der Speicherbedarf. Jeder parallele Slot benötigt einen eigenen Key/Value-Cache (KV-Cache). Dabei handelt es sich um den Speicherbereich, in dem das Modell die bereits verarbeiteten Tokens vorhält. Wenn Sie weitere Slots hinzufügen, ohne den VRAM (Videospeicher der GPU) zu erweitern, wird aus einer langsamen Antwort ein fehlgeschlagener Ladevorgang.

Steuerung durch OLLAMA_NUM_PARALLEL, OLLAMA_MAX_QUEUE und OLLAMA_MAX_LOADED_MODELS

Dies sind die Standardwerte aktueller Ollama-Releases im August 2026. Prüfen Sie Ihre Werte, statt dieser Zahlen 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 die Anzahl automatisch: 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 bei voller Warteschlange eintrifft, wird sofort abgewiesen.

Der maximale Speicherbedarf ergibt sich aus dem Produkt der ersten beiden Werte. Zwei geladene Modelle mit jeweils vier Slots benötigen acht Slot-Zuweisungen für den KV-Cache, die gleichzeitig im Speicher bleiben. Ollama versucht, diesen Bedarf bereitzustellen. Auf einem Rechner mit nur einer GPU ist es meist besser, ein Modell zu laden 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 Parallelisierung nicht kostenlos. Wenn Sie von einem Slot auf vier wechseln, wird bei unveränderter Kontextlänge pro Anfrage der vierfache KV-Cache benötigt. Zwischen den Slots wird nichts gemeinsam verwendet. 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 der Werte, die Sie festlegen wollten:

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

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

Wenn die Modellgewichte zusammen mit diesem KV-Cache nicht in den VRAM passen, verschiebt Ollama einige Layer in den System-RAM. 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 Parallelisierung kann den Durchsatz daher verringern, statt ihn zu erhöhen. Bei einem ausreichend großen Modell steht die Entscheidung bereits durch die Modellgewichte fest, bevor die Slot-Berechnung beginnt. Deshalb geht es beim Self-Hosting eines Modells in der Größe von Kimi K3 eher um die Anzahl Ihrer Karten als um die Anzahl der festgelegten Slots.

ollama ps

Die Spalte PROCESSOR zeigt 100% GPU an, wenn das gesamte Modell 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 steigt 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 anschließend erneut ollama ps aus. So ermitteln Sie die Speicherkosten Ihrer Änderung durch eine Messung statt durch eine Schätzung. Wenn diese Messung zeigt, dass das Modell nicht mehr in den VRAM passt, beachten Sie, dass die Modellgewichte die andere Hälfte desselben Budgets bilden. Ein Wechsel von einem fp16- zu einem q8- oder q4-Build gibt häufig mehr VRAM frei, als der zusätzliche Slot kostet.

Kontextlänge und Slot-Anzahl werden miteinander multipliziert. Sie müssen daher gemeinsam festgelegt werden. Ein großer Kontext mit vier Slots entspricht vier großen Kontexten. Wenn Sie zusätzlich das num_ctx-Kontextfenster für Ihr Modell anpassen, ändern Sie immer nur einen der beiden Werte. Andernfalls können Sie nicht feststellen, welcher Wert den Speicher der Karte vollständig belegt hat.

So setzen Sie Variablen, damit sie einen Reboot überstehen

Unter Linux läuft Ollama als systemd-Dienst. Wenn Sie export OLLAMA_NUM_PARALLEL=4 in Ihrer Shell ausführen, ändert das nichts, 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 übergeben wird. Fehlt Ihre Variable dort, wurde die Drop-in-Datei nicht gespeichert oder daemon-reload wurde übersprungen. Prüfen Sie die Einstellung zusätzlich direkt auf dem Server:

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

Ollama protokolliert beim Start seine gesamte Umgebung 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 verwendet weiterhin die beim Start festgelegte Anzahl von Slots, weil dieser Wert beim Start in den Runner-Prozess übernommen wird. Der obige Neustart entlädt alle Modelle. Die nächste Anfrage lädt das Modell daher mit der neuen Einstellung erneut und benötigt die Ladezeit nur einmal. Wie lange ein Modell danach resident bleibt, ist eine separate Einstellung. Sie wird unter ein Ollama-Modell zwischen Anfragen geladen halten beschrieben.

Wie sich bediente, eingereihte und abgewiesene Anfragen auf dem Client zeigen

Senden Sie mehrere Anfragen gleichzeitig und messen Sie ihre Laufzeiten. 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 ist die Zeit bis zum ersten Byte des Streams. Sie entspricht annähernd der Zeit bis zum ersten Token (TTFT), weil der erste gestreamte Block das erste Token enthält.

Parallel bedient. Jede Anfrage meldet einen ähnlichen Wert für ttfb, und total steigt bei allen Anfragen gleichzeitig an. Die laufenden Slots teilen sich die GPU. Deshalb ist jede Antwort langsamer als bei einer einzelnen Anfrage, während pro Minute mehr Antworten fertig werden. Das ist der Betriebsmodus, den Sie mit einer Erhöhung von OLLAMA_NUM_PARALLEL erreichen.

Eingereiht. Die ersten Anfragen antworten schnell. Bei den späteren Anfragen folgt auf einen großen Wert für ttfb eine normale Generierung. Die Wartezeit entsteht durch die Warteschlange, nicht durch das Modell. In einem Chatfenster sieht der Benutzer zunächst eine lange Pause ohne Ausgabe. Danach erscheint der Text mit voller Geschwindigkeit. Dieses Muster – langsamer Start, anschließend schnelle Ausgabe – weist auf eine Warteschlange und nicht auf eine überlastete GPU hin.

Abgewiesen. Der Client erhält http=503 nahezu 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 Größe der Warteschlange. ollama ps und der Endpunkt /api/ps melden die geladenen Modelle, nicht die wartenden Anfragen. Daher messen Sie die Warteschlange auf der Clientseite, indem Sie die Zeit bis zum ersten Byte beobachten. Alternativ zählen Sie die 503-Antworten an der Komponente, die dem Dienst vorgeschaltet ist.

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 lange vorher auf. Der Aufrufer erhält dann einen clientseitigen Timeout. Dieser sagt nichts über die Ursache aus und liefert Ihrem Monitoring keinen auswertbaren Alarm.

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 wiederholen, ein Client kann die Anfragen verlangsamen, ein Dashboard kann den Fehler zählen und eine Person kann ihn 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 Zeitfensters abgearbeitet werden. Eine deutlich längere Warteschlange führt dann nur zu Timeouts.

Wann Sie eine Warteschlange vor Ollama setzen

Die integrierte Warteschlange arbeitet nach dem FIFO-Prinzip (First In, First Out) und kennt den jeweiligen Aufrufer nicht. Für eine Anwendung, die mit einem Server kommuniziert, reicht das aus. Zusätzliche Infrastruktur würde nur weitere Fehlerquellen schaffen. Setzen Sie einen vorgeschalteten Dienst ein, wenn einer der folgenden Punkte zutrifft.

• Sie benötigen Prioritäten. Ein interaktiver Chat sollte nicht hinter einem Batch-Auftrag zur Zusammenfassung warten. Die Warteschlange von Ollama unterstützt keine Prioritäten. Batch-Aufträge müssen daher außerhalb der Warteschlange zurückgehalten und schrittweise eingespeist werden.
• Sie benötigen Fairness. Ein einzelner Client kann die Warteschlange vollständig füllen. Alle anderen erhalten dann 503.
• Die Aufträge müssen einen Neustart überstehen. Die Warteschlange 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 einsehbaren Stelle protokolliert werden.

Die einfache Variante ist ein Reverse Proxy. In nginx begrenzt limit_conn die Anzahl gleichzeitiger Verbindungen. limit_req begrenzt die Ankunftsrate pro Client. Überzählige Anfragen werden dadurch am Proxy abgewiesen und erreichen die Warteschlange von Ollama nicht. Die aufwendige Variante ist eine Auftragswarteschlange mit einer vorgeschalteten Datenbank und einem Worker, der Ollama aufruft. Diese Variante benötigen Sie, sobald Anfragen einen Neustart des Prozesses überstehen müssen. Die Dimensionierung für realen Netzwerkverkehr ist ein eigenes Thema: 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 weitere Konfiguration ü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 kann nicht geändert werden, ohne das Modell zu entladen. Dieses Design eignet sich gut für eine einzelne 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 zu einem bereits laufenden Batch hinzu. Dadurch richtet sich die Speichernutzung nach dem tatsächlichen Bedarf und nicht nach einer festen Aufteilung. Wenn Ihr Ziel eine große Anzahl 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 nur von wenigen Personen stammt, 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 einer anderen GPU, einem anderen Modell, einer anderen Quantisierung und einer anderen Kontextlänge sowie von einem anderen Prompt. Nichts davon entspricht Ihrer Umgebung. Betrachten Sie jeden gelesenen Wert daher nur als groben Hinweis und messen Sie das System, das Sie tatsächlich verwenden.

Ollama gibt Zeitmessungen im abschließenden JSON-Objekt jeder Antwort zurück. eval_count ist die Anzahl der generierten Tokens und eval_duration ist 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 Test 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 pro Anfrage. Die Verarbeitungsgeschwindigkeit pro Anfrage sinkt immer, wenn weitere Slots hinzugefügt werden. Entscheidend ist, ob sie stärker sinkt, als Ihre Benutzer akzeptieren. Tokens pro Sekunde bei einem lokalen LLM messen beschreibt die Methode ausführlicher und zeigt auch, wie der Prompt zwischen den Durchläufen konstant gehalten wird.

Ein öffentlich erreichbarer Endpunkt mit einer großzügigen Warteschlange ist ein Ziel für DoS-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 nimmt 512 wartende Anfragen von jedem an, der ihn findet. Ein Angreifer kann diese Warteschlange nahezu ohne Aufwand füllen: lange Prompts, keine Anmeldung, keine Ratenbegrenzung, keine Kosten. Ihre eigenen Benutzer erhalten dann 503-Antworten oder müssen lange warten. Außerdem ist das System währenddessen dauerhaft ausgelastet.

Belassen Sie den Listener auf dem Loopback-Interface 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 bietet keinen Schutz.

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 der Reihe nach. Die wartende Anfrage hält ihre HTTP-Verbindung offen und sendet keine Bytes, bis ein Slot frei wird. Auf der Clientseite sieht das genauso aus wie ein langsames Modell. Ausschlaggebend ist der zeitliche Verlauf: Eine lange Pause und anschließend Text mit voller Geschwindigkeit weisen auf eine Warteschlange hin. Ein langsames Tröpfeln ab dem ersten Token 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 Ollamas Überlauffehler der Warteschlange. Er wird mit dem HTTP-Status 503 zurückgegeben. 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 in die Warteschlange aufzunehmen. Das ist weder ein Speicherfehler noch ein Modellfehler. Eine größere Warteschlange lässt die Aufrufer nur länger warten, bevor dieselbe Ablehnung erfolgt. Die eigentlichen Lösungen sind mehr Slots, wenn der VRAM dafür ausreicht, eine geringere eingehende Last oder eine vorgeschaltete Warteschlange, die Anfragen erneut senden und priorisieren kann.

Wird Ollama durch eine höhere Einstellung von OLLAMA_NUM_PARALLEL schneller?

Nein. Dadurch können mehr Anfragen gleichzeitig verarbeitet werden. Jede dieser Anfragen ist jedoch langsamer, als sie bei alleiniger Verarbeitung wäre, weil sie dieselbe GPU verwendet. Außerdem vervielfacht sich der KV-Cache, da Ollama den Runner mit einer Gesamtkontextlänge von 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 enthält.

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

Ja. Der Server liest die Variablen beim Start ein. Ein laufendes Modell verwendet weiterhin 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 enthält die Umgebung, die der Server tatsächlich geladen hat.

Wie viele parallele Slots sollte ich festlegen?

Beginnen Sie mit 1 und erhöhen Sie den Wert jeweils um einen Schritt. Starten Sie Ollama nach jedem Schritt neu, senden Sie eine Anfrage zum Laden des Modells und führen Sie ollama ps aus. Beenden Sie den Vorgang beim letzten Wert, bei dem PROCESSOR weiterhin 100% GPU enthält und die Spalte SIZE noch ausreichend Reserven für den längsten von Ihnen bereitgestellten Kontext lässt. Messen Sie bei dieser Einstellung unter Ihrer 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 fällt.