d1-2B vs Liquid AI d1-3B : le plus petit modèle gagne le classement et perd au déploiement

Quatre questions décident de cette confrontation, et aucune d’elles n’est « quel modèle est le meilleur ». L’état inclut-il la vidéo ? Dépasse-t-il 32K tokens ? Faut-il l’exécuter sous llama.cpp ? Pouvez-vous vous permettre d’être la première personne à le tester ? d1-2B est le modèle décisionnel de 1,92 B de Liquid AI, construit sur LFM3-VL-2B et ayant obtenu 51,1 au tableau Decision Index du fournisseur. Liquid AI d1-3B est le modèle de 3,12 B sorti le 7 octobre, construit sur LFM2.5-VL-3B et ayant obtenu 49,0 au même tableau. Le modèle plus récent et plus petit arrive en tête en moyenne. Il perd encore trois des lignes qu’un déploiement active réellement, et c’est celui des deux qui n’a ni prise en charge par llama.cpp ni résultat de test indépendant. Cette page est organisée autour de ces quatre questions plutôt qu’autour du classement, car le classement ne répond à aucune d’elles.

La réponse courte, selon la charge de travail

• Triage en texte seul à fort volume — d1-2B, grâce à 1 132 décisions par seconde pour 64 états traités par lots et 3,84 Go de poids. L’avantage du 3B sur Typed Decisions est sans importance lorsque la sortie est une étiquette.

• Lecture de diagrammes et de graphiques — Liquid AI d1-3B. Il l'emporte sur AI2D 79,9 contre 76,7, et c'est le modèle qui peut s'appuyer sur une exécution indépendante.

• Documents longs, formulaires longs, retranscriptions d'appels longues — d1-2B. Sa fenêtre est de 128K tokens contre 32 768, et la fiche indique honnêtement que la fiabilité diminue au-delà d'environ 64K, ce qui laisse encore deux fois la capacité totale du 3B.

• Boîtiers edge exécutant llama.cpp — Liquid AI d1-3B, par défaut plutôt que par mérite. Il dispose d'un dépôt GGUF et d'une version quantifiée à activation des poids ; d1-2B n'a ni l'un ni l'autre.

• Tout cas où un mauvais choix coûte cher et n'a pas été testé — ni l'un ni l'autre, tant que vous n'avez pas exécuté les deux sur vos propres données. Un seul d'entre eux a même été exécuté par un tiers.

Même famille, à une génération d’écart

Les deux modèles ne sont pas de la même fratrie, contrairement à ce que les noms suggèrent. Liquid AI d1-3B descend de LFM2.5-VL-3B, lui-même dérivé de LFM2.5-2.6B-Base, et embarque un encodeur visuel SigLIP2 NaFlex de 400M. d1-2B descend de LFM3-VL-2B, la famille suivante, reposant sur un backbone de 24 couches réparties entre 13 convolutions courtes à portes, 5 couches d’attention à fenêtre glissante et 6 couches d’attention globale. C’est de cet écart générationnel que vient l’inversion des benchmarks : l’architecture plus récente en fait plus par paramètre, si bien que le checkpoint plus petit peut surclasser le plus grand sur la plupart des lignes.

• Paramètres — 1,92 Md pour d1-2B contre 3,12 Md pour Liquid AI d1-3B.

• Télécharger — 3,84 Go contre 6,25 Go de safetensors BF16, les deux en fichier unique.

• Contexte — 128K tokens contre 32 768.

• Vocabulaire — 128 000 tokens contre le vocabulaire LFM2.5.

• Entrées — texte ou JSON, images ou vidéo, ainsi que des questions nommées, pour le d1-2B ; texte ou JSON et images pour le 3B. La vidéo est la différence de capacité la plus nette entre eux.

• Langues — seize chacune, le même ensemble.

• Licence — LFM Open License v1.0 pour les deux, l’utilisation commerciale étant conditionnée au maintien d’un chiffre d’affaires annuel inférieur à $10,000,000. Aucune raison liée à la licence ne justifie de préférer l’une ou l’autre.

• Publication — les poids de d1-3B ont été mis en ligne le 5 octobre et annoncés le 7 octobre. Le dépôt de d1-2B a été créé le 24 octobre et n'a jamais fait l'objet d'un billet dédié ; la seule phrase du fournisseur qui le nomme figure dans le lancement de LFM3 du 27 octobre.

Un détail de documentation mérite d’être lu comme un signal plutôt que comme un fait : la page de documentation des modèles de décision de Liquid AI liste désormais d1-2B, d1-omni-2B, d1-omni-600M, d1.1 et d1-ultra. Elle ne liste plus d1-3B. Le 3B n’a pas été retiré — son dépôt, ses builds GGUF et MLX sont tous disponibles — mais l’index du fournisseur lui-même a déplacé le créneau des poids ouverts vers le 2B.

