Liquid AI d1 vs Liquid AI d1-omni-600M : le modèle de décision ouvert qui peut vous entendre

Recherchez le nom Liquid AI d1 et vous tomberez sur un modèle de trois milliards de paramètres qui lit le texte et les images. L'autre checkpoint ouvert de la même famille ne fait qu'un cinquième de la taille, prend en compte jusqu'à trente secondes de parole, et est le seul des deux qui puisse décider quoi que ce soit au sujet d'une voix. Il s'appelle Liquid AI d1-omni-600M, et si vous avez découvert la famille via une bibliothèque d'exécution locale plutôt que via la documentation propre du fournisseur, il y a de bonnes chances que vous n'ayez jamais vu son nom. C'est la situation que cette comparaison vise à corriger, car les deux modèles ne sont pas des réponses concurrentes à la même question. Ce sont des réponses à deux questions différentes, et une seule d'entre elles implique l'écoute.

Chaque chiffre ci-dessous provient de la documentation de Liquid AI elle-même : la fiche du modèle LiquidAI/d1-omni-600M, le dépôt compagnon d1-omni-600M-GGUF, et l’article de publication du 7 octobre qui annonçait les deux checkpoints ouverts à la fois. Les lignes de performance ont été notées par le fournisseur sur un indice qu’il maintient, plutôt que soumises à un classement public, et l’article affirme sans détour que les benchmarks dédiés à la décision audio sont un problème ouvert. Rien ici n’a été reproduit par qui que ce soit en dehors du laboratoire.

De quoi sont faits 587 millions de paramètres

Le chiffre phare cache une répartition inhabituelle. Les paramètres totaux s'élèvent à 587 M, et ils ne forment pas un seul empilement : un tronc partagé de 381 M auquel est rattachée la tête de décision, un encodeur visuel de 94 M et un encodeur audio de 112 M. Chaque modalité passe par les mêmes poids de tronc, ce qui est le choix de conception qui maintient l'ensemble compact — le modèle n'est pas trois modèles portant un trench-coat, c'est un seul tronc décisionnel avec deux façons de l'alimenter.

Les pièces proviennent de différents endroits du catalogue de Liquid. Le tronc descend de LFM2.5-Encoder-350M, un encodeur bidirectionnel, plutôt que de la lignée uniquement décodeur dont provient son frère aîné. La tour de vision est un SigLIP2 tiré de LFM2.5-VL-450M, avec un adaptateur et des mises à jour LoRA appliquées au backbone. Le chemin audio est un encodeur FastConformer à 17 couches avec son propre adaptateur, affiné par rapport à un backbone textuel gelé. La fiche indique un contexte de 16 384 tokens partagé entre les positions texte, image et audio, avec le texte réduit à 896 tokens lorsque des images sont présentes, et un vocabulaire de 65 536 tokens — la moitié des 128 000 de son grand frère. Ce dernier chiffre mérite votre attention si vous travaillez dans une langue que la famille ne couvre que partiellement.

Le contraste entre bidirectionnel et décodeur seul explique pourquoi les deux modèles donnent une impression différente à quiconque les a fait tourner tous les deux. Le tronc en forme d’encodeur lit tout l’état d’un seul coup, dans les deux directions, avant de produire quoi que ce soit. Celui en forme de décodeur lit vers l’avant comme le fait un modèle de langage. Les deux sont entraînés à rapporter des réponses à partir d’une distribution avec zéro jeton de sortie, donc ni l’un ni l’autre n’écrit de texte — mais la mécanique sous-jacente relève d’une autre classe de modèle, et l’écart de précision abordé ci-dessous est le coût visible de la conception plus petite, en forme d’encodeur.

Trente secondes de discours, et rien pour l’évaluer.

L’audio est la raison d’être de ce checkpoint. Il accepte un seul clip allant jusqu’à 30 secondes, en mono 16 kHz, dans la même passe avant qui produit la réponse, et il est le seul membre à poids ouverts de la famille capable de le faire. Pour le travail embarqué, ce n’est pas une fonctionnalité marginale. Une caméra qui signale un défaut sur une ligne de production est un problème de vision que le grand frère gère déjà ; un appareil qui achemine une requête vocale, classe un énoncé ou détermine si un appelant demande un remboursement est un problème que seul celui-ci peut traiter.

Deux contraintes s'ajoutent à cette capacité, et toutes deux sont documentées, ce qui signifie qu'il n'y a aucune excuse pour se prendre les pieds dedans en production. Premièrement, une requête transporte des images ou de l'audio, jamais les deux — transmettre les deux déclenche une ValueError au lieu d'en abandonner un discrètement, si bien que l'échec est bruyant et facile à repérer en phase de test. Deuxièmement, le volet audio a été entraîné sur des échanges entre un locuteur anglophone et un assistant, avec des clips tronqués à 30 secondes. C'est une seule géométrie de locuteur, une seule structure de tours de parole et une seule distribution d'accents. Le pointer sur des enregistrements de centres d'appels ou de l'audio de terrain, c'est exiger un comportement que la fiche ne revendique pas, et c'est exactement le genre d'écart qu'un benchmark mettrait au jour s'il en existait un.

