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, und die Frist ist abgelaufen. Es ist nichts abgestürzt, und keine Datei ist beschädigt. Die Verarbeitung lief noch, als die Zeit abgelaufen ist.

Die Formulierung stammt aus dem standardmäßigen context-Paket von Go. Das ist bereits ein nützlicher Hinweis. Ein Python-Client auf Basis von httpx löst stattdessen httpx.ReadTimeout aus. Ein Browser zeigt einen einfachen Netzwerkfehler an. Wenn Sie genau diese Formulierung sehen, hat ein Go-Programm das Warten beendet: das Ollama-Befehlszeilentool, der Ollama-Server selbst oder eine Go-Anwendung, die die API (application programming interface) aufruft.

Fünf Ebenen sind beteiligt. Drei davon setzen jeweils eine eigene Frist: Ihr Client, das Timeout für das Laden des Modells auf dem Server und ein Reverse Proxy. Die beiden anderen, keep_alive und num_ctx, setzen keine Frist. Sie bestimmen jedoch, wie viel Arbeit innerhalb einer Frist abgeschlossen werden muss. Sie schlagen an unterschiedlichen Stellen fehl und erfordern jeweils eine andere Lösung. Deshalb müssen Sie ermitteln, welche Ebene den Fehler verursacht.

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 zum ersten Mal von der Festplatte gelesen wird.
3. keep_alive, das das Modell zwischen Anfragen entlädt. Dadurch muss der nächste Aufruf die Ladezeit erneut aufbringen.
4. Ein num_ctx, das groß genug ist, dass allein die Prompt-Verarbeitung auf einem System ohne GPU minutenlang läuft.
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 mehr 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 entlädt ein inaktives Modell, um Speicher freizugeben. Die Einstellung keep_alive legt fest, wann das geschieht. Laut Dokumentation von Ollama beträgt der Standardwert 5 Minuten, Stand Oktober 2026. Eine Chat-Anwendung, die einmal pro Stunde verwendet wird, lädt das Modell daher bei jeder einzelnen Nachricht neu. Jede Nachricht verursacht den vollständigen Kaltstart. Bei einer Zeitüberschreitung handelt es sich um die erste Anfrage nach einer Ruhephase. Genau dieses Muster wird oft als zufällig beschrieben.

Prüfen Sie, welches Modell momentan im Speicher liegt:

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

Eine leere Liste oder eine Ablaufzeit in wenigen Minuten bestätigt dies. keep_alive akzeptiert eine Dauerangabe wie "10m" oder "24h", eine einfache Anzahl von Sekunden, 0 zum sofortigen Entladen und eine negative Zahl, um das Modell unbegrenzt im Speicher zu halten. Sie können den Wert pro Anfrage setzen oder OLLAMA_KEEP_ALIVE auf dem Dienst für jede Anfrage festlegen. Der Wert der Anfrage hat Vorrang: Laut Dokumentation von Ollama überschreibt der API-Parameter keep_alive die Einstellung OLLAMA_KEEP_ALIVE. Ein Client, der seinen eigenen Wert für keep_alive sendet, entlädt das Modell daher weiterhin nach seinem eigenen Zeitplan.

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

Eine Anfrage mit einem Modell und ohne Prompt lädt das Modell und wird anschließend beendet. Das ist die dokumentierte Methode, um einen Server nach einem Reboot vorzuwärmen. Sie sollte in einer kleinen systemd-Unit umgesetzt werden, damit nach einem Reboot niemand auf den ersten Kaltstart warten muss. Die Kosten sind eindeutig: Ein dauerhaft im Speicher gehaltenes Modell belegt den Speicher permanent. Auf einem kleinen Server können Sie daher ein Modell dauerhaft vorhalten, 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 die gesamte Eingabe lesen. Diese Phase heißt Prefill und wird von prompt eval gemessen. num_ctx legt die Kontextlänge fest und hat dabei 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. In beiden Fällen steigt der Rechenaufwand.

Auf einem Server ohne GPU ist der 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 Zahlen aus dem vorherigen Abschnitt. Senden Sie den langen Prompt und lesen Sie prompt_eval_count und prompt_eval_duration aus. Diese Werte definiert Ollama als die Zeit, die für die Auswertung der nicht gecachten Prompt-Tokens benötigt wird. Mehrere Minuten bei einem kleinen eval_duration sind ein Hinweis auf den Prefill. Da nur nicht gecachte Tokens gezählt werden, kann eine Wiederholung desselben Prompts bei einem noch geladenen Modell einen deutlich kleineren Wert liefern. Vergleichen Sie deshalb die ersten Ausführungen. Um die Kosten eines größeren Caches zu ermitteln, führen Sie den Prompt mit "options": {"num_ctx": 2048} und anschließend mit 32768 aus. Lesen Sie außerdem load_duration aus, da die Zeit zum Laden des Modells dort und nicht in prompt_eval_duration gemeldet wird.

Der Standardwert des Servers stammt aus OLLAMA_CONTEXT_LENGTH. Ein request-spezifischer num_ctx im Objekt options überschreibt diesen Wert. Ihn 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 an den tatsächlich verfügbaren Speicher anpassen 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 kleinere Quantisierung wird schneller geladen, weil weniger Daten gelesen werden müssen