Le tableau d’affichage, à lire ligne par ligne

Tous les chiffres ci-dessous proviennent du tableau de référence de la fiche modèle de d1-2B, qui évalue quatre modèles d1 ouverts sur les mêmes éléments avec le même évaluateur. C'est important car la propre fiche de Liquid AI d1-3B indique 48.57 sur Decision Index 0.2.1, tandis que ce tableau indique 49.0 sur la version 0.3 ; l'écart tient à l'édition de l'indice, non à un changement de modèle, et la fiche le précise dans une note. Comparer directement les deux fiches — 48.57 contre 51.1 — reviendrait à soustraire des résultats de deux tests différents. Comparer à l'intérieur de ce tableau est légitime, et c'est ce que fait le reste de cette section.

• Suite publique Decision Index v0.3 — 51,1 contre 49,0.

• DecisionBench (Hanno Labs) v1 — 77,1 contre 73,1.

• Decision Bench (decisionbench.ai) v4 — 85,2 contre 83,6.

• JevBench v1.4.1 — 77,9 vs 76,2.

• ImajevBench v2.0-lite — 75,5 vs 64,0, le plus grand écart du côté décisionnel.

• WorkflowEvals — 81,6 vs 74,4.

• le tableau de bord interne de Liquid AI — 63,2 contre 58,8.

• Moyenne Vision — 70,2 contre 65,4 sur dix-huit benchmarks.

Toutes les suites de décision nommées de ce tableau reviennent au 2B, ce que signifie l’article de lancement du LFM3 lorsqu’il qualifie le d1-2B de remplaçant du d1-3B « avec un tiers de paramètres en moins » et de meilleurs scores « sur les quatre suites de décision ». L’affirmation est exacte telle qu’écrite — et plus restrictive que « bat le 3B », d’où l’existence du paragraphe suivant. Puis viennent les trois lignes qui vont dans l’autre sens. Fast Decisions est de 58,8 pour le d1-2B contre 59,3 pour le 3B. Typed Decisions est de 61,3 contre 65,0. AI2D est de 76,7 contre 79,9. Aucun de ces écarts n’est important, et deux des trois tiennent dans un point, mais ce sont les lignes où les 1,2 milliard de paramètres supplémentaires apportent encore quelque chose de mesurable : les décisions axées sur la vitesse, l’extraction typée et la lecture de diagrammes. Si les tâches de votre pipeline consistent à extraire des données typées de formulaires, le 3B n’est pas l’option obsolète que la page de documentation laisse entendre.

Latence : les deux chiffres phares ne sont pas comparables

Liquid AI annonce 5,7 ms par décision pour d1-2B et 8 ms pour Liquid AI d1-3B, et ce ne sont pas les mêmes mesures. Le chiffre du 2B est obtenu sur une H100 PCIe ; celui du 3B sur une RTX 4090. Un écart de 2,3 ms entre deux GPU différents ne vous dit rien sur le modèle qui est le plus rapide sur votre matériel, et le répéter comme une comparaison serait exactement le genre de blanchiment de chiffres que ce blog cherche à éviter.

Il y a une seule machine que les deux cartes mentionnent. Sur un Apple M5 Pro, le d1-2B prend 18,6 ms par question et le 3B prend 30 ms — une réduction de 38 % sur un silicium identique. C'est la comparaison de vitesse honnête, et elle va dans le même sens que le suggère la différence de taille. Côté traitement par lots, le d1-2B traite 1 132 décisions par seconde sur un H100 PCIe et 1 699 par seconde sur un MI325X avec 64 états en un seul appel ; la carte du 3B rapporte 475 par seconde sur une RTX 4090 et 1 106 par seconde sur un MI325X. La ligne MI325X est celle que les deux cartes partagent, et là, le 2B est en avance d'environ 54 %.

Le seul test indépendant existant a exécuté le 3B

À la mi-octobre, Efraín Garay a évalué huit modèles de décision par rapport à Decision Index 0.3 et à trois tâches sur données réelles, puis a publié les résultats avec le code. Deux constats concernent cette comparaison.

Le premier résultat est rassurant pour le classement. Il a reconstruit la suite publique à partir de son kit, vérifié que les fichiers téléchargés correspondaient aux fichiers officiels, échantillonné 6 000 requêtes et attribué à Liquid AI d1-3B un score de 49,11, contre 49,04 pour Liquid lui-même sur les mêmes lignes et 48,99 sur la suite complète. C'est la preuve la plus solide dont on dispose que les chiffres de la v0.3 dans le tableau ci-dessus sont calculés correctement. C'est une preuve concernant le 3B, pas le d1-2B, qu'il n'a pas testé.

