Liquid AI d1-omni-600M est désormais disponible au téléchargement sur Ollama : un modèle de décision de 600 M qui peut vous entendre

Liquid AI d1-omni-600M est devenu un paquet Ollama le 17 octobre 2026 à 22:32 UTC. Cet horodatage n’est pas une supposition : le registre d’Ollama fournit un en-tête ollama-push-time sur chaque manifeste, et les quatre tags derrière le nom d1-omni ont été acceptés entre 22:31:25 et 22:32:13 ce soir-là, environ quatre heures avant la rédaction de ces lignes. Le modèle lui-même n’est pas nouveau — Liquid AI a publié les poids ouverts de Liquid AI d1-omni-600M aux côtés de Liquid AI d1-3B le 5 octobre 2026 et a annoncé les deux dans son billet « Open d1 » le 7 octobre — mais jusqu’à la nuit dernière, les seuls moyens d’exécuter la version capable de traiter l’audio sur votre propre matériel étaient un environnement transformers avec trust_remote_code=True ou une version de llama.cpp que vous compiliez vous-même. Désormais, c’est ollama pull d1-omni. Personne ne l’a annoncé : ni le blog de Liquid AI, ni Ollama.

Le packaging est toute l’histoire, et il vaut la peine d’être précis quant aux parties qui en sont documentées. Les articles de blog les plus récents de Liquid AI sont d1-ultra le 15 octobre et LFM2.5-24B-A2B le 13 octobre, et aucun ne mentionne Ollama ; la page de déploiement Ollama du laboratoire lui-même continue de vous expliquer comment exécuter ses dépôts GGUF directement depuis Hugging Face avec ollama run hf.co/LiquidAI/... et ne nomme jamais un modèle d1. Le blog d’Ollama est tout aussi silencieux — ses dernières entrées sont Reflection's Beam le 16 octobre et une intégration Fly.io le 13 octobre. Ce qui existe à la place, c’est une entrée de registre, quatre tags, un digest vérifiable et une page de bibliothèque encore en cours de rédaction pendant que cet article était écrit : une première capture de cette page a renvoyé « No readme », et une capture quarante minutes plus tard a renvoyé une description complète rédigée par Liquid AI, avec un tableau de benchmarks et une section licence. Si vous voulez un événement daté et vérifiable pour ces sept derniers jours, c’est cet en-tête.

Ce que le registre a réellement accepté

Quatre tags correspondent à deux images : c’est la première chose à comprendre avant de faire un pull. d1-omni:latest, d1-omni:600m et d1-omni:600m-q8_0 partagent le même manifeste — digest 1ba59f63e836 — tandis que d1-omni:600m-bf16 en est un second, de digest c1e95fce6627. Il n’existe pas de tag F16, bien que le propre dépôt GGUF du fournisseur publie un trunk F16.

• Couches de poids (build Q8_0) — un tronc de 407 Mo issu de d1-omni-600M-Q8_0.gguf, plus un projecteur de 442 Mo issu de mmproj-d1-omni-600M-BF16.gguf, avec un blob de licence de 10,5 Ko et un blob de paramètres de 18 octets, pour un total de 849 659 968 octets.

• Taille indiquée — 850 Mo pour le tag par défaut et 1,2 Go pour 600m-bf16, tous deux tels qu’affichés sur la page de la bibliothèque.

• Seuil d’exécution — nécessite : 0.40.4 dans le blob de configuration, qui indique également model_family : lfm2, model_type : 380.73M et le type de fichier Q8_0.

• Contexte — le blob de paramètres fixe num_ctx à 16 384.

• Licence — le texte intégré est la LFM Open License v1.0, désignant Liquid AI, Inc. comme concédant, ce qui correspond à l’identifiant lfm1.0 sur la fiche du modèle.

