Liquid AI d1-ultra vs Liquid AI d1-3B : un endpoint loué à 0,042 $ le million, ou un checkpoint de 2,87 Go que vous possédez

Liquid AI d1-ultra est facturé 0,042 $ par million de jetons d'entrée et tourne sur l'accélérateur d'un tiers, dans le centre de données d'un tiers. Liquid AI d1-3B n'est facturé à rien par appel et tourne sur un Jetson Orin Nano posé sur un bureau. Ces deux phrases décrivent des modèles que Liquid AI a publiés à huit jours d'intervalle — d1-3B comme checkpoint à poids ouverts annoncé le 7 octobre 2026, d1-ultra comme modèle uniquement disponible via API le 15 octobre — et elles décrivent exactement la même tâche : confier au modèle un état composé de texte, d'images ou des deux, lui confier un ensemble de questions typées, et obtenir en retour des réponses calibrées à partir d'une seule passe avant, sans qu'un seul jeton de sortie soit généré. Ni l'un ni l'autre n'écrit de la prose. Ni l'un ni l'autre ne diffuse en continu. La différence entre eux n'est pas de savoir « lequel est le plus intelligent » dans l'abstrait, car la réponse honnête dépend entièrement de combien de fois par jour vous posez la question. Pour un modèle dont les modes de défaillance ne sont pas encore documentés, le pendant utile est le registre de ce qui a déjà mal tourné ailleurs : les incidents d'IA documentés et les défaillances d'agents autour des modèles de cette classe sont rassemblés dans l'OrcaRouter AI Incident Archive où chaque entrée comporte ses propres sources, son niveau de gravité, son niveau de confiance et son indicateur de contestation.

Ce cadrage est la raison pour laquelle cette comparaison vaut plus qu’une fiche technique. d1-3B et d1-ultra se situent aux extrémités opposées d’un choix que Liquid AI a désormais explicité dans sa propre documentation : vous pouvez louer le modèle le plus performant de la famille au token, ou bien posséder un modèle de 3,12 milliards de paramètres et payer à la place en silicium, en électricité et en heures d’ingénierie. Les deux sont des produits actuels. d1-ultra est le tout dernier produit livré par l’entreprise, et d1-3B est celui par lequel la plupart des lecteurs devraient probablement commencer. Déterminer lequel convient à un pipeline donné est une question arithmétique avec un véritable point de bascule, et elle peut être tranchée avec des chiffres publiés — ce qui suit.

Une note sur les sources avant les chiffres, car elle importe plus que leur mise en forme. Presque tout ce qui suit provient des propres publications de Liquid AI : les fiches de modèle, le billet du 7 octobre sur les poids ouverts et le billet du 15 octobre sur d1-ultra. Nous n'avons reproduit indépendamment aucun benchmark de modèle décisionnel pour cet article et, pour autant que nous puissions en juger, personne d'autre ne l'a fait non plus. Lorsqu'un chiffre résulte de notre calcul sur un nombre publié plutôt que d'une mesure de quiconque, la phrase qui l'accompagne le précise.

Ce qu’est réellement chaque modèle, à la mi-octobre 2026

Liquid AI d1-3B est un modèle de décision à poids ouverts de 3,12 milliards de paramètres, entraîné à partir de LFM2.5-VL-3B, un modèle vision-langage à décodeur seul. Il embarque un encodeur visuel SigLIP2 NaFlex 400M, une fenêtre de contexte de 32 768 tokens et un vocabulaire de 128 000 tokens, prend du texte, du JSON, des images ou un mélange de ceux-ci comme état, et répond à une ou plusieurs questions — Choice, Score, ou noul, la primitive oui/non qui renvoie une probabilité entre 0 et 1 — en une seule passe avant. Les poids sont sur Hugging Face sous la LFM Open License, que le fournisseur décrit comme libre d'utilisation, y compris à des fins commerciales en dessous de 10 millions de dollars de chiffre d'affaires annuel. La prise en charge de llama.cpp dès le premier jour est annoncée, avec des builds NVFP4 sur Apple, AMD, Qualcomm et NVIDIA.

