Die Inferenz-Runtime

Konfiguration

Alle Umgebungsvariablen und Optionen für die Lebensmitteldatenbank (FOOD_SOURCE)

Diese Seite wurde maschinell aus der englischen Dokumentation übersetzt.

Alles läuft über Umgebungsvariablen, die beim Start validiert werden; ein ungültiger Wert stoppt den Prozess, anstatt ihn stillschweigend zu beeinträchtigen. Die kommentierte Master-Liste ist .env.example. Die Dokumentation von openplate listet jede Variable für diesen Container auf eine Seite. Sie stehen neben denen für die App und den Sync-Dienst. Die wichtigsten Variablen sind:

Variable	Standardwert
`MODEL_PROFILE`	`lite`	`lite` \	`lite-apache` \	`quality` \	`external`
`API_KEYS`	(generiert)	Kommagetrennte Bearer-Keys. Setze diesen Wert.
`PORT`	`8300`	Der einzige freigegebene Port.
`CONCURRENCY`	`2`	Laufende Scans; legt auch die KV-Slots von llama.cpp fest. Fügt keine CPU-Threads hinzu: Die Slots teilen sich die `LLAMA_THREADS` Threads.
`MAX_QUEUE_DEPTH`	`8`	Darüber hinaus erhalten Aufrufer 429 + `Retry-After`.
`RATE_LIMIT_RPM`	`60`	Pro Schlüssel.
`LATENCY_CEILING_MS`	`0`	0 = deaktiviert. Zulassungsrichtlinie: Lehne Arbeit ab, die du nicht rechtzeitig beenden kannst. Siehe Hardware.
`RUNTIME_COMPLETION_TIMEOUT_MS`	`600000`	Gesamtobergrenze für einen einzelnen Vervollständigungsaufruf, `0` = deaktiviert. Dient der Überwachung der Dienstgesundheit, nicht als Latenzrichtlinie: Es gibt einen Worker-Slot frei, den eine hängende Laufzeitumgebung sonst nie freigeben würde. Gilt auch im gebündelten Modus. Siehe Laufzeitumgebungen.
`IMAGE_MAX_LONG_EDGE`	`896`	Zielgröße für Herunterskalierung. Die Latenz steigt quadratisch an.
`MAX_IMAGE_BYTES`	`8388608`	Die maximale Fotogröße nach der Base64-Decodierung, in Bytes (8 MiB). Eine größere Datei wird mit dem Hinweis abgelehnt, ihre Größe zu ändern. Das Limit für den Request-Body leitet sich aus diesem Wert ab.
`FOOD_SOURCE`	`fdc`	Siehe Lebensmitteldaten.
`CONTEXT_SIZE`	`8192`	Kontext pro laufendem Scan. Der Container multipliziert ihn mit `CONCURRENCY`, bevor er ihn an llama.cpp übergibt, da `-c` von llama.cpp der gesamt ist, den es auf Slots aufteilt.
`LLAMA_EXTRA_ARGS`	(leer)	Zusätzliche Flags, die am Ende des llama-server-Befehls angehängt werden, getrennt an Leerzeichen. Nur im gebündelten Modus.
`LLAMA_THREADS`	`nproc - 2`	CPU-Threads für llama.cpp (dessen `-t`). Zwei Kerne bleiben für den Dienst, die Bilddekodierung und das Betriebssystem frei, sodass ein Rechner mit 6 Kernen 4 Threads ausführt und ein Rechner mit 4 Kernen 2 Threads, egal was `CONCURRENCY` angibt. Wenn du llama.cpp jeden Kern gibst, führt das zu Ressourcenkonflikten auf dem Rechner, nicht zu mehr Geschwindigkeit. Das Startprotokoll gibt den Wert als `-t N` aus. Nur im gebündelten Modus.
`MODELS_DIR`	`/models`	Das Volume für Modellgewichte.
`RUNTIME_PORT`	`8080`	Der Port des gebündelten llama-server, auf `127.0.0.1` innerhalb des Containers. Nur im gebündelten Modus.
`WEIGHTS_MIRROR_BASE`	(leer)	Optionaler Spiegelserver; Hugging Face dient als Fallback.
`GPU_LAYERS`	(automatisch)	Überschreibt die GPU-Auto-Erkennung. `0` erzwingt die CPU.
`NVIDIA_VISIBLE_DEVICES`	(von der Runtime gesetzt)	Die NVIDIA-Container-Runtime setzt dies, wenn du `--gpus all` übergibst. Die automatische Erkennung liest es aus. Jeder andere Wert als `void` oder `none` lagert jede Schicht aus. Du setzt dies nicht selbst.
`LOG_LEVEL`	`info`	`debug` \	`info` \	`warn` \	`error`
`PROFILE`	(von `MODEL_PROFILE`)	Der Profilname im Startprotokoll: `lite`, `quality` oder `custom`. Der Container setzt ihn anhand von `MODEL_PROFILE`. Wenn du ihn selbst setzt, ändert sich nur diese Protokollzeile.

