d1-omni vs Liquid AI D1 Omni 600M : deux noms, un seul checkpoint, et un nombre de contexte dont personne ne peut trouver la source

Liquid AI D1 Omni 600M et d1-omni ne sont pas deux modèles, et ce ne sont pas non plus deux points de contrôle du même modèle. Il s’agit d’un seul ensemble de poids — le modèle de décision multimodal de Liquid AI à 587 M de paramètres, construit sur Liquid AI LFM2.5-Encoder-350M et publié sur Hugging Face le 5 octobre 2026 sous le nom de dépôt LiquidAI/d1-omni-600M — portant deux noms de fichiers différents dans deux catalogues différents. L’un de ces catalogues, celui du fournisseur, indique ce qu’est le modèle. L’autre, celui d’Ollama, indique dans quoi quelqu’un l’a empaqueté et affiche sur la fiche trois chiffres que la documentation du fournisseur ne corrobore pas. Tout l’intérêt de cette comparaison tient à cet écart, car, pour un modèle aussi petit, l’empaquetage n’est pas une note de bas de page — c’est la différence entre un modèle texte et image, et le modèle que la fiche dit que vous avez téléchargé.

Le fournisseur n'a rien annoncé au sujet de l'entrée Ollama, et il n'y a ni note de mainteneur, ni entrée de journal des modifications, ni readme sur la page Ollama pour en expliquer quoi que ce soit. Le cadre honnête de tout ce qui suit est donc le suivant : les poids sont publics et inspectables, l'empaquetage est public et inspectable, et l'interprétation de l'empaquetage proposée ici est la nôtre, pas celle de Liquid AI. Lorsqu'un chiffre ne peut pas être rattaché à une source, cet article le dit plutôt que de le répéter.

Quels sont réellement les deux noms

Liquid AI a publié le modèle sur Hugging Face avec un horodatage de création au 5 octobre 2026, deux jours avant son apparition dans l'article de blog du fournisseur « Open d1 : modèles de décision en périphérie pour le texte, la vision et l'audio » le 7 octobre. Les poids sont sous licence selon les propres conditions LFM 1.0 de Liquid, étiquetés d1_omni, system-one, multimodal, vision, audio et decision-model, et ont totalisé environ 13 900 téléchargements et 135 mentions J'aime au moment de la rédaction. Des variantes quantifiées ont suivi selon leur propre calendrier : un dépôt GGUF le 6 octobre, des versions MLX pour Apple Silicon le 12 octobre.

L'entrée Ollama ne correspond à aucun de ces dépôts. Il s'agit d'une page de la bibliothèque Ollama nommée d1-omni qui porte le badge « vision 600m », affiche quatre tags et avait été mise à jour quelques minutes avant la rédaction de ce texte — ce qui explique pourquoi le radar l'a fait remonter. Rien n'y mentionne Liquid AI, LFM2.5-Encoder-350M, ni le dépôt Hugging Face d'où proviennent les octets.

Donc la différence pratique tient à un nom de fichier et à un chemin de distribution, pas à un modèle. Ce qui diffère, et ce qui compte, ce sont les métadonnées qui entourent les octets.

Les trois nombres sur la carte Ollama, vérifiés un par un

La page d'Ollama affiche une taille, une fenêtre de contexte et une liste d'entrées pour chaque tag. Ces trois éléments méritent un second regard, car sur ce modèle, deux d'entre eux ne résistent pas à la confrontation avec la source.

• Fenêtre de contexte — 125K sur la fiche modèle, 16 384 dans toutes les sources du fournisseur.La fiche modèle de Liquid AI indique un plafond de 16 384 tokens couvrant ensemble les positions texte, image et audio, et la page de documentation du fournisseur consacrée à d1-omni-600M indique « 16K tokens ». La chaîne 125K n’apparaît dans aucune des deux. Il peut s’agir d’un artefact de la configuration positionnelle de l’architecture sous-jacente LFM2.5-Encoder ou de la manière dont Ollama signale une limite de cache, mais ce n’est pas un chiffre publié par Liquid AI et ce n’est pas un chiffre que cet article peut attribuer à quiconque. Ce qui rend l’écart plus qu’une simple question de pointilleux, c’est le nombre qui suit.