Il n'en existe aucun. L'article de publication qualifie les benchmarks dédiés à la décision audio de « problème ouvert à l'heure actuelle » et invite la communauté à en créer un, ce qui est une chose franche à écrire pour un laboratoire et une contrainte réelle pour quiconque évalue le modèle. Liquid AI d1-omni-600M doit justifier sa raison d'être sur la base d'une capacité que personne ne peut encore mesurer. Le fournisseur a également totalement omis de communiquer les chiffres d'inférence, au motif déclaré que le modèle est une version de recherche précoce en cours de développement actif. Il n'existe donc aucune donnée de latence pour le 600M — ni pour le texte, ni pour la vision, ni pour le chemin audio qui est tout l'intérêt.

Ce que l'on peut dire sans rien inventer relève de l'arithmétique sur le nombre de paramètres publié : à la précision float16 que la fiche recommande pour les GPU, 587 M de paramètres représentent de l'ordre de 1,2 Go de poids avant les activations, contre environ 6,2 Go pour l'homologue de 3,12 B à la même précision. La fiche comporte aussi un avertissement sur la précision qu'il est facile de laisser passer et qui ne doit pas l'être : le modèle a été entraîné en float32, le float16 est recommandé sur les GPU, et le bfloat16 a modifié la réponse principale sur certaines lignes lors des tests. Si votre pile de service utilise bfloat16 par défaut, c'est un modèle pour lequel ce défaut n'est pas sûr.

Pourquoi il est facile de passer à côté de la moitié la plus petite de la famille

La raison pour laquelle un lecteur arrive au 3B et s'arrête est structurelle plutôt qu'accidentelle. L'index de documentation de Liquid AI répertorie trois lignes sous les modèles de décision et elles ne se lisent pas de la même manière : d1-3B et d1-omni-600M comportent des liens Hugging Face et GGUF avec un « Non » dans la colonne entraînable, tandis que d1 occupe sa propre ligne avec les simples lettres « API » là où se trouveraient les liens de téléchargement de tous les autres modèles. Le billet d'annonce qualifie d1 de nom de famille et ne distingue jamais le point de terminaison servi du checkpoint ouvert. Les bibliothèques d'exécution locales prennent alors le 3B, parce que c'est celui dont la taille et le nombre de modalités correspondent à l'entrée qu'elles veulent publier, et le 600M n'apparaît pas du tout dans la même liste.

Le résultat est une famille dont l'histoire d'accès publiée, lue rapidement, ressemble à un modèle et à une ligne d'API. Ce qui est réellement proposé, ce sont deux checkpoints ouverts avec des troncs différents, des modalités différentes et un écart de 32 points entre leurs scores sur l'index du fournisseur lui-même, plus un endpoint hébergé dont le fournisseur n'a jamais confirmé la relation avec l'un ou l'autre des checkpoints. Le 600M n'est caché derrière rien. Il n'a simplement aucun nom qu'une recherche de d1 fera apparaître, et c'est le seul des deux qui entend.

Les scores qui existent, et la seule colonne qui vaut la peine d’être lue

Sur Decision Index 0.2.1, le fournisseur annonce 15,95 pour Liquid AI d1-omni-600M contre 48,57 pour son grand frère — un écart suffisamment important pour que le total soit presque inutile comme base de choix. Les sous-scores sont plus instructifs que la somme, et l’un d’eux est vraiment surprenant.

• Connaissances — 8,3 contre 23,8

• Langue — 12,9 contre 56,4

• Récupération — 35,0 contre 52,8

• Outils — 15,1 contre 74,5

• Arts — 6,8 contre 36,3

La récupération est le domaine où le petit modèle tient bon, avec une perte inférieure à un tiers du score du modèle plus grand, alors que dans les quatre autres colonnes, il en perd 60 à 80 %. Ce schéma correspond à ce qu'un encodeur entraîné devrait savoir bien faire : faire correspondre un état à un contenu est proche de ce pour quoi le tronc a été conçu, et cela dépend beaucoup moins de la capacité linguistique en couches que son homologue en forme de décodeur a héritée d'un pré-entraînement bien plus important. La colonne Outils raconte l'histoire inverse, et un écart de 59 points y est le chiffre à scruter si votre charge de travail consiste à acheminer une requête vers la bonne fonction.

Sur sept benchmarks textuels publics, le tableau s'adoucit. Le fournisseur rapporte une moyenne de 78,4 pour le 600M contre 82,9 pour le 3B, le petit modèle perdant de justesse sur SQuAD 2.0 (74,0 contre 85,3), PubMedQA (61,3 contre 66,0), BoolQ (77,7 contre 86,7) et XNLI (74,7 contre 85,0), tout en gagnant sur la détection de toxicité Civil Comments (95,8 contre 93,0) et l'identification de paraphrases PAWS-X (79,5 contre 76,9). La propre présentation de Liquid est que le 600M bat la moyenne de 77,1 d'un modèle de décision 2B avec un quart des paramètres. Deux suites de benchmarks donnent deux verdicts apparents différents, tous deux auto-déclarés, et la lecture honnête est qu'aucune ne tranche quoi que ce soit sur le chemin audio, parce que le chemin audio ne figure dans aucune des deux suites.

Là où les deux se rencontrent réellement

Malgré toutes leurs divergences, le modèle de programmation est identique, et c'est ce qui les rend interchangeables dans un sens bien précis. Tous deux répondent à des questions de type noul, choice et score sur un état, tous deux renvoient la réponse choisie avec une carte de probabilités et une valeur de confiance comprise entre 0 et 1, et tous deux indiquent output_tokens : 0. Le champ de confiance est celui que les gens interprètent mal : il mesure à quel point les probabilités favorisent une réponse, et non la probabilité que cette réponse soit correcte. Un 0,96 sur une question mal posée est une réponse fausse donnée avec assurance, et le champ ne vous en avertira pas.

Là où ils se rejoignent en pratique, c'est une cascade. Filtrez avec Liquid AI d1-omni-600M — à moindre coût, en local, et y compris les cas audio qu'aucun évaluateur purement textuel ne peut traiter — puis faites remonter les éléments qu'il situe près du milieu de son échelle vers le point de contrôle plus grand pour une décision plus fine. Les règles d'escalade sont la confiance et la distribution que le 600M renvoie déjà, de sorte que la logique de routage n'a besoin d'aucun modèle supplémentaire, et sur une charge de travail composée en forte majorité d'éléments faciles, la majeure partie du trafic n'atteint jamais le second étage. Cette composition fonctionne parce que les deux modèles renvoient le même type d'objet. Deux modèles arbitraires ne le feraient pas.

Si cette cascade finit un jour par conditionner un appel à un modèle génératif que vous louez plutôt que vous n'exécutez, c'est dans la couche en dessous que la plomberie devient intéressante, et c'est aussi là que nous intervenons. Faire passer une décision par une chaîne de modèles est exactement le type de problème auquel une règle de routage est destinée : OrcaRouter compose plusieurs modèles derrière un seul point de terminaison compatible OpenAI, chacun à son prix catalogue du fournisseur, répercuté avec 0 % de marge, avec un basculement automatique entre fournisseurs afin qu'une escalade qui échoue au niveau du fournisseur soit réessayée sur une solution de repli au lieu de faire échouer la requête. Nous n'hébergeons aucun modèle Liquid AI — nous avons vérifié avant d'écrire ceci — donc rien de ce qui précède n'est une affirmation quant au fait d'appeler ces poids via nous. L'essentiel est que le modèle de décision est la partie bon marché du pipeline et que le modèle emprunté de l'autre côté est la partie qui tombe.

D'où vient le fichier, si vous voulez l'exécuter aujourd'hui

Pour un déploiement local, le propre dépôt GGUF du fournisseur pour le 600M propose Q8_0 à 407 Mo et F16 et BF16 à 764 Mo chacun, sans version 4 bits répertoriée — donc le plus petit téléchargement officiel est environ sept fois plus petit que la version correspondante du modèle plus grand et à peu près de la même taille qu'une photographie à résolution moyenne. L'exemple fourni par la carte elle-même démarre un serveur llama.cpp avec des flags de batch de 4096 et suggère de les porter à 16384 pour des états plus longs, puis interroge le même endpoint /v1/systemone qu'utilise son grand frère.

La seule chose que la voie locale ne vous donne pas, ce sont les chiffres du chemin audio, parce qu’ils n’existent pas. Si vous comptez faire passer de la parole par ce système devant de vrais utilisateurs, c’est à vous de construire l’évaluation : un ensemble de clips annotés, les trois mêmes types de questions, et un taux de réponse mesuré par classe. Ce n’est pas un rejet du modèle — un checkpoint de 587M qui décide sur un clip vocal en une seule passe est un outil véritablement différent d’un classifieur de texte vissé à une étape de transcription, et il mérite un vrai test plutôt qu’un test fondé sur des impressions.

Si cette cascade venait à conditionner un appel à un modèle génératif que vous louez plutôt que d’exécuter vous-même, OrcaRouter compose plusieurs modèles derrière un point de terminaison compatible OpenAI, chacun au prix catalogue de son fournisseur, répercuté avec 0 % de marge.

Choisir un checkpoint omni plutôt qu'un modèle exclusivement textuel est aussi le bon moment pour examiner ce qui a déjà mal tourné dans cette catégorie : les incidents d'IA documentés et les défaillances d'agents impliquant de petits modèles multimodaux sont recensés dans the OrcaRouter AI Incident Archive, où chaque entrée comporte ses propres sources, son niveau de gravité, son degré de confiance et son indicateur de contestation.