ARTEMIS vs LFM2.5-2.6B-Base : le checkpoint qui ne peut pas faire le travail, et le harnais qui a besoin qu’il le fasse

Quatre éléments figurent sur la feuille de route ARTEMIS de Google, et un seul d’entre eux exige un modèle qui n’existe manifestement pas encore : des modèles vision-langage légers embarqués, pour une automatisation à faible latence où la confidentialité prime. Le candidat évident pour un tel rôle est un modèle de la classe de taille de LFM2.5-2.6B-Base — le checkpoint pré-entraîné de 2,69 milliards de paramètres de Liquid AI, publié sous forme de poids ouverts avec un contexte de 131 072 tokens et une empreinte suffisamment petite pour un téléphone. Il est aussi, tel qu’il est livré, incapable d’occuper ce créneau, et les raisons de cela méritent d’être comprises avant que quiconque ne les place dans un tableau comparatif. ARTEMIS de Google est un harnais d’automatisation Android en langage naturel, publié en open source sous Apache 2.0 en août 2026, qui pilote un véritable téléphone via ADB et revendique un taux d’achèvement de plus de 99 % sur le benchmark AndroidWorld de Google Research. LFM2.5-2.6B-Base est une matière brute pré-entraînée, sans affinage sur instructions, sans template de chat et — délibérément — sans benchmarks publiés, destinée aux équipes qui le post-entraîneront elles-mêmes. L’un est un logiciel fini avec un problème de modèle non résolu. L’autre est des poids inachevés avec un problème de licence résolu. Ni l’un ni l’autre n’est un substitut à l’autre, et le point où ils se rejoignent vraiment n’est pas celui que vous devineriez.

Ce qu'est réellement LFM2.5-2.6B-Base

Retirez le branding et il reste une fondation soigneusement construite pour le travail en local, avec des spécifications qui se lisent comme si quelqu'un avait optimisé pour la bande passante mémoire plutôt que pour la position dans les classements.

• Taille — 2,69 Md de paramètres en bfloat16 dans un seul shard d'environ 5,39 Go, présenté comme « 2,6 Md ».

• Architecture — 30 couches dans une répartition hybride : 22 blocs de convolution courte à double porte sur 8 couches d'attention à requêtes groupées, largeur cachée 2048, 32 têtes d'attention contre 8 têtes KV, embeddings liés. Même code>Lfm2ForCausalLM/code> classe que la génération précédente, donc aucun code de modélisation personnalisé n'est requis.

• Entraînement — environ 34 000 milliards de tokens, avec une phase d’entraînement intermédiaire dédiée à l’extension du contexte.

• Vocabulaire — 128 000 tokens, doublé cette génération pour mieux gérer les écritures non latines. Environ 262 M de paramètres, soit environ un dixième du modèle, se trouvent dans l’embedding lié.

• Contexte — la fiche du modèle et la configuration ne concordent pas ici, et il vaut la peine de le savoir : la documentation annonce 131 072 jetons tandis que code>config.json/code> définit code>max_position_embeddings/code> à 128 000. Prévoyez 128 K et considérez tout ce qui dépasse comme non vérifié.

• Langues — seize : anglais, arabe, chinois, français, allemand, hindi, indonésien, italien, japonais, coréen, polonais, portugais, russe, espagnol, thaï, vietnamien.

• Benchmarks — aucun. Liquid ne publie aucune évaluation pour le checkpoint de base, et la fiche du modèle présente cette omission comme intentionnelle : cet artefact existe pour être post-entraîné, et non pour être mesuré dans son état brut.

Cette dernière ligne est tout l'intérêt de la publication, et c'est aussi la raison pour laquelle une « X vs LFM2.5-2.6B-Base » comparaison doit être traitée avec prudence. Un point de contrôle de base n'a d'avis sur rien. Demandez-lui de planifier un flux de travail Android et il poursuivra votre texte de manière probabiliste, car on ne lui a jamais appris à répondre. La fiche ne le recommande que pour les cas qui exigent un affinage intensif : un assistant propre à une langue, un assistant propre à un domaine dans un secteur réglementé, l'entraînement sur des données propriétaires, ou comme étudiant en distillation. Pour tout ce qui est prêt à l'emploi, y compris l'appel d'outils, Liquid vous oriente plutôt vers le LFM2.5-2.6B post-entraîné.

Ce dont ARTEMIS a besoin de la part d’un modèle, ce qu’un checkpoint de base n’offre pas

ARTEMIS est une boucle de contrôle à deux modes. Flash est un cycle réactif d'observation et d'action d'environ 3–5 secondes par étape. Pro est un graphe multi-agents d'environ 15–40 secondes par étape, avec un Planificateur tenant un plan Markdown vivant, un Opérateur disposant de l'ensemble d'outils complet, et un Vérificateur en lecture seule vérifiant des points de contrôle à quatre niveaux, de code>off/code> à code>strict/code>. Les deux modes demandent la même chose au modèle sous-jacent : regarder une capture d'écran, choisir une action dans un ensemble d'outils fixe, et recommencer en une seconde ou deux, cent fois, sans perdre le fil.

