Test d'acceptation de vision locale LFM2.5-VL-3B : comment qualifier les VLM sur appareil pour les écrans, les documents et les flux de travail privés

Le test d'acceptation de vision locale LFM2.5-VL-3B de Liquid AI doit être jugé comme un exercice de qualification de route, pas comme un titre de fiche modèle. La question pratique est plus précise : un petit modèle vision-langage local peut-il traiter une tâche privée d'écran, de document ou d'ancrage assez bien pour que le produit puisse accepter le résultat sans envoyer l'image à un VLM cloud ?

Cette question est facile à formuler et difficile à prouver. Une capture d'écran de démonstration soignée montre seulement que le modèle peut lire un certain contenu visuel. Une route de production doit survivre à un appareil plus chaud, à une mémoire limitée, à une dérive de l'état d'écran entre la capture et l'action, à des scans inclinés, à des tableaux denses et à des règles de confidentialité qui interdisent l'envoi.

Cet article utilise comme sources le billet de publication de Liquid AI, la fiche modèle Hugging Face, la documentation Liquid, les notes sur les capacités de vision, les conseils d'évaluation matérielle, la documentation de déploiement ONNX, les artefacts ONNX et les artefacts GGUF. Traitez les chiffres de benchmark, de vitesse et de capacité de ces pages comme mesurés par le fournisseur ou propres à la source jusqu'à ce que votre équipe les reproduise sur ses propres appareils. L'objectif n'est pas de prouver que la vision locale bat la vision cloud partout. L'objectif est de décider où le local est accepté, où le cloud reste nécessaire et où le repli hybride est le modèle d'exploitation le plus honnête.

Pour des modèles d'acceptation liés, consultez les travaux d'Optijara sur la reproductibilité de la visibilité du fil, le test de route de capture sélectionnée par l'IA, le test de frontière de mémoire du contexte de travail et le test d'acceptation de route d'inférence.

Pourquoi LFM2.5-VL-3B a besoin d'un test d'acceptation, pas d'un récapitulatif de lancement

Un VLM local ne doit pas être adopté parce qu'il est nouveau, compact ou prometteur sur des benchmarks. Il mérite sa place seulement quand une route définie réussit l'acceptation. Une route peut extraire les champs d'en-tête d'une facture à partir d'une photo de téléphone hors ligne. Une autre peut identifier le bouton actif dans un écran d'application contrôlé. Une autre peut résumer une capture d'écran expurgée sans déplacer l'image hors de l'appareil. Chaque route a besoin de son propre seuil d'exactitude, de latence, de confidentialité et de repli.

Les sources de Liquid AI établissent ce que l'éditeur met à disposition : la page du modèle LFM2.5-VL-3B, les artefacts publics du modèle, la documentation runtime et les conseils de déploiement. Elles ne prouvent pas que votre flux caméra, votre choix de quantification, votre runtime mobile, votre budget mémoire ou votre conception d'interface se comportera correctement en utilisation soutenue. Cette preuve manquante est le test d'acceptation.

Les flux de travail d'écrans et de documents sont moins tolérants que le chat ouvert. Une mauvaise coordonnée peut cliquer sur le mauvais contrôle. Un champ manqué peut corrompre un formulaire. Une ligne de tableau hallucinée peut entrer dans un enregistrement métier. Un repli cloud qui se déclenche discrètement peut affaiblir l'attente de confidentialité que les utilisateurs pensaient obtenir. La vision locale inspire confiance seulement quand ces échecs sont mesurés directement.

Ce qu'il faut vérifier avant les tests : artefacts, licence, runtime et adéquation avec les appareils

Commencez par épingler les poids du modèle, la configuration du processeur, le tokenizer, les exemples de runtime et toute variante quantifiée. Utilisez des révisions immuables quand c'est possible. Enregistrez le nom de l'artefact, l'URL source, le commit ou la révision, les hash de fichiers, le script de conversion et le code de prétraitement. Un résultat de test lié seulement à l'expression LFM2.5-VL-3B est trop vague pour une acceptation en production.

