Ollama: „context deadline exceeded“ beheben

Was „context deadline exceeded“ tatsächlich bedeutet

Der Ollama-Fehler context deadline exceeded ist eine Timeout-Meldung. Ein Teil des Go-Codes hat für die Anfrage eine Frist gesetzt. Das Modell wurde innerhalb dieser Frist nicht fertig. Die Frist ist abgelaufen. Es ist kein Absturz aufgetreten, und keine Datei ist beschädigt. Die Verarbeitung lief noch, als die Zeit abgelaufen ist.

Die Formulierung stammt aus Go's standardmäßigem context-Paket. Das ist bereits ein nützlicher Hinweis. Ein auf httpx basierender Python-Client löst stattdessen httpx.ReadTimeout aus. Ein Browser zeigt einen allgemeinen Netzwerkfehler an. Wenn Sie genau diese Formulierung sehen, hat ein Go-Programm das Warten abgebrochen: das Ollama-Kommandozeilentool, der Ollama-Server selbst oder eine Go-Anwendung, die die API (Application Programming Interface) aufruft.

Fünf Ebenen können diese Frist festlegen. Sie greifen an unterschiedlichen Stellen. Für jede Ebene ist eine andere Lösung erforderlich. Entscheidend ist daher, herauszufinden, welche Ebene ausgelöst wurde.

1. Ihr HTTP-Client, der der Anfrage ein festes Zeitbudget gegeben hat.
2. Das Timeout des Ollama-Servers für das Laden des Modells. Es greift, während ein großes Modell erstmals von der Festplatte gelesen wird.
3. keep_alive, das Modell zwischen Anfragen entlädt, sodass der nächste Aufruf die Ladezeit erneut abwarten muss.
4. Ein num_ctx, dessen Verarbeitung auf einem Rechner ohne GPU mehrere Minuten dauert.
5. Ein Reverse Proxy wie nginx oder Traefik, der die Verbindung beendet, bevor Ollama geantwortet hat.

Arbeiten Sie diese Liste in der angegebenen Reihenfolge ab. Jeder folgende Schritt entfernt eine Ebene aus der Fehlersuche. Dadurch müssen Sie nicht raten.

Über die API testen, um den Proxy auszuschließen

Führen Sie die Anfrage direkt auf dem Server an Ollama aus, ohne zwischengeschalteten Proxy.

time curl -s http://127.0.0.1:11434/api/generate -d '{
  "model": "llama3.1:8b",
  "prompt": "Why is the sky blue?",
  "stream": false
}' | head -c 400

curl setzt selbst keine allgemeine Zeitbegrenzung, sondern nur ein Verbindungs-Timeout. Dieser Befehl wartet daher so lange, wie Ollama benötigt. Damit lässt sich das Problem eingrenzen. Wenn ein JSON-Body zurückkommt, hat Ollama geantwortet. Die Zeitbegrenzung liegt dann bei einer Komponente davor. Wenn dieser Aufruf mehrere Minuten hängt, entsteht die Verzögerung innerhalb von Ollama. Ihr Proxy ist dann nicht die Ursache.

Senden Sie jetzt dieselbe Anfrage über Ihre öffentliche URL und messen Sie die benötigte Zeit.

curl -s -o /dev/null -w '%{http_code} %{time_total}\n' \
  -X POST https://llm.example.com/api/generate \
  -d '{"model": "llama3.1:8b", "prompt": "hi", "stream": false}'

Ein Status von 504 nach einer verdächtig genau wirkenden Anzahl von Sekunden, etwa 60.0 oder 30.0, weist auf ein Proxy-Timeout hin. Proxys verwenden runde Standardwerte. Ein Modell beendet die Verarbeitung nicht zweimal hintereinander exakt nach 60.000 Sekunden. Wenn der direkte Aufruf sofort abgelehnt wird und nicht langsam ist, liegt ein Problem mit dem Listener und nicht mit der Zeitbegrenzung vor. Welche Adresse Ollama an Port 11434 bindet behandelt diesen Fall.

Überwachen Sie das Serverprotokoll, während die Anfrage verarbeitet wird

Öffnen Sie eine zweite Sitzung und verfolgen Sie das Dienstprotokoll. Senden Sie die Anfrage anschließend erneut.

journalctl -u ollama --no-pager --follow --pager-end

Bei einem erfolgreichen Kaltstart wird zuerst das Laden des Modells protokolliert. Danach startet ein Runner, und anschließend wird die Anfrage verarbeitet. Ein fehlgeschlagenes Laden sieht dagegen so aus. Diese Zeichenfolge weist auf das eigene Ladezeitlimit des Servers hin:

