Die Inferenz-Runtime

Fehlerbehebung

Startphasen, Symptomtabelle, Offline-Installation und vorinstallierte Daten

Diese Seite wurde maschinell aus der englischen Dokumentation übersetzt.

Funktioniert es oder hängt es?

docker logs -f openplate-inference durchläuft nacheinander drei Phasen. So sieht jede einzelne aus, damit du erkennen kannst, ob das System ausgelastet oder fehlerhaft ist.

Stufe 1: Herunterladen der Modellgewichte (nur beim ersten Start; dauert an einem Heimanschluss zwischen wenigen Minuten und einer Stunde). Die Größen werden vorab angezeigt, damit du sie mit deiner Verbindungsgeschwindigkeit vergleichen kannst:

═══════════════════════════════════════════════════════════════════════
  openplate-inference: weights for MODEL_PROFILE=lite
  destination: /models   total: 1.96 GiB
═══════════════════════════════════════════════════════════════════════
▶ [model] downloading LFM2.5-VL-1.6B-Q8_0.gguf (1.16 GiB) from https://huggingface.co/...
   This is a one-time download into /models. It is resumable:
   restarting the container continues where it stopped.
######################################                            54.2%

Hängt der Vorgang? Wenn sich der Prozentsatz fünf Minuten lang nicht geändert hat, stockt der Download. Starte den Container neu: Er setzt den Vorgang fort und beginnt nicht von vorn. Bei späteren Starts besteht diese Stufe stattdessen aus wenigen Sekunden Hashing:

▶ [model] LFM2.5-VL-1.6B-Q8_0.gguf: already present, verifying sha256 (1.16 GiB)...
✅ [model] LFM2.5-VL-1.6B-Q8_0.gguf verified, skipping download.
✅ All weights for profile 'lite' are present and verified.

Wenn eine Prüfsumme fehlschlägt, gibt das Protokoll den genauen Befehl aus, um die fehlerhafte Datei zu löschen und es erneut zu versuchen. Führe ihn aus. Wenn es bei derselben Datei zweimal fehlschlägt, verändert etwas zwischen dir und Hugging Face den Download (ein Captive Portal oder ein filternder Proxy tut so etwas). Versuche es über ein anderes Netzwerk oder befülle das Volume vorab manuell (siehe unten).

Stufe 2: Laden des Modells (5 bis 60 s, bei jedem Start):

═══════════════════════════════════════════════════════════════════════
  Starting llama-server (this loads the model, expect 5 to 60 s)
    profile:  lite
    model:    /models/LFM2.5-VL-1.6B-Q8_0.gguf
    mmproj:   /models/mmproj-LFM2.5-VL-1.6b-F16.gguf
    GPU:      none detected, CPU only (-ngl 0, -t 8)
    context:  8192   slots: 2
═══════════════════════════════════════════════════════════════════════
...
main: server is listening on http://127.0.0.1:8080 - starting the main loop

Prüfe die Zeile GPU:. Hier wird die Ursache für "Ich habe --gpus all übergeben und es ist immer noch langsam" diagnostiziert: Wenn dort none detected steht, erreicht die GPU den Container nicht, und keine noch so aufwendige Optimierung an anderer Stelle hilft weiter.

Stufe 3: Bereit:

{"level":"info","msg":"openplate-inference listening","port":8300,
 "model":"openplate-plate-1","profile":"lite","concurrency":2,"keyIds":"a1b2c3d4"}

/readyz gibt ab hier 200 zurück. Der Dienst nimmt bewusst Verbindungen an, vor das Laden des Modells abgeschlossen ist: Ein Start, der bei einem Ladevorgang von mehreren Gigabyte blockiert, lässt sich nicht von einem abgestürzten Container unterscheiden. Bis die Laufzeitumgebung bereit ist, teilt /readyz dies mit.

Häufige Fehler in der Reihenfolge ihres Auftretens

