Auto-hébergement d’un modèle Vision-Langage pour une intelligence documentaire axée sur la confidentialité
Chaque année, des millions d'Américains qui demandent l'aide alimentaire SNAP (Supplemental Nutrition Assistance Program) se retrouvent bloqués à l'étape de soumission de documents, attendant plusieurs jours qu'un humain examine ce qu'ils ont envoyé. mRelief, un organisme à but non lucratif qui a aidé plus de 4 millions de personnes à accéder aux aides sociales et à débloquer 1,7 milliard de dollars en prestations SNAP, consacrait 23 heures de travail par semaine à cet examen seul.
Automatiser cette étape impliquait de classer des documents en 35 catégories et d'en extraire des données structurées. La contrainte la plus difficile : ces documents (pièces d'identité, relevés financiers, documents d'immigration, etc.) ne pouvaient pas quitter l'infrastructure de mRelief. Envoyer des images à une API tierce signifie que vos données quittent votre VPC (Virtual Private Cloud) dès que la requête est envoyée, emportant avec elles la piste d'audit et introduisant un risque tiers dans chaque conversation de conformité.
mRelief est arrivé bien préparé : leur flux de données était déjà en production, structuré autour d'une fenêtre stricte de 60 jours qui a façonné la conception de notre pipeline dès le premier jour. Ils disposaient de données réelles d'applicants, ce qui a rendu nos chiffres significatifs (sans dérive entre l'expérimentation et la production). Lorsque les annotations semblaient incohérentes, l'intuition des experts nous a aidés à distinguer les véritables erreurs du modèle du bruit d'étiquetage, ce qui a directement orienté notre processus d'expérimentation.
Nous avons livré deux pipelines : Gemini 2.5 Flash en option par défaut, et un pipeline entièrement auto-hébergé et open source pour les flux de travail où les données doivent rester dans l'environnement propre de mRelief.
Trouver le bon modèle d'IA
Sélectionner le bon modèle pour un pipeline auto-hébergé est différent d’en choisir un pour une API. Le comportement en production compte autant que les scores de benchmarks : la robustesse sous une décodification contrainte, la fiabilité de la sortie structurée à grande échelle, l’impact de la quantification sur les performances réelles plutôt que sur des benchmarks synthétiques.
Nous avons mené une recherche systématique sur différentes variantes de modèles et quantifications, suivie dans MLflow (une plateforme open-source pour suivre les expériences ML), et retenu Qwen3-VL-8B-FP8. LLe choix s'est résumé à une question de chiffres : une configuration concurrente affichait des performances dans un écart d'environ 3 % sur les métriques de précision, mais le modèle venait tout juste d'être publié et le support de son framework d'inférence était encore en retard, rendant le comportement de la structure de sortie trop instable pour la production. Un score marginalement supérieur ne vaut pas un modèle qui se comporte parfois mal lorsque vous avez besoin de réponses structurées fiables à grande échelle.
Nous avons testé plusieurs niveaux de quantification : Q4, Q8, FP8… (à voir comme une technique de compression) pour différentes tailles de modèles (8b, 4b, 2b…). La leçon clé : une quantification plus agressive sur un modèle plus grand surpasse constamment une quantification légère sur un modèle plus petit. Le FP8 réduit le modèle de ~17 Go à ~10 Go avec une perte de précision quasi nulle, laissant suffisamment de mémoire GPU pour que l'instance gère plusieurs requêtes simultanées sur un seul GPU.
Le résultat : 85–88 % de précision top-1 et 92–95 % en top-2, proche de la parité avec Gemini sur la classification. L'écart apparaît sur les scans dégradés et les mises en page complexes, où l'ancrage visuel de Gemini est plus solide. Sur les types de documents à haute sensibilité, comme les pièces d'identité et les cartes de sécurité sociale, le pipeline open source est à la hauteur de Gemini.
Mettre en place la bonne infrastructure
Nous avons déployé sur Cloud Run GPU avec un NVIDIA L4 et une facturation à l'usage (scale-to-zero), le bon choix pour un trafic irrégulier et imprévisible où le coût d'un GPU toujours allumé n'est pas justifié. La contrepartie : des démarrages à froid et un point de départ difficile : environ 11 minutes de bout en bout. De nombreuses optimisations ont ramené ce délai à 130–150 secondes.
Le placement VPC a été le gain le plus important et le moins coûteux. Placer le service Cloud Run et le bucket GCS (Google Cloud Storage) dans le même VPC a considérablement augmenté la bande passante de téléchargement disponible. Sans cela, le trafic GCS est limité par les chemins réseau standard. À l'intérieur du VPC, c'est rapide. Coût : quelques centimes par mois.
Désactiver la compilation des graphs CUDA dans vLLM réduit le débit maximal sur les instances chaudes, mais lorsqu’on a le démarrage à froid comme goulot d’étranglement, c’est un choix évident, dès qu’on connaît le levier.
Run:ai Model Streamer parallélise le téléchargement depuis GCS et diffuse les poids directement en mémoire GPU, éliminant l'étape de téléchargement sur disque puis de chargement qui coûtait des dizaines de secondes. Nous avons d'abord essayé de construire notre propre solution. Model Streamer l'a surpassée, donc nous n'avons pas investi davantage de temps à résoudre un problème qui avait déjà été résolu.
Deux approches qui n'ont pas fonctionné : intégrer les poids du modèle dans l'image a ajouté une surcharge de déploiement qui annulait les gains au démarrage à froid, et GCS Anywhere Cache n'a produit aucune amélioration mesurable.
Ce que cela demande vraiment
Il existe une version de ce projet où l'on génère un conteneur vLLM fonctionnel, on le déploie, et c'est terminé. Les démarrages à froid restent à 11 minutes. La sélection du modèle suit un classement. Les optimisations d'infrastructure qui ont vraiment fait la différence restent non découvertes.
Les décisions importantes ici n’étaient pas seulement techniques, mais aussi expérientielles. Choisir la stabilité en production plutôt que le gain de benchmark, comprendre comment la quantification se comporte sur des documents réels plutôt que sur des évaluations synthétiques, diagnostiquer où se trouvent les véritables goulots d’étranglement, découvrir qu’un changement VPC coûtant quelques centimes dépasse toutes les autres optimisations. Ce ne sont pas des résultats que l’on obtient en codant à l'instinct. Cela vient en menant les expériences, en comprenant les résultats et en ayant la capacité de reconnaître les bons leviers à activer.
Un praticien expérimenté qui travaille avec des outils d'IA est une combinaison genuinement différente de l'un ou l'autre pris séparément. L’IA accélère la génération d’hypothèses, automatise l’instrumentation fastidieuse, et explore des options plus rapidement qu'un individu seul ne pourrait le faire manuellement. L'humain apporte le jugement pour savoir quelles options méritent d'être poursuivies, l'instinct de se méfier d'un benchmark qui semble trop propre, et le contexte accumulé pour reconnaître quand un système « fonctionnel » n'est pas réellement prêt pour la production. C'est cette combinaison que ce projet exigeait.
Côté client, mRelief s'est démarqué : ils ont avancé vite et poussé fort. Ils ont intégré notre API rapidement, l'ont testée sur des flux de travail réels, et ont constamment fait remonter de nouvelles exigences et fonctionnalités (détection d'écriture manuscrite, comptage de documents par image, pipeline de confidentialité) qui ont affiné le système final. Ce niveau d'engagement et de curiosité technique a eu un réel impact sur la qualité du système livré.
Pour cet organisme à but non lucratif, cela se traduit par un système d’intelligence documentaire visant 75 % d’automatisation d’un processus qui consommait 23 heures de personnel par semaine, avec une solution auto-hébergé maintenant les données sensibles des demandeurs entièrement dans leur propre infrastructure, traçable de bout en bout, sans fournisseur de modèle tiers dans la chaîne. 2,3 milliards de dollars de prestations débloquées et 2,9 millions de foyers servis — un impact réel.
Prêt à construire ? Contactez-nous.