Liquid AI d1-3B débarque sur Ollama : un point de terminaison local discret pour un modèle de décision

Il y a un nouveau d1 dans la bibliothèque d'Ollama, et ce n'est pas un modèle de conversation. L'entrée le décrit en une seule ligne — « un modèle de décision 3B de Liquid AI, construit sur LFM2.5-VL-3B » — et cette phrase contient à elle seule les deux faits qui comptent le plus. Liquid AI d1-3B, le petit modèle que Liquid AI a construit par-dessus Liquid AI LFM2.5-VL-3B et publié en poids ouverts le 5 octobre 2026, est désormais empaqueté de sorte qu'un simple pull le dépose sur votre propre machine ; et il renvoie toujours des probabilités calibrées sur des questions typées plutôt que du texte généré, exactement comme le fait le checkpoint sous-jacent. Si vous avez une étape de triage, de routage, de modération ou de filtrage dans un pipeline, c'est la première fois que cette famille de modèles précise se trouve à une commande d'être exécutée sans clé API, sans coût par appel et sans qu'aucun texte d'état ne quitte votre matériel.

Le mot « quiet » joue toutefois ici un vrai rôle, et il vaut la peine d'être précis sur la moitié de cette histoire qui est documentée et sur celle qui ne l'est pas. Le blog de Liquid AI lui-même n'a jamais mentionné Ollama : l'article le plus récent du laboratoire, daté du 13 octobre 2026, porte sur un autre modèle de la gamme LFM2.5, et ses deux articles sur d1 — l'annonce du 5 octobre consacrée à la vision et la sortie « Open d1 » du 7 octobre — décrivent des poids, une API et un score de benchmark, pas un runtime local. La page de bibliothèque d'Ollama pour d1 ne porte aucune annonce non plus, et l'index de documentation du fournisseur non plus, qui coche GGUF comme disponible pour Liquid AI d1-3B et son homologue capable d'audio Liquid AI d1-omni-600M tout en ne citant llama.cpp, Ollama et MLX que comme options de déploiement génériques. Ce qui existe, c'est un paquet publié, une entrée de registre avec un digest que vous pouvez vérifier, un readme fonctionnel, et un compteur de téléchargements qui affichait 10,4 K au moment où ceci a été écrit, le 15 octobre 2026. Ce qui n'existe pas, c'est une phrase du fournisseur disant « c'est nous qui l'avons fait ».

Ce que l'annonce contient réellement

Trois tags sont listés — d1:latest, d1:3b et d1:3b-q8_0 — et tous les trois renvoient au même digest de manifeste, 8c2d9ddae441. C'est la première chose à comprendre à propos de cette page : le compteur « 3 modèles » de la bibliothèque compte des tags, pas des checkpoints. Un seul artefact, trois noms, 3,7 Go, une fenêtre de contexte de 32K, et une entrée texte et image. Si vous espériez choisir une taille ou une quantification, il n'y a encore rien à choisir.

Le registre derrière la page est plus informatif que la page. Le blob de configuration du paquet indique une famille de modèles lfm2, un type de modèle 2.7B, un type de fichier Q8_0 et un runtime minimal Ollama 0.40.4. Il est livré en deux couches de poids : un modèle génératif de 2,87 Go et un projecteur distinct de 856 Mo. Cette deuxième couche est l'encodeur visuel, et sa présence indique que le build local conserve la voie multimodale plutôt que de réduire d1 au texte — le modèle peut encore lire une photographie aux côtés d'un ticket d'assistance et répondre à des questions sur les deux. Les deux nombres sur cette page qui semblent se contredire — « 3B » dans la description et « 2.7B » dans le registre — se lisent mieux comme le tronc et l'ensemble : la fiche de modèle de Liquid AI situe le checkpoint à 3.12B de paramètres, y compris un encodeur visuel de 400M de paramètres, et le tronc linguistique est le chiffre le plus petit. Ce calcul est le nôtre, pas celui du fournisseur, et il est proposé à titre d'explication plutôt que de spécification.

Il n'existe aucune date calendaire nulle part sur la page de la bibliothèque. Elle affiche des horodatages relatifs — « Updated 2 hours ago » au moment de la capture — et un compteur de téléchargements, ce qui signifie que le jour où cette fiche est apparue pour la première fois n'est pas connaissable à partir de la fiche elle-même. Les repères datés se trouvent tous sur Hugging Face et chez le fournisseur : le dépôt de poids pour Liquid AI d1-3B a été créé le 5 octobre 2026, un dépôt GGUF compagnon le 6 octobre, et Liquid AI a publié son billet d'annonce le 7 octobre. Si vous devez mettre une date sur « quand cela est devenu exécutable localement », la réponse honnête aujourd'hui est que le paquet existe et est en cours de téléchargement, et personne en dehors d'Ollama ne peut dire quel matin il a été mis en ligne.

Pourquoi un événement packaging est un véritable événement

