d1-2B : Liquid AI a livré un modèle de décision de 1,9 milliard de paramètres sans publier d'article pour l'annoncer

Le dépôt Hugging Face de LiquidAI/d1-2B a été créé à 19 h 30 UTC le 24 octobre 2026. Son homologue, d1-Omni-2B, est apparu vingt-quatre secondes plus tard. À la fin de cette soirée, les deux dépôts étaient complets — 3,84 Go de safetensors BF16, une quarantaine de fichiers de code Transformers personnalisé, une table de calibration, une API de questions typées — et rien de ce que Liquid AI a publié ne disait que l’un ou l’autre de ces modèles existait. La première phrase du fournisseur qui nomme d1-2B est arrivée le 27 octobre, lors du lancement de la famille LFM3 — le même billet publié sur liquid.ai et sur le blog de Hugging Face — sous la forme d’une proposition dans un paragraphe consacré à deux modèles de décision. Il n’y a eu aucun billet dédié depuis. Ce n’est donc pas une histoire de lancement, et la traiter comme telle reviendrait à inventer un moment marketing qui n’a jamais eu lieu. C’est l’histoire d’un artefact de modèle complet accompagné d’une annonce incomplète, et des deux choses qu’un lecteur peut encore faire avec cela : lire le dépôt, et tenir à distance les chiffres du fournisseur jusqu’à ce que quelqu’un en dehors du laboratoire les fasse tourner.

Les cinq jours entre les poids et la sentence

La famille d1 a été publiée deux fois, et aucune des deux publications ne ressemblait à celle-ci. Le 7 octobre, Liquid AI a publié « Open d1 : modèles de décision edge pour le texte, la vision et l’audio », qui présentait d1-3B avec 3,12 milliards de paramètres et d1-omni-600M avec 587 millions, avec une affirmation phare, un tableau de benchmarks, des chiffres de latence et un billet de blog resté en ligne depuis. Ce billet ne contient aucun modèle 2B.

La gamme 2B a suivi un calendrier différent. Le checkpoint de base LFM3-Omni-2B est apparu le 21 octobre. Le 24 octobre, à 19:30 et 19:30:24 UTC, Liquid AI a créé les dépôts d1-2B et d1-Omni-2B. Puis, le 27 octobre, l’article de lancement de LFM3 a qualifié le duo de « modèles de décision spécialisés à partir des modèles vision et omni » — une description, pas une annonce. Le même jour, quatre dépôts dérivés pour d1-2B ont été mis en ligne : des builds MLX en fp16, 8 bits et 4 bits, plus un export ONNX. Personne n’a écrit d’article à leur sujet non plus.

Cela compte pour une raison pratique. Une annonce est le moment où un fournisseur s’engage sur son positionnement : à quoi sert le modèle, combien il coûte, quel environnement d’exécution il cible, ce qu’il ne fait pas. La fiche fait une partie de ce travail, et le fait remarquablement bien. Mais les lacunes laissées par le billet manquant sont réelles et précises, et elles sont listées en bas de ce texte plutôt que passées sous silence.

Ce que le dépôt vous dira réellement

Retirez le cadrage et le checkpoint est un petit classificateur multimodal densément spécifié qui refuse de générer du texte. Chaque appel renvoie des réponses typées avec des probabilités attachées et output_tokens: 0. La fiche le dit sans détour : d1-2B « n’est pas un modèle de chat. »

• Paramètres — 1,92 Md, fourni sous la forme d’un fichier unique safetensors BF16 de 3,84 Go.

• Base — LFM3-VL-2B, sur le backbone LFM3 : 24 couches, dont 13 convolutions courtes à portes, 5 mécanismes d’attention à fenêtre glissante et 6 mécanismes d’attention globale.

• Contexte — 128K tokens et un vocabulaire de 128 000 tokens, quatre fois la fenêtre de 32 768 de d1-3B.

• Saisie — un état qui peut être du texte ou n'importe quelle valeur JSON, des images ou une vidéo, et un nombre quelconque de questions nommées, le tout dans une seule média-liste. La vidéo est la fonctionnalité que d1-3B ne répertorie pas.

• Sortie — oui/non, un choix parmi des options nommées, un score ordonné, une valeur ou une date lue dans un document avec son étendue, un nombre avec un intervalle p10–p90, une boîte englobante, ou chaque instance d’un objet avec un décompte. Chacune porte une probabilité.

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

• Licence — LFM Open License v1.0. L'usage commercial est accordé en dessous de 10 000 000 $ de chiffre d'affaires annuel ; le texte de la licence définit ce montant comme un seuil, et les droits d'usage commercial au-delà de celui-ci sont subordonnés au fait de ne pas le dépasser.

