Ollama API Timeout auf 60 Sekunden begrenzt trotz timeoutSeconds-Konfiguration

Der Benutzer meldet, dass Anfragen an sein lokales Ollama-Modell (ollama/gemma4:e4b) konsistent nach genau 60 Sekunden timeouten, unabhängig von der timeoutSeconds-Einstellung in der OpenClaw-Konfiguration.

Angewendete Konfiguration

"agents": {
  "defaults": {
    "model": {
      "primary": "ollama/gemma4:e4b"
    },
    "models": {
      "ollama/gemma4:e4b": {},
      "ollama/gemma4:26b": {}
    },
    "workspace": "/Users/xxxxxx/.openclaw/workspace",
    "compaction": {
      "mode": "safeguard"
    },
    "timeoutSeconds": 1800
  }
}

Fehleräußerung

Wenn der Timeout auftritt, wird folgendes Verhalten beobachtet:

Error: Request to Ollama API timed out after 60000ms
    at async OllamaProvider.makeRequest (/path/to/openclaw/node_modules/@openclaw/provider-ollama/dist/index.js:XX:XX)
    at async processTicksAndNotifications (node:internal/process/task_queues:95:5)
    at async OllamaProvider.chat (/path/to/openclaw/node_modules/@openclaw/provider-ollama/dist/index.js:XX:XX)

[AXIOS_ERROR]: ECONNABORTED - Timeout of 60000ms exceeded

Wichtige Indikatoren

• Der Timeout-Wert von 60000ms (60 Sekunden) ist in der HTTP-Client-Schicht fest codiert
• Die timeoutSeconds: 1800-Einstellung der Anwendung wird nicht an die zugrunde liegende HTTP-Anfrage weitergegeben
• Tritt nur bei langlebigen Ollama-Inferenzoperationen auf (z.B. große Modellantworten, komplexe Prompts)
• Das Problem ist zu 100% reproduzierbar bei Anfragen, die 60 Sekunden überschreiten

Das Timeout-Problem stammt aus einem Schicht-Mismatch zwischen der Anwendungsebene-Konfiguration und dem HTTP-Client-Ebene-Timeout. Das OpenClaw-Konfigurationsfeld timeoutSeconds: 1800 ist als Anwendungsebene-Timeout gedacht, wird aber nicht an den zugrunde liegenden HTTP-Client (typischerweise Axios) weitergeleitet, der mit der Ollama REST-API kommuniziert.

Technische Fehlersequenz

1. Konfigurationsladen: OpenClaw lädt das agents.defaults.timeoutSeconds: 1800 aus der Konfigurationsdatei in den Agent-Kontext.
2. Modellanfrage-Initialisierung: Wenn eine Chat-Anfrage initiiert wird, ruft das System die Modellkonfiguration für ollama/gemma4:e4b ab.
3. Provider-Instanziierung: Die OllamaProvider-Klasse wird instanziiert, um die HTTP-Kommunikation mit dem lokalen Ollama-Server zu behandeln.
4. HTTP-Client-Standardwert angewendet: Die Axios-Instanz (oder Node.js fetch) innerhalb des Ollama-Providers verwendet ihren Standard-Timeout von 60000ms, weil die timeoutSeconds-Konfiguration nicht an den HTTP-Client-Konstruktor weitergegeben wird.
5. Anfrage-Abbruch: Nach genau 60 Sekunden bricht Axios die Anfrage mit ECONNABORTED ab, unabhängig von der Anwendungsabsicht.

Code-Pfad-Analyse

Der problematische Code existiert in der HTTP-Client-Initialisierung des Ollama-Providers:

// In node_modules/@openclaw/provider-ollama/dist/index.js (vereinfacht)
class OllamaProvider {
  constructor(config) {
    // BUG: timeout ist auf 60000ms fest codiert
    this.httpClient = axios.create({
      baseURL: config.baseUrl || 'http://localhost:11434',
      timeout: 60000  // <<< FEST CODIERT - ignoriert config.timeoutSeconds
    });
  }
  
  async chat(messages, options) {
    // options.timeoutSeconds (1800) wird hier nie weitergegeben
    const response = await this.httpClient.post('/api/chat', {
      model: this.model,
      messages: messages
    });
  }
}

Architektonische Inkonsistenz

OpenClaws Konfigurationssystem verwendet timeoutSeconds für Agent-Ebene-Timeout-Kontrolle, aber die Provider-Implementierungen haben fest codierte HTTP-Timeouts, die diese Einstellung umgehen. Die Konfigurationskette ist unterbrochen zwischen:

• agents.defaults.timeoutSeconds (Anwendungsschicht)
• → ModelConfig (Modell-Routingschicht)
• → OllamaProvider (HTTP-Transportschicht) ❌ NICHT VERBUNDEN

Lösung 1: Provider-Timeout über Umgebungsvariable überschreiben

Wenn der OpenClaw Ollama-Provider eine umgebungsbasierte Timeout-Konfiguration unterstützt:

# Zu Ihrer Shell-Konfigurationsdatei oder .env-Datei hinzufügen
export OLLAMA_HTTP_TIMEOUT=1800000
# Oder für den spezifischen Provider
export OPENCLAW_PROVIDER_TIMEOUT=1800000

Lösung 2: Konfiguration über anbieterspezifische Modelleinstellungen

Timeout-Konfiguration direkt zur Modelldefinition hinzufügen:

"agents": {
  "defaults": {
    "model": {
      "primary": "ollama/gemma4:e4b"
    },
    "models": {
      "ollama/gemma4:e4b": {
        "provider": "ollama",
        "options": {
          "timeout": 1800000
        }
      },
      "ollama/gemma4:26b": {
        "provider": "ollama",
        "options": {
          "timeout": 1800000
        }
      }
    },
    "workspace": "/Users/xxxxxx/.openclaw/workspace",
    "compaction": {
      "mode": "safeguard"
    },
    "timeoutSeconds": 1800
  }
}