Ce projecteur mérite un second regard, car il est plus gros que le modèle auquel il est attaché. La lecture directe des métadonnées GGUF depuis le blob de registre montre clip.has_vision_encoder = True et clip.has_audio_encoder = True dans le même fichier : 197 tenseurs de vision répartis sur 12 blocs, avec des embeddings de largeur 768 et des entrées de 256 pixels, et 641 tenseurs audio répartis sur 17 blocs, avec des embeddings de largeur 512 et 128 bins mel. C’est la tour SigLIP2 et l’encodeur FastConformer qui voyagent tous deux dans le bundle multimodal, ce qui explique pourquoi un tronc de 381 M de paramètres est livré derrière une pièce jointe de 442 Mo. La capacité audio se trouve physiquement dans le paquet que vous téléchargez ; la question de savoir si le point de terminaison peut y accéder vient plus tard.

Le modèle compte 587 M de paramètres et le badge 125K est plus grand que la réalité.

La page d'Ollama annonce une « fenêtre de contexte de 125K » sur chaque tag. Le num_ctx propre au paquet est de 16 384, et la fiche modèle de Liquid AI dit la même chose en toutes lettres : 16 384 tokens couvrant ensemble les positions de texte, d'image et d'audio, le texte d'état et de question étant ramené à 896 tokens chaque fois que des images sont présentes. Le chiffre de 125K est traçable — le GGUF trunk porte lfm2.context_length = 128000 — mais il s'agit du plafond de l'architecture, pas de la fenêtre dont vous disposez, et c'est le nombre le plus susceptible d'induire en erreur une personne qui dimensionne un remplacement pour un classificateur à contexte long. Considérez 16 384 comme la valeur de travail, et 896 tokens de texte comme la valeur de travail lorsqu'une image est dans l'état.

Le reste des métadonnées corrobore la fiche modèle plutôt que le discours marketing. Le tronc compte 18 blocs, des embeddings de 1 024 dimensions et un vocabulaire de 65 536, et ce n’est pas un décodeur : lfm2.attention.causal vaut False. Ses nombres de têtes KV par couche se lisent 0, 0, 8, 0, 0, 8, …, ce qui signifie que la plupart de ces blocs ne sont pas du tout des blocs d’attention, ce qui trahit l’ascendance d’un encodeur bidirectionnel. La tête de décision comporte deux blocs (lfm2.decision.block_count = 2), et les constantes d’étalonnage que le fournisseur garde dans config.json se trouvent aussi dans ce GGUF — les questions à choix portent une température de 1,7465 avec deux options, de 1,3999 avec trois à cinq, de 1,1751 avec six à dix et de 1,3725 au-delà de onze ; oui/non est à 1,6663 ; les questions notées sont à 1,7301 pour trois à cinq niveaux et à 1,0 pour six à dix. Voilà toute la conception réunie en un seul endroit : un ensemble fixe de réponses nommées, notées en une seule passe, calibrées selon la forme de la question, avec output_tokens : 0 à la fin.

Ce n’est pas un modèle de chat et il ne rédige pas de texte. Liquid AI répertorie quinze langues, ne fournit les données d’entraînement audio qu’en anglais — des demandes échangées entre un locuteur et un assistant — et limite les clips à 30 secondes. La fiche met également en garde contre bfloat16 sur les GPU : lors des propres tests du fournisseur, cela a modifié la réponse principale sur 0,8 % des lignes de texte et 1,7 % des lignes audio, alors que float16 correspondait à float32 partout.

L'audio est présent dans les poids et absent de l'API documentée.

Voici l'écart qu'il vaut la peine de connaître avant de signaler un bug. Le readme de la page de la bibliothèque, rédigé par Liquid AI, documente l'audio en plaçant un WAV encodé en base64 dans le tableau images d'une requête /v1/systemone. Le readme GGUF Hugging Face du fournisseur pour le même checkpoint le documente différemment, avec un tableau files transportant data:audio/wav;base64,… vers le serveur llama.cpp. Et la référence de point de terminaison publiée par Ollama ne documente ni l'un ni l'autre : son schéma de requête comporte state, images, questions et keep_alive, décrit images comme « nécessite un modèle avec vision, comme Clef », et ne contient aucun champ audio ni aucun champ files. En revanche, le guide des modèles de décision d'Ollama lui-même nomme Nimble, Tev1, Clef et Clef Flash comme modèles de décision et indique seulement que les modèles Clef peuvent aussi juger des images.

