Le moteur d'inférence

Configuration

Toutes les variables d'environnement, et les options de base de données d'aliments (FOOD_SOURCE)

Cette page est traduite automatiquement à partir de la documentation en anglais.

Tout passe par des variables d'environnement, validées au démarrage ; une valeur incorrecte arrête le processus au lieu de dégrader silencieusement le service. La liste de référence annotée se trouve dans .env.example. La documentation d'openplate liste chaque variable pour ce conteneur sur une page. Elles figurent à côté de celles de l'application et du service de synchronisation. Les variables les plus importantes sont :

variable	valeur par défaut
`MODEL_PROFILE`	`lite`	`lite` \	`lite-apache` \	`quality` \	`external`
`API_KEYS`	(généré)	Clés Bearer séparées par des virgules. Définis cette valeur.
`PORT`	`8300`	Le seul port exposé.
`CONCURRENCY`	`2`	Analyses en cours ; définit aussi les emplacements KV de llama.cpp. Cela n'ajoute pas de threads CPU : les emplacements partagent les `LLAMA_THREADS` threads.
`MAX_QUEUE_DEPTH`	`8`	Au-delà, les clients reçoivent 429 + `Retry-After`.
`RATE_LIMIT_RPM`	`60`	Par clé.
`LATENCY_CEILING_MS`	`0`	0 = désactivé. Politique d'admission : rejette le travail impossible à terminer à temps. Consulte Matériel.
`RUNTIME_COMPLETION_TIMEOUT_MS`	`600000`	Limite totale sur un appel de complétion ; `0` = désactivé. Politique de vivacité, pas de latence : cela libère un emplacement de traitement qu'un runtime bloqué ne rendra jamais. S'applique aussi en mode groupé. Consulte Runtimes.
`IMAGE_MAX_LONG_EDGE`	`896`	Cible de réduction d'échelle. La latence augmente avec le carré.
`MAX_IMAGE_BYTES`	`8388608`	La taille maximale de photo acceptée après décodage base64, en octets (8 Mio). Un fichier plus volumineux est rejeté avec un message demandant de le redimensionner. La limite du corps de la requête découle de cette valeur.
`FOOD_SOURCE`	`fdc`	Consulte Données alimentaires.
`CONTEXT_SIZE`	`8192`	Contexte par analyse en cours. Le conteneur le multiplie par `CONCURRENCY` avant de le transmettre à llama.cpp, car le paramètre `-c` de llama.cpp correspond au total qu'il répartit entre les emplacements.
`LLAMA_EXTRA_ARGS`	(vide)	Drapeaux supplémentaires ajoutés à la fin de la commande llama-server, séparés par des espaces. Mode intégré uniquement.
`LLAMA_THREADS`	`nproc - 2`	Threads CPU pour llama.cpp (son `-t`). Deux cœurs sont laissés pour le service, le décodage d'image et le système d'exploitation, donc une machine à 6 cœurs exécute 4 threads et une machine à 4 cœurs en exécute 2, peu importe ce que `CONCURRENCY` indique. Donner tous les cœurs à llama.cpp sature la machine au lieu de l'accélérer. Le journal de démarrage affiche la valeur sous la forme `-t N`. Mode intégré uniquement.
`MODELS_DIR`	`/models`	Le volume des poids.
`RUNTIME_PORT`	`8080`	Le port du llama-server intégré, sur `127.0.0.1` à l'intérieur du conteneur. Mode intégré uniquement.
`WEIGHTS_MIRROR_BASE`	(vide)	Miroir optionnel ; Hugging Face sert de repli.
`GPU_LAYERS`	(auto)	Remplace l'auto-détection du GPU. `0` force le CPU.
`NVIDIA_VISIBLE_DEVICES`	(défini par le moteur d'exécution)	Le runtime de conteneur NVIDIA le définit quand tu passes `--gpus all`. La détection automatique le lit. Toute valeur autre que `void` ou `none` délègue chaque couche. Tu ne le définis pas toi-même.
`LOG_LEVEL`	`info`	`debug` \	`info` \	`warn` \	`error`
`PROFILE`	(depuis `MODEL_PROFILE`)	Le nom du profil dans le journal de démarrage : `lite`, `quality` ou `custom`. Le conteneur le définit à partir de `MODEL_PROFILE`. Le définir toi-même modifie seulement cette ligne de journal.

Les variables du mode externe (MODEL_RUNTIME_URL, MODEL_ID, MODEL_RUNTIME_API_KEY) sont documentées dans Apporte ton propre moteur d'exécution.

llama-server tourne dans le conteneur lié à 127.0.0.1 seulement et n'est pas accessible depuis l'extérieur. Ce n'est pas configurable : c'est un point de terminaison de vision brute sans authentification, et le but est que tu ne puisses pas le publier par accident.

Données alimentaires (`FoodSource`)

Le modèle identifie les aliments et estime les grammes. Les macronutriments sont résolus à partir d'une base de données alimentaires, par nom, jamais générés par le modèle.

`FOOD_SOURCE`	ce que ça fait	réseau	notes
`fdc` (par défaut)	Cherche les noms dans un extrait inclus de USDA FoodData Central, 8 041 aliments génériques, livré dans l'image à `data/fdc-foods.json`.	aucun	Hors ligne, sans clé, sans compte, sans requête sortante. Domaine public. C'est l'option par défaut car c'est la seule qui n'a besoin de rien ni de personne.
`off`	Interroge Open Food Facts en direct lors de ton exécution.	sortant, par scan	Performant sur les produits de marque et emballés, moins précis sur les plats cuisinés génériques. L'adresse est `OFF_API_URL`, `https://world.openfoodfacts.org` par défaut. Lis la note de licence ci-dessous avant d'activer. Rien d'issu d'OFF n'est inclus dans cette image.
`lcc`	Interroge l'API publique de lowcarbcheck.	sortant, par scan	Les données les plus larges des trois (sélectionnées + BLS + USDA), et exclusivement distantes à titre définitif, car BLS 4.0 interdit la redistribution. L'attribution est transmise dans la réponse pour parvenir à l'interface utilisateur. Sans `LCC_API_KEY`, chaque requête utilise le palier anonyme gratuit de LowCarbCheck ; voir ci-dessous.
`none`	Aucune résolution. Chaque élément revient avec des macronutriments nuls.	aucun	Pour les clients qui effectuent leur propre recherche nutritionnelle.

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

Sans LCC_API_KEY, FOOD_SOURCE=lcc utilise le palier anonyme de LowCarbCheck : 1 000 crédits par jour UTC, partagés par toutes les requêtes issues de ton adresse IP. Une recherche coûte 1 crédit. Une analyse émet jusqu'à 3 requêtes de recherche par élément identifié, selon le plafond d'affinage défini dans search-foods.ts, sur un maximum de 8 éléments. Le pire des cas s'élève donc à 24 crédits par analyse. Le pipeline n'appelle jamais le point d'accès par aliment, cela couvre donc la totalité du coût. Ce pire des cas permet environ 41 analyses par jour. La plupart des jours en permettent davantage, car une recherche s'arrête dès qu'une requête dépasse le seuil d'acceptation. Quand le palier est épuisé, chaque élément restant prend des macros nulles jusqu'au jour UTC suivant, et l'analyse renvoie toujours 200. Une clé gratuite obtenue sur lowcarbcheck.org/developers porte le quota à 100 000 crédits par mois, jusqu'à 120 requêtes par minute. Ce quota est rattaché à la clé plutôt qu'à ton adresse IP. Définis-la comme LCC_API_KEY. Le service l'envoie comme jeton porteur à LCC_API_URL et nulle part ailleurs, et ne la journalise jamais. Une clé rejetée par LowCarbCheck échoue de la même manière qu'un quota épuisé : macros nulles et code 200. fdc ne nécessite aucun réseau ni aucun quota.

Les macronutriments résolus sont étiquetés. Les aliments associés à la base de données incluent un provenance de "corpus", ainsi qu'une chaîne attribution si la source l'exige. Les aliments non associés omettent ces deux champs, et macrosPer100g vaut null. openplate expose ces valeurs afin que tu puisses distinguer les entrées confirmées de la base de données des éléments sans données de macronutriments.

L'absence de base de données d'aliments ne bloque pas les scans. Si FDC_DATASET_PATH ne pointe sur rien, le service consigne un avertissement, désactive la résolution et continue d'identifier les assiettes. Tu obtiens les noms et les grammes avec des macronutriments nuls : dégradé, pas cassé. Régénère l'extrait avec pnpm food-data:fdc (nécessite le réseau).

EMBEDDING_RUNTIME_URL est facultatif. Si tu le pointes vers un second environnement d'exécution compatible OpenAI qui sert /v1/embeddings (par exemple llama-server --embedding), la recherche devient hybride : l'évaluateur lexical trouve des candidats et le modèle de plongement les reclasse, ce qui permet à « haut de cuisse de poulet grillé » de correspondre à la bonne ligne même si la formulation de la base diffère. Si tu le laisses non défini, son état par défaut, la recherche reste uniquement lexicale, ce qui donne un classement légèrement moins bon mais ne provoque jamais d'erreur. Si l'environnement de plongement est injoignable, le système repasse en recherche purement lexicale avec un simple avertissement, sans jamais faire échouer un scan.

`FOOD_SOURCE=off` et le partage à l'identique de l'ODbL

Les données d'Open Food Facts sont publiées sous la Open Database Licence (ODbL), qui impose un partage à l'identique. Si tu actives ce connecteur puis publies ou redistribues une base de données intégrant des données d'OFF (non pas les consultations unitaires que tu affiches, mais une base de données dérivée), l'ODbL t'oblige à mettre aussi cette base dérivée à disposition sous la même licence ODbL, et à créditer Open Food Facts.

Pour une instance domestique qui affiche le résultat d'une recherche et l'enregistre dans ton propre journal, cela ne s'applique pas. Si tu conçois un produit basé dessus, cela s'applique, et c'est la raison pour laquelle off n'est pas le choix par défaut. fdc n'impose aucune obligation de partage à l'identique.

Les conditions de licence des modèles et des données sont regroupées dans Licences.