Error: timed out waiting for llama runner to start - progress 0.00 -

Die Meldung bedeutet, dass der Modellprozess innerhalb des vom Server vorgegebenen Zeitbudgets nicht vollständig gestartet wurde. Der Fortschrittswert zeigt, wie weit der Start fortgeschritten ist. Der Wert 0.00 bedeutet, dass der Runner vor Ablauf der Frist überhaupt keinen Fortschritt gemeldet hat. Meist wird die Datei noch gelesen oder der Rechner verwendet bereits den Auslagerungsspeicher. Um während des Ladens weitere Details zu erhalten, starten Sie den Dienst mit gesetztem OLLAMA_DEBUG=1 neu und wiederholen Sie den Vorgang.

Ermitteln, ob die Verzögerung durch das Laden oder die Generierung entsteht

Ollama gibt eigene Zeitmessungen aus. Sie müssen diesen Teil daher nicht schätzen.

ollama run --verbose llama3.1:8b "Why is the sky blue?"

Nach der Antwort gibt Ollama total duration, load duration, prompt eval count, prompt eval rate, eval count und eval rate aus. Führen Sie den Befehl zweimal aus. Beim zweiten Durchlauf sollte load duration auf nahezu null sinken, weil das Modell bereits im Arbeitsspeicher geladen ist. Sinkt der Wert nicht, wird das Modell zwischen den beiden Durchläufen entladen. Das ist der weiter unten beschriebene Fall keep_alive.

Dieselben Werte liefert die API im abschließenden JSON-Objekt als load_duration, prompt_eval_duration und eval_duration zurück. Laut Dokumentation werden alle Zeitangaben in Nanosekunden zurückgegeben. Teilen Sie sie daher durch 10^9, um die Sekunden abzulesen.

curl -s http://127.0.0.1:11434/api/generate -d '{
  "model": "llama3.1:8b",
  "prompt": "Why is the sky blue?",
  "stream": false
}' | python3 -c 'import json,sys; d=json.load(sys.stdin); print({k: round(v/1e9, 2) for k, v in d.items() if k.endswith("_duration")})'

Sehen Sie sich den größten Wert an. Wenn load_duration dominiert, liegt ein Problem beim Laden des Modells vor. Fahren Sie dann mit den nächsten beiden Abschnitten fort. Wenn prompt_eval_duration dominiert, verursacht die Verarbeitung der Eingabe die Verzögerung. Fahren Sie dann mit dem Abschnitt num_ctx fort. Wenn eval_duration dominiert, generiert das Modell auf dieser Hardware einfach langsam. Keine Timeout-Einstellung wird daran etwas ändern. Kürzen Sie die Ausgabe mit num_predict oder verwenden Sie ein kleineres Modell.

OLLAMA_LOAD_TIMEOUT erhöhen, nachdem Sie Ihre Version geprüft haben

Die Servervariable, die festlegt, wie lange der Server auf den Start eines Modells wartet, lautet OLLAMA_LOAD_TIMEOUT. Ihr Standardwert wurde zwischen Releases geändert. Lesen Sie den Wert daher für Ihren Build aus und nicht aus einem beliebigen Artikel, auch nicht aus diesem. Geben Sie zuerst die Version aus.

ollama --version

Öffnen Sie anschließend den Quellcode für genau diesen Tag, https://github.com/ollama/ollama/blob/<your version>/envconfig/config.go, und suchen Sie nach OLLAMA_LOAD_TIMEOUT. Der Wert in dieser Datei ist der Standardwert, mit dem Ihre Binärdatei kompiliert wurde. Legen Sie Ihren eigenen Wert über ein systemd-Drop-in fest.

sudo systemctl edit ollama.service

Fügen Sie die Variablen unter einem Abschnitt [Service] ein. Das ist die Methode, die die eigene Ollama-Dokumentation für Linux beschreibt:

[Service]
Environment="OLLAMA_LOAD_TIMEOUT=15m"
Environment="OLLAMA_KEEP_ALIVE=-1"

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

Der letzte Befehl gibt die Umgebung aus, die der Dienst tatsächlich erhalten hat. Eine leere Ausgabe bedeutet, dass das Drop-in außerhalb der Editor-Markierungen gespeichert wurde oder unter dem falschen Abschnittsnamen steht. Daher ist keine der gesetzten Variablen aktiv. Beachten Sie, was dadurch erreicht wird: Ein längeres Ladezeitlimit verhindert, dass der Server vorzeitig abbricht. Es beschleunigt nichts. Passt das Modell nicht in den Arbeitsspeicher, verwendet die Maschine Swap, der Ladevorgang wird sehr langsam, und ein größerer Wert verschiebt den Fehler lediglich nach hinten.