Variablen für den externen Modus (MODEL_RUNTIME_URL, MODEL_ID, MODEL_RUNTIME_API_KEY) sind in Eigene Laufzeitumgebung einbinden dokumentiert.

llama-server läuft innerhalb des Containers gebunden an nur 127.0.0.1 und ist von außen nicht erreichbar. Das lässt sich nicht konfigurieren: Es handelt sich um einen unauthentifizierten Rohendpunkt für Bilderkennung, der sich absichtlich nicht versehentlich freigeben lässt.

Lebensmitteldaten (`FoodSource`)

Das Modell erkennt Lebensmittel und schätzt Grammangaben. Makronährstoffe werden namentlich aus einer Lebensmitteldatenbank abgefragt, nie vom Modell generiert.

`FOOD_SOURCE`	Funktionsweise	Netzwerk	Hinweise
`fdc` (Standard)	Sucht Namen in einem mitgelieferten Auszug von USDA FoodData Central nach, 8.041 generische Lebensmittel, der im Image unter `data/fdc-foods.json` liegt.	nichts	Offline, kein Schlüssel, kein Konto, keine ausgehende Anfrage. Gemeinfrei. Das ist der Standard, weil es die einzige Option ist, die von niemandem etwas braucht.
`off`	Fragt Open Food Facts während der Laufzeit live ab.	ausgehend, pro Scan	Stark bei Marken- und verpackten Produkten, schwächer bei gewöhnlichen gekochten Speisen. Die Adresse ist `OFF_API_URL`, standardmäßig `https://world.openfoodfacts.org`. Lies den Lizenzhinweis unten, bevor du die Option aktivierst. Dieses Image enthält nichts, was von OFF abgeleitet ist.
`lcc`	Fragt die öffentliche lowcarbcheck-API ab.	ausgehend, pro Scan	Die umfangreichsten Daten der drei Quellen (kuratiert + BLS + USDA) und dauerhaft nur remote verfügbar, da BLS 4.0 eine Weiterverbreitung untersagt. Die Quellenangabe wird in die Antwort durchgereicht, damit sie die UI erreicht. Ohne `LCC_API_KEY` läuft jede Anfrage über das kostenlose anonyme Kontingent von LowCarbCheck, siehe unten.
`none`	Keine Zuordnung. Jeder Eintrag kommt mit leeren Makronährwerten (null) zurück.	nichts	Für Clients, die Nährwerte selbst nachschlagen.

bash

-e FOOD_SOURCE=fdc                         # default
-e FDC_DATASET_PATH=./data/fdc-foods.json  # relative to the working directory
-e OFF_API_URL=https://world.openfoodfacts.org  # only read when FOOD_SOURCE=off
-e LCC_API_URL=https://lowcarbcheck.org    # only read when FOOD_SOURCE=lcc
-e LCC_API_KEY=lcc_live_…                   # optional; only read when FOOD_SOURCE=lcc
-e EMBEDDING_RUNTIME_URL=http://…          # optional; enables hybrid re-ranking