C'est une demande exigeante — suivre des instructions dans le cadre d'un schéma rigide, une compréhension visuelle ancrée et une cohérence sur un long horizon — et c'est exactement l'ensemble des compétences qu'un checkpoint de base n'a pas reçu. Les propres backends testés d'ARTEMIS sont des modèles hébergés : Gemini, Claude, GPT-4o, Qwen-VL. Chacun d'entre eux est affiné pour suivre des instructions en vue de l'utilisation d'outils, et chacun d'entre eux est de grande taille.

Donc l'écart n'est pas une question de taille. Un modèle post-entraîné de 2,6 B peut tenir une boucle d'appel d'outils — le propre homologue post-entraîné de Liquid affirme surpasser Gemma 4 E2B-it et E4B-it sur toutes ses évaluations de suivi d'instructions et presque toutes celles d'utilisation d'outils, bien que ce soient des chiffres rapportés par le fournisseur, sans vérification indépendante. L'écart, c'est qu'un checkpoint base n'a reçu aucun de ces entraînements, donc il ne peut pas du tout être inséré dans un harnais.

La licence est la différence la plus nette.

C'est ici que la confrontation se décide réellement, et c'est la partie que la plupart des comparaisons omettent.

• ARTEMIS — Apache 2.0. Utilisez-le commercialement, forkez-le, intégrez-le dans un produit, sans condition de revenus. La seule obligation est de conserver les mentions et d'indiquer vos modifications, une obligation que le projet lui-même a dû réparer publiquement en septembre 2026 après que Minitap a allégué que 228 des 229 fichiers d'ARTEMIS correspondaient à son propre projet Apache-2.0 code>mobile-use/code> et que les noms des auteurs avaient été supprimés par un force-push. Le dépôt porte désormais une mention de crédit à Minitap.

• LFM2.5-2.6B-Base — la LFM Open License, une licence personnalisée plutôt qu’Apache ou MIT. En dessous de 10 M$ de chiffre d’affaires annuel, l’octroi est large, perpétuel et sans redevances. À ce seuil ou au-delà, la licence ne s’étend pas du tout à l’usage commercial, et vous devez contacter Liquid. Le détail important pour quiconque développe sur cette base : les œuvres dérivées héritent des mêmes conditions. Le checkpoint que vous post-entraînez n’est pas une nouvelle chose que vous possédez en propre — il reporte la licence conditionnée par le chiffre d’affaires, avec une exception pour les organisations à but non lucratif qualifiées.

Mettez ces deux faits côte à côte et la décision s’inverse selon qui vous êtes. Une entreprise financée qui veut livrer un agent côté téléphone dispose d’un harnais Apache-2.0 qu’elle peut utiliser librement et d’un checkpoint qu’elle pourrait ne pas être autorisée à utiliser du tout à des fins commerciales. Un développeur individuel ou une startup en dessous du seuil dispose des deux, et la licence n’est qu’une note de bas de page. Aucun des deux fournisseurs n’est déraisonnable — Liquid est une entreprise qui protège son offre commerciale, Google libère en open source des outils de test — mais « poids ouverts » et « poids ouverts » ne sont pas la même autorisation, et une comparaison qui s’arrête au nombre de paramètres ne vous dira pas lequel vous avez.

La famille, parce que le checkpoint de base est la mauvaise porte pour y entrer.

Si l’objectif est un agent Android embarqué, trois modèles frères comptent davantage que la base, et celui dont la feuille de route ARTEMIS a réellement besoin n’est pas celui qui paraît évident.

• LFM2.5-2.6B — le pendant agentique post-entraîné. Le débit rapporté par le fournisseur est d'environ 30 jetons par seconde sur du matériel de classe téléphone, 113 sur un Ryzen AI Max+ 395 et 220 sur un Apple M5 Max, pour une exécution en moins de 2,5 Go.

• LFM2.5-VL-3B — le modèle edge vision-langage, construit sur la même base avec un encodeur SigLIP2 400M NaFlex, avec une précision de grounding precision@1 rapportée par le fournisseur, passée de 57,1 à 87,9 sur RefCOCO et, selon Liquid, des performances sur les éléments d'interface à l'écran qui surpassent des modèles Gemma bien plus grands et se situent à 0,7 % d'un Qwen 3.5 de 4,7B. Non vérifié, mais c'est le seul membre de cette famille qui peut voir un écran.

• LFM2.5-230M — le palier d'extraction et de classification, explicitement déconseillé pour les travaux à forte intensité de raisonnement.

