Liquid AI présente LFM2.5-2.6B, un modèle de 2,6 milliards de paramètres orienté tool calling et workflows agentiques, conçu pour fonctionner sur CPU, GPU et appareils locaux.
Faire tourner un agent IA sans envoyer chaque requête vers une API cloud reste difficile : il faut un modèle assez petit pour tenir en mémoire, assez rapide sur du matériel courant et suffisamment fiable pour appeler des outils en plusieurs étapes. Liquid AI affirme répondre à ce compromis avec LFM2.5-2.6B, un modèle de 2,6 milliards de paramètres conçu dès le départ pour l’exécution locale et les workflows agentiques.
Selon l’annonce publiée sur Hugging Face, le modèle cible aussi bien les laptops que les téléphones, avec une prise en charge du tool calling, des séquences d’actions et de plusieurs moteurs d’inférence. La promesse est pragmatique : garder les données sur l’appareil et éviter une facture d’inférence proportionnelle au volume d’usage. Il faut toutefois lire les performances publiées comme des résultats communiqués par l’éditeur, dans son propre protocole d’évaluation.
LFM2.5-2.6B vise les agents locaux qui doivent suivre des instructions et utiliser des outils. Les chiffres annoncés sont solides pour cette taille de modèle, mais ils ne remplacent pas un test sur tes outils, tes prompts et tes contraintes de sécurité.
Un modèle de 2,6 milliards de paramètres pensé pour agir localement
Le positionnement de LFM2.5-2.6B n’est pas celui d’un modèle généraliste géant. Liquid AI le présente comme une brique destinée aux applications où l’agent doit exécuter des actions : interroger une base locale, déclencher une fonction, remplir un formulaire, lancer une recherche ou coordonner plusieurs appels d’outils.
Le gain recherché est double. D’abord, l’exécution sur l’appareil limite l’exposition des données : une application traitant des notes, documents internes ou données client peut réduire les transferts vers un service tiers. Ensuite, un modèle local supprime le coût marginal d’une API pour chaque token généré, même s’il reste évidemment des coûts matériels, d’intégration et de maintenance.
Liquid AI annonce une consommation mémoire inférieure à 2,5 Go, sans préciser dans l’extrait fourni le format de poids, le niveau de quantification ni le protocole exact associé à cette mesure. C’est donc un ordre de grandeur utile pour évaluer la cible matérielle, pas une garantie de mémoire pour toutes les configurations. Le contexte du modèle peut atteindre 128 000 tokens après une phase d’entraînement intermédiaire, d’après l’éditeur.
Un entraînement centré sur les harnais agentiques et le tool calling
La méthode revendiquée explique largement ce positionnement. Liquid AI indique que le modèle a été pré-entraîné sur environ 34 000 milliards de tokens, avant un post-entraînement en quatre étapes. Deux phases de supervised fine-tuning accordent une place importante aux données agentiques : utilisation d’outils, recherche web et trajectoires issues de harnais d’agents.
L’entreprise décrit ensuite un système d’enseignants spécialisés par domaine, notamment les mathématiques, le code et l’usage d’outils. Ces enseignants sont distillés dans un modèle unique via une phase appelée multi-domain on-policy distillation. Enfin, une étape d’apprentissage par renforcement agentique place le modèle dans de véritables environnements multi-tours.
Dans cette dernière phase, l’architecture sépare l’optimisation du modèle, la génération des actions et l’exécution dans l’environnement. Le point intéressant pour les développeurs est la compatibilité revendiquée avec des harnais traités comme des boîtes noires. Liquid AI cite notamment OpenClaw et Hermes Agent. Un proxy capture les trajectoires au niveau des tokens sans exiger de modification du harnais, selon la description de l’entreprise.
Cette approche ne garantit pas qu’un agent sera fiable en production. Elle indique en revanche que le modèle a été entraîné dans des conditions plus proches d’un agent réel qu’un simple dialogue question-réponse. Pour une intégration, il faudra toujours encadrer les permissions, valider les arguments des outils et prévoir des mécanismes de confirmation pour les actions sensibles.
Des benchmarks favorables, avec une faiblesse déclarée en code
Liquid AI compare LFM2.5-2.6B à des modèles allant jusqu’à 9,7 milliards de paramètres : Gemma-4-E2B-it, Gemma-4-E4B-it, Qwen3.5-4B et Qwen3.5-9B. Dans le tableau publié, LFM2.5-2.6B arrive en tête sur les mesures d’instruction following présentées, dont IFBench, Multi-IF et IFStruct. Il obtient aussi les meilleurs scores affichés sur ToolSandbox et BrowseComp+ avec OpenClaw.
Sur BFCLv4, benchmark d’appel de fonctions, le Qwen3.5-9B est devant avec 60,13, contre 56,88 pour LFM2.5-2.6B. Le modèle de Liquid AI reste également derrière les modèles plus grands sur LiveCodeBenchv6 : 59,41, contre 69,86 pour Qwen3.5-9B. La source reconnaît explicitement que le code est le domaine où les modèles de taille supérieure conservent une avance nette.
C’est une limite à prendre au sérieux. Si ton produit doit produire, corriger ou raisonner longuement sur du code complexe, ce modèle n’est pas nécessairement le meilleur choix de la sélection. En revanche, pour un assistant qui suit des procédures strictes, appelle des fonctions définies et enchaîne des tâches courtes, son ratio taille/capacités paraît être son argument principal.
220 tokens par seconde sur M5 Max : ce que disent les chiffres d’inférence
L’éditeur annonce des vitesses de décodage de 220 tokens par seconde sur Apple M5 Max et de 113 tokens par seconde sur AMD Ryzen AI Max+ 395. Il avance également qu’à 30 tokens par seconde, l’usage d’agents capables devient envisageable sur téléphone. Ces résultats dépendent nécessairement du matériel, du backend, du format du modèle, de la longueur du contexte et de la charge applicative ; la source ne détaille pas ici l’ensemble des paramètres de test.
Côté GPU et forte concurrence, Liquid AI annonce près de 15 000 tokens de sortie par seconde, soit environ 1,3 milliard de tokens quotidiens sur une H100. Pour une équipe qui auto-héberge, ce chiffre suggère une bonne densité de service. Pour un usage individuel ou embarqué, les résultats CPU sont plus parlants : ils évitent de faire du GPU une condition obligatoire.
LFM2.5-2.6B est annoncé compatible dès sa sortie avec llama.cpp, MLX, vLLM, SGLang et ONNX. Cette couverture compte autant que les scores : elle ouvre des options différentes selon que tu déploies une application native, un serveur local, une démo navigateur ou une infrastructure à concurrence élevée.
Comment l’évaluer sans confondre démo et déploiement
Le modèle et sa variante Base sont disponibles sur Hugging Face. La source propose aussi une démo WebGPU dans le navigateur et un exemple Python basé sur transformers version 5.0.0 ou supérieure. Avant d’en faire une dépendance produit, commence par un test ciblé sur quelques dizaines de scénarios réels.
- Définis 3 à 5 outils aux schémas simples et vérifie que les arguments générés sont exploitables.
- Mesure le taux de réussite sur des tâches multi-étapes, pas seulement sur une question isolée.
- Teste la latence avec ton contexte réel, notamment si tu exploites de longs documents.
- Ajoute une couche de validation côté application : liste blanche d’outils, contrôle des paramètres et journalisation.
- Compare le coût complet avec une API distante : matériel, énergie, observabilité et temps d’exploitation compris.
Le bon cas d’usage n’est pas « remplacer n’importe quel grand modèle ». C’est construire un agent local, rapide et contrôlable, dont les tâches sont bien définies et les outils correctement bornés. Sur ce terrain, LFM2.5-2.6B mérite un essai ; pour des besoins de code exigeants, les résultats publiés invitent plutôt à conserver une option de modèle plus grand.