Liquid AI d1-ultra is the same shape of product pointed at a harder problem. It is API-only — there are no weights, no GGUF, no MLX or ONNX export, and the vendor's documentation index lists it in a row whose only downloadable artifact is the word "API". It was built, per the announcement, on "a larger open-weight model with a series of Liquid-specific heavy customizations," which is the entire architectural disclosure: no parameter count, no context window and no latency figure appear on the vendor's pages. Third-party gateway listings put the context window at 32,768 tokens and one listing has described it as roughly 8.3B total parameters with about 1.5B active per token, but those are catalogue entries, not vendor statements, and we treat them as unconfirmed. The model string is d1-ultra, on the same endpoint as d1: https://api.liquid.ai/decisions/v1/systemone.

Si ces paragraphes sont si déséquilibrés, ce n’est pas pour des raisons éditoriales. C’est toute la comparaison. d1-3B est documenté à un niveau de détail qui permet de dimensionner le matériel avant même de télécharger quoi que ce soit. d1-ultra est documenté à un niveau de détail qui permet de l’appeler et rien de plus.

Les deux numéros d’index ne se situent pas sur la même règle.

Chaque article secondaire consacré à ce duo placera 65 à côté de 48,57 et vous laissera tirer la conclusion évidente. Lisez d’abord les libellés, car les deux nombres ont été publiés sous des instruments différents.

• le chiffre de d1-3B — 48,57, sur le split public de Decision Index v0.2.1, dans l'article de publication du 7 octobre. Le fournisseur déclare en outre que le modèle devance tout ce qui est sous 10B et se situe au même niveau que Decider 35B-A3B, un modèle douze fois plus grand.

• le chiffre de d1-ultra — 65, décrit dans la publication du 15 octobre comme étant en tête de l'Artificial Analysis Decision Index avec au moins huit points d'avance, et accompagné de l'affirmation que d1-ultra surpasse Jev 1.14 sur toutes les tâches. La couverture médiatique de l'annonce a rapporté Jev 1.14 à 57, ce qui est cohérent avec une avance de huit points.

Deux choses sont vraies et méritent d’être dites clairement. Premièrement, l’indice derrière le 65 de d1-ultra est celui d’un tiers, mais le chiffre nous est parvenu via l’annonce de Liquid AI elle-même et via les articles de presse qui en ont parlé — nous n’avons pas pu charger nous-mêmes un tableau public affichant 65 — il est donc rapporté par le fournisseur dans cet article. Deuxièmement, rien ne garantit qu’un score sur split public en version 0.2.1 et un score d’indice non versionné soient sur la même échelle, et l’indice v0.3 comporte un split vision privé sur lequel la version ouverte n’a explicitement pas fourni de résultats. Considérez l’écart comme directionnel — le modèle payant est nettement meilleur — et non comme une mesure de 16,4 points. Personne, y compris nous, n’a fait passer ces deux modèles par un harnais commun.

Latence : un chiffre est publié, l'autre ne l'est pas.

La vitesse du modèle ouvert est exceptionnellement bien documentée, ce qui rend l'omission sur le modèle payant d'autant plus flagrante. La fiche de d1-3B rapporte une seule question en 8 ms sur une RTX 4090, 9 ms sur un AMD MI325X, 16 ms sur un Jetson AGX Thor, 26 ms sur un Jetson AGX Orin 64 GB, 30 ms sur un Apple M5 Pro et 50 ms sur un Jetson Orin Nano, avec un débit en mode groupé atteignant 1 106 décisions par seconde sur le MI325X.

Il s'agit de temps de passe avant sur du matériel explicitement désigné, et non de temps de requête de bout en bout, et la distinction n'a rien de pédant. La dernière fois que Liquid AI a publié une latence hébergée pour un modèle de décision — le billet du 5 octobre présentant d1 — elle était de 200 à 300 ms pour une décision textuelle, soit un aller-retour API incluant la mise en file d'attente et le réseau, et elle n'est pas comparable à une passe de 8 ms sur une carte locale. Pour d1-ultra, le fournisseur n'a publié aucun chiffre de latence, sous aucune des deux formes. Si votre pipeline est limité par la latence plutôt que par la précision, cette absence est l'élément le plus important de cette page : vous ne pouvez pas, à l'heure actuelle, dire si le modèle coûteux est rapide, et le seul moyen de le savoir est de le mesurer vous-même.