Ollama a ouvert une catégorie de modèles de décision le 29 septembre 2026, lorsqu’elle a livré le point de terminaison /v1/systemone et un indicateur CLI --ask pour les modèles qui répondent à des questions typées en une seule passe avant. Nimble et Clef ont été les premières familles à franchir cette porte. Ce que le nouveau paquet d1 apporte est autre chose qu’une nouvelle ligne de benchmark : il prend un modèle qui jusqu’ici vivait soit dans un environnement Python avec une classe de modèle embarquée, soit derrière un point de terminaison hébergé, et il fait de l’inférence locale une commande.

Le contrat mérite d’être reformulé, car il ne correspond pas à ce que la plupart des lecteurs entendent par « exécuter un modèle ». Vous transmettez à d1 un état — une chaîne, un objet JSON, un tableau, ou une chaîne accompagnée d’images — ainsi qu’un ensemble de questions nommées, et vous recevez des réponses sans aucun jeton généré. noul est une question oui/non à laquelle on répond par une seule probabilité comprise entre 0 et 1. choice renvoie l’étiquette sélectionnée, une confiance et une carte de probabilités complète sur vos options. score place l’état sur une grille ordonnée de deux à dix niveaux et renvoie le niveau pondéré par les probabilités ainsi que la probabilité de chaque niveau. Un seul état, jusqu’à 64 questions, une seule passe sur l’entrée. La réponse d’exemple d’Ollama pour un ticket d’assistance renvoie usage.output_tokens: 0, ce qui constitue l’expression la plus claire possible du concept.

Pour quiconque dont le pipeline appelle déjà un modèle de décision via HTTP, la voie locale change trois choses à la fois : la latence, car la requête cesse de quitter la machine ; le coût, car il n’y a pas de compteur par appel ; et le traitement des données, car le texte du ticket et la photographie que vous classez ne traversent jamais le réseau. Si ce que vous traitez est le message d’un client ou un document interne, ce dernier argument est généralement le seul qu’il faille avancer.

L'exécuter, et les limites que la doc lui impose

Il existe trois façons d'accéder au système, et elles sont toutes documentées sur la page de la bibliothèque. La voie CLI est ollama run d1 --ask « Is a refund being requested? » avec l'état transmis via un pipe depuis un fichier, et les options --choice et --level pour les deux autres types de questions. La voie HTTP est un POST vers http://localhost:11434/v1/systemone avec un modèle, un état, un tableau images facultatif et un objet questions. La voie SDK pointe le client Python de TypeSafe vers localhost, où la clé API est ignorée et n'importe quelle valeur de remplacement fonctionne.

Les limites proviennent de la documentation du point de terminaison d'Ollama plutôt que de Liquid AI, et elles sont plus strictes que celles d'un modèle génératif : les requêtes doivent tenir dans 64 Kio sans images et 32 Mio avec, la diffusion en continu n'est pas prise en charge, les modèles hébergés dans le cloud sont rejetés d'emblée, et les images doivent être des PNG, JPEG ou WebP en base64 envoyés dans le corps de la requête — les URL distantes sont refusées. Les images sont partagées par chaque question d'une requête, donc une image que vous ne voulez voir prise en compte que pour la première réponse doit être envoyée dans son propre appel. L'entrée n'est jamais tronquée, ce qui signifie qu'un état surdimensionné constitue une erreur plutôt qu'une invite silencieusement tronquée.

Deux détails de documentation méritent d’être signalés comme non résolus. La référence du point de terminaison d’Ollama décrit le type choice comme acceptant de 2 à 255 clés d’option, tandis que la page de capacités des modèles de décision indique de 2 à 26 — l’un des deux est obsolète, et l’on ne voit pas clairement lequel. Et la page de capacités nomme ses modèles pris en charge Nimble, Tev1, Clef et Clef Flash, sans mentionner d1, même si le readme du paquet d1 lui-même indique qu’il fonctionne via /v1/systemone et --ask. Le paquet nécessite Ollama 0.40.4 ; le minimum documenté pour le point de terminaison lui-même est 0.35.0. Rien de tout cela n’est une contradiction qui vous empêche de récupérer le modèle, mais lisez la version requise sur le paquet plutôt que celle du guide des capacités.

Les chiffres, et qui a produit chacun d'entre eux

Maintenant, la partie qui mérite le plus de prudence. Chaque chiffre de performance associé à ce modèle provient de Liquid AI, et il n'existe aucune évaluation indépendante de Liquid AI d1-3B pour autant que nous puissions le constater. Les résultats rapportés par le fournisseur, repris sur la page Ollama et sur la fiche du modèle, sont les suivants :

• Decision Index 0.2.1 — 48,57 pour d1-3B, contre 47,11 pour Decider 35B-A3B, que Liquid décrit comme le meilleur score pour un modèle de décision de moins de 10 milliards de paramètres. • 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. • Latence — 8 ms par décision sur une RTX 4090, 9 ms sur une AMD MI325X et 30 ms sur une Apple M5 Pro. • Débit — 475 décisions par seconde sur la 4090 et 1 106 sur la MI325X lorsque les questions sont regroupées en lots. • Ablation — le même ensemble de questions traité sans images obtient 45,1, ce qui constitue la propre mesure de Liquid de la contribution de la voie vision.

