Liquid AI d1 vs Liquid AI d1-3B : Ce que la bibliothèque Ollama appelle un modèle et ce que le fournisseur appelle deux

Il existe deux façons de nommer le même ensemble de poids, et Liquid AI d1 et Liquid AI d1-3B illustrent la différence mieux que ne le ferait n'importe quelle comparaison de paramètres. Retirez un trait d'union et un suffixe de taille du second nom, et vous obtenez le premier ; il est donc tentant de considérer la chaîne la plus courte comme un surnom. Les deux catalogues qui répertorient réellement ces modèles ne confirment pas cette lecture. L'index de documentation de Liquid AI conserve d1 dans sa propre ligne avec les lettres « API » là où se trouvent les liens de téléchargement, et conserve d1-3B et d1-omni-600M dans une paire de lignes distincte avec des liens Hugging Face et GGUF fonctionnels et un « Non » dans la colonne entraînable. Ollama, dont l'entrée de bibliothèque est la raison pour laquelle cette paire vaut la peine d'être évoquée, regroupe le tout sur une seule page appelée d1, la décrit en une seule ligne comme « un modèle de décision 3B de Liquid AI, construit sur LFM2.5-VL-3B », et propose précisément trois tags en dessous. Comparer Liquid AI d1 à Liquid AI d1-3B n'est donc pas une comparaison entre un point de terminaison hébergé et un checkpoint ouvert, et ce n'est pas non plus une comparaison entre deux checkpoints. C'est une comparaison entre un point de terminaison hébergé et le checkpoint ouvert que l'écosystème d'exécution local a décidé être d1 lorsqu'on prononce le mot sans précision. La suite porte en grande partie sur celle de ces lectures dont votre déploiement dépend réellement.

Une note sur l'origine des chiffres ci-dessous, car l'honnêteté compte plus que leur mise en forme. Tout ce qui est numérique ici provient des propres rapports de Liquid AI, sur les fiches de modèle ou dans l'article de publication du 7 octobre. Les lignes du Decision Index ont été notées par le fournisseur avec l'outil de notation officiel, plutôt que soumises à un classement public, et aucun tiers n'a reproduit de façon indépendante le moindre résultat de d1 que nous ayons pu trouver. Lorsqu'un nombre est obtenu par un calcul arithmétique à partir d'une donnée publiée plutôt que par une mesure, c'est indiqué.

D'où viennent les deux noms

Le nom plus court est le plus ancien. Le billet du 5 octobre de Liquid AI a présenté le modèle sous le nom de Liquid AI d1 — « notre premier modèle de décision », multimodal dans cette version, répondant à des questions saisies sur un état de texte, d'images, ou des deux, en une seule passe avant avec zéro jeton de sortie. Ce billet cite un prix hébergé de 0,04 $ par million de jetons d'entrée, ne facture que les jetons d'entrée, et note que les images sont facturées comme du texte à 1,5 jeton par zone de 32×32, si bien qu'une image de 1024×1024 coûte 1 536 jetons. Il indique également la latence de décision pour le texte comme étant de 200–300 ms. Ce sont des chiffres de service hébergé, et le billet précise explicitement que le runtime qui les sous-tend est le point de terminaison de décision propre au fournisseur, à l'adresse api.liquid.ai/decisions/v1/systemone.

Le nom plus long apparaît dans la publication du 7 octobre et sur Hugging Face, et c'est celui qui porte le détail reproductible : 3,12 B de paramètres, un contexte de 32 768 tokens, un vocabulaire de 128 000 tokens, seize langues documentées, un encodeur visuel SigLIP2 NaFlex de 400 M optimisé pour la forme, et la chaîne de base LFM2.5-2.6B-Base → LFM2.5-VL-3B → d1-3B. Cette fiche indique aussi clairement que le modèle n'est pas un modèle de dialogue et qu'il n'écrit pas de texte. C'est le checkpoint sur lequel repose tout l'écosystème local : le dépôt GGUF contient Q4_K_M à 1,67 GB, Q8_0 à 2,87 GB, ainsi que F16 et BF16 à 5,4 GB chacun.

