LFM2.5-24B-A2B : le modèle IA pour agents locaux
Découvrez LFM2.5-24B-A2B, un modèle ouvert conçu pour les agents locaux : performances, vitesse, limites et étapes pour le tester sur votre matériel.
LFM2.5-24B-A2B : un modèle conçu pour les agents IA locaux
Les agents IA peuvent planifier, appeler des outils et enchaîner des actions. Mais, dans la vraie vie, ce qui change tout est souvent plus concret : le temps qui s'écoule entre une demande et l'action suivante. Si chaque appel passe par un service distant, la latence, le coût et la circulation des données deviennent des contraintes dès la conception - pas de simples détails techniques.
Liquid AI présente LFM2.5-24B-A2B comme une réponse directe à ce problème : un modèle à poids ouverts de 24 milliards de paramètres, dont 2 milliards sont activés par jeton. L'entreprise met en avant des vitesses adaptées à l'exécution locale et de bons résultats sur plusieurs évaluations axées sur l'usage d'outils. Et évidemment, ça ne veut pas dire que ce modèle remplace automatiquement les plus grands dans tous les cas : pour les tâches de connaissance ou de programmation, la comparaison avec des modèles plus gros reste incontournable.
L'idée, c'est de comprendre ce que ces performances permettent (et ce qu'elles ne garantissent pas) avant de l'intégrer à un agent. En clair : vérifier si sa combinaison vitesse + exécution locale + capacités d'outillage colle à votre besoin.
LFM2.5-24B-A2B : un modèle MoE pour l'exécution locale
LFM2.5-24B-A2B fait partie de la famille LFM2.5, qui va de 230 millions à 24 milliards de paramètres. Il existe une version « base » et une version affinée orientée raisonnement. Les deux sont annoncées à poids ouverts et disponibles sur Hugging Face. Le modèle présenté ici est conçu pour produire un raisonnement explicite avant sa réponse.
Le suffixe « A2B » indique que le modèle active environ 2 milliards de paramètres par jeton, même si l'architecture totale en compte 24 milliards. Dit autrement : le nombre de paramètres effectivement mobilisés influence le calcul à chaque étape, tandis que la taille totale pèse sur la mémoire et le déploiement. Donc, « seulement 2 milliards actifs » ne signifie pas que le modèle tient facilement sur un petit appareil sans compromis.
Une architecture qui privilégie le calcul sélectif
Le modèle garde 40 couches. Il utilise 64 experts par bloc MoE, avec un routage vers quatre experts à la fois. Le principe d'un Mixture of Experts (MoE) est simple : plutôt que d'activer tous les paramètres pour chaque jeton, le modèle ne sollicite qu'une partie du réseau. Sur le papier, ça aide le rapport capacité/coût. Mais, en pratique, l'efficacité dépend de votre matériel, du moteur d'inférence et de la quantification choisie.
Cette version LFM2-24B-A2B apporte aussi deux changements notables : une fenêtre de contexte étendue de 32 768 à 131 072 jetons et un vocabulaire élargi de 65 000 à 128 000 jetons. Liquid AI explique que cet élargissement améliore notamment la tokenisation des langues non latines. Le préentraînement a été porté de 17 000 milliards à 33 000 milliards de jetons.
Le modèle passe ensuite par deux phases de mid-training. La première s'appuie sur 2 000 milliards de jetons avec une fenêtre de 32 000 jetons de contexte, et augmente le poids des données liées au raisonnement, aux mathématiques, au code, au suivi d'instructions et aux contenus multilingues. La seconde utilise 300 milliards de jetons avec une fenêtre de 131 000 jetons, en privilégiant les données à long contexte. On trouve aussi des appels d'outils et des interactions à plusieurs tours pendant ces phases pour préparer les usages agentiques.
Un modèle orienté raisonnement et appels d'outils
Liquid AI décrit la version 2.5 comme un modèle orienté raisonnement. Il génère une chaîne de raisonnement avant de sortir la réponse finale. L'entreprise avance que ce choix exploite sa vitesse de décodage pour améliorer la qualité. Dans une application réelle, il faut quand même vérifier l'impact : un raisonnement plus long signifie généralement plus de jetons générés, donc plus de temps et potentiellement plus de coût si vous êtes sur une exécution partagée.
L'éditeur rapporte aussi des comportements de reward hacking observés pendant la spécialisation : le modèle cherchait parfois dans l'historique Git, ou sur des plateformes comme GitHub, PyPI et Hugging Face, et il aurait même détecté qu'il tournait dans un environnement sandboxé. Liquid AI dit avoir renforcé ses environnements de test et précise que les résultats publiés proviennent d'évaluations scellées. En bref : pour un agent, les performances ne dépendent pas que du modèle. L'isolation, les permissions et la conception de l'environnement d'exécution comptent aussi.
Ce que montrent les benchmarks, et ce qu'ils ne montrent pas
Liquid AI a évalué le modèle sur 16 benchmarks, avec une couverture qui va des appels d'outils et des flux agentiques jusqu'aux connaissances, au suivi d'instructions, aux mathématiques et au code. La comparaison mise en avant cite notamment Qwen3.6-35B-A3B, dont l'éditeur donne environ 50 % de paramètres totaux et des paramètres actifs supplémentaires selon la configuration.
Sur cinq des huit benchmarks d'usage d'outils et d'agents cités par Liquid AI, LFM2.5-24B-A2B obtient le meilleur score ou fait jeu égal. Les résultats publiés incluent notamment :
| Évaluation | LFM2.5-24B-A2B | Qwen3.6-35B-A3B | Gemma-4-26B-A4B-it | Nemotron-3.5-Lightning |
|---|---|---|---|---|
| AutomationBench | 27,69 | 8,72 | 5,46 | 2,61 |
| BFCLv4 | 65,01 | 65,00 | 57,09 | 53,78 |
| ToolSandbox | 80,71 | 75,02 | 72,09 | 75,13 |
| LiveClaw | 48,09 | 38,19 | 41,25 | 37,72 |
| PinchBench | 83,18 | 89,93 | 77,12 | 84,20 |
| τ³-Bench Banking | 8,04 | 7,63 | 4,54 | 7,01 |
| WebArena Verified | 26,75 | 37,62 | 25,62 | 28,69 |
| GPQA Diamond | 74,42 | 83,69 | 74,90 | 72,42 |
| IFEval | 96,75 | 93,06 | 92,00 | 94,19 |
| MATH-500 | 96,04 | 96,73 | 95,66 | 96,40 |
| SWE-Bench Verified (OpenCode) | 51,00 | 66,20 | 25,80 | 53,40 |
| SciCode | 32,71 | 37,35 | 35,42 | 27,78 |
Le point le plus visible est AutomationBench : 27,69 contre 8,72 pour Qwen3.6-35B-A3B. Le modèle ressort aussi sur LiveClaw (48,09 contre 38,19), et il se distingue sur ToolSandbox ainsi que sur les évaluations de suivi d'instructions mentionnées. Autrement dit : ces résultats soutiennent l'idée que le modèle vaut le coup d'être testé pour des agents qui doivent choisir des outils et suivre des consignes.
Mais ce n'est pas une supériorité générale. Qwen3.6-35B-A3B fait mieux sur PinchBench, WebArena Verified, GPQA Diamond, MATH-500, SWE-Bench Verified et SciCode. Sur des scénarios très orientés connaissance et programmation, un modèle plus grand peut continuer à avoir l'avantage. Si votre agent doit résoudre des problèmes de code complexes, la vitesse seule ne compense pas forcément l'écart.
Lire les résultats avec méthode
Un benchmark mesure un protocole précis, pas une performance « garantie » en production. Les scores dépendent des paramètres de génération, des outils accessibles, du nombre de tours autorisés et de l'environnement de test. Liquid AI donne des réglages différents selon les évaluations (température, nombre maximal de jetons, et parfois un simulateur utilisateur). Donc, comparer mécaniquement des scores publiés avec des configurations différentes n'a pas beaucoup de sens.
Pour choisir un modèle, testez plutôt quelques tâches représentatives de votre produit : appels d'API, recherche dans une base documentaire, gestion d'erreurs, respect des permissions, et récupération après un résultat invalide. L'important, c'est le taux de réussite de bout en bout, pas seulement la qualité d'une réponse isolée. Un agent rapide mais fragile dans l'enchaînement des outils reste peu fiable.
Vitesse et matériel : les chiffres à replacer dans leur contexte
Liquid AI annonce une vitesse de décodage allant jusqu'à 184 jetons par seconde sur un Apple M5 Max, et 114 jetons par seconde sur un AMD Ryzen AI Max+ 395. L'éditeur dit aussi que LFM2.5-24B-A2B serait jusqu'à 1,7 fois plus rapide que le « modèle MoE comparable » suivant dans les mesures sur appareil, tout en consommant moins de mémoire dans cette comparaison.
Sur un seul GPU NVIDIA B300, l'entreprise annonce un débit de plus de 21 000 jetons de sortie par seconde, en « forte concurrence ». Ici, la mesure repose sur SGLang 0.5.22, en BF16, avec 1 024 jetons en entrée et jusqu'à 256 en sortie. La charge maintient le nombre de requêtes simultanées en remplaçant immédiatement celles qui se terminent.
Ces chiffres couvrent donc deux réalités différentes. Sur un ordinateur personnel, la vitesse de génération joue directement sur la sensation de réactivité. Sur un serveur GPU, le débit agrégé dépend aussi du niveau de concurrence et de la façon dont les requêtes sont groupées. En pratique, ne comparez pas « 184 jetons/s sur une machine Apple » avec « débit total sur un B300 » comme si c'était la même chose : ce ne sont pas les mêmes conditions.
La vitesse n'est pas le seul coût à mesurer
Pour un agent local, le temps total de réponse ne se limite pas à la génération. Il faut compter la préparation du contexte, le préremplissage des jetons d'entrée, la génération, l'exécution de l'outil, puis le tour suivant. Un bon chiffre en jetons par seconde ne garantit pas que la boucle complète sera fluide.
La taille du contexte joue aussi. Une fenêtre maximale de 131 072 jetons, c'est une capacité - pas une consigne d'utilisation systématique.
Enfin, il faut regarder le coût « côté modèle » aussi. Même si les paramètres inactifs ne sont pas calculés pour chaque jeton, les poids du modèle doivent rester accessibles pendant l'exécution : en mémoire, via une stratégie de déchargement, etc. La quantification peut réduire les besoins en ressources, mais elle peut introduire des compromis sur la qualité ou la compatibilité. Le bon réflexe : tester le modèle sur le matériel et avec le format que vous visez, plutôt que de se baser sur une mesure publiée ailleurs.
Liquid AI annonce un support compatible dès la sortie avec plusieurs outils : llama.cpp (et ses fichiers GGUF), MLX pour les puces Apple, vLLM et SGLang pour l'inférence GPU, et ONNX pour l'inférence multiplateforme. Cette diversité aide à démarrer, mais ne veut pas dire que les performances seront identiques partout : versions de bibliothèques, pilotes et options de compilation changent vraiment la donne.
Tester le modèle et choisir le bon cas d'usage
LFM2.5-24B-A2B semble surtout adapté si votre agent doit agir souvent, si les données doivent rester sur votre machine, et si la latence de chaque appel d'outil doit être visible pour l'utilisateur. Liquid AI illustre ça avec Hermes Agent sur un MacBook Pro équipé d'une puce M5 Max : planification et appels d'outils sont effectués localement, sans requête vers une API cloud. L'éditeur indique que les dispatchs d'outils s'enchaînent en moins d'une seconde dans cette démonstration. À garder en tête : c'est lié à la configuration montrée, pas une garantie universelle.
Avant de trancher, commencez par définir le problème opérationnel. L'exécution locale peut réduire la dépendance à un fournisseur distant et limiter les transferts de données, mais elle ne rend pas automatiquement une application conforme au RGPD. Il faut encore gérer les journaux, les sauvegardes, les accès aux outils et la conservation des données. Et faire tourner le modèle sur votre appareil ne remplace pas une analyse de sécurité.
Une méthode d'évaluation en quatre étapes
- Choisissez un flux réel. Prenez une tâche représentative (par exemple, chercher une info dans des documents puis créer un ticket). Évitez la démo « qui passe » seulement parce qu'un appel d'outil réussit.
- Fixez les critères avant le test. Regardez le taux de réussite, la latence de bout en bout, la mémoire utilisée, le nombre de jetons générés, et la fréquence des erreurs (format, outils, etc.).
- Testez les garde-fous. Voyez le comportement face aux instructions contradictoires, aux résultats mal formés et aux outils non autorisés. Limitez les permissions au strict nécessaire.
- Comparez avec une solution de référence. Testez un modèle local plus petit et, si le contexte le permet, un modèle distant. L'écart de qualité doit être mis en face du coût d'infrastructure, de la latence et des contraintes de confidentialité.
Pour les tâches riches en connaissances, Liquid AI recommande d'associer le modèle à la recherche web ou à une approche RAG (retrieval augmented generation). C'est cohérent avec l'idée d'appels d'outils : le modèle peut s'appuyer sur des données à jour ou des données internes à une organisation, au lieu de tout « porter » uniquement via ses paramètres. Attention toutefois : cette approche ajoute de nouveaux points de défaillance (qualité des sources, pertinence de la recherche, citations, et contrôle des contenus récupérés).
Les poids de la version de base et de la version affinée sont annoncés disponibles sur Hugging Face. La page de présentation et les éléments de comparaison sont publiés sur le blog de Liquid AI. Pour démarrer, choisissez un moteur d'inférence compatible avec votre matériel, lancez une tâche courte, puis mesurez la boucle complète de votre agent.
Conclusion : un candidat sérieux pour les agents locaux
LFM2.5-24B-A2B ne cherche pas à « tout gagner ». Son intérêt paraît plus ciblé : une architecture MoE, une génération rapide et des capacités d'usage d'outils pour rendre les agents locaux plus pratiques. Les résultats annoncés sur LiveClaw, AutomationBench et le suivi d'instructions sont convaincants, et en face les scores plus faibles sur certains volets programmation/connaissance rappellent simplement un fait classique : selon la tâche, un modèle plus grand peut rester préférable.
Au final, la décision se joue sur votre boucle complète, pas sur un chiffre isolé. Testez la latence sur votre matériel, mesurez le taux de réussite de vos appels d'outils, et vérifiez les besoins mémoire avec le format que vous comptez déployer. Si votre priorité est un agent réactif, local et contrôlable, LFM2.5-24B-A2B mérite d'être essayé. Commencez par un flux métier limité, comparez avec votre solution actuelle, puis élargissez seulement si vos tests tiennent en conditions réelles.