LFM3-1.7B vs Granite 4.2 30B : deux modèles d'agents dont le verdict diffère selon l'axe

Placez LFM3-1.7B et Granite 4.2 30B sur la même page et les moyennes agrégées pointent dans des directions opposées selon la ligne que vous lisez. Sur le Berkeley Function Calling Leaderboard V4, le modèle de 1,73 milliard de paramètres de Liquid AI obtient 71,39 contre 61,39 pour IBM — une victoire de dix points pour un modèle environ dix-sept fois plus petit. Sur SWE-bench Verified, Granite obtient 57,00 contre 43,40 pour LFM3-1.7B, une victoire de 13,6 points dans l'autre direction.Le routage n'ajoute pas de marge au prix catalogue d'un fournisseur. Les prix catalogue des fournisseurs sont répercutés à 0 % de marge.

Les deux modèles sont conçus pour les agents, tous deux ont été publiés à moins de deux mois d’intervalle en 2026, et les deux fournisseurs publient suffisamment de benchmarks qui se chevauchent pour qu’une véritable comparaison soit possible plutôt qu’un collage. Cela en fait une confrontation rare où la question intéressante n’est pas de savoir quel modèle est meilleur, mais sur quel axe se situe réellement votre charge de travail. Très peu de tâches nécessitent à la fois un score BFCL de 71 et un score SWE-bench de 57, et celles qui en ont besoin ne sont bien servies par aucun des deux modèles pris isolément.

Les deux nombres qui se croisent

Granite 4.2 30B est sorti le 25 août 2026 sous licence Apache 2.0, un modèle dense d'environ 30B construit sur la base Granite 4.1 30B et entraîné sur environ 15 000 milliards de tokens. Le positionnement d'IBM est celui de l'entreprise : trois modes de réflexion configurables, un appel natif d'outils conforme au schéma OpenAI, douze langues testées, et un pipeline d'entraînement en trois étapes se terminant par un apprentissage par renforcement GRPO en plusieurs phases.

LFM3-1.7B est arrivé deux mois plus tard, annoncé le 27 octobre 2026, post-entraîné spécifiquement sur des harnais agentiques — Liquid cite Hermes Agent, PI et OpenClaw dans la fiche du modèle. Il s'agit d'un modèle dense de 1,73 B avec un contexte de 256 K, explicitement positionné pour les agents locaux et l'appel d'outils plutôt que pour le raisonnement général.

Le croisement des benchmarks n’est pas le fruit d’un seul chiffre faible. Toute la table publiée de LFM3-1.7B penche du côté agentique : 71,39 BFCL V4, 80,36 ToolSandbox, 68,01 τ³-bench, 45,60 LiveClaw, 38,42 WebArena-Verified. Celle de Granite penche du côté ingénierie : 57,00 SWE-bench Verified, 33,29 SWE-bench Pro, 41,89 SWE-bench Multilingual, 38,76 SciCode, 29,24 sur TerminalBench 2.1. Chaque fournisseur a optimisé pour une définition différente de « agent », et les tables de benchmarks sont honnêtes sur la définition retenue.

τ³ à 68,01 contre 68,05, voilà le vrai titre

Sous les deux écarts spectaculaires se cache une égalité parfaite. Sur τ³-bench, l’évaluation de l’utilisation d’outils qui mesure l’achèvement de tâches multi-tours avec des simulateurs d’utilisateurs et des politiques de domaine, LFM3-1.7B obtient 68,01 et Granite 4.2 30B obtient 68,05 — une différence de quatre centièmes de point, indiscernable du bruit.

C'est un résultat plus intéressant que chacun des deux grands écarts, car τ³ est le benchmark le plus proche de ce que font réellement la plupart des déploiements d’agents : tenir une conversation, suivre une politique, appeler la bonne fonction, se remettre d’une erreur. Si un modèle de 1,73B fait jeu égal avec un modèle dense de 30B sur ce point, le nombre de paramètres achète autre chose qu’une utilisation compétente des outils sur plusieurs tours.