Ce qu'aucun document du fournisseur ne dit ouvertement, c'est que Liquid AI d1 et Liquid AI d1-3B sont les mêmes poids. L'index de la documentation leur attribue des lignes distinctes. L'article de publication appelle d1 une famille, pas un point de contrôle. Des analyses tierces ont remarqué l'écart et noté que le fournisseur n'a pas confirmé l'identification. Donc la déclaration honnête est brève : les chiffres publiés pour les deux noms ne se contredisent nulle part là où nous pouvons le vérifier, la publication de la famille et le point de terminaison servi ont été annoncés à deux jours d'intervalle avec une description compatible, et le fournisseur n'a pas dit qu'il s'agissait du même modèle. Considérez l'équivalence comme une hypothèse de travail raisonnable et non comme un fait que le fournisseur a avalisé.

Ce que le build local change réellement

L'entrée d'Ollama n'est pas une republication et pas un nouveau checkpoint. C'est une décision d'empaquetage, et cet empaquetage impose trois contraintes que la documentation du fournisseur elle-même ne mentionne pas du tout. La première est la liste des tags : d1:latest, d1:3b et d1:3b-q8_0, trois tags désignant une seule quantification. Le dépôt GGUF publié par Liquid contient quatre précisions, et le Q4_K_M de 1,67 Go — celui vers lequel la plupart des gens se tourneraient sur un ordinateur portable — ne figure pas parmi les tags Ollama. Ce que vous pouvez récupérer, c'est le Q8_0 de 2,87 Go et ce vers quoi il s'étend dans le stockage local ; la page de la bibliothèque indique un téléchargement de 3,7 Go.

Le deuxième est le contrat de requête. Ollama répond pour ces modèles sur /v1/systemone, prend un state accompagné d'un objet questions et renvoie des réponses typées avec output_tokens: 0. C'est la même forme que celle utilisée par le point de terminaison hébergé du fournisseur, ce qui fait du passage entre local et hébergé un simple changement de configuration plutôt qu'une réécriture. La troisième contrainte se trouve dans la documentation du point de terminaison d'Ollama plutôt que sur la page du modèle, et elle est plus stricte que celle d'un modèle génératif : les requêtes doivent tenir dans 64 KiB sans images et 32 MiB avec, le streaming n'est pas pris en charge, les modèles hébergés dans le cloud sont rejetés, et les images doivent être en base64 PNG, JPEG ou WebP dans le corps de la requête — les URL distantes sont refusées. Les images sont partagées par toutes les questions d'une requête, donc une image que vous voulez qu'une seule réponse prenne en compte nécessite son propre appel. L'entrée n'est jamais tronquée, ce qui signifie qu'un state trop volumineux renvoie une erreur au lieu d'être silencieusement coupé. C'est le meilleur mode de défaillance, et c'est malgré tout un mode de défaillance que votre client doit gérer.

Deux détails de documentation restent non résolus et méritent d'être connus avant que vous ne signaliez un bug. La référence des points de terminaison d'Ollama décrit le type de question à choix comme acceptant de 2 à 255 clés d'option, tandis que sa page de capacités des modèles de décision indique 2 à 26 ; l'une des deux est obsolète. Et la page de capacités répertorie ses modèles pris en charge comme étant Nimble, Tev1, Clef et Clef Flash, sans aucune mention de d1 — même si le readme du paquet d1 lui-même documente la prise en charge de /v1/systemone et --ask, et que le paquet exige Ollama 0.40.4 alors que le minimum documenté du point de terminaison lui-même est 0.35.0. Lisez l'exigence de version indiquée sur le paquet, pas celle du guide.

Les numéros, et sous quel nom ils ont été publiés

C'est la partie de l'appariement qu'il est le plus facile de se tromper, car les deux noms sont publiés avec des chiffres de performance et ces chiffres ne sont pas organisés comme on pourrait s'y attendre.

• Decision Index 0.2.1 — 48,57, publié sous Liquid AI d1-3B. Liquid le décrit comme le meilleur score pour un modèle de décision de moins de 10 milliards de paramètres et le place devant un modèle 35B-A3B à 47,11. • Latence de décision textuelle — 200–300 ms, publiée sous Liquid AI d1 dans l’article sur l’API hébergée. Aucun chiffre équivalent n’est rattaché au nom propre du checkpoint ouvert. • Latence pour une question unique sur du matériel local — 8 ms sur une RTX 4090, 16 ms sur un Jetson AGX Thor, 26 ms sur un Jetson AGX Orin 64 GB, 50 ms sur un Orin Nano, 30 ms sur un Apple M5 Pro. Publiée sous Liquid AI d1-3B. • Débit — 475 décisions par seconde sur la RTX 4090 et 1 106 par seconde sur un AMD MI325X avec des questions regroupées en lots. Publié sous Liquid AI d1-3B. • Vision — une moyenne de 74,1 sur onze benchmarks publics d’images, contre 73,9 pour la base LFM2.5-VL-3B dont il est issu. Publiée sous Liquid AI d1-3B. • Ablation d’image — le même ensemble de questions, auquel on a retiré les images, obtient 45,1, ce qui est la mesure du fournisseur lui-même de ce qu’apporte la branche vision. Publiée sous Liquid AI d1-3B.

