LFM2.5-VL-3B : un modèle vision-langage local rapide de Liquid AI

Faire tourner une IA capable de lire un document, repérer un élément à l’écran et déclencher une action ne devrait pas forcément imposer un aller-retour vers une API cloud. C’est le positionnement de LFM2.5-VL-3B, le nouveau modèle vision-langage de Liquid AI : un modèle de 3,1 milliards de paramètres, destiné aux usages locaux et aux charges à fort volume.

Selon l’éditeur, ce modèle améliore quatre dimensions par rapport à la précédente génération : la compréhension des interfaces, la localisation d’objets demandés en langage naturel, le traitement de plusieurs images et le function calling. Les résultats publiés sont prometteurs, notamment sur les écrans et le grounding. Mais ils restent des mesures communiquées par Liquid AI : avant de l’intégrer à un produit, teste-le sur tes propres captures, documents et contraintes matérielles.

Un modèle multimodal orienté écrans, documents et actions

LFM2.5-VL-3B associe un encodeur visuel SigLIP2 400M NaFlex au même backbone préentraîné que le modèle texte LFM2.5-2.6B de Liquid AI. Son rôle ne se limite donc pas à décrire une image. Le modèle est présenté comme capable de traiter des documents, des graphiques, du texte intégré dans une image et des éléments d’interface.

La différence est concrète pour les équipes produit. Une IA qui comprend une interface peut, par exemple, servir d’étape de perception dans un agent qui reçoit une capture d’écran. Une fonction de grounding lui permet en théorie d’indiquer où se trouve l’objet demandé plutôt que de seulement confirmer sa présence. Et le function calling relie cette lecture visuelle à une action structurée : appeler un outil, transmettre un paramètre ou lancer une étape d’automatisation.

Liquid AI affirme aussi que le modèle répond directement, sans mode de raisonnement explicite, afin de préserver la latence dans des applications temps réel et embarquées. Cela ne signifie pas qu’il sera adapté à toutes les tâches complexes : la rapidité de réponse et la robustesse d’une décision métier sont deux critères distincts.

Les chiffres publiés montrent un net progrès sur les interfaces

Les tableaux de Liquid AI comparent LFM2.5-VL-3B à son prédécesseur LFM2-VL-3B ainsi qu’à plusieurs modèles Gemma, InternVL et Qwen. Sur l’ensemble des benchmarks visuels retenus, le nouveau modèle obtient une moyenne de 69,4, contre 57,2 pour LFM2-VL-3B. Cette moyenne rejoint celle d’InternVL 3.5 4B et se situe juste sous les 70,1 de Qwen3.5-4B dans ce protocole particulier.

Le saut le plus visible concerne la compréhension d’écrans. Sur ScreenSpot-v2, Liquid AI rapporte 78,7 sur desktop, 81,2 sur mobile et 82,2 sur le web. Le modèle précédent plafonnait respectivement à 6,0, 7,6 et 2,5. L’écart mérite l’attention si tu construis un agent de navigation ou un outil d’assistance basé sur des captures d’écran.

Le grounding progresse également fortement : 87,9 sur RefCOCO-avg, contre 57,1 pour LFM2-VL-3B. Sur les tâches documentaires, les résultats annoncés sont de 91,1 sur DocVQA, 84,3 sur TextVQA et 81,3 sur ChartQA. Le modèle semble donc particulièrement positionné sur des flux où il faut extraire une information depuis une pièce jointe ou une interface.

Ces chiffres doivent toutefois être lus avec méthode. La source précise que les scores sont normalisés sur 100, que l’évaluation a été réalisée avec vLLM 0.26.0 et les paramètres de génération recommandés par chaque modèle lorsqu’ils étaient disponibles. Les modèles ont été sollicités en mode sans raisonnement explicite. Ce cadre facilite une comparaison, mais ne remplace pas un test sur des PDFs bruités, des interfaces internes ou des documents français spécifiques à ton activité.

Le function calling rend le modèle intéressant pour les agents locaux