Ce que cela apporte se voit dans BFCL et SWE-bench, qui mesurent des choses différentes. BFCL V4 évalue l’exactitude des appels de fonction à tour unique par rapport à un schéma — le 71,39 de LFM3-1.7B suggère que le post-entraînement de Liquid sur de véritables harnais d’agents a directement porté ses fruits. SWE-bench Verified évalue la réparation de bout en bout d’un véritable problème GitHub, ce qui exige de garder un dépôt dans le contexte, de planifier à travers les fichiers et de produire un correctif qui passe les tests — le 57,00 de Granite reflète un modèle doté de cette capacité et un jeu d’entraînement conçu pour cela.

Ainsi, la répartition est lisible. Petit modèle, bien entraîné sur les schémas d’outils : remporte le test d’appel de fonction. Grand modèle, entraîné à la réparation de code : remporte le test du dépôt. Égalité sur le terrain intermédiaire multi-tour où les deux ont été spécifiquement entraînés.

Le contexte est le point où les spécifications divergent le plus fortement.

• Contexte — 262 144 tokens pour LFM3-1.7B ; 128K natif pour Granite 4.2 30B, extensible à 512K. L'extension n'est pas gratuite, et IBM reconnaît honnêtement qu'il s'agit d'une extension plutôt que d'une fenêtre native.

• Rétention sur contexte long — 65,56 sur RULER à 128K pour LFM3-1.7B, contre 81,4 pour Granite 4.2 30B sur la même famille de benchmarks. Le modèle plus grand retient davantage d'un document long, ce qui est l'inverse de ce que suggèrent les chiffres de contexte mis en avant.

• Empreinte — environ 1 Go en 4 bits contre environ 30 B de poids BF16, avec des builds officiels FP8, NVFP4 et MXFP4. Il s'agit d'un modèle mono-GPU, et non d'un modèle pour portable.

• Langues — seize pour LFM3-1.7B contre douze testées pour Granite, avec un chevauchement différent. Les douze de Granite incluent le tchèque et le néerlandais ; celles de Liquid incluent le thaï, le vietnamien et l'indonésien.

• Modes de réflexion — Granite 4.2 30B propose des modes complet, à faible effort et sans réflexion. LFM3-1.7B ne dispose pas d'une telle option, et sa fiche indique qu'il n'est pas destiné au raisonnement complexe en plusieurs étapes.

• Licence — Apache 2.0 pour Granite face à la LFM Open License v1.0, gratuite en dessous de 10 millions de dollars de chiffre d'affaires annuel et nécessitant une licence commerciale au-delà.

Quels coûts un 30B dense présente-t-il qu’un 1.73B ne présente pas ?

Granite 4.2 30B est dense, ce qui signifie que ses trente milliards de paramètres sont tous sollicités à chaque token. Aucune réduction liée aux paramètres actifs ici : le coût de calcul par token est environ dix-sept fois celui du petit modèle, et le coût mémoire correspond au fichier de poids complet. IBM fournit des quantifications pour rendre cela exploitable, mais il n’existe aucune configuration dans laquelle il tourne sur un téléphone.

L’avantage de LFM3-1.7B ne réside pas avant tout dans sa vitesse. Il tient au fait que le modèle s’inscrit dans le même budget mémoire que le reste de votre application. Un modèle de 1 Go laisse de la place pour un stockage de documents, un cache et un second modèle sur le même appareil — ce qui rend un agent local possible, et non simplement théoriquement local. Liquid rapporte un décodage de 1,8 à 2,8 fois plus rapide que ses prédécesseurs sur le matériel testé, ainsi qu’un cache KV de 1,6 Go à 128K, deux éléments qui comptent pour un agent embarqué tenant une longue conversation.

En contrepartie, la capacité de 30B de Granite joue un rôle concret dans les chiffres SWE-bench. Si la tâche de votre agent consiste à modifier du code dans un dépôt, l’écart de 13,6 points n’est pas quelque chose qu’un modèle plus petit rattrape par le prompting, et les économies de calcul se paient par un moins bon résultat.

Licences, signature et la question des achats