Warum die erste Anfrage nach einer Pause langsam ist

Ollama entfernt ein nicht verwendetes Modell aus dem Speicher, um Speicher freizugeben. Die Einstellung keep_alive legt fest, wann das geschieht. In der Dokumentation von Ollama ist als Standardwert 5 Minuten angegeben, geprüft im September 2026. Eine Chat-Anwendung, die einmal pro Stunde verwendet wird, lädt das Modell daher bei jeder einzelnen Nachricht neu. Jede Nachricht verursacht dann den vollständigen Kaltstart. Bei einer Anfrage, die wegen eines Timeouts fehlschlägt, handelt es sich um die erste Anfrage nach einer Ruhephase. Genau dieses Muster wird häufig als zufällig beschrieben.

Prüfen Sie, welches Modell derzeit im Speicher resident ist:

ollama ps
curl -s http://127.0.0.1:11434/api/ps

Eine leere Liste oder ein Ablaufzeitpunkt in wenigen Minuten bestätigt dies. keep_alive akzeptiert eine Zeitangabe wie "10m" oder "24h", eine einfache Anzahl von Sekunden, 0 zum sofortigen Entfernen aus dem Speicher und eine negative Zahl, um das Modell dauerhaft im Speicher zu halten. Setzen Sie den Wert pro Anfrage oder setzen Sie OLLAMA_KEEP_ALIVE auf dem Dienst für jede Anfrage.

curl -s http://127.0.0.1:11434/api/generate -d '{
  "model": "llama3.1:8b",
  "keep_alive": -1
}'

Eine Anfrage mit einem Modell, aber ohne Prompt, lädt das Modell und wird anschließend beendet. Dies ist die dokumentierte Methode, um einen Rechner nach einem Reboot vorzuwärmen. Sie gehört in eine kleine systemd-Unit, damit niemand auf einen Kaltstart warten muss. Der Preis ist eindeutig: Ein dauerhaft im Speicher gehaltenes Modell belegt seinen Speicher für immer. Auf einem kleinen Rechner können Sie daher ein Modell dauerhaft im Speicher halten, nicht vier. Ein Modell zwischen Anfragen im Speicher halten erläutert die Speicherberechnung und die Warm-up-Unit.

Warum ein großer Wert für num_ctx vor dem ersten Token zu einem Timeout führt

Bevor ein Modell etwas ausgibt, muss es den gesamten Prompt lesen. Diese Phase heißt Prefill und wird von prompt eval gemessen. num_ctx legt die Kontextlänge fest und hat zwei Auswirkungen. Der Wert begrenzt die Anzahl der Tokens, die das Modell berücksichtigen darf, und bestimmt die Größe des KV-Cache (Key-Value-Cache), den der Server vorab reserviert. Beides erhöht den Arbeitsaufwand.

Auf einem Server ohne GPU ist Prefill langsam und wächst linear mit der Anzahl der Prompt-Tokens. Ein langes Dokument, das in einen Chat eingefügt wird, kann mehrere Minuten im Prefill verbringen, während der Client überhaupt nichts anzeigt, weil das Streaming noch nicht begonnen hat. Der Client erreicht sein Zeitlimit und meldet context deadline exceeded, während der Server die gesamte Zeit gearbeitet hat. Belegen Sie das mit den Werten aus dem vorherigen Abschnitt: Führen Sie denselben Prompt mit "options": {"num_ctx": 2048} und anschließend mit 32768 aus und vergleichen Sie prompt_eval_duration.

Der Standardwert des Servers stammt aus OLLAMA_CONTEXT_LENGTH. Ein anforderungsspezifischer num_ctx im Objekt options überschreibt diesen Wert. Den Wert auf das vom Modell angegebene Maximum zu erhöhen, nur weil dieses Maximum existiert, ist ein typischer Fehler. Die Reservierung des KV-Cache kann das Modell aus dem RAM verdrängen und aus einer funktionierenden Konfiguration eine Konfiguration mit Swapping machen. num_ctx passend zum tatsächlich verfügbaren Speicher festlegen enthält die Details zur Dimensionierung.

Warum nginx den Fehler 504 Gateway Time-out zurückgibt

nginx dokumentiert proxy_read_timeout mit einem Standardwert von 60s, und sein Fehlerprotokoll benennt den Fehler eindeutig:

upstream timed out (110: Connection timed out) while reading response header from upstream