Deux problèmes ressortent de cette liste, et aucun des deux n’est fatal, ce qui explique précisément pourquoi ils passent inaperçus. Le chiffre hébergé et le chiffre local présentent un écart de 25 à 37 fois — 200–300 ms contre 8 ms — et ils ont été mesurés sur des éléments que le fournisseur ne décrit pas en termes comparables. Interpréter cet écart comme « le local est plus rapide » n’est pas étayé, car le chiffre hébergé est de bout en bout via une API et les 8 ms correspondent à une passe avant sur un GPU nommé. Ce ne sont pas les mêmes mesures, et le fournisseur ne prétend jamais qu’elles le sont.

Le deuxième problème est la ligne vision. Une amélioration de 0,2 point par rapport au modèle de base sur onze benchmarks d’images se situe dans le bruit de la plupart des rapports de benchmarks, donc quoi que la tête de décision vous apporte, ce n’est pas un encodeur d’images sensiblement meilleur. La ligne d’ablation paraît bien plus impressionnante dans l’autre sens — un écart d’environ 29 points lorsque les images sont ajoutées — mais elle compare deux ensembles de questions différents plutôt que deux versions d’un même ensemble, ce que Liquid indique dans le post lui-même. Les deux lignes sont utiles. Aucune des deux ne soutient une affirmation forte sur la qualité des décisions visuelles, et aucun tiers n’a exécuté ni l’une ni l’autre.

Là où les deux noms divergent en pratique

Pour un acheteur, la distinction se résume à quatre questions, et les réponses ne vont pas toutes dans le même sens.

• Structure des coûts — Liquid AI d1 est facturé par jeton d’entrée, au tarif publié par le fournisseur, sans jeton de sortie à payer. Liquid AI d1-3B est un téléchargement de 2,87 Go dans l’empaquetage d’Ollama ou de 1,67 Go depuis le dépôt GGUF du fournisseur, sans aucun compteur par appel. • Latence, mesurable — la voie hébergée annonce 200–300 ms par décision textuelle. Les 8 ms publiés de la voie locale correspondent à une passe avant sur une RTX 4090 avec un modèle chaud, ce qui est un chiffre réel et non un aller-retour de requête. • Chemin des données — la voie hébergée envoie l’état au fournisseur. La voie locale le garde sur la machine, ce qui, pour un ticket d’assistance, une note médicale ou une photographie, est généralement l’argument qui clôt le débat. • Épinglage de version — Liquid AI d1 derrière un point de terminaison, c’est ce que le fournisseur sert aujourd’hui. Liquid AI d1-3B dans Ollama est un paquet fixe que vous contrôlez, et le compromis est que vous vous chargez des mises à niveau.

La réalité embarrassante qui sous-tend les quatre, c’est que le checkpoint ouvert est un modèle frère du modèle hébergé plutôt qu’un substitut de celui-ci, et le fournisseur n’a pas dit le contraire. La fiche de modèle du checkpoint ouvert le recommande pour le routage et le triage, la modération, la classification d’intention, les contrôles d’extraction, le reranking, l’utilisation d’un LLM comme juge et les garde-fous, et le décrit comme post-entraîné sur LFM2.5-VL-3B pour des décisions calibrées en une seule passe. Le billet consacré à l’offre hébergée décrit le même ensemble de tâches avec d’autres mots et cite le tarif de l’offre hébergée. S’il s’agit d’un seul et même modèle, la version locale est une copie gratuite d’un produit hébergé, ce qu’un laboratoire ferait rarement sans le dire. S’il s’agit de deux affinages d’une base commune, il ne faut pas présumer que les chiffres publiés sont transposables dans un sens ou dans l’autre. La seconde explication exige moins du fournisseur et correspond mieux aux éléments dont nous disposons.