Apache 2.0 est la raison pour laquelle une grande organisation peut adopter Granite 4.2 30B sans revue juridique. Il n'y a pas de seuil de chiffre d'affaires, pas de déclencheur commercial, pas de négociation. IBM signe également cryptographiquement les modèles Granite publiés depuis avril 2026, ce qui ressemble à un détail jusqu'au moment où c'est vous qui devez prouver que les poids en production sont bien ceux qui ont été validés.

La Liquid's LFM Open License v1.0 est véritablement permissive à l’échelle d’une startup — gratuite pour un usage commercial en dessous de 10 millions de dollars de chiffre d’affaires annuel — mais au-delà de ce seuil, elle exige une licence commerciale payante. Pour un développeur individuel ou une petite équipe, ce n’est pas un problème. Pour une unité commerciale au sein d’une entreprise plus grande, c’est une conversation qui commence avant le premier déploiement et qui peut ne pas se terminer rapidement. Cette asymétrie n’est reflétée dans aucun benchmark et tranche souvent la question à elle seule.

Faire tourner les deux sans parier sur l’un ou l’autre

Pour une équipe qui évalue ces deux modèles, la démarche pratique n’est pas d’en choisir un d’abord. Les deux sont à poids ouverts et aucun n’a été validé par des évaluateurs indépendants, ce qui signifie que le seul benchmark qui compte est le vôtre. Faites passer les modèles candidats par un point de terminaison unique, exécutez les mêmes traces d’agent sur les deux, et comparez sur votre tâche plutôt que sur BFCL ou SWE-bench.

OrcaRouter est utile ici moins comme hébergeur que comme surface de contrôle : une seule clé et une seule facture pour plus de 200 modèles, les prix catalogue des fournisseurs répercutés avec 0 % de marge, et un basculement automatique pour qu'une exécution d'évaluation ne meure pas parce qu'un fournisseur a connu une heure difficile. Ni LFM3-1.7B ni Granite 4.2 30B ne figurent aujourd'hui dans notre catalogue — les deux sont des téléchargements à poids ouverts, et l'auto-hébergement est la voie pour chacun. Là où le routage gagne sa place, c'est dans la pile qui l'entoure : le modèle de pointe vers lequel votre agent escalade, ou le second avis auquel vous vous comparez lorsque le correctif du modèle local échoue à ses tests.

Qui devrait prendre lequel

Prenez LFM3-1.7B si l'agent s'exécute sur l'appareil de l'utilisateur, si le travail consiste en appels d'outils et en extraction structurée contre une API, et si un contexte de 256K avec une empreinte de 1 Go est ce qui rend le produit possible. Acceptez l'avertissement du fournisseur lui-même selon lequel il n'est pas destiné au codage agentique, et gardez un modèle plus grand derrière lui pour les cas qui en ont besoin.

Choisissez Granite 4.2 30B si l'agent touche à une base de code, si vous avez besoin d'Apache 2.0 et de poids signés pour vos achats, si la charge de travail bénéficie d'un effort de réflexion configurable, et si vous disposez d'un GPU pour le servir. Le déficit BFCL est réel mais étroit : il mesure l'exactitude du schéma sur un seul appel, et un modèle 30B doté d'un schéma d'outils bien conçu comble une grande partie de cet écart en pratique.

Choisissez la répartition si vous construisez ce que les deux fournisseurs visent — un agent local qui gère les appels d'outils de routine dans un gigaoctet et délègue à un serveur le travail à l'échelle du dépôt. Cette architecture emploie chaque modèle là où son propre tableau de benchmarks indique qu'il est fort, et c'est le seul agencement dans lequel les axes croisés cessent de poser problème.

La question à surveiller est de savoir si la recette d’entraînement postérieur agentique de Liquid se transpose à un point de contrôle plus grand. Si un futur modèle LFM conserve le comportement BFCL de classe 71,39 et ajoute de la capacité pour le travail sur les dépôts, la séparation selon l’axe s’effondre et cette comparaison devient une simple décision de taille. D’ici là, les deux modèles ne sont pas en concurrence pour le même poste — ils sont les deux moitiés d’un même tout.