L’arithmétique que les pages marketing ne font pas

C'est ici que les deux produits divergent véritablement, et c'est un calcul que l'on peut faire sur un coin de table. Prenons une étape de triage du support qui pose une question noul par ticket, 200 000 tickets par mois, avec environ 1 200 jetons d'entrée par question, y compris une petite capture d'écran. Cela fait 240 millions de jetons d'entrée par mois, la quantité qui rend lisible le tarif par million.

• Sur d1-ultra à 0,042 $ par million de tokens d’entrée, cela représente environ 10,08 $ par mois. Sur d1-3B à zéro par appel, cela fait 0,00 $ par mois, plus ce que coûte le matériel.

• Une build Q8_0 de 2,87 Go tient confortablement sur un Jetson Orin Nano. Si vous achetez cette machine spécifiquement pour cette charge de travail, le délai de rentabilité par rapport au point de terminaison hébergé se compte en années, pas en semaines — ce qui est la conclusion honnête, et non celle qu’un fabricant de matériel imprimerait.

• Inversez le volume. À 200 millions de questions par mois — 240 milliards de jetons d’entrée — la facture de d1-ultra s’élève à environ 10 080 $ par mois, et le build local consomme toujours la même électricité. C’est là que posséder le checkpoint cesse d’être une préférence philosophique pour devenir un poste budgétaire.

Trois mises en garde, qui vont toutes dans le même sens. Tous les décomptes de tokens ci-dessus sont ceux que nous avons choisis ; la longueur de votre état et le nombre de vos images seront différents, et les images sont facturées comme du texte à raison de 1,5 token par patch de 32×32 pixels, donc une seule image de 1024×1024 représente 1 536 tokens d’entrée. Chaque question est facturée comme son propre prompt, incluant son texte et toutes ses images, donc poser trois questions sur la même capture d’écran revient à payer cette capture d’écran trois fois. Et rien de tout cela n’inclut le coût d’ingénierie : la voie locale vous vaut un choix de quantification, un runtime à maintenir à jour, et un encodeur visuel qui consomme de la mémoire avant même les 3,12 B de poids. Si vous appelez un modèle quelques milliers de fois par mois, le point de terminaison hébergé est moins cher que la réunion où vous décidez de l’auto-héberger.

Là où chacune cesse d’être la bonne réponse

Liquid AI d1-3B est le choix par défaut approprié lorsque l'un de ces éléments constitue la contrainte déterminante : les données ne peuvent pas quitter les locaux ou l'appareil ; le saut réseau est inacceptable ; le volume est suffisamment élevé pour que la tarification à l'appel devienne le coût dominant ; ou l'état est une image de caméra en direct ou une capture d'écran que vous préférez ne pas envoyer à un tiers. Le positionnement du fournisseur lui-même étaye le premier de ces points — la version ouverte est explicitement destinée à un déploiement en périphérie et sur appareil, sur le matériel NVIDIA DGX, RTX et Jetson — et les 17 820 téléchargements enregistrés par le checkpoint au cours de son premier mois suggèrent que beaucoup de personnes sont rapidement arrivées à la même conclusion.

Liquid AI d1-ultra est la bonne réponse lorsque la décision elle-même est la partie difficile. Questions à forte composante de connaissances, affirmations visuelles qui doivent être confrontées au contexte du monde réel — les exemples du fournisseur lui-même sont les défauts de circuits imprimés et la mise en correspondance d'une réclamation pour dommage avec une photo client — et cas de longue traîne où la confiance d'un modèle 3B ne mérite tout simplement pas qu'on lui fasse confiance. L'affirmation spécifique que Liquid AI avance pour ce modèle n'est pas seulement l'exactitude, mais la calibration : la plupart des modèles de décision sont trop confiants, soutient l'article, et d1-ultra a été entraîné de sorte que ses probabilités aient un sens. Si vous appliquez un seuil sur une probabilité plutôt que de prendre l'argmax — en routant tout ce qui dépasse 0,8 vers une résolution automatique et tout le reste vers un humain —, la calibration est tout l'enjeu, et c'est aussi l'affirmation de cette version qui est la plus difficile à vérifier pour un observateur extérieur.