Die Quantisierung gibt an, mit welcher Präzision die Gewichte gespeichert werden. Eine geringere Präzision 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 und keine Messwerte von einem Testsystem. Der standardmäßige 8B-Build hat eine Größe von 4.9 GB. Der Build desselben Modells mit voller Präzision ist 16 GB groß. Damit müssen mehr als dreimal so viele Bytes gelesen und mehr als dreimal so viele Daten im Arbeitsspeicher gehalten werden. Bei einem gemieteten Server mit gemeinsam genutztem Speicher entscheidet dieser Unterschied darüber, ob das Laden abgeschlossen wird oder der Zeitüberschreitungsfehler ausgelöst wird. Ermitteln, welches Modell in Ihren Arbeitsspeicher passt Diese Prüfung sollten Sie durchführen, bevor Sie größere Dateien herunterladen.

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 anschließend erneut aus.

1. Fixieren Sie das Modell mit OLLAMA_KEEP_ALIVE=-1 und laden Sie es beim Booten vor, damit Benutzeranfragen nicht mehr für die Ladezeit bezahlen. Prüfen Sie anschließend, dass kein Client einen eigenen Wert für keep_alive sendet, da ein Wert in der Anfrage die Servereinstellung überschreibt.
2. Verringern Sie num_ctx auf den Wert, den Ihre Prompts tatsächlich benötigen. Dadurch verkürzt sich die Prefill-Phase, und der vom KV-Cache belegte Speicher wird freigegeben.
3. Verwenden Sie eine kleinere Quantisierung. Dadurch müssen beim Laden weniger Bytes gelesen werden, und das Modell lässt mehr Speicher für den Cache frei.
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 Limit von 30 Sekunden schlägt fehl, wenn das Modell länger benötigt.

Hinter all diesen Ursachen kann ein weiterer Grund stecken. Ollama verarbeitet nur eine begrenzte Anzahl von Anfragen gleichzeitig und reiht die übrigen ein. Dadurch kann ein zweiter Aufrufer in der Warteschlange bleiben, während seine eigene Deadline abläuft, obwohl kein langsames Modell erkennbar ist. Das Server-Log zeigt dann, dass die Anfrage verspätet verarbeitet wurde, statt einen Fehler zu melden. Was geschieht, wenn mehrere Personen einen Ollama-Server gemeinsam verwenden behandelt die Einstellungen für die Parallelverarbeitung. Die grundlegende Installation auf einem VPS beschreibt die Einrichtung des Dienstes, die diese Überschreibungen voraussetzen.

FAQ

Was bedeutet „context deadline exceeded“ in Ollama?

Die Frist für die Anfrage ist abgelaufen, bevor das Modell geantwortet hat. Die Meldung stammt aus dem Go-Paket context. Sie wurde daher von einem Go-Programm ausgegeben: vom Ollama-Befehlszeilentool, vom Ollama-Server oder von einer Go-Anwendung, die die API aufruft. Es handelt sich um ein Timeout. Nichts ist beschädigt oder fehlerhaft. Als Nächstes müssen Sie ermitteln, welche Ebene die Frist gesetzt hat. Client, Modell-Ladevorgang und Reverse Proxy setzen jeweils eigene Fristen. keep_alive und num_ctx bestimmen, wie viel Arbeit innerhalb dieser Fristen abgeschlossen werden muss.

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, da curl keine Gesamtdauer begrenzt. Wenn dieser Aufruf einen JSON-Body zurückgibt, antwortet Ollama. Die Frist gehört dann zu Ihrem Client oder 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 nicht verwendetes Modell, um Speicher freizugeben. Der Zeitplan dafür wird durch keep_alive festgelegt. Der dokumentierte Standardwert beträgt 5 Minuten; dies wurde im Oktober 2026 geprüft. Die erste Anfrage nach einer Leerlaufphase lädt das Modell erneut von der Festplatte und benötigt die vollständige Kaltstartzeit. Eine unmittelbar danach gesendete Anfrage findet das Modell bereits im Speicher und wird schnell beantwortet. Führen Sie ollama ps aus, um zu sehen, welche Modelle geladen sind und wann sie entladen werden. Setzen Sie OLLAMA_KEEP_ALIVE=-1, damit das Modell im Speicher bleibt. Der belegte Speicher bleibt dann erhalten. Ein Client, der eigenes keep_alive sendet, überschreibt diese Einstellung. Prüfen Sie daher auch Ihre Clients.

Warum schlägt es nur über nginx fehl?

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 den Timeout mit jedem Chunk zurück. Eine mit "stream": false gesendete Anfrage muss dagegen innerhalb eines einzelnen 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 durch eine Erhöhung von OLLAMA_LOAD_TIMEOUT schneller?

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 das System Swap. Der Ladevorgang wird sehr langsam. Ein größeres Timeout verschiebt den Fehler nur nach hinten, ohne ihn zu beheben. Prüfen Sie den Standardwert für Ihren Build, indem Sie ollama --version ausführen und envconfig/config.go für diesen Tag lesen. Ein Ladevorgang, der mehrere Minuten benötigt, ist dann ein Hinweis darauf, dass Sie eine kleinere Quantisierung verwenden sollten.