La position honnête sur l’audio dans Ollama aujourd’hui est donc la suivante : l’encodeur est vérifié comme présent dans le blob, le readme du fournisseur indique qu’il fonctionne via les images, et le schéma publié ne l’admet pas. L’entrée d’images sur le même modèle repose sur des bases plus solides — la vision est une capacité documentée de System One et d1-omni apparaît dans la liste des catégories de vision d’Ollama. Deux lacunes documentaires plus petites s’ajoutent à celle-là : la référence de l’endpoint autorise jusqu’à 255 clés d’option dans une question à choix, tandis que le guide de décision indique 2 à 26, et le plancher d’exécution du paquet, 0.40.4, est supérieur au 0.35.0 cité par la documentation de l’endpoint.

Classé sous vision, non sous décision

Le filtre de recherche de modèles d’Ollama classe les modèles de décision dans leur propre catégorie. Celle-ci contient neuf entrées — nimble-v3, pplx-decider, kev, tev1, nimble, clef-flash, clef, laya et strands-decider — et ni d1 ni d1-omni n’en font partie. La page de d1-omni est étiquetée vision et 600m, et elle apparaît bien dans la liste vision, donc un lecteur qui cherche « modèle de décision » ne trouvera pas le plus récent. C’est un problème de découvrabilité plutôt que de capacité, mais cela compte si vous comptiez comparer les familles de décision dans le catalogue d’Ollama lui-même et avez conclu que ce modèle n’existait pas.

Ce que cela signifie aussi, c’est que d1-omni est le premier modèle de décision de la bibliothèque d’Ollama à pouvoir accepter la parole, tout simplement — l’encodeur audio est inclus dans le paquet et aucun autre modèle de cette liste de neuf n’en possède un. Que le point de terminaison lui transmette ou non votre WAV est la question ouverte de la section ci-dessus, et c’est l’élément qui a le plus de chances d’avoir changé d’ici à ce que vous lisiez ceci.

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

Chaque chiffre de précision associé à Liquid AI d1-omni-600M est celui de Liquid AI, et à notre connaissance, il n'existe aucune évaluation indépendante d'un modèle d1 — aucune ligne dans un classement, aucune exécution par un tiers, aucun rejet publié de la notation du fournisseur. Le fournisseur a lui-même évalué les deux checkpoints d1 avec le scorer officiel Decision Index plutôt que de les soumettre au classement public, et l'indique sur la fiche ; chaque ligne concurrente de son tableau provient du classement v0.2.1, ce qui signifie que la comparaison met un chiffre auto-évalué à côté de chiffres évalués en externe.

• Indice de décision 0.2.1 — 15,95 pour d1-omni-600M (connaissances 8,3, langage 12,9, récupération 35,0, outils 15,1, arts 6,8) contre 48,57 pour d1-3B.

{{1}}Des benchmarks comme décisions, moyenne sur sept — 78,4 pour d1-omni-600M contre 82,9 pour d1-3B, le modèle 600M étant en tête sur Civil Comments (95,8 vs 93,0) et PAWS-X (79,5 vs 76,9) et en retrait sur BoolQ (77,7 vs 86,7) et SQuAD 2.0 (74,0 vs 85,3).{{/1}}

• Décisions rapides, répartition dev — 76,9, déclaré par le fournisseur, aucune ligne de comparaison publiée.

• Vitesse — rien. La fiche indique clairement que les chiffres d’inférence ne sont pas communiqués parce qu’il s’agit d’une version de recherche précoce en cours de développement actif ; toute affirmation de latence que vous voyez ailleurs à son sujet provient donc de la mesure de quelqu’un d’autre.

• Numéros de fixture sur la page Ollama — l’exemple concret du readme montre urgent répondu à 0,998 et technique à 0,995. Ce sont des sorties illustratives d’une seule requête, publiées par le runtime, et elles ne constituent pas un benchmark.