La disponibilité des poids ne vaut pas autorisation pour chaque usage produit. Examinez la fiche modèle et le texte de licence avant toute redistribution, intégration commerciale, expédition sur appareil, mise au point fine ou service API. Gardez la revue de licence dans le même dossier d'acceptation que les résultats d'exactitude et de runtime. Séparer la revue juridique de la revue technique est une façon pour les équipes de perdre le fil.

Le choix du runtime compte aussi. Un chemin Hugging Face en pleine précision peut ne pas se comporter comme un chemin mobile ONNX. Un build GGUF quantifié peut déplacer la pression mémoire, la latence, la stabilité de sortie ou la gestion des images. Testez chaque route séparément. Ne laissez pas un bon résultat sur un runtime valider un runtime différent par association.

Construisez une matrice d'appareils avant de publier le premier score. Incluez la version de l'OS, le CPU, la disponibilité du GPU ou du NPU, la RAM, le stockage, le profil thermique, l'état de la batterie, l'état du réseau et le runtime. Ajoutez au moins un appareil d'entrée de gamme qui ressemble à la base d'utilisateurs réelle. Si une route réussit seulement sur un appareil de laboratoire branché qui a démarré froid, elle n'a pas réussi la route produit.

Le cadre LVAT d'Optijara : test d'acceptation de vision locale

LVAT est un cadre d'acceptation en quatre parties pour décider quand LFM2.5-VL-3B peut traiter localement une tâche visuelle. Le cadre est conçu pour être propre à chaque tâche. Une route peut réussir pour le tri de documents et échouer pour l'automatisation précise d'interface utilisateur, et ce n'est pas une contradiction. C'est l'objectif du test.

Preuve de frontière locale et de confidentialité. Désactivez le réseau et exécutez la route. Inspectez les journaux, les rapports de crash, l'analytique, les tampons de télémétrie, les charges utiles de repli et les vérifications de mise à jour. Confirmez que les prompts, les images, les sorties OCR et les coordonnées restent dans la frontière prévue, sauf si une politique de repli explicite est déclenchée et divulguée.

Fidélité visuelle sur les écrans et les documents. Incluez les petites polices, les positions de défilement, les popups, les modales, le faible contraste, le flou, la compression, les captures tournées, les tableaux denses, les formulaires, les scans et les pages multilingues. Notez les champs exacts, la structure normalisée des tableaux, la préservation de la mise en page et les omissions de texte. Enregistrez ce qui se dégrade quand les images sont redimensionnées, découpées en tuiles ou recadrées.

Actionnabilité par l'ancrage et les schémas d'outils. Testez les sorties de coordonnées par rapport aux fenêtres de tolérance, au chevauchement de régions et à la sécurité des cibles de clic. Pour les appels d'outils, validez chaque sortie contre des schémas JSON stricts. Comptez les schémas invalides, les tentatives d'action risquées, les mauvaises références de cible et les cas où le modèle devrait s'abstenir.

Tolérance sous stress appareil, entrées malformées et repli. Exécutez la route sous pression mémoire, en boucles soutenues, sur des appareils chauds et avec batterie faible. Ajoutez des images cassées, des captures d'écran partielles, des captures interrompues et des états d'écran changeants. Le repli doit être visible, motivé et auditable. Si l'utilisateur ne peut pas savoir quand le cloud a été utilisé, le produit cache une décision architecturale.

Matrice de décision de route LVAT : local, cloud ou hybride

Le local doit être le choix par défaut quand la tâche est sensible à la confidentialité, que la taille de l'image est gérable, que l'appareil réussit les tests soutenus de latence et de mémoire, que l'exactitude d'ancrage reste dans la tolérance et que la route fonctionne hors ligne. Les exemples incluent le tri documentaire étroit, le résumé local de captures d'écran ou la détection de régions d'interface contrôlées après réussite sur un jeu de tests de référence.