• L’état que vous pouvez réellement transmettre est plafonné à 896 tokens sur le chemin image.La fiche de Liquid indique que, lorsque des images sont présentes, « le texte d’état et de question est tronqué à 896 tokens, comme à l’entraînement ». Ainsi, une requête de décision accompagnée d’une photo dispose d’un budget de texte à peu près de la taille de cette phrase, quel que soit le chiffre de contexte affiché sur une page de pull. Si vous dimensionniez un prompt de triage sur 125K en vous attendant à payer pour un état long, vous le dimensionneriez sur un nombre qui ne décrit pas l’environnement d’exécution. Le chiffre de 16 384 est le vrai plafond ; le chiffre de 896 est la véritable limite de travail pour le chemin multimodal ; le 125K est un nombre sans trace documentaire.

• Taille — 850 Mo sur la carte, deux fichiers dans le registre. Le tag Ollama d1-omni:latest correspond à un fichier de poids quantifiés de 407 Mo désigné Q8_0, plus un fichier de projecteur de 442 Mo désigné BF16 ; 407 + 442 = 849, que la page arrondit à 850 Mo. Les deux sont indiqués honnêtement ; l’arithmétique n’est que la somme d’un appariement en précision mixte plutôt que d’un seul fichier. Le d1-omni:600m-bf16 est le tag le plus propre : 764 Mo de poids BF16 plus le même projecteur de 442 Mo, 1,2 Go sur disque, et le projecteur est identique octet pour octet entre les deux tags. À noter pour la section suivante, car un projecteur qui transporte ses propres poids peut modifier le nombre effectif de paramètres.

Un détail de plus qui mérite d’être consigné plutôt qu’expliqué : le blob de paramètres d’exécution à l’intérieur du paquet d1-omni d’Ollama fait la même longueur, octet pour octet — 18 octets — que celui à l’intérieur du paquet distinct d’Ollama d1, qui livre Liquid AI d1-3B avec 2,87 Go de poids Q8_0 et un projecteur de 855 Mo. Deux architectures, deux nombres de paramètres, deux ordres de grandeur de paramètres entre eux, et la même configuration d’exécution de 18 octets. C’est une constante de packaging, pas une affirmation concernant l’un ou l’autre des modèles.

Ce que disent les poids eux-mêmes

Si l’on retire l’emballage, le modèle est remarquablement bien documenté. {{1}}Liquid AI D1 Omni 600M totalise 587 M de paramètres répartis en trois parties{{/1}} : un tronc commun et une tête de décision de 381 M, un encodeur visuel de 94 M et un encodeur audio de 112 M. Le tronc est bidirectionnel — il s’agit d’un encodeur, pas d’un décodeur — et c’est le même tronc pour chaque modalité, avec des tours spécifiques à chaque modalité greffées dessus.

• Vision provient d'une tour SigLIP2 héritée de Liquid AI LFM2.5-VL-450M, avec un adaptateur et des mises à jour LoRA qui n'étaient actives que pour les entrées d'images tandis que l'encodeur lui-même restait gelé.

• L’audio provient d’un FastConformer à 17 couches doté de son propre adaptateur, affiné lors d’une étape où le squelette textuel était gelé, puis l’ensemble de la pile a été affiné, le LoRA a été fusionné et les poids ont été moyennés par rapport au point de contrôle précédent.

• Le vocabulaire compte 65 536 tokens répartis sur 15 langues : anglais, allemand, espagnol, français, italien, néerlandais, polonais, portugais, arabe, hindi, japonais, russe, turc, vietnamien et chinois.

• Les modalités ne peuvent pas être mélangées. Une seule requête associe du texte et des images, ou du texte et jusqu’à 30 secondes de parole — pas les deux. L’audio doit être en 16 kHz mono, entre 0,5 et 30 secondes, et a été entraîné sur des échanges entre un locuteur anglophone et un assistant, ce qui constitue une contrainte réelle pour tout contenu multilingue ou bruité.

Rien de tout cela n’apparaît sur la page Ollama, et cette omission a une conséquence que l’on voit directement dans les exemples d’utilisation. Les extraits d’Ollama sont des appels de chat — une chaîne de modèle, un tableau de messages, le mot « Hello! » — et le checkpoint sous-jacent ne peut pas y répondre. Ce n’est pas un modèle de chat et il n’écrit pas de texte. Il renvoie des réponses typées : une probabilité oui/non, une étiquette avec une probabilité par étiquette, ou une position sur une échelle ordonnée, le tout lu directement dans la distribution de sortie sans qu’aucun jeton de sortie ne soit généré. Les interfaces publiées le reflètent : system_one et probabilities via Transformers, ou un /v1/systemone point de terminaison via llama.cpp 0.7.0 et versions ultérieures. Un appel de type chat adressé à un modèle de décision est l’erreur que cet écart de dénomination invite à commettre.

Deux réserves accompagnent chacun de ces chiffres.

Premièrement, Liquid a évalué ses propres lignes à l’aide du scoreur officiel plutôt que de les soumettre au classement public, et aucun tiers n’a reproduit le moindre résultat de d1-omni-600M — le fournisseur indique clairement sur la fiche du modèle qu’il ne communique pas de chiffres d’inférence pour ce checkpoint, car il s’agit d’une version de recherche précoce en développement actif. Deuxièmement, les deux chiffres phares ne concordent pas : l’écart d’indice de 32 points et l’écart de moyenne des benchmarks de 4,5 points décrivent le même modèle, c’est pourquoi ce sont les sous-scores, et non les totaux, qu’il convient de lire. Retrieval à 35,0 et Tools à 15,1 contre Arts à 6,8 vous indiquent pour quelles tâches ce checkpoint est prêt ou non. Audio ne dispose d’aucune colonne de benchmark ; Liquid qualifie les benchmarks dédiés aux décisions audio de problème ouvert.

Liquid AI D1 Omni 600M arrive également en tête de sa propre famille sur deux des sept : Civil Comments à 95,8 et PAWS-X à 79,5. Ce sont les deux lignes où un encodeur de 587M surpasse nettement le décodeur de 3B, et toutes deux relèvent davantage de la classification de texte que du raisonnement — ce qui cadre avec l’architecture plutôt que de la contredire.

Choisissez selon ce que vous voulez. Si vous voulez qu'il tourne localement sous Ollama, d1-omni est le nom qui fonctionne — 850 Mo pour la version Q8_0, 1,2 Go pour BF16, le même chemin d'image que documente Liquid, et aucun des deux tags ne contenant de projecteur audio. Si vous voulez le modèle décrit par le fournisseur, Liquid AI D1 Omni 600M est le nom à rechercher, et la voie Transformers via le dépôt Hugging Face est celle dont la longueur de contexte, la liste des modalités et le nombre de paramètres correspondent à la documentation.

Dans les deux cas, il s'agit de la moitié bon marché d'un pipeline. Le modèle de décision classe ; autre chose doit agir sur la classification. C'est la frontière sur laquelle se situe OrcaRouter, et celle qu'il vaut la peine d'énoncer précisément : aucun modèle Liquid AI ne figure dans notre catalogue, donc l'appel d1-omni lui-même se fait là où vous l'exécutez déjà — ces poids sur votre propre matériel, ou l'API du fournisseur lui-même et les plateformes tierces pour les versions hébergées. Ce à quoi servent les plus de 200 modèles derrière une clé compatible OpenAI, c'est tout ce qui se trouve en aval, au prix catalogue de chaque fournisseur répercuté avec 0 % de marge, avec bascule automatique entre fournisseurs lorsqu'une requête triée est distribuée vers un modèle qui passe une mauvaise journée.

Qu’est-ce qui réglerait la question en suspens ?

Trois choses permettraient de clore ce point, et aucune ne nécessite une annonce du fournisseur. Quelqu’un comparant la sortie du tag Ollama de 850MB au checkpoint Hugging Face sur les mêmes entrées nous dirait si l’empaquetage a modifié les réponses. Un commit llama.cpp ou une entrée du journal des modifications d’Ollama expliquant la valeur de contexte nous dirait si 125K est une erreur ou une capacité que la fiche modèle n’a pas encore prise en compte. Et un résultat audio publié — n’importe quel résultat audio — sortirait ce checkpoint de la catégorie qu’il occupe actuellement, à savoir un modèle bien documenté avec une couche d’empaquetage non documentée et un tableau de scores qui est entièrement celui du fournisseur.

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.