Quelle est la conclusion inconfortable pour le checkpoint de base dans cette confrontation : l’élément de feuille de route d’ARTEMIS est une exigence de vision, le checkpoint de base est uniquement textuel, et le membre de la famille qui remplit ce créneau est la variante VL à laquelle on a déjà appliqué à la fois l’encodeur de vision et le post-entraînement. Le rôle du checkpoint de base dans une pile d’automatisation Android n’est pas de piloter le téléphone. Il doit être la matière première sous-jacente au petit modèle qui finira par s’en charger, quel qu’il soit.

Là où ils se rejoignent vraiment : le volant d'inertie que personne n'a encore construit

Voici la seule connexion qui soit réelle plutôt que rhétorique, et elle va à rebours du sens habituel. La fonctionnalité la plus sous-estimée d’ARTEMIS n’est pas l’agent — ce sont les données résiduelles. Chaque exécution capture des piles de crash, des captures d’écran d’images clés, un registre de session des étapes compressées et un rapport de diagnostic, et Pro ouvre un « incident d’exécution » dès qu’une action échoue et le garde en contexte jusqu’à ce qu’un succès ultérieur le résolve. C’est un corpus étiqueté des moments précis où la perception d’un agent d’interface utilisateur s’est trompée.

Associez cela à un checkpoint dont l’unique raison d’être est le post-entraînement, et vous obtenez une boucle évidente : exécutez le harness sur un modèle hébergé, collectez les traces où il a trébuché sur votre application, puis affinez un modèle 2,6B précisément sur ces frames. C’est le genre de jeu de données propriétaire que la fiche de Liquid elle-même cite comme justification pour publier un checkpoint de base — « entraîner sur vos propres données » — et la licence conditionnée aux revenus signifie que c’est une voie qui a du sens pour les équipes sous le seuil et qui nécessite une discussion pour les équipes au-dessus.

Pour être explicite quant au statut de cette idée : personne n’a publié cette boucle, aucun des deux fournisseurs ne la suggère, et rien ne prouve que l’un ou l’autre l’ait testée. C’est une proposition, non un résultat, et il faut la lire comme telle. Mais c’est le seul cadre dans lequel ces deux artefacts sont des collaborateurs plutôt qu’une erreur de catégorie.

Si vous allez jusqu'au fine-tuning, l'ensemble de comparaison est l'autre moitié du problème. LFM2.5-2.6B-Base ne figure pas dans notre catalogue — aucune variante LFM2.5 n'y figure — donc ce checkpoint provient de la distribution propre à Liquid et des hébergeurs tiers habituels. Là où un catalogue routé mérite sa place, c'est lorsqu'il s'agit de comparer votre fine-tuning aux modèles qu'il doit battre en matière d'utilisation d'outils, sur une seule clé et une seule facture, avec basculement pour qu'un mauvais après-midi d'un fournisseur ne devienne pas le mauvais après-midi de votre évaluation. C'est une chose vraiment utile à avoir quand tout l'intérêt de l'exercice est un face-à-face que vous comptez exploiter.

Alors, lequel est ton problème ?

Si vous avez une application Android et que vous voulez qu’elle soit testée automatiquement ce trimestre, c’est ARTEMIS qu’il vous faut, et LFM2.5-2.6B-Base ne fait pas partie de la solution — vous exécuterez ARTEMIS sur un modèle de vision hébergé, vous paierez à chaque étape, et l’élément de feuille de route concernant les VLM embarqués finira par arriver et résoudra un problème de coût que vous n’avez pas encore mesuré.

Si vous construisez un produit qui doit fonctionner sur un téléphone sans réseau, vous voulez la voie des petits modèles, et LFM2.5-2.6B-Base marque le début de ce projet plutôt que de faire partie de sa solution : vous le post-entraînerez, vous lirez la LFM Open License au regard de vos projections de revenus avant d’écrire le premier script d’entraînement, et si votre agent a besoin de voir un écran, vous finirez plutôt sur la variante VL.

La seule chose à ne pas faire est de mettre ces deux-là côte à côte, de déclarer le harnais plus capable, puis de passer à autre chose. La comparaison utile se fait entre les deux piles complètes — modèle hébergé plus harnais, face à petit modèle affiné plus un framework que vous construisez — et une seule de ces piles possède un taux de réussite publié sur un benchmark public, ce qui vaut exactement autant que le fait que l’autre n’a aucune facture cloud du tout.

Là où un catalogue routé justifie sa place, c'est en comparant votre modèle affiné aux modèles qu'il doit battre en matière d'utilisation d'outils, sur une seule clé et une seule facture, avec basculement pour qu'un mauvais après-midi d'un fournisseur ne devienne pas un mauvais après-midi pour votre évaluation.

LFM2.5-2.6B-Base ne figure pas dans notre catalogue — aucune variante de LFM2.5 n'y figure — ce checkpoint provient donc de la distribution propre à Liquid et des hébergeurs tiers habituels.