Le cloud reste plus sûr quand la tâche exige un raisonnement plus large, un contexte plus grand, une compréhension multilingue plus complexe, des seuils d'exactitude que le local n'atteint pas, des lots de documents lourds ou des politiques d'audit qui nécessitent des contrôles de modèle centralisés. La confidentialité locale a une vraie valeur. Elle ne compense pas une capacité manquante quand la capacité est la contrainte déterminante.

Le routage hybride est souvent la meilleure voie de première publication. Exécutez d'abord le local pour les classes d'entrées acceptées. Escaladez quand la confiance est faible, que l'entrée est malformée, que l'appareil est chaud, que la pression mémoire est élevée, que la langue ou le type de document est hors de l'ensemble accepté, ou que l'utilisateur a accepté le repli cloud.

Mesurez le coût par tâche acceptée, pas le prix brut des tokens ni la vitesse de démonstration. Incluez l'utilisation des ressources appareil, la gestion des échecs, le volume de repli, la surveillance, la maintenance, les tests de régression et le risque de mise à jour. La route la moins chère sur une diapositive peut devenir coûteuse une fois que la logique de nouvelle tentative et les tickets de support entrent dans le calcul.

Checklist de mise en oeuvre pour les écrans, les documents et l'ancrage d'objets

Définissez le timing des captures d'écran, l'orientation, les règles de recadrage, les limites de redimensionnement, la stratégie de découpage en tuiles et l'expurgation avant de mesurer le modèle. Incluez des tests de dérive d'état d'écran où la cible se déplace après la capture. Testez les superpositions, les états du clavier, les popups et les positions de défilement. Cela ressemble à des détails produit, mais ils expliquent souvent plus d'échecs que le modèle lui-même.

Construisez un ensemble représentatif de formulaires, factures, tableaux, scans, images à faible contraste et pages multilingues. Utilisez des échantillons sensibles expurgés quand c'est possible. Notez l'exactitude des champs, le comportement face aux champs manquants, l'alignement des lignes et colonnes, la normalisation des tableaux et le refus lorsque l'image est illisible.

Évaluez les coordonnées avec des fenêtres de tolérance et le chevauchement de régions, pas avec la justesse narrative. Un modèle qui dit bouton en haut à droite n'est pas équivalent à un modèle qui renvoie une région cliquable sûre. Ajoutez des tests négatifs où l'objet est absent ou seulement partiellement visible.

Chaque sortie d'outil doit être validée par schéma avant usage. Exigez des champs typés, des valeurs de coordonnées bornées, des champs de confiance ou d'abstention, une raison de route et des drapeaux d'action sûre. Rejetez le JSON malformé au lieu de le réparer discrètement en production. Réparer une mauvaise structure peut transformer une erreur du modèle en erreur applicative.

Versionnez les prompts, les seuils, le code de prétraitement, les artefacts de modèle et les jeux de tests de référence. Exécutez des tests de régression avant de changer la quantification, le runtime, la révision du modèle ou le prétraitement caméra. Définissez les critères de rollback avant le déploiement, pendant que personne ne débat sous pression d'incident.

{
  "framework": "Optijara LVAT",
  "accepted_route": "local only after task-level pass",
  "rejected_route": "local when grounding, schema, privacy or sustained-device tests fail",
  "fallback_triggers": ["low confidence", "malformed image", "thermal pressure", "unsupported language", "schema failure"],
  "required_evidence": ["pinned artifacts", "device matrix", "golden tests", "privacy audit", "rollback plan"]
}

Plan de mesure : de la vitesse de démonstration à la fiabilité soutenue des appareils

Mesurez le démarrage à froid, la latence à chaud et la latence soutenue par catégorie de tâche. Ne copiez pas un seuil universel depuis une page de modèle. Une action rapide d'assistant personnel, un lot de documents et un lecteur d'écran d'accessibilité ont des tolérances différentes. Rapportez le p50 et le p95 pour chaque route et chaque appareil.