Ohne LCC_API_KEY läuft FOOD_SOURCE=lcc über die anonyme Stufe von LowCarbCheck: 1.000 Credits pro UTC-Tag, geteilt von allen Anfragen deiner IP-Adresse. Eine Suche kostet 1 Credit. Ein Scan setzt pro erkanntem Posten bis zu 3 Suchanfragen ab, festgelegt durch die Verfeinerungsobergrenze in search-foods.ts, bei bis zu 8 Posten. Das ergibt im schlechtesten Fall 24 Credits pro Scan. Die Pipeline ruft den Endpunkt für einzelne Lebensmittel nie auf, daher deckt dies die gesamten Kosten ab. Dieser schlechteste Fall erlaubt etwa 41 Scans pro Tag. Die meisten Tage erlauben mehr, da eine Suche stoppt, sobald eine Anfrage die Akzeptanzschwelle erreicht. Wenn das Kontingent aufgebraucht ist, liefert jeder verbleibende Posten bis zum nächsten UTC-Tag Null-Makros, und der Scan liefert weiterhin 200 zurück. Ein kostenloser Schlüssel von lowcarbcheck.org/developers erhöht das Kontingent auf 100.000 Credits pro Monat bei bis zu 120 Anfragen pro Minute. Dieses Kontingent ist an den Schlüssel gebunden statt an deine IP-Adresse. Setze ihn als LCC_API_KEY. Der Dienst sendet ihn als Bearer-Token an LCC_API_URL und nirgendwo sonst hin und protokolliert ihn nie. Weist LowCarbCheck einen Schlüssel ab, scheitert dies genauso wie ein erschöpftes Kontingent: Null-Makros und ein 200. fdc benötigt kein Netzwerk und kein Kontingent.

Zugeordnete Makronährwerte sind gekennzeichnet. Lebensmittel, die mit der Datenbank abgeglichen wurden, enthalten ein provenance von "corpus" sowie eine attribution-Zeichenkette, falls die Quelle dies verlangt. Nicht zugeordnete Lebensmittel lassen beide Felder weg, und macrosPer100g ist null. openplate legt diese Werte offen, damit Benutzer bestätigte Datenbankeinträge von Einträgen ohne Makronährstoffdaten trennen können.

Eine fehlende Lebensmitteldatenbank stoppt Scans nicht. Verweist FDC_DATASET_PATH auf das Leere, protokolliert der Dienst eine Warnung, deaktiviert den Abgleich und identifiziert Teller weiterhin. Du erhältst Namen und Grammangaben ohne Nährwerte: funktional eingeschränkt, aber nicht defekt. Erzeuge den Auszug mit pnpm food-data:fdc neu (erfordert Netzwerkzugriff).

EMBEDDING_RUNTIME_URL ist optional. Verweist es auf eine zweite OpenAI-kompatible Laufzeitumgebung, die /v1/embeddings bereitstellt (z. B. llama-server --embedding), arbeitet der Abruf als hybrid: Der lexikalische Scorer liefert Treffer und das Embedding-Modell ordnet sie neu an. So landet „gegrillte Hähnchenkeule“ in der richtigen Zeile, selbst wenn die Datenbank sie anders benennt. Bleibt der Wert ungesetzt, der Standard, erfolgt der Abruf rein lexikalisch. Das verschlechtert das Ranking leicht, stellt aber nie einen Fehler dar. Eine unerreichbare Embedding-Laufzeitumgebung schaltet mit einer einzigen Warnung auf rein lexikalischen Abruf um; ein Scan schlägt dadurch nie fehl.

`FOOD_SOURCE=off` und die ODbL-Weitergabe unter gleichen Bedingungen

Die Daten von Open Food Facts stehen unter der Open Database Licence (ODbL), die Weitergabe unter gleichen Bedingungen ist. Wenn du diese Schnittstelle aktivierst und danach eine Datenbank veröffentlichst oder weitergibst, die OFF-Daten enthält (nicht die einzelnen angezeigten Abfragen, sondern abgeleitete Datenbank), verpflichtet dich die ODbL, diese abgeleitete Datenbank ebenfalls unter der ODbL bereitzustellen und Open Food Facts als Quelle zu nennen.

Für eine Instanz im Privathaushalt, die eine Abfrage anzeigt und in deinem Tagebuch speichert, gilt dies nicht. Wenn du darauf ein Produkt aufbaust, gilt es sehr wohl, weshalb off nicht der Standard ist. fdc enthält keine Pflicht zur Weitergabe unter gleichen Bedingungen.

Die Lizenzbestimmungen für Modelle und Daten sind in Lizenzierung zusammengefasst.