L’écart entre 15,95 et 48,57 est l’élément le plus utile de la fiche, car il tranche la question de l’achat dans les mots mêmes du fournisseur : le readme vous indique d’utiliser d1 lorsque la précision sur le texte et les images est ce qui compte, et de vous tourner vers d1-omni lorsque l’encombrement compte ou que vous avez besoin de l’audio. Un modèle de 587M qui obtient 78,4 sur sept benchmarks publics, réinterprété en décisions, est un classificateur de périphérie plausible. Ce n’est pas une version plus petite du 3B.

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

Nous ne proposons pas ce modèle. Une vérification de notre catalogue le 18 octobre a renvoyé 208 identifiants de modèle et aucun d'entre eux ne provient de Liquid AI, donc rien ici ne constitue une affirmation de disponibilité et il n'existe de notre côté aucune voie pour le récupérer. Si vous voulez Liquid AI d1-omni-600M, la voie locale est celle décrite ci-dessus, et la voie hébergée est l'API propre au fournisseur et toutes les plateformes tierces qui le prennent en charge.

Ce que le packaging change, c'est la forme du système qui l'entoure, et c'est là que nous sommes utiles. Un modèle de décision n'est presque jamais l'ensemble du pipeline : le ticket qu'il étiquette, l'image qu'il signale et la transcription qu'il aiguille doivent encore être traités, résumés ou escaladés par quelque chose qui produit du texte. Ces appels génératifs passent par une clé compatible OpenAI pour plus de 200 modèles hébergés, au prix catalogue du fournisseur, répercuté avec 0 % de marge, de sorte qu'un changement de tarif d'un fournisseur vous parvienne le jour même plutôt que par le biais d'un nouveau contrat. Et comme d1-omni-600M est livré sans preuve indépendante de précision ni latence publiée, la bonne façon de le placer devant du trafic réel est de passer par un basculement automatique entre fournisseurs — laissez-lui gérer les appels pour lesquels il est confiant, et gardez une porte de sortie lorsqu'il ne l'est pas, au lieu de faire de 587 M de paramètres un point de défaillance unique pour votre étape de triage. La décision reste locale ; le repli n'a pas à l'être.

Qu'est-ce qui changerait cette lecture ?

Quatre choses, dont chacune suffirait à transformer une note de packaging en un article différent. Ollama documentant l’audio dans le schéma de requête de System One, ce qui convertirait l’astuce WAV-dans-images du readme en une entrée prise en charge et ferait de ce modèle le premier modèle de décision capable de traiter la parole que l’on puisse exécuter avec une seule commande. L’une ou l’autre des entreprises reconnaissant le portage — Liquid AI ajoutant d1-omni à la page Ollama de sa documentation de déploiement, ou Ollama le répertoriant parmi les modèles de décision plutôt que dans la catégorie vision. Un chiffre de vitesse provenant de n’importe qui, éditeur ou non, puisqu’il n’en existe aucun aujourd’hui. Et une ligne indépendante dans le Decision Index pour n’importe quel modèle d1, qui reste la seule pièce manquante dans toute la famille.

D’ici là, la décision est simple. Si vous exécutez déjà Ollama en version 0.40.4 ou ultérieure, le pull tient en une seule commande, le téléchargement fait 850 Mo, et vous obtenez un classifieur de 587 M qui répond à des questions saisies au clavier en une seule passe avant sur le texte et les images — et, si le readme dit vrai, sur plus de 30 secondes de parole en anglais. Si votre contexte est long, gardez à l’esprit la fenêtre de 16 384 jetons et le budget de 896 jetons pour le texte plutôt que le badge 125K. Et si vous avez besoin de preuves de son exactitude avant qu’il n’étiquette quoi que ce soit qu’un client voit, ces preuves n’existent pas encore, ni pour ce modèle ni pour aucun de ses frères.

Les défaillances documentées de l’IA et les incidents d’agents à l’origine de versions comme celle-ci sont recueillis dans l’OrcaRouter AI Incident Archive, où chaque entrée comporte ses propres sources, sa gravité, sa note de confiance et un indicateur de contestation.