• Vitesse — 5,7 ms pour une seule décision sur un H100 PCIe et 3,8 ms sur un AMD MI325X, avec respectivement 1 132 et 1 699 décisions par seconde lorsque 64 états sont regroupés dans un seul appel. Sur un Apple M5 Pro, la valeur pour une question unique est de 18,6 ms.

L’affirmation qui vaut la peine d’être débattue : elle surpasse le modèle qu’elle a remplacé.

La fiche de Liquid AI formule une affirmation comparative sans nuance : d1-2B « devance les modèles d1 ouverts en moyenne et sur notre tableau de plus d’une centaine de benchmarks de décision, devant d1-3B à moins de deux tiers de sa taille ». Il s’agit d’une déclaration forte de la part d’un modèle de 1,92 B à propos d’un modèle de 3,12 B, et elle est vérifiable, car la fiche présente les quatre modèles d1 ouverts dans un seul tableau évalué sur les mêmes éléments avec le même évaluateur.

Le chiffre principal est de 51,1 contre 49,0 sur la suite publique Decision Index, version 0.3 — une avance de 2,1 points. Avant que quiconque y voie une victoire nette, deux réserves doivent être mentionnées à côté. Premièrement, la propre fiche de d1-3B indique 48,57 sur Decision Index 0.2.1, et l’écart entre 48,57 et 49,0 tient à la version de l’index, non à une amélioration du modèle ; la fiche de d1-2B précise que les quatre modèles ont été réévalués sur les mêmes éléments et que certains chiffres de d1-3B diffèrent donc de sa propre fiche. Deuxièmement, la suite publique ne représente qu’une fraction de ce qui détermine le classement public : l’évaluateur indépendant qui l’a reconstruite décrit 37 benchmarks publics pondérés à 20 % du score, le reste provenant de tests privés que seuls les mainteneurs exécutent.

Ce qui rend le 49.0 crédible comme chiffre — même si d1-2B lui-même n’a fait l’objet d’aucune vérification externe — c’est que quelqu’un a déjà reproduit le 3B sur cette version exacte. Efraín Garay a exécuté d1-3B sur un échantillon stratifié de 6 000 requêtes de Decision Index 0.3 à la mi-octobre et a obtenu 49,11, contre 49,04 pour Liquid sur les mêmes lignes et 48,99 sur la suite complète. C’est une reproduction à un dixième de point près. Cela ne valide pas le 51,1 de d1-2B, qu’aucun tiers n’a exécuté, mais cela valide la méthode de notation derrière le tableau dans lequel figure 51,1.

Là où le modèle plus petit n’est pas en tête

« En tête sur la plupart des benchmarks individuels » joue un rôle discret dans cette phrase. Dans le tableau des résultats d’une même exécution, d1-3B l’emporte encore sur trois des quelque vingt lignes qui comptent pour une décision de déploiement :

• Décisions rapides — 59,3 pour le 3B contre 58,8, le seul benchmark de décision axé sur la vitesse où le modèle le plus grand prend légèrement l’avantage.

• Décisions typées — 65,0 contre 61,3, soit un écart de 3,7 points, et, à lui seul, l'argument le plus clair en faveur du modèle plus ancien lorsque la sortie doit être une valeur typée plutôt qu'un libellé.

• AI2D — 79,9 contre 76,7, le benchmark de lecture de diagrammes, où une tour de vision plus grande permet encore de gagner en précision.

Partout ailleurs, l’ordre s’inverse, parfois nettement. VisualWebBench est à 96,2 pour d1-2B contre 71,4 pour d1-3B. ImajevBench v2.0-lite est à 75,5 contre 64,0. MMMU-Pro est à 26,4 contre 18,5 — les deux sont suffisamment bas pour qu’aucun des deux modèles ne doive être considéré comme fiable pour un raisonnement multimodal difficile, ce qui mérite d’être dit clairement plutôt que de présenter l’écart de 7,9 points comme une victoire. Les moyennes de vision sont de 70,2 et 65,4.

Trois absences que la carte ne peut combler

L’annonce manquante se traduit par des artefacts manquants. Aucun de ces points n’est un défaut du modèle ; chacun constitue une raison pour laquelle le modèle est plus difficile à adopter aujourd’hui que ne le laisse entendre sa ligne de référence.

• Aucun GGUF. d1-3B et d1-omni-600M ont tous deux obtenu des dépôts GGUF le 6 octobre, un jour après la mise en ligne de leurs poids, et d1-3B a ensuite reçu une version 8 bits à activation des poids ainsi que quatre variantes MLX. d1-2B dispose de versions MLX et ONNX depuis le 27 octobre, mais pas de GGUF — il n’existe donc aucun chemin llama.cpp publié pour la tête de décision, bien que le modèle de base LFM3-VL-2B ait obtenu son propre GGUF le 19 octobre. Si votre stack edge repose sur llama.cpp, tout est dit.