Liquid AI met aussi en avant les performances texte du modèle sur le suivi d’instructions et l’usage d’outils. LFM2.5-VL-3B obtient 59,5 sur ToolSandbox et 32,5 sur BFCL V4, contre 26,4 et 20,5 pour le précédent LFM2-VL-3B. D’après l’éditeur, ces résultats le placent au niveau de Gemma-4-E2B sur certains tests de tool use, et de Qwen3.5-2B dans cette catégorie.

Pour un développeur, le function calling ne supprime pas le besoin d’un cadre d’exécution fiable. Le modèle peut produire l’intention et les arguments d’un appel ; ton application doit encore valider les schémas, contrôler les permissions, gérer les échecs et journaliser les actions. C’est encore plus vrai lorsqu’une observation visuelle déclenche une opération sur un compte, une commande e-commerce ou un environnement de production.

La source indique que le post-entraînement s’appuie d’abord sur du fine-tuning supervisé, avec distillation depuis un modèle enseignant et entraînement Antidoom, puis sur un apprentissage par renforcement à récompenses multiples. Liquid AI indique également avoir entraîné le modèle sur environ 34 000 milliards de tokens, avec quatre fois plus de données visuelles que précédemment. Son vocabulaire a été doublé à 128 000 unités pour mieux prendre en charge les écritures non latines.

Ces éléments expliquent l’orientation multilingue annoncée, mais la source ne fournit pas de détail précis sur la qualité en français, ni une ventilation exhaustive des langues et jeux de données. Il serait donc imprudent d’en déduire un niveau de fiabilité particulier pour des documents francophones.

Des promesses de vitesse solides, à vérifier sur ton matériel

Le principal argument de LFM2.5-VL-3B est son exécution locale. Liquid AI annonce environ 3 Go de mémoire nécessaires, 228 tokens par seconde sur une puce M5 Max, 116 tokens/s sur un Ryzen AI Max+ 395 et 20 tokens/s sur un Galaxy S26 Ultra. Ces données suggèrent qu’un déploiement embarqué est envisageable sur des appareils récents, sans envoyer systématiquement les images vers un service distant.

Pour l’inférence serveur, l’éditeur annonce un débit de sortie d’environ 11 000 tokens par seconde à forte concurrence, et jusqu’à près d’un milliard de tokens générés par jour sur une H100. Il affirme que le modèle est le plus rapide des modèles comparés sur les entrées multi-images et le débit de sortie.

Attention : ces mesures ne donnent pas toutes les conditions de test détaillées dans l’extrait fourni. La vitesse réelle dépendra du format des images, du nombre de frames, de la quantification, du batch, de la longueur de contexte et du runtime choisi. Le support annoncé dès la sortie couvre néanmoins les briques habituelles : llama.cpp, MLX, vLLM, SGLang et ONNX.

Comment évaluer LFM2.5-VL-3B avant de l’intégrer

Le modèle est disponible via Hugging Face sous l’identifiant LiquidAI/LFM2.5-VL-3B. La documentation source propose de l’utiliser avec transformers>=5.10.1, un processeur automatique et AutoModelForImageTextToText. Commence néanmoins par une évaluation courte et instrumentée :

• constitue un jeu de 50 à 100 images représentatives : interfaces, scans, factures, graphiques ou photos produit ;
• sépare les tests de lecture, de localisation d’éléments et d’appel de fonctions ;
• mesure le taux de réponses exploitables, les erreurs d’extraction et les hallucinations ;
• teste les cas sensibles : texte petit, interfaces sombres, langues mélangées, images floues et éléments partiellement masqués ;
• encadre tout appel d’outil par une validation stricte côté application.

LFM2.5-VL-3B paraît particulièrement pertinent si tu cherches un modèle compact pour comprendre des écrans et des documents sans sacrifier la vitesse. Les benchmarks publiés donnent un signal favorable, surtout face à la génération précédente. La prochaine étape n’est pas de lui confier immédiatement un workflow critique : c’est de vérifier, sur tes propres cas, si ses gains de latence et de confidentialité compensent les erreurs qui subsistent inévitablement dans une chaîne multimodale.