Le deuxième est un avertissement sur ce que mesure un indice. Sur une base synthétique de fraude à la carte bancaire composée de 10 000 paiements, Liquid AI d1-3B a obtenu une AUC de 0,314 — inférieure au hasard, classant les anomalies comme moins suspectes que les paiements normaux, parce que les rafales de paiements consécutifs se situaient à une probabilité médiane de 0,41 contre 0,56 pour un paiement normal. Le modèle était deuxième sur l’indice public et dernier sur cette tâche. La leçon se transpose directement : le 51,1 de d1-2B est un score sur une suite de décisions générale, et personne n’a montré qu’il prédit la performance sur votre décision spécifique. Le fournisseur le dit d’ailleurs dans sa propre fiche, dans l’instruction de calibrer les seuils sur vos propres données.

Ce que vous pouvez réellement exécuter aujourd'hui

C’est ici que la comparaison n’est plus serrée. Liquid AI d1-3B dispose d’un dépôt GGUF depuis le 6 octobre, d’une version 8 bits avec quantification des poids et des activations depuis le 7 octobre, et de quatre variantes MLX depuis le 12 octobre. d1-2B a reçu trois versions MLX et un export ONNX le 27 octobre, et rien d’autre. Il n’existe pas de GGUF pour d1-2B, aucune quantification au-delà des 4 bits et 8 bits de MLX, et donc aucune voie llama.cpp publiée pour la tête de décision — même si le modèle de base, LFM3-VL-2B, dispose de son propre GGUF depuis le 19 octobre.

Pour un déploiement Transformers, la différence disparaît : les deux se chargent avec trust_remote_code=True et exposent les mêmes system_one et system_one_batch appels. Pour un déploiement en périphérie, ce n'est pas le cas. Si votre pile est llama.cpp sur un Jetson ou un téléphone, le 3B est le seul des deux que vous pouvez exécuter sans écrire d'intégration d'exécution, et ses chiffres publiés pour l'edge — 16 ms sur Jetson AGX Thor, 26 ms sur AGX Orin 64GB, 50 ms sur Orin Nano — sont ceux sur lesquels vous pouvez planifier.

Aucun des deux modèles n’est servi par OrcaRouter, donc choisir entre eux est de toute façon une décision d’auto-hébergement. Là où un routeur gagne sa place, c’est un cran au-dessus : les modèles de décision tournent rarement seuls, et l’étape générative qui agit sur une étiquette de routage provient généralement d’un modèle hébergé. Une clé compatible OpenAI pour plus de 200 modèles, un DSL de routage qui vous permet de composer ces étapes en un seul appel, et un basculement automatique empêchent cette moitié du pipeline de devenir un second projet d’intégration, tandis que le nœud de décision reste sur votre propre matériel.

Si vous migrez, trois choses changent

La surface d'API est suffisamment proche pour qu'un portage paraisse trivial, et il ne l'est pas. D'abord, le contrat d'entrée : d1-3B prend des images ; d1-2B prend une liste media pouvant inclure de la vidéo, et sa fiche décrit le média comme encodé une seule fois pour toutes les questions d'un appel. Le code qui passe une seule image s'exécutera, mais il n'utilisera pas ce pour quoi le modèle a été conçu.

Deuxièmement, le seuil. Les deux modèles renvoient des probabilités, et tous deux ont besoin d’un seuil de décision ajusté sur vos données. Un seuil réglé sur la calibration de d1-3B ne se transfère pas — les tables de calibration sont fournies dans chaque dépôt, ajustées séparément — donc une migration qui conserve l’ancien seuil produira un point de fonctionnement différent et, dans un parcours de modération ou de détection de fraude, un profil d’erreur différent.

Troisièmement, la falaise de fiabilité. La fenêtre de 128K est le point phare ; la fiche indique que les réponses deviennent moins fiables au-delà d’environ 64K jetons d’état. Sur le 3B, le plafond est de 32 768, donc une migration vers d1-2B constituera généralement un gain de capacité net — mais un pipeline qui commence à injecter des états de 100K jetons parce qu’il le peut désormais teste la partie de la plage que le fournisseur a signalée comme plus faible.

Le verdict est moins symétrique que le tableau des scores. Pour une nouvelle implémentation dans Transformers, sur du texte, des images ou de la vidéo, avec des états qui peuvent durer longtemps, d1-2B est le meilleur choix par défaut et le moins coûteux à exécuter. Pour un déploiement en périphérie sous llama.cpp, pour l’extraction typée ou pour une vision riche en diagrammes, Liquid AI d1-3B reste le modèle à choisir — et c’est le seul des deux à bénéficier de preuves externes. La seule chose à ne pas faire est de choisir sur la seule base de la ligne 51,1 contre 49,0. Deux points sur l’indice d’un fournisseur, entre deux modèles que personne n’a testés sur votre tâche, ne constituent pas une décision ; c’est un départage.