• Aucun prix et aucun point de terminaison. La fiche ne mentionne ni API hébergée, ni prix par token, ni fournisseur d’inférence. Ce n’est pas inhabituel pour une publication à poids ouverts, mais cela signifie que la seule façon d’utiliser d1-2B est de l’exécuter, et la section déploiement de la fiche s’arrête à un extrait Transformers.

• Aucun benchmark indépendant. Au 28 octobre, le dépôt affiche 44 téléchargements et 13 mentions J’aime. L’évaluation indépendante des modèles de décision disponible porte sur d1-3B et d1-omni-600M, et non sur ce modèle. Tous les chiffres de performance ci-dessus sont ceux de Liquid AI.

Il y a aussi une limite que la fiche du modèle énonce à son propre sujet : les réponses « deviennent moins fiables au-delà d’environ 64K tokens d’état », soit la moitié de la fenêtre de 128K annoncée, et les estimations sont fiables sur les décomptes et les scores, mais moins sur les quantités libres. Un modèle dont la fiche indique elle-même où il se dégrade est plus utile qu’un modèle qui ne le fait pas, mais le chiffre phare de 128K doit être lu comme une capacité, pas comme une plage de travail.

À quoi ressemble vraiment un premier déploiement

Le chemin pratique est Transformers 5.19 ou plus récent avec trust_remote_code=True, bf16 sur GPU, et l'appel system_one ou system_one_batch. Il n'y a pas de paramètres d'échantillonnage parce qu'il n'y a pas d'échantillonnage. Le seul réglage qui compte est set_size, qui vaut par défaut la taille entraînée de 16 ; l'augmenter permet de gagner en vitesse au détriment de la précision du texte.

La recommandation de la fiche elle-même est l’étape que la plupart des équipes sautent : calibrez votre seuil de décision sur des données issues de votre propre usage. Une probabilité de 0,62 ne veut rien dire isolément. Si vous aiguillez des tickets d’assistance ou signalez des documents, le seuil qui sépare « escalader » de « traiter automatiquement » doit être ajusté sur votre propre échantillon annoté, car la calibration du fournisseur a été ajustée sur le sien.

La forme à laquelle cela correspond est une étape de pipeline, pas un assistant : triage, modération, classification d'intention, extraction à partir de formulaires, reranking, inspection visuelle. Ce sont exactement les endroits où un pipeline appelle déjà plusieurs modèles, et où les étapes génératives autour de la décision proviennent généralement d'une API hébergée. OrcaRouter ne sert aujourd'hui aucun modèle Liquid AI — celui-ci compris — donc exécuter d1-2B signifie l'exécuter vous-même. Ce à quoi un routeur est utile, c'est le reste de la chaîne : une clé compatible OpenAI pour plus de 200 modèles hébergés, un DSL de routage qui compose les étapes en un seul appel, et un basculement automatique en cas de défaillance d'un fournisseur, afin que le nœud de décision sur votre GPU ne soit pas pris en otage par le nœud génératif à côté.

Qu’est-ce qui changerait cette histoire ?

Quatre choses, par ordre décroissant de leur importance. Un GGUF mettrait d1-2B sur le même pied d’exécution que ses pairs et donnerait corps à l’argument de l’edge. Un article dédié dirait aux acheteurs à quoi Liquid AI destine le modèle, au-delà de la liste des étapes du pipeline figurant sur la fiche. Une exécution indépendante — idéalement le même échantillon de 6 000 lignes qui a reproduit d1-3B — transformerait 51,1 d’une affirmation de fournisseur en une mesure. Et un prix d’hébergement permettrait enfin de répondre à la question de construire ou d’acheter.

D’ici là, le résumé honnête est restreint et utile : un modèle de décision de 1,92 B existe, son dépôt est suffisamment complet pour être évalué, son avance au benchmark sur le 3B est réelle dans le tableau du fournisseur issu de la même exécution et non vérifiée partout ailleurs, et l’annonce manquante l’a laissé sans l’emballage — environnement d’exécution, point de terminaison, prix — dont la plupart des équipes ont besoin avant de mettre un modèle dans un pipeline. Si vous utilisez déjà Transformers et voulez un classifieur à fenêtre de 128K avec entrée vidéo, cela vaut une après-midi. Si vous avez besoin de llama.cpp ou d’un point de terminaison géré, attendez.