Matériel et latence mesurée

Chaque valeur présentée ici indique le matériel sur lequel elle a été mesurée, et les projections sont signalées comme telles.

Toutes les mesures portent sur le même jeu de référence de 50 photos avec les mêmes invites. La méthodologie complète, les intervalles de confiance et les exécutions se trouvent dans eval/BASELINE.md et eval/PERFORMANCE.md.

Les profils

Les deux variantes lite fonctionnent sur CPU. quality fonctionne aussi sur CPU, très lentement, et correspond plutôt à un profil GPU.

quality sur un GPU, mesures réelles

Les deux lignes : Qwen3-VL-8B-Instruct Q4_K_M + F16 mmproj, contexte 8192, images réduites à 896 px, llama.cpp llama-server b10380, pods loués, 50 photos. Les deux incluent environ 0,35 à 0,6 s d'aller-retour réseau et proxy qu'un conteneur sur ta propre machine n'a pas à payer, donc servir en local est plus rapide que ces chiffres, pas plus lent. Précision sur la même exécution : 72,8 % de rappel sur les éléments de base avec zéro hallucination sur les 50 assiettes, statistiquement impossible à distinguer du modèle de pointe dans le cloud qu'openplate utilise par défaut.

N'importe quelle carte d'environ 24 GB de cette catégorie convient. C'est ce que nous avons mesuré ; nous n'en avons pas mesuré de plus petite.

Plancher de VRAM. Les poids font 4,68 GiB (Q4_K_M) + 1,08 GiB (tour de vision F16) = 5.8 GiB, et l'ensemble de travail total mesuré à 8192 de contexte avec 2 slots était de 6,3 GB. Donc une carte de la catégorie 12 GB devrait être confortable et une carte de 8 GB est envisageable mais juste (tu devrais probablement réduire le contexte ou décharger une partie du modèle). C'est de l'arithmétique, pas un chiffre testé : 24 GB est la seule taille que nous avons mesurée. Si tu essaies 12 GB et que ça fonctionne, c'est une information utile.

La vraie variable est la bande passante mémoire, pas la VRAM

La vitesse de génération sur une requête unique est limitée par la bande passante : chaque jeton parcourt l'ensemble complet des poids actifs. Les deux cartes mesurées sont toutes les deux à peu près dans la catégorie ~1 000 GB/s (RTX 4090 ≈ 1008 GB/s, RTX 3090 ≈ 936 GB/s), et leurs p50 mesurés suivent cette tendance : 0,94 s contre 1,72 s.

Projection, pas une mesure : une carte de la catégorie ~300 GB/s (L4, et la plupart des cartes pour stations de travail capables d'inférence) a environ 3× moins de bande passante que la 3090, ce qui la situe à une projection de 4 à 6 s par analyse. C'est extrapolé à partir de la ligne de la 3090, non mesuré, et les chiffres réels sont généralement pires qu'une mise à l'échelle linéaire.

CPU : mesuré

Hôte pour chaque ligne ci-dessous : AMD Ryzen 9 7940HS, 14 threads, pas de GPU (-ngl 0), llama.cpp llama-server, contexte 8192, les mêmes 50 photos.

lite : la ligne à retenir pour planifier. Mesuré le 2026-08-13 via le service en production : exactement ce code, sa réduction à 896 px, sa grammaire, son mappage de sortie, 50/50 images, 0 erreur, requêtes séquentielles sur le loopback.

Source : eval/runs/2026-08-13-lite-cpu-v3/results.json. Cette exécution mesurait uniquement la latence : la précision n'a pas été évaluée. Le chiffre de rappel de lite provient d'une exécution de différent (2026-08-12 : 62,1 % de rappel sur les éléments de base, ce qui explique pourquoi lite est documenté comme le plancher pour l'auto-hébergement contraint plutôt que comme la référence). Deux exécutions, deux chiffres, cités séparément.

La latence augmente avec la complexité de l'assiette ainsi qu'avec le nombre de threads. Le coût d'une analyse dépend de la longueur de son prompt, des jetons que le modèle lit pour cette photo, et le prompt était quatre fois plus long pour un petit-déjeuner complet que pour une simple assiette. Deux analyses mesurées via le service fourni sur le même modèle de processeur, dans une machine virtuelle à 6 vCPU avec les 4 threads par défaut (2026-09-27) :

Sur une machine ordinaire dotée d'un processeur standard, prévois donc entre 5 secondes et une minute environ par assiette : la fourchette basse avec beaucoup de threads et une assiette simple, la fourchette haute avec peu de threads et une assiette chargée. Ce sont deux analyses isolées, pas une distribution.

quality sur le même processeur : ≈94 s / assiette (p50, 12/08/2026), mesuré sous un pipeline antérieur plus verbeux en pleine résolution d'image, et non remesuré avec le pipeline livré, traite donc cette valeur comme une borne supérieure. quality correspond à un profil GPU.

RAM (RSS mesuré) : lite 1,55 Go, quality 6,31 Go.

Le débit du processeur ne s'améliore pas avec la concurrence. Mesure concrète : deux requêtes simultanées coûtent 0,75 à 0,83× par rapport aux deux mêmes exécutées l'une après l'autre, soit un gain de débit de 1,2 à 1,3× pour un déploiement ×2, payé intégralement en latence par requête (une requête isolée prend 2,5 s ; deux en cours prennent 3,7 s chacune). Prévois la capacité comme si la machine traitait les requêtes en série.

Machine minimale sur processeur pour lite : 8 cœurs modernes ou plus avec AVX2, 4 Go de RAM disponible (1,55 Go pour le modèle, de la marge pour tout le reste), environ 3 Go de disque (1,96 Gio de poids plus l'image, environ 1 Go). 8 threads au lieu de 14 double approximativement la latence par assiette. Pas de GPU, pas de CUDA, aucun appel externe, vérifié par scripts/smoke-lite.sh, qui construit l'image processeur, la démarre sans GPU et lui soumet une vraie photo.

Aucun plafond de latence par défaut

LATENCY_CEILING_MS vaut 0, ce qui correspond à désactivé par défaut. Une machine qui rejetterait de la charge au-delà d'un seuil refuserait des requêtes qu'elle est tout à fait capable de traiter, et sur processeur, une analyse prend légitimement entre quelques secondes et quelques minutes. L'expérience utilisateur adaptée est asynchrone : tu prends la photo, tu ranges le téléphone, et l'assiette est analysée quand tu rouvres l'application. Ce qui ne convient pas sur processeur, c'est un aperçu direct qui se rafraîchit pendant le cadrage.

Si tu veux une limite sur ta propre machine, définis LATENCY_CEILING_MS=10000 et le service se mettra à refuser le travail qu'il ne peut pas terminer en dix secondes. La plupart des auto-hébergeurs devraient laisser cette option désactivée.