Symptom	Ursache
Container bricht sofort ab, eine Zeile Fehlerausgabe auf stderr	Fehlerhafte Konfiguration. Die Meldung nennt die Variable. Die Konfiguration wird beim Start geprüft: Ein Dienst, der ohne Modell-Laufzeitumgebung startet, beantwortet jeden Scan mit 502.
Download stockt, kein Fortschritt	Neu starten; der Vorgang wird fortgesetzt.
`CHECKSUM MISMATCH`	Führe den ausgegebenen Wiederherstellungsbefehl aus.
`/readyz` liefert nie 200, Protokolle enden nach Stufe 2	Nicht genügend Arbeitsspeicher beim Laden des Modells. Prüfe `docker stats` und die Arbeitsspeicher-Mindestwerte.
Scans liefern 401	Falscher oder veralteter Schlüssel. Ein Neustart generiert den Startschlüssel neu. Setze `API_KEYS`.
Scans liefern 429 mit `Retry-After`	Funktioniert wie vorgesehen: Die Warteschlange ist voll oder du hast `RATE_LIMIT_RPM` überschritten.
Scans liefern 502	Der Dienst läuft, die Modell-Laufzeitumgebung jedoch nicht. Sieh dir Stufe 2 an. Prüfe im externen Modus `MODEL_RUNTIME_API_KEY` (siehe Readiness).
Scans sind erfolgreich, aber jedes `macrosPer100g` ist null	Die Makronährstoff-Auflösung ist deaktiviert. Entweder `FOOD_SOURCE=none`, oder die Lebensmitteldatenbank konnte nicht gelesen werden: Das Startprotokoll gibt Aufschluss darüber. Siehe Lebensmitteldaten. Die Erkennung funktioniert weiterhin.
`FOOD_SOURCE=lcc`, und Makronährstoffe werden im Laufe des Tages zu null	Ohne `LCC_API_KEY` ist die anonyme Stufe aufgebraucht (1.000 Credits pro UTC-Tag pro IP). Mit einem Schlüssel ist dessen monatliches Kontingent erschöpft oder LowCarbCheck hat den Schlüssel abgelehnt. LowCarbCheck ist eventuell auch nicht erreichbar. Das Protokoll enthält eine Warnmeldung mit den Feldern `stage`, `source`, `failed` und `attempted`. Setze `LCC_API_KEY`, prüfe den Schlüssel, wechsle zu `fdc` oder warte auf den nächsten UTC-Tag.
openplate zeigt keine Karte mit "Diese Instanz stellt eigene KI bereit"	`DEFAULT_INFERENCE_BASE_URL` ist nicht gesetzt oder über den Browser nicht erreichbar. Siehe Pfad A in der README-Schnellstartanleitung.

Offline-Installation oder vorab befüllte Installation

Kopiere die GGUFs selbst in das Volume, dann prüft der Download-Schritt die Dateien nur noch. Die Dateinamen müssen exakt übereinstimmen; das Manifest mit allen Dateinamen und SHA256-Prüfsummen steht oben in scripts/fetch-weights.sh.

bash

docker run --rm -v openplate-models:/models -v "$PWD:/src" alpine \
  cp /src/LFM2.5-VL-1.6B-Q8_0.gguf /src/mmproj-LFM2.5-VL-1.6b-F16.gguf /models/

Wenn du die Gewichte auf deinem eigenen Speicher spiegelst, setze WEIGHTS_MIRROR_BASE auf eine Basis-URL mit diesen Dateinamen. Hugging Face bleibt die Rückfallebene und Prüfsummen werden in jedem Fall erzwungen, ein Spiegelserver kann dir also keine abweichenden Gewichte unterschieben.

Kommst du immer noch nicht weiter?

Laufzeitkompatibilitätsprobleme (502 bei jedem Scan, verstümmelte Ausgabe, falsche Nebenläufigkeit): Eigene Laufzeitumgebung einbinden.
Langsam, aber funktioniert: Hardware & gemessene Latenz.
Alles andere: Erstelle ein Issue mit deiner Laufzeitart und -version, dem verwendeten Modell, der betroffenen Anfrage samt Antwort und deiner Ausgabe von /readyz.