Das wichtige Detail steht in der nginx-Dokumentation: Das Timeout „wird nur zwischen zwei aufeinanderfolgenden Lesevorgängen gesetzt, nicht für die Übertragung der gesamten Antwort“. Eine Streaming-Antwort setzt die Zeitmessung mit jedem Chunk zurück. Dadurch funktionieren Streaming-Chats weiterhin. Eine Anfrage mit "stream": false sendet erst etwas, wenn die Antwort vollständig ist. Die gesamte Generierung muss daher innerhalb dieses Zeitfensters abgeschlossen werden. Deshalb funktioniert dasselbe Modell im Chatfenster, läuft aber bei einem Skript in einen Timeout.

location / {
    proxy_pass http://127.0.0.1:11434;
    proxy_http_version 1.1;
    proxy_set_header Host $host;
    proxy_read_timeout 600s;
    proxy_send_timeout 600s;
    proxy_buffering off;
}

sudo nginx -t && sudo systemctl reload nginx

proxy_buffering off ist für Streaming relevant. Bei aktivierter Pufferung kann nginx die Antwort sammeln und erst am Ende weitergeben. Dadurch erscheinen die Tokens nicht mehr einzeln, und ein funktionierender Stream wirkt wie ein hängender Prozess.

Traefik legt dieselbe Einstellung im ServersTransport fest, den der Router verwendet.

http:
  serversTransports:
    ollama:
      forwardingTimeouts:
        dialTimeout: "30s"
        responseHeaderTimeout: "0s"
        idleConnTimeout: "60s"

responseHeaderTimeout bestimmt die Wartezeit auf die Antwort-Header, nachdem die Anfrage geschrieben wurde. Der Wert 0 bedeutet, dass kein Timeout gilt. Der Dienst muss mit serversTransport: ollama auf den Transport anhand seines Namens verweisen. Andernfalls haben Sie einen Block bearbeitet, den kein Dienst verwendet.

Eine niedrigere Quantisierung wird schneller geladen, weil weniger Daten gelesen werden müssen

Die Quantisierung gibt an, mit welcher Genauigkeit die Gewichte gespeichert werden. Eine niedrigere Genauigkeit ergibt eine kleinere Datei. Beim Laden eines Modells wird diese Datei größtenteils vom Datenträger in den Arbeitsspeicher gelesen.

[
  {
    "label": "q4_K_M",
    "download_size_gb": 4.9
  },
  {
    "label": "q8_0",
    "download_size_gb": 8.5
  },
  {
    "label": "fp16",
    "download_size_gb": 16
  }
]

Das sind die auf der Modellseite veröffentlichten Größen, keine Messwerte von einem Testserver. Der standardmäßige 8B-Build umfasst 4.9 GB. Der Build desselben Modells mit voller Genauigkeit umfasst 16 GB. Damit müssen mehr als dreimal so viele Bytes gelesen und mehr als dreimal so viele Daten im Arbeitsspeicher gehalten werden. Auf einem gemieteten Server mit gemeinsam genutztem Speicher entscheidet dieser Unterschied darüber, ob das Laden abgeschlossen wird oder ein Timeout auftritt. Ermitteln, welches Modell in Ihren Arbeitsspeicher passt ist die Prüfung, die Sie vor dem Abrufen großer Dateien durchführen sollten.

Was Sie auf einem gemieteten Server ändern sollten

Wenden Sie diese Änderungen in der Reihenfolge an, die sich aus den Messwerten ergibt. Nehmen Sie jeweils nur eine Änderung vor und führen Sie den Zeitmessbefehl danach erneut aus.

1. Fixieren Sie das Modell mit OLLAMA_KEEP_ALIVE=-1 oder laden Sie es beim Booten vor. Dadurch muss keine Benutzeranfrage die Ladezeit abwarten.
2. Setzen Sie num_ctx auf den Wert, den Ihre Prompts tatsächlich benötigen. Das verkürzt das Prefill und gibt den Speicher frei, den der KV-Cache belegt hat.
3. Verwenden Sie eine kleinere Quantisierung. Dadurch müssen beim Laden weniger Bytes gelesen werden, und das Modell lässt mehr Platz für den Cache.
4. Erhöhen Sie proxy_read_timeout in nginx oder responseHeaderTimeout in Traefik. Deaktivieren Sie außerdem das Buffering, damit gestreamte Tokens den Client erreichen.
5. Erhöhen Sie das Timeout in Ihrem eigenen Client. Ein Go- oder Python-Programm mit einem Budget von 30 Sekunden schlägt fehl, wenn das Modell länger benötigt.

