LFM3 : des modèles IA compacts pour l’IA spécialisée
Découvrez LFM3, la famille de modèles IA compacts de Liquid AI : capacités, performances, usages locaux et limites à évaluer avant un déploiement.
LFM3 : des modèles compacts pour une IA spécialisée, locale et multimodale
Les modèles d'IA « très puissants » ne sont pas toujours ceux dont on a besoin en production. Souvent, une entreprise veut traiter des documents sensibles sans envoyer chaque requête vers le cloud, gérer des demandes vocales ou automatiser un morceau précis d'un processus métier. Dans ce contexte, la taille du modèle, son coût d'inférence et la possibilité de l'adapter en local comptent presque autant que les scores sur un benchmark.
C'est l'idée derrière LFM3, la nouvelle famille de modèles open-weight de Liquid AI. Elle regroupe des modèles de texte, de vision, d'audio, multimodaux et de décision, dans une gamme autour de deux milliards de paramètres. L'objectif est simple : proposer des modèles assez compacts pour tourner sur des appareils locaux, tout en restant capables d'être spécialisés sur un besoin précis.
La vraie question n'est donc pas seulement : LFM3 fait-il de bons scores ? Il faut plutôt voir ce que recouvre la famille, où ses performances peuvent servir concrètement, ce que change le déploiement en conditions réelles, et surtout quelles vérifications restent à faire avant de l'intégrer à un produit.
LFM3 : une famille de modèles IA compacts
LFM3 désigne une nouvelle génération de modèles fondamentaux de Liquid AI. Le premier lot annoncé regroupe six modèles dérivés d'un même modèle de base, LFM3-1.7B. Quatre couvrent des modalités distinctes - texte, image, audio et multimodal - et deux modèles de décision sont prévus pour la vision ou l'audio, avec une logique proche.
Les poids des modèles de base et des versions post-entraînées sont annoncés comme ouverts. Concrètement, cela veut dire que l'on peut les télécharger, les exécuter dans un environnement compatible et les adapter, à condition de respecter les conditions de licence propres à chaque modèle. Et « open-weight » ne veut pas forcément dire « open source » au sens strict : les données d'entraînement, le code complet et tous les détails de fabrication ne sont pas nécessairement publiés.
Les six modèles et leurs rôles
- LFM3-1.7B traite le texte, avec des usages ciblés pour les agents, l'usage d'outils et des applications spécialisées. Sa fenêtre de contexte peut aller jusqu'à 256 000 tokens.
- LFM3-VL-2B travaille sur images et vidéos. Il est pensé pour répondre à des questions visuelles, lire des graphiques ou localiser des objets.
- LFM3-Audio-2B reçoit du texte ou de l'audio et peut répondre par du texte, de la parole ou les deux. Il gère 18 langues, selon Liquid AI.
- LFM3-Omni-2B combine vision, audio et langage dans un même modèle : par exemple, comprendre une vidéo avec le son et répondre à une consigne parlée.
- d1-2B traite des entrées textuelles et visuelles pour produire des décisions structurées : un choix, une valeur ou une localisation.
- d1-Omni-2B étend cette approche aux entrées audio.
Cette séparation par « familles » répond à un point pratique : un modèle généraliste n'est pas forcément le meilleur choix pour chaque tâche. Pour une application qui attend des sorties exploitables (champs structurés), un modèle de décision peut être plus simple à intégrer qu'un modèle qui « rédige » une longue réponse. Et si l'entrée principale, c'est la voix, un modèle audio n'est pas un luxe.
Ce que veut dire « compact »
Ces modèles tournent autour de deux milliards de paramètres, avec des tailles qui varient selon les variantes. C'est clairement en dessous des grands modèles hébergés dans le cloud, mais ça ne suffit pas à garantir qu'un modèle tournera partout. La mémoire disponible, la quantification, la longueur du contexte et le moteur d'inférence jouent aussi.
L'intérêt est surtout opérationnel : une équipe peut tester une exécution locale, limiter certains transferts de données et adapter le modèle à un domaine sans dépendre systématiquement d'un service distant. Pour un acteur français qui traite des documents RH, des dossiers clients ou des données industrielles, ça peut aider à concevoir une architecture compatible avec les contraintes internes et le RGPD. Mais attention : « local » ne veut pas dire « conforme automatiquement ». Les accès, la conservation, la sécurité et les usages doivent être définis et documentés.
Une architecture pensée pour la vitesse et le multimodal
LFM3 s'appuie sur une architecture hybride issue des travaux précédents de Liquid AI. Le modèle de base a été préentraîné sur 22 000 milliards de tokens, puis adapté avec des étapes complémentaires. Le but est de viser un compromis entre capacité, vitesse d'inférence et coût mémoire, notamment quand le contexte devient long.
Convolutions et attention, selon le besoin
Sur LFM3-1.7B, le modèle textuel mélange trois types de blocs : des convolutions courtes à portes, de l'attention à fenêtre glissante et de l'attention globale. Sur ses 24 couches, 13 utilisent des convolutions, 5 une fenêtre glissante de 256 tokens et 6 une attention globale. L'idée est de ne pas « payer » le coût de l'attention étendue partout, mais de la réserver aux cas où elle sert vraiment.
Liquid AI indique que LFM3-1.7B serait environ 25 % plus rapide que LFM2-1.2B sur un contexte de 8 000 tokens, à nombre de paramètres comparable. La société rapporte aussi des gains sur plusieurs appareils et une consommation mémoire réduite dans ses évaluations. Ces chiffres restent à prendre comme des indications : ils dépendent du matériel, du format de quantification, du moteur d'inférence et des réglages. Il faut donc les vérifier sur la configuration visée, pas les extrapoler à partir d'un seul cas de test.
Le modèle de texte a été entraîné sur un corpus qui, selon Liquid AI, inclut notamment des articles scientifiques, du code à l'échelle de dépôts, davantage de mathématiques et des traces d'usage d'outils. Une étape supplémentaire a aussi étendu le contexte jusqu'à 256 000 tokens. Mais cette longueur maximale ne veut pas dire que chaque requête à 256 000 tokens restera rapide et « peu coûteuse » : le cache mémoire lié au contexte peut vite devenir un facteur bloquant.
Des encodeurs pour la vision et l'audio
LFM3-VL-2B utilise un nouvel encodeur visuel combinant convolutions et attention. Liquid AI annonce qu'il demande moins de calcul que l'encodeur des anciens modèles visuels, tout en gardant une qualité comparable selon leurs tests. Le modèle traite aussi la vidéo, ce qui permet d'interroger des séquences, pas seulement des images isolées.
Côté audio, l'encodeur est conçu pour un flux « en direct ». L'entreprise annonce un délai avant le premier token pouvant descendre à 50 millisecondes dans certaines conditions. Un nouveau codec, LiquidCodec, vise une parole en flux continu et, d'après les mesures publiées, à environ 87 fois le temps réel sur un cœur de processeur Apple M4 Max.
Au niveau produit, ce genre de choix peut réduire la latence ou faciliter certains scénarios interactifs. Mais ça ne remplace pas les mesures bout en bout : une application vocale doit aussi gérer la qualité de transcription, le bruit ambiant, les interruptions, le réseau éventuel et la latence de ses outils externes.
Des usages métier concrets, du texte à la décision
La valeur de LFM3 dépend moins de la liste des modalités que de la capacité à choisir le bon modèle pour un processus précis. Les exemples annoncés vont de l'agent textuel à l'inspection visuelle, en passant par l'assistant vocal et le tri automatisé de dossiers.
Agents locaux et automatisation textuelle
LFM3-1.7B a été post-entraîné pour fonctionner dans des environnements d'agents et appeler des outils. Les tâches visées incluent la recherche, le tri de demandes, la gestion d'agenda ou l'exécution d'actions dans des logiciels. En entreprise, on peut s'en servir pour classer des tickets, préparer une synthèse de dossier ou déclencher une recherche dans une base interne.
Liquid AI publie des comparaisons où le modèle obtient de bons résultats sur plusieurs tâches d'usage d'outils et d'instruction, parfois face à des modèles plus grands. Par contre, les résultats sont moins solides sur certains tests de connaissances et de « programmation agentique » - là où les modèles plus gros gardent souvent un avantage. Autrement dit, il faut lire les résultats tâche par tâche, et éviter de conclure qu'un modèle compact remplace un modèle généraliste supérieur sur tout.
Un agent n'est pas « fiable » parce qu'il sait appeler une fonction correctement dans un benchmark. En production, il faut restreindre les permissions, valider les actions sensibles, journaliser les appels et prévoir une reprise en cas d'erreur. Sur un processus lié à la facturation, à l'URSSAF ou à des données de salariés, les règles métier et le contrôle humain doivent rester explicites.
Vision, audio et traitement multimodal
LFM3-VL-2B peut analyser des images, des documents, des interfaces et des vidéos. Liquid AI annonce une moyenne de 71,4 sur 62 évaluations visuelles, sur une moyenne non pondérée des benchmarks publiés. L'entreprise le compare à des modèles de taille similaire et indique des résultats proches de modèles plus grands sur certaines catégories. Ces chiffres restent ceux de l'éditeur : le choix des évaluations, les conditions de test et la pertinence par rapport au cas métier comptent avant toute conclusion.
Un exemple décrit par Liquid AI concerne l'inspection de pales d'éoliennes à partir de photos prises par drones. Après ajustement sur environ 3 000 images, l'entreprise rapporte une précision de classification de 67 % sur un jeu de test d'environ 1 400 images. Le modèle de base obtenait moins de 10 % sur ces catégories, dans la même présentation. L'exemple montre l'intérêt du fine-tuning, mais aussi sa limite : 67 % n'est pas un score « automatique » pour une inspection à fort enjeu, surtout sans garde-fous.
LFM3-Audio-2B vise les échanges vocaux, la transcription, la synthèse et l'interprétation de sons. LFM3-Omni-2B peut croiser ce qui est entendu et ce qui apparaît dans une image ou une vidéo. Cela ouvre des usages comme décrire une scène, aider à la formation ou offrir une interface mains libres. Dans l'automobile, la voix peut être plus naturelle qu'un écran ; dans un atelier, le fait d'analyser localement peut réduire le besoin d'envoyer images et sons en continu vers le cloud.
Des modèles de décision plutôt que de la rédaction
Les modèles d1 suivent une logique différente : ils prennent une entrée et produisent des sorties structurées, parfois avec une probabilité. Ils peuvent par exemple extraire une date, sélectionner une catégorie, repérer un objet ou estimer une valeur. Plusieurs questions peuvent être posées sur le même document pendant une même passe.
Pour une équipe produit, cette sortie structurée est souvent plus facile à contrôler qu'un texte libre. On peut définir un schéma attendu, vérifier les champs obligatoires et faire remonter les cas incertains dans une file de revue. Les résultats publiés par Liquid AI indiquent que d1-2B dépasse l'ancien d1-3B sur plusieurs indices internes et publics, malgré une taille plus faible. Là encore, ça ne dispense pas d'évaluer les erreurs selon l'impact réel dans le processus visé.
Comment évaluer LFM3 avant un déploiement
Pour évaluer un modèle compact, il faut partir de la tâche, des contraintes et du coût d'une erreur. Une démo « qui impressionne » ou un benchmark moyen ne suffit pas : les performances peuvent varier selon les données, le matériel et la façon dont l'application encadre le modèle.
Une méthode de test en cinq étapes
- Définissez une tâche mesurable. Par exemple : extraire un numéro de facture, classer un ticket ou localiser un défaut visible. Évitez les objectifs vagues du type « améliorer l'assistance ».
- Constituez un jeu de données représentatif. Prenez des cas courants, des formats difficiles, les langues utilisées et des exemples ambigus. Gardez les données de test séparées de celles utilisées pour ajuster le modèle.
- Choisissez le modèle selon l'entrée et la sortie. Texte pour un agent, vision pour une image, audio pour la parole, Omni si plusieurs modalités doivent être croisées, modèle d1 si vous voulez une décision structurée.
- Mesurez qualité et ressources en même temps. Suivez les erreurs métier, la latence, la mémoire, le débit et le coût sur le matériel réel. Vérifiez aussi la performance avec la quantification prévue en production.
- Préparez un mécanisme de repli. Les cas incertains doivent pouvoir être revus par une personne, traités par un modèle plus grand ou rejetés. Le seuil de confiance doit être calibré sur vos propres données.
Cette approche évite de confondre « capacité » et « fiabilité ». Un système peut être correct en moyenne et échouer sur une sous-population : un accent, un type de document, une facture rare, une condition d'éclairage peu fréquente. Sur les usages sensibles, la traçabilité des décisions et la capacité à corriger les erreurs doivent être prévues dès le design, pas ajoutées après coup.
Fine-tuning : utile quand les données le justifient
Liquid AI présente LFM3 comme une base faite pour la spécialisation. Dans l'exemple d'inspection visuelle, un ajustement sur quelques milliers d'images améliore le résultat sur une tâche étroite. Mais ça ne veut pas dire qu'un petit jeu de données suffira partout. La qualité des annotations, la diversité des cas et la proximité entre données d'entraînement et données rencontrées ensuite pèsent souvent plus que le volume annoncé.
Avant d'entraîner, comparez trois options : un prompt bien construit, une recherche documentaire avec récupération de contexte, et un fine-tuning. Le fine-tuning sert à modifier le comportement ou à apprendre des régularités propres à une tâche ; ce n'est pas toujours le meilleur moyen de garder une base de connaissances à jour. Et il faut compter avec des coûts de préparation, d'évaluation et de suivi des versions.
Les limites à intégrer au calcul
L'exécution locale peut aider sur la confidentialité et réduire la dépendance réseau, mais elle déplace une partie des contraintes vers l'appareil : mémoire, consommation, mises à jour et compatibilité matérielle. Un contexte très long, par exemple, peut exiger plus de mémoire, même si le modèle lui-même reste « compact ».
Les chiffres de performance fournis par l'éditeur doivent être traités comme des indicateurs à reproduire. Les benchmarks ne reflètent pas toujours les données françaises, les accents, les documents administratifs, ni les conditions d'usage réelles. Et même si les poids sont ouverts, ça ne règle pas tout côté gouvernance : droits d'accès aux données, sécurité, audit des sorties et information des utilisateurs restent à gérer.
Conclusion : choisir un modèle selon la contrainte réelle
LFM3 montre bien que l'IA ne se résume plus à prendre « le plus gros modèle qu'on peut héberger dans le cloud ». Une famille compacte, multimodale et orientée vers des tâches précises peut répondre mieux à un besoin quand la latence, la confidentialité, le coût ou l'exécution locale deviennent des contraintes fortes.
Cela dit, les annonces de performances ne remplacent pas un test sur vos données. Commencez par clarifier la tâche, l'impact concret d'une erreur et votre environnement de déploiement. Ensuite, comparez le modèle de base, un éventuel fine-tuning et vos solutions de repli. C'est comme ça que la promesse d'une IA capable de fonctionner près de l'utilisateur devient un choix d'architecture défendable, pas juste une démonstration technique.