La ligne vision est celle qui devrait modérer les attentes. Une amélioration de 0,2 point par rapport au modèle de base sur un ensemble de benchmarks d'images se situe dans le bruit de la plupart des rapports de benchmark ; quoi que la tête de décision vous apporte, ce n'est pas un encodeur d'images nettement meilleur. La ligne d'ablation est plus intéressante dans l'autre sens — une variation d'environ 29 points lorsque les images sont ajoutées — mais elle compare deux ensembles de questions différents, et non deux versions du même ensemble. Et l'indice de décision est un instrument tiers sur lequel Liquid a noté ses propres entrées plutôt que de les soumettre à un classement public, alors considérez 48,57 comme une affirmation de fournisseur faite avec la règle de quelqu'un d'autre. Les chiffres de vitesse ne sont pas non plus audités : 8 ms sur une 4090 est un chiffre plausible pour un modèle 3B effectuant une seule passe avant, et il reste vrai que personne n'a publié une exécution qui ne lui appartient pas.

Là où OrcaRouter est pertinent, et là où il ne l'est pas

OrcaRouter ne sert pas Liquid AI d1-3B. Nous avons vérifié notre catalogue avant d’écrire ceci — 207 modèles, aucun de Liquid AI, aucun modèle de décision — donc si vous voulez appeler d1 depuis une API plutôt que depuis votre propre matériel, la voie hébergée aujourd’hui est le point de terminaison de décision du fournisseur lui-même à api.liquid.ai/decisions/v1/systemone, où un palier payant d1 gère les images et un palier gratuit d1:free est uniquement textuel, plus les plateformes tierces qui l’adoptent. Rien dans cet article ne doit être interprété comme une affirmation selon laquelle nous l’hébergeons.

Ce que nous faisons est adjacent au problème que ce modèle résout. Si un modèle de décision existe, c'est parce que les pipelines ont besoin d'un moyen peu coûteux et déterministe de choisir parmi des options, et l'exemple documenté de d1 lui-même est un ticket routé vers une équipe de destination — ce qui est un problème de routage un niveau en dessous du nôtre. Lorsque cette décision conditionne un appel à un modèle génératif que vous louez plutôt que d'exécuter, OrcaRouter est une clé compatible OpenAI pour plus de 200 modèles hébergés au prix catalogue du fournisseur, répercutée avec 0 % de marge, de sorte qu'une baisse de prix d'un fournisseur vous parvient le jour où elle est appliquée plutôt qu'au prochain renouvellement de contrat. Et comme la moitié locale de ce pipeline est celle que vous possédez, le risque se situe dans la moitié hébergée : la bascule automatique entre fournisseurs maintient en vie une requête triée lorsque le modèle vers lequel vous l'avez routée tombe en panne. Ni l'un ni l'autre n'est une raison d'utiliser un modèle de décision 3B. Ce sont des raisons pour lesquelles l'élément de l'autre côté de la décision ne devrait pas être un point de défaillance unique.

Qu'est-ce qui pourrait transformer cette note d'emballage en une histoire ?

Cinq choses, dont n'importe laquelle changerait la lecture. Que Liquid AI reconnaisse le portage, ou que son index de documentation ajoute Ollama à la ligne de déploiement qu'il remplit actuellement avec llama.cpp et MLX. Une seconde quantification : le propre dépôt GGUF de Liquid AI propose Q4_K_M, F16 et BF16 aux côtés de Q8_0, donc une version locale plus petite est techniquement disponible, simplement pas via ce paquet. Un chemin local pour Liquid AI d1-omni-600M, le frère de 587 M de paramètres qui lit jusqu'à trente secondes d'audio et que le fournisseur qualifie de version de recherche précoce — celui-là compterait davantage que le 3B pour le travail embarqué, et on n'en voit encore la trace dans aucune bibliothèque. Une ligne indépendante dans le Decision Index, ou une entrée dans un classement public, qui est la seule pièce manquante dans toute cette famille de modèles. Et qu'Ollama ajoute d1 à sa page de capacités décisionnelles, un changement d'une seule ligne qui vous dirait que le portage est entériné plutôt qu'accidentel.

D'ici là, la décision est assez simple à prendre selon vos propres conditions. Si vous exécutez déjà une version récente d'Ollama, le pull se fait en une seule commande, le téléchargement fait 3,7 Go, et ce qu'il remplace est soit un appel hébergé que vous préféreriez ne pas faire avec le texte d'un client, soit un environnement Python dont la maintenance demande plus de travail que le modèle ne le vaut. Si vous avez besoin de preuves indépendantes de l'exactitude avant que cela ne soit mis devant de vrais utilisateurs, ces preuves n'existent encore pour aucun modèle d1, et aucune quantité d'empaquetage local ne les créera.

Exécuter l’étape de décision sur votre propre matériel est aussi l’occasion de regarder ce qui a déjà mal tourné dans cette catégorie : les incidents d’IA documentés et les défaillances d’agents impliquant des modèles de décision sont recensés dans l’OrcaRouter AI Incident Archive, où chaque entrée comporte ses propres sources, un niveau de gravité, une note de confiance et un indicateur de contestation.