Hinter all diesen Ursachen kann noch ein weiterer Grund stehen. Ollama verarbeitet nur eine begrenzte Anzahl von Anfragen gleichzeitig und reiht die übrigen ein. Ein zweiter Aufrufer kann deshalb in der Warteschlange stehen, während seine eigene Deadline abläuft, obwohl das Modell selbst nicht langsam ist. Im Server-Log ist dann zu sehen, dass die Anfrage verspätet verarbeitet wird, nicht dass sie fehlgeschlagen ist. Was geschieht, wenn mehrere Personen einen Ollama-Server gemeinsam nutzen behandelt die Einstellungen für die Parallelverarbeitung. Die Basisinstallation auf einem VPS behandelt die Einrichtung des Dienstes, von der diese Überschreibungen ausgehen.

FAQ

Was bedeutet „context deadline exceeded“ in Ollama?

Das bedeutet, dass eine für die Anfrage gesetzte Frist abgelaufen ist, bevor das Modell geantwortet hat. Die Meldung stammt aus dem Go-context-Paket. Sie wurde daher von einem Go-Programm ausgegeben: vom Ollama-Kommandozeilenprogramm, vom Ollama-Server oder von einer Go-Anwendung, die die API aufruft. Es handelt sich um ein Timeout. Es ist nichts beschädigt oder fehlerhaft. Als Nächstes müssen Sie feststellen, welche Schicht die Frist gesetzt hat, weil der Client, das Laden des Modells, keep_alive, num_ctx und der Reverse Proxy jeweils eigene Fristen setzen.

Sollte ich das Client-Timeout oder das Ollama-Timeout erhöhen?

Messen Sie zuerst. Senden Sie die Anfrage mit curl direkt auf dem Server an http://127.0.0.1:11434, weil curl keine allgemeine Zeitbegrenzung erzwingt. Wenn dieser Aufruf einen JSON-Body zurückgibt, antwortet Ollama. Die Frist gehört dann zu Ihrem Client oder zu Ihrem Proxy. Erhöhen Sie sie dort. Wenn auch dieser Aufruf hängt, liegt die Verzögerung innerhalb von Ollama. Die Felder load_duration und prompt_eval_duration in der Antwort zeigen, ob das Modell geladen wird oder Ihre Eingabe gelesen wird.

Warum läuft die erste Anfrage in ein Timeout, während die nächste funktioniert?

Ollama entlädt ein inaktives Modell, um Speicher freizugeben. Der Zeitplan dafür wird durch keep_alive festgelegt. Der dokumentierte Standardwert beträgt 5 Minuten, geprüft im September 2026. Die erste Anfrage nach einer Leerlaufphase lädt das Modell erneut von der Festplatte und benötigt die vollständige Kaltstartzeit. Eine direkt danach gesendete Anfrage findet das Modell bereits im Speicher und wird schnell beantwortet. Führen Sie ollama ps aus, um zu sehen, was geladen ist und wann es abläuft. Setzen Sie OLLAMA_KEEP_ALIVE=-1, damit das Modell im Speicher bleibt. Der Speicher bleibt dann belegt.

Warum schlägt es nur fehl, wenn ich nginx verwende?

nginx dokumentiert proxy_read_timeout mit einem Standardwert von 60s. Dieses Timeout gilt zwischen zwei aufeinanderfolgenden Lesevorgängen und nicht für die gesamte Antwort. Eine Streaming-Antwort setzt es mit jedem Chunk zurück. Eine mit "stream": false gesendete Anfrage muss dagegen innerhalb eines einzigen Zeitfensters abgeschlossen werden. Deshalb funktioniert das Chatfenster, während ein Skript fehlschlägt. Suchen Sie im nginx-Fehlerprotokoll nach upstream timed out (110: Connection timed out) while reading response header from upstream. Erhöhen Sie anschließend proxy_read_timeout und setzen Sie proxy_buffering off.

Wird das Laden schneller, wenn ich OLLAMA_LOAD_TIMEOUT erhöhe?

Nein. Dadurch ändert sich nur, wie lange der Server wartet, bevor er aufgibt und timed out waiting for llama runner to start protokolliert. Wenn das Modell nicht in den Speicher passt, verwendet der Rechner Swap. Das Laden wird dann sehr langsam. Ein längeres Timeout verschiebt den Fehler nach hinten, behebt ihn aber nicht. Prüfen Sie den Standardwert für Ihren Build mit ollama --version und lesen Sie envconfig/config.go bei diesem Tag. Ein Ladevorgang, der mehrere Minuten benötigt, ist ein Hinweis darauf, eine kleinere Quantisierung zu verwenden.