Les cas où ni l’un ni l’autre n’est le bon choix méritent aussi d’être nommés. Si votre réponse est un texte libre, une trace en plusieurs étapes ou un résumé, un modèle de décision n’est pas l’outil approprié, et le fournisseur le dit dans sa propre documentation. Si vous avez besoin d’audio dans l’état plutôt que de texte et d’images uniquement, le troisième membre de la famille, d1-omni-600M, est celui qui le prend en charge — utiliser d1-ultra pour ce travail n’est pas une mise à niveau, c’est une erreur de catégorie.

Intégrer cela dans une stack que vous exploitez déjà

Un modèle de décision ne constitue presque jamais l’intégralité du pipeline. C’est la porte : ce qui décide si un ticket est urgent, si une photo correspond à un défaut, si un appel d’outil est approuvé. Quelque chose doit encore écrire la réponse, et sur la voie locale, ce quelque chose est un second modèle que vous devez désormais héberger — c’est le coût réel du passage à l’auto-hébergement, et celui qui n’apparaît jamais dans la comparaison par token. Le schéma qui fonctionne réellement à petit et moyen volume est un d1-3B local pour la porte à haute fréquence et un endpoint loué pour le cas difficile rare, avec une clé OrcaRouter portant les modèles génératifs vers lesquels ces décisions se ramifient : une seule API sur plus de 200 modèles, prix catalogue des fournisseurs répercuté avec 0 % de marge, et basculement automatique entre fournisseurs afin qu’un mauvais après-midi chez un seul fournisseur en amont ne transforme pas votre file de triage en arriéré. Il convient d’être précis sur ce que cela couvre et ne couvre pas — nous n’hébergeons aucun modèle Liquid AI, donc l’appel de décision lui-même est envoyé à l’API de Liquid AI ou au checkpoint local, et OrcaRouter est ce qui se trouve derrière.

Dès que l’on cesse de traiter le modèle de décision comme fixe, la comparaison cesse d’être binaire. Le DSL de routage permet de composer une porte bon marché et un rédacteur coûteux en un seul appel, et la fusion permet à un panel de modèles de répondre ensemble lorsqu’un seul n’est pas suffisamment fiable. Aucun de ces deux éléments n’est une raison de préférer d1-ultra à d1-3B. Tous deux sont des raisons de reconsidérer ce choix au volume où l’arithmétique bouge réellement.

Qu’est-ce qui changerait cette réponse ?

Trois choses, par ordre de probabilité. Un benchmark indépendant qui fait passer d1-3B et d1-ultra dans le même harnais sur les mêmes tâches — à ce moment-là, l’écart entre 48,57 et 65 devient une mesure plutôt qu’une estimation indicative. Une latence publiée pour d1-ultra, sans laquelle tout pipeline sensible à la latence devrait considérer le modèle hébergé comme un inconnu et le mesurer d’abord dans un chemin canari. Et, à terme, une version open-weight construite sur le backbone plus grand, que l’historique de la famille rend moins invraisemblable qu’elle n’en a l’air : tous les autres modèles d1 qui ont commencé en hébergé ont fini par être téléchargeables en deux jours.

D'ici là, la règle empirique reste valable. Commencez par d1-3B, car il est gratuit à essayer, rapide sur du matériel que vous possédez peut-être déjà, et suffisamment bien documenté pour dimensionner correctement avant de vous engager. Déplacez vers d1-ultra les décisions spécifiques qui s'avèrent peu convaincantes. L'écart entre les deux est réel ; il est simplement plus étroit que ne le suggère la différence de prix, et bien plus étroit que ne le laissent entendre les chiffres d'indice lorsqu'on les imprime côte à côte sans leurs libellés de version.