chat ping

chat ping prüft, ob der konfigurierte Sprachmodell-Dienst erreichbar ist und ob das vorgesehene Chat-Modell dort geladen ist. Reine Diagnose — keine Konversation wird angefasst, keine Datei mutiert, kein Modell-Pull ausgelöst.

Pendant zu vector ping für die Embedding-Seite: gleiche Form, gleiche Exit-Code-Semantik, gleiche Lesebarkeit.

Wofür ist das?

Erst-Setup einer Apparat-Installation. Nachdem docker compose up -d durchgelaufen ist, sagt dir chat ping in einer Zeile, ob der Chat-Stack steht oder noch ein ollama pull … fehlt.
Diagnose eines stillen Ausfalls. Wenn chat ask plötzlich nichts mehr ausspuckt, lokalisiert chat ping das Problem zuverlässig auf eine der drei Stellen — Dienst aus, Modell weg oder beides okay.
Skripte und Supervisoren. Die Exit-Codes sind so geschnitten, dass ein Wrapper-Skript automatisch entscheiden kann, ob es retryen, warten oder abbrechen soll.

Aufruf

apparat chat ping

Das Kommando hat keine Optionen. Endpunkt und Modellname kommen aus den Umgebungsvariablen APPARAT_LLM_ENDPOINT und APPARAT_LLM_MODEL.

Beispielausgaben

Alles in Ordnung:

✅ Service reachable.
  Available models:
    - qwen2.5:7b-instruct
    - jina/jina-embeddings-v2-base-de:latest
✅ Configured chat model is loaded.

Dienst erreichbar, Chat-Modell fehlt:

✅ Service reachable.
  Available models:
    - jina/jina-embeddings-v2-base-de:latest
⚠ Configured chat model is not loaded.
  Model "qwen2.5:7b-instruct" not loaded. Run: docker compose exec ollama ollama pull qwen2.5:7b-instruct

Dienst unerreichbar:

❌ Service unreachable.
  Connection to http://ollama:11434 failed: …

Exit-Codes

Code	Bedeutung
0	Dienst erreichbar und konfiguriertes Chat-Modell geladen.
1	Dienst unerreichbar (Container nicht gestartet, Netz blockiert, Endpunkt fehlerhaft konfiguriert).
2	Dienst erreichbar, aber das konfigurierte Chat-Modell ist nicht geladen. Die Detail-Zeile enthält den passenden `ollama pull …`-Befehl.

Die Trennung zwischen 1 und 2 macht den Unterschied zwischen Infrastruktur-Problem (Code 1) und Setup-Lücke (Code 2) sichtbar — relevant für Monitoring-Skripte und für die Entscheidung, ob ein Pull oder ein Container-Neustart die Lösung ist.

Konfiguration

Umgebungsvariable	Bedeutung	Default
`APPARAT_LLM_ENDPOINT`	Basis-URL des Sprachmodell-Dienstes (Ollama-API).	`http://ollama:11434` (im Container)
`APPARAT_LLM_MODEL`	Modellname, der erwartet wird. `:latest`-Suffix ist optional.	`qwen2.5:7b-instruct`
`APPARAT_LLM_TIMEOUT`	Timeout pro HTTP-Aufruf in Sekunden. Großzügig, weil der erste Aufruf das Modell erst in den Speicher laden muss.	`120`
`APPARAT_LLM_CONNECT_TIMEOUT`	Timeout allein für den Verbindungsaufbau in Sekunden. Hält den Wert klein, damit ein nicht erreichbarer Inferenz-Host schnell und mit klarer Fehlermeldung abbricht, statt bis zum vollen `APPARAT_LLM_TIMEOUT` zu hängen.	`10`

Default-Endpunkt ist derselbe wie für den Embedding-Dienst — beide laufen out of the box im selben Compose-Stack. Wer einen externen Inferenz-Host nutzt (etwa eine NVIDIA DGX Spark im LAN), kann beide Endpunkte gemeinsam oder getrennt umstellen, indem er APPARAT_EMBEDDING_ENDPOINT und APPARAT_LLM_ENDPOINT auseinanderzieht. Auf dem Host ohne Container ist http://ollama:11434 nicht auflösbar; dort wird http://localhost:11434 gesetzt, falls eine Host-Installation von Ollama die Anlaufstelle ist.

Was nebenbei wichtig ist

chat ping ist eine reine Diagnose: es prüft Erreichbarkeit und Modell-Liste, lädt aber keine Modelle nach (der ollama pull-Befehl in der Ausgabe ist ein Vorschlag, kein Aufruf) und ruft das Modell nicht produktiv. Ob das Modell tatsächlich Antworten generiert, zeigt sich beim ersten echten Lauf — typischerweise chat ask oder chat start. Die Konversations-Ablage conversations.sqlite bleibt unangetastet.