OpenClaw meldet eine Zeitüberschreitung der LLM-Anfrage

Eine Zeitüberschreitung bei der Modellanfrage ist einer der ersten Fehler, denen man begegnet, nachdem man OpenClaw auf ein lokales Modell umgestellt hat, und die Fehlerbehebungsseiten der Dokumentation nennen dafür eine kurze Liste von Ursachen. Die meisten betreffen das lokale Backend: ein großes Modell, das kalt geladen wird, ein Kontextfenster, das die Hardware nicht tragen kann, ein Host, der auf curl antwortet, aber nicht dem Gateway. Zwei betreffen gehostete Anbieter: ein Rate-Limit, das als 429 daherkommt, und eine vorgelagerte Sperre, die als 403 daherkommt. Hier ist jede Ursache mit ihrer Lösung, in der Reihenfolge, in der die Dokumentation sie auszuprobieren empfiehlt.

Die lokalen Ursachen

• Ein kaltes Modell: Große lokale Modelle können beim ersten Laden lange brauchen. Legen Sie für den Ollama-Anbieter ein längeres Timeout fest (das Beispiel der Dokumentation sind 300 Sekunden) und halten Sie das Modell zwischen Turns mit einem Keep-alive-Parameter im Modelleintrag geladen; dieselbe Einstellung verlängert auch das Verbindungs-Timeout, wenn der Host Verbindungen nur langsam annimmt.
• Ein zu großes Kontextfenster: Viele Modelle werben mit Kontexten, die die Hardware nicht bequem bewältigen kann. Begrenzen Sie im Modelleintrag sowohl das Token-Budget von OpenClaw als auch den Anfragekontext, um eine vorhersehbare Latenz bis zum ersten Token zu erhalten.
• Ein Host, der mit curl funktioniert, aber nicht mit OpenClaw: Prüfen Sie von dem Rechner und der Laufzeitumgebung aus, auf denen das Gateway läuft, denn eine Basis-URL mit localhost zeigt aus einem Docker-Container ins Leere, die URL kann das OpenAI-kompatible Suffix tragen, das das Verhalten ändert, der entfernte Host braucht möglicherweise Änderungen an Firewall oder Binding, und das Modell liegt vielleicht auf dem Daemon des Laptops statt auf dem entfernten.

Große lokale Modelle können beim ersten Laden lange brauchen.

Das Backend, das Proben besteht und trotzdem scheitert

Die Fehlerbehebungsseite für Anbieter beschreibt einen Fall, in dem ein lokales OpenAI-kompatibles Backend auf kleine direkte Anfragen antwortet und bei Agent-Läufen trotzdem scheitert: Der Transport stimmt wahrscheinlich, und das Backend scheitert an der größeren Prompt-Form der Agent-Laufzeit; das Beispiel der Dokumentation ist Gemma auf manchen llama-server-Builds. Eine Meldung über einen unvollständigen Turn ohne Payloads bedeutet, dass das Backend die Anfrage abgeschlossen, aber keinen sichtbaren Text zurückgegeben hat; OpenClaw wiederholt einen solchen Turn einmal. Werden die Fehler nach dem Deaktivieren der Tools seltener, verschwinden aber nicht, waren Tool-Schemas Teil der Last, und der Rest liegt an der Kapazität des Backends oder an einem Bug.

Die gehosteten Ursachen

• Ein 429 mit der Meldung, dass für langen Kontext zusätzliche Nutzung erforderlich ist: Das ausgewählte Anthropic-Modell hat ein natives Fenster von einer Million Tokens, oder eine alte Konfiguration trägt noch das veraltete Long-Context-Flag, und der Zugang ist dafür nicht berechtigt. Wechseln Sie zu einem Standardfenster, verwenden Sie einen berechtigten Zugang oder einen API-Schlüssel, und konfigurieren Sie Fallback-Modelle, damit Läufe weiterlaufen.
• Ein generischer 403 mit der Meldung, dass die Anfrage blockiert wurde: nicht immer ein OpenClaw-Problem; er kann von einem CDN, einer WAF, einer Bot-Management-Regel oder einem Reverse Proxy vor einem OpenAI-kompatiblen Endpunkt stammen. Prüfen Sie also den Status, den Gateway-Status und die Logs, bevor Sie die Konfiguration ändern.
• Die falsche URL: Das OpenAI-kompatible Suffix auf einem Ollama-Host macht Tool-Calling kaputt und kann ein Modell dazu bringen, Tool-JSON als Text auszugeben; die native URL ohne das Suffix ist die Lösung.

OpenClaw mit Ollama ist die vollständige Seite zu lokalen Modellen, und OpenClaw antwortet nicht ist die Stufenfolge, wenn das Symptom Stille statt eines Timeouts ist.

Wie Sie nachsehen

Die Suche nach jeder dieser Ursachen beginnt mit denselben drei Befehlen, die die Dokumentation immer wieder nennt: die Logs verfolgen, den Modellstatus prüfen und die Modellkonfiguration lesen. OpenClaw-Logs erklärt, wo die Datei liegt und wie Sie sie mit tail verfolgen.

Auf Diali

Auf Diali sind die Modelle gehostet, und die Timeouts stellen wir ein, sodass die lokale Hälfte dieser Liste nicht zutrifft; die gehostete Hälfte wird durch Fallback-Routing abgefangen, bevor eine Antwort verloren geht. Gehostetes OpenClaw auf Diali ist der Assistent.

• Kaltes Modell: ein längeres Anbieter-Timeout und ein Keep-alive.
• Zu viel Kontext: Budget und Anfragekontext begrenzen.
• Ein 429 oder 403 kommt vom Anbieter, nicht vom Gateway.