Exécutez des boucles assez longues pour exposer la limitation thermique, les crashs, la croissance mémoire et l'impact batterie. Suivez si la route s'abstient ou escalade quand l'appareil franchit un seuil de ressources. La fiabilité soutenue compte plus qu'une démonstration attrayante.

Utilisez la correspondance exacte des champs, l'exactitude des tableaux normalisés, la cohérence des régions de mise en page, le taux de réussite d'ancrage, l'évitement des clics risqués, le taux de schéma valide, la précision de l'abstention et la qualité du repli. La bonne métrique est celle qui est liée à la valeur utilisateur acceptée. Pour une route de factures, il peut s'agir de l'exactitude des champs et de la qualité du refus. Pour une action d'interface, l'évitement des clics risqués peut compter plus qu'une description fluide.

Testez le fonctionnement hors ligne avec le réseau désactivé. Inspectez les journaux runtime, l'analytique applicative, les rapports de crash et les files de repli. L'inférence locale ne signifie pas automatiquement privé si des images sensibles apparaissent dans la télémétrie ou les charges utiles d'escalade cloud.

Erreurs fréquentes des équipes lors de la qualification des VLM locaux

Les benchmarks sont des signaux utiles, pas une preuve de déploiement. Un modèle peut obtenir un bon score sur un benchmark et échouer quand même sur une action d'écran étroite parce que le recadrage, la résolution, la langue de l'interface ou le schéma de coordonnées diffère de la tâche du benchmark.

Les images propres masquent le risque de production. Ajoutez du flou, de la compression, des reflets, des captures partielles, des modales, du défilement, du texte minuscule et des documents malformés. L'acceptation doit refléter les entrées désordonnées que les utilisateurs créent réellement.

Ne supposez pas que les chemins ONNX, GGUF, quantifiés et pleine précision sont interchangeables. Traitez chaque combinaison modèle plus runtime plus appareil comme une route candidate séparée. Cette règle paraît fastidieuse jusqu'à ce qu'une mise à jour change la stabilité de sortie sur une classe d'appareils et que personne ne puisse reproduire l'ancien résultat.

Le repli est utile quand il est visible et contrôlé. Il est dangereux quand il cache le fait que la route locale échoue trop souvent. Suivez la raison du repli, la classe d'entrée, l'état des ressources et le résultat final. Un taux de repli élevé n'est pas un succès de vision locale.

L'inférence sur appareil peut encore fuiter par les journaux, les dumps de crash, l'analytique, la surveillance, les systèmes de mise à jour ou le repli cloud. L'acceptation de confidentialité exige une inspection, pas des suppositions.

Réserves, limites et recommandations aux opérateurs

LVAT ne peut pas prouver le comportement futur du modèle, chaque variante d'appareil, chaque type de document, chaque langue ou chaque état d'interface. C'est un processus d'acceptation pour des routes connues. Relancez-le quand les artefacts, les runtimes, les prompts, le prétraitement, les appareils ou les politiques de repli changent.

Les routes locales apportent une taille de packaging, une gestion des mises à jour, un impact batterie, un comportement thermique, une variance d'accélérateur et une complexité de support. Les routes cloud apportent une dépendance réseau, une revue de confidentialité, une variance de fournisseur et des coûts d'inférence récurrents. Les routes hybrides apportent des exigences de politique de routage, de divulgation et d'observabilité. Aucune n'est universellement la meilleure.

Un sprint LVAT pratique commence par la revue des artefacts et de la licence, puis construit une matrice appareil/runtime, un jeu de tests de référence, un pipeline de prétraitement, un runner de scoring, un audit de confidentialité et une politique de repli. Le résultat est une décision de route : local accepté, cloud requis ou hybride avec déclencheurs explicites. Si une équipe évalue LFM2.5-VL-3B pour des flux de travail visuels privés, c'est ce niveau de qualification qui garde la décision ancrée dans les preuves.

La règle est simple : acceptez la vision locale seulement quand les preuves la soutiennent. Épinglez les artefacts, testez la route, mesurez le comportement soutenu des appareils, auditez la frontière de confidentialité et gardez le repli honnête.