Lösung 3: Direkte Axios-Timeout-Überschreibung (Workaround)

Wenn Sie Zugriff auf die Provider-Quelle haben, erstellen Sie eine lokale Überschreibung. Erstellen Sie eine Patch-Datei unter:

~/.openclaw/providers/ollama-patch.js

Mit Inhalt:

const axios = require('axios');

// Client mit konfigurierbarem Timeout erstellen
const createOllamaClient = (baseUrl, timeoutMs = 60000) => {
  return axios.create({
    baseURL: baseUrl || 'http://localhost:11434',
    timeout: timeoutMs,
    // Längere Timeouts für Streaming sicherstellen
    httpAgent: new (require('http').Agent)({ 
      timeout: timeoutMs,
      keepAlive: true 
    })
  });
};

module.exports = { createOllamaClient };

Lösung 4: Ollama-Server-Timeout konfigurieren (serverseitig)

Konfigurieren Sie den Ollama-Server selbst, um längere Anfragebearbeitung zu ermöglichen:

# In Ihrem Ollama-Startskript oder systemd-Dienst
OLLAMA_KEEP_ALIVE=0 \
OLLAMA_CONTEXT_SIZE=32768 \
ollama serve

# Oder Umgebung vor dem Start setzen
export OLLAMA_KEEP_ALIVE=0

Lösung 5: OpenClaws Provider-Konfigurationsdatei verwenden

Erstellen Sie eine dedizierte Provider-Konfiguration:

# Datei: ~/.openclaw/config/providers.yaml
providers:
  ollama:
    baseUrl: http://localhost:11434
    timeout: 1800000  # 30 Minuten in Millisekunden
    keepAlive: true
    modelDefaults:
      temperature: 0.7
      numCtx: 32768

Vorher vs. Nachher Konfiguration

Vorher (Standard 60-Sekunden-Timeout):

"models": {
  "ollama/gemma4:e4b": {}
}

Nachher (1800-Sekunden-Timeout):

"models": {
  "ollama/gemma4:e4b": {
    "providerOptions": {
      "timeout": 1800000
    }
  }
}

Schritt 1: Ollama-Server-Status überprüfen

# Prüfen ob Ollama läuft und antwortet
curl http://localhost:11434/api/tags

# Erwartete Ausgabe:
# {
#   "models": [
#     {
#       "name": "gemma4:e4b",
#       "size": 4800000000,
#       "digest": "sha256:..."
#     }
#   ]
# }

Schritt 2: Direkte Ollama-API-Latenz testen

# Einfache Chat-Anfrage direkt an Ollama testen
curl http://localhost:11434/api/chat -d '{
  "model": "gemma4:e4b",
  "messages": [{"role": "user", "content": "Hallo"}],
  "stream": false
}'

# Überprüfen dass die Antwort ohne Timeout auf Ollama-Ebene abgeschlossen wird

Schritt 3: OpenClaw-Konfigurationsladen verifizieren

# OpenClaw mit Debug-Logging ausführen um Konfigurationsparsing zu verifizieren
OPENCLAW_LOG_LEVEL=debug openclaw chat --model ollama/gemma4:e4b --prompt "test"

# Achten Sie auf diese Zeilen in der Ausgabe:
# [DEBUG] Config loaded: timeoutSeconds=1800
# [DEBUG] Provider ollama initialized with timeout=1800000

Schritt 4: Mit erweitertem Timeout-Szenario testen

Erstellen Sie einen Test, der mehr als 60 Sekunden benötigt:

# Testskript zur Überprüfung dass der Timeout eingehalten wird
node -e "
const { OllamaProvider } = require('@openclaw/provider-ollama');

async function testTimeout() {
  const provider = new OllamaProvider({
    model: 'ollama/gemma4:e4b',
    timeout: 1800000
  });
  
  const startTime = Date.now();
  try {
    const response = await provider.chat([
      { role: 'user', content: 'Generate a very long story about...' }
    ]);
    const duration = Date.now() - startTime;
    console.log('SUCCESS: Request completed in', duration, 'ms');
    console.log('Response:', response.message.content.substring(0, 100) + '...');
  } catch (error) {
    console.error('FAILED after', Date.now() - startTime, 'ms');
    console.error('Error:', error.message);
  }
}

testTimeout();
"

Schritt 5: HTTP-Client-Timeout-Wert bestätigen

# Dies temporär zu Ihrem Provider-Code hinzufügen zum Debuggen:
console.log('HTTP Client timeout:', provider.httpClient.defaults.timeout);

// Sollte ausgeben: 1800000 (nicht 60000)

Erwartete erfolgreiche Ausgabe

# Nach der Korrektur sollten Sie sehen:
[INFO] Starting request to ollama/gemma4:e4b
[DEBUG] Using timeout: 1800000ms
[INFO] Response received in 125000ms
[SUCCESS] Token count: 5421, Time: 125.0s

Die folgenden Fehler sind häufig mit dem Ollama-Timeout-Problem assoziiert:

• ECONNABORTED — Axios-Fehlercode, der anzeigt, dass die Anfrage wegen Timeout abgebrochen wurde. Tritt auf, wenn der HTTP-Client einen Timeout hat, bevor eine Antwort empfangen wird.
• ETIMEDOUT — TCP-Ebene Timeout-Fehler. Zeigt einen netzwerkebenen Verbindungs-Timeout an, oft auf Betriebssystem- oder Firewall-Ebene anstatt auf Anwendungsebene.