Les grands modèles attirent l’attention par leurs capacités générales. D’autres projets cherchent à faire fonctionner une IA plus près de l’appareil et d’un besoin précis. Liquid AI a présenté LFM3 le 27 octobre 2026, une famille compacte couvrant plusieurs types d’entrées. L’annonce intéresse les développeurs qui veulent adapter un modèle à une application plutôt que dépendre systématiquement d’un service distant généraliste.
Le mot « compact » mérite toutefois une lecture technique. La taille des poids du modèle ne décrit pas, à elle seule, toute la mémoire nécessaire ni la qualité obtenue sur un usage particulier.
Une famille spécialisée, autour de deux milliards de paramètres
Dans sa présentation de LFM3, Liquid AI annonce six modèles de l’ordre de deux milliards de paramètres, couvrant notamment le texte, la vision, l’audio et des usages de décision. Les poids sont disponibles, avec des conditions de licence à examiner selon le projet.
Le modèle texte LFM3-1.7B est annoncé avec un contexte de 256 000 tokens et des poids occupant environ 1 Go en précision 4 bits. Ce chiffre ne représente pas toute la mémoire de fonctionnement : le moteur d’exécution, le contexte et les autres composants de l’application s’ajoutent. Les comparaisons publiées par le fournisseur doivent être distinguées d’une validation sur ses propres tâches.
Choisir une tâche avant de choisir un score
Un modèle peut être intéressant pour classer des documents courts et moins adapté à une analyse complexe de plusieurs dossiers. La bonne évaluation commence par des exemples représentatifs du travail réel, avec une définition de ce qui constitue une réponse acceptable.
Il faut inclure les cas faciles, les ambiguïtés et les demandes auxquelles le système devrait refuser de répondre faute d’information. Un outil qui remplit toujours une case peut sembler efficace tout en cachant ses erreurs. La capacité à signaler une incertitude compte autant que la fluidité du texte produit.
Pour une application spécialisée, la stabilité du format peut également avoir beaucoup de valeur. Une réponse correcte mais difficile à exploiter automatiquement peut demander une étape supplémentaire. Les essais doivent donc couvrir la chaîne complète, depuis l’entrée jusqu’à l’action ou au document final attendu.
Le fonctionnement local ne garantit pas tout
Exécuter un modèle sur son matériel peut limiter certains transferts de données. Cela ne rend pas automatiquement toute l’application hors ligne ou confidentielle. Des outils connectés, des journaux externes ou des fonctions de recherche peuvent continuer à communiquer avec d’autres services.
L’architecture doit donc être examinée dans son ensemble. Quelles données entrent ? Où sont-elles conservées ? Quels outils peuvent être appelés ? Qui accède aux résultats ? Ces questions restent nécessaires même lorsque le calcul principal se déroule sur un appareil de l’organisation.
La maintenance ne disparaît pas non plus. Il faut suivre les versions, corriger les dépendances et tester les évolutions avant de les généraliser. Un modèle local peut donner davantage de maîtrise, à condition de prévoir les moyens de l’exercer dans la durée.
Le matériel se teste dans les conditions prévues
Une démonstration avec une demande courte ne suffit pas à prévoir l’usage avec de longs documents ou plusieurs utilisateurs. La mémoire, le délai avant la première réponse et la vitesse de traitement peuvent changer selon le contexte fourni et le moteur utilisé.
Notre article sur les ressources des PC portables dédiés à l’IA rappelle qu’une fiche mémoire ne raconte pas tout. Il faut regarder la charge complète et le confort obtenu pendant les autres tâches de l’utilisateur. Un assistant rapide seul peut devenir gênant s’il monopolise une machine de travail.
Pour un premier essai, mieux vaut conserver une configuration simple et mesurer quelques tâches typiques. Noter le matériel, la précision utilisée et la taille des entrées permet ensuite de comparer les résultats sans mélanger des conditions différentes.
Une alternative à évaluer sans promesse universelle
LFM3 illustre une tendance utile : chercher une IA adaptée au lieu et à la tâche, plutôt qu’augmenter systématiquement la taille du modèle. Cette approche peut ouvrir des possibilités pour des applications ciblées et des contraintes matérielles précises.
La décision doit néanmoins reposer sur des essais locaux, des conditions de licence comprises et un plan d’exploitation réaliste. Le modèle le plus pertinent n’est pas forcément celui qui gagne le plus de comparaisons publiques. C’est celui qui réalise le travail attendu avec un niveau d’erreur, un délai et un coût que l’équipe sait accepter et surveiller.
Je suis Romain Delcourt, rédacteur tech passionné par le numérique et l’intelligence artificielle. J’écris pour décoder les tendances, les outils et les changements qui façonnent nos usages au quotidien.