Exécuter les deux moitiés de la décision sans exécuter deux piles

Quel que soit le nom sur lequel vous vous arrêtez, le pipeline qui l'entoure a tendance à se ressembler. Une file d'attente du support reçoit une question à choix portant sur une équipe de destination, une question booléenne pour savoir si un remboursement est demandé, et une question de score pour l'urgence — un état, trois réponses, une seule passe. Là où les deux noms divergent véritablement, c'est au moment où la décision conditionne un appel à un modèle génératif que vous louez au lieu de l'exécuter vous-même. Cet appel est un problème différent, avec un profil de défaillance différent, et c'est la partie du pipeline où le fait que d1 soit juste importe le moins : une réponse de routage à 0,98 de probabilité suivie d'un 502 de la part du modèle vers lequel vous avez routé reste une requête échouée dans les deux cas.

Nous n'hébergeons aucun modèle Liquid AI — nous avons vérifié notre propre catalogue avant d'écrire ces lignes — donc rien ici n'affirme que ces poids soient appelables via nous. Ce que nous faisons, c'est la couche située de l'autre côté de la décision : une seule clé compatible OpenAI pour les modèles vers lesquels une requête triée se ramifie, au prix catalogue de chaque fournisseur, répercuté avec 0 % de marge, de sorte qu'une baisse de prix d'un fournisseur vous parvienne le jour où elle entre en vigueur plutôt qu'au renouvellement du contrat, avec le basculement automatique entre fournisseurs afin qu'une requête triée survive à la mise hors ligne du modèle vers lequel vous l'avez dirigée. Si vous intégrez pour la première fois un modèle de décision dans un pipeline, c'est cette moitié-là qu'il vaut la peine de rendre ennuyeuse.

Quel nom utiliser, selon la situation

Si vous voulez essayer le modèle cette semaine sans environnement Python qui vaille la peine d’être maintenu, utilisez le nom qu’utilise le runtime local. Téléchargez Liquid AI d1 depuis la bibliothèque, acceptez Q8_0 et 3,7 Go, et considérez le plafond de requêtes de 64 Kio et la règle d’absence de streaming comme des contraintes de conception plutôt que des nuisances. Vous obtenez un véritable point de terminaison, de vraies réponses typées et aucun compteur par appel dès le premier jour.

Si vous avez besoin d'une empreinte plus réduite que Q8_0, le nom à utiliser est Liquid AI d1-3B, car la version Q4_K_M de 1,67 Go se trouve dans le dépôt GGUF du fournisseur et non dans la fiche de la bibliothèque. Ce simple fait constitue la différence la plus pratique entre les deux noms aujourd'hui, et c'est celui qui a le plus de risques d'échapper à quiconque lit la page de la bibliothèque et s'arrête là.

Si vous présentez cela à des utilisateurs payants et avez d'abord besoin de preuves de précision, aucun des deux noms ne vous aide pour l'instant. Il n'existe aucune évaluation indépendante d'un modèle d1 que nous ayons pu trouver, les lignes du Decision Index étaient auto-évaluées, et le fournisseur n'a publié aucun benchmark de décision audio. Ce que vous pouvez faire, c'est instrumenter la valeur de confiance que le modèle renvoie déjà — de 0 à 1, reflétant la force avec laquelle les probabilités favorisent une réponse plutôt que la probabilité que cette réponse soit juste — et découvrir sur votre propre trafic où la chose est incertaine. Cette mesure vaut plus que n'importe laquelle des diapositives ci-dessus, et elle prend une journée.

Le modèle de décision est la moitié la moins coûteuse du pipeline. Le modèle génératif vers lequel il oriente est la moitié qui a besoin d’un contrat — une clé compatible OpenAI porte les modèles vers lesquels se ramifie une requête triée, chacun au prix catalogue de son fournisseur, répercuté avec 0 % de marge.

Dimensionner un checkpoint distillé à la baisse par rapport à sa propre version complète publiée est aussi un bon moment pour consulter l’historique : les incidents d’IA et les défaillances d’agents documentés liés aux petits modèles Liquid sont recensés dans l’OrcaRouter AI Incident Archive, où chaque entrée comporte ses propres sources, un degré de gravité, une note de confiance et un indicateur de contestation.