d1-2B vs Liquid AI d1-omni-600M : quand l'entrée décisive est le son

Placez une note vocale et une facture photographiée devant ces deux modèles : un seul des deux peut répondre, et ce n'est pas celui qui a le meilleur score. d1-2B lit le texte, le JSON, les images et la vidéo, et ne peut pas du tout accepter l'audio. Liquid AI d1-omni-600M lit du texte avec des images ou du texte avec jusqu'à 30 secondes de parole, et ne peut pas accepter de l'audio et des images dans la même requête. Cette seule asymétrie décide de la plupart des déploiements réels avant même que l'un ou l'autre benchmark ne soit consulté. Ce qui suit est malgré tout la version honnête de la comparaison : les points sur lesquels le modèle 587M est réellement compétitif, ceux sur lesquels le modèle 1,92B est loin d'être remplaçable, et l'unique schéma de pipeline qui utilise les deux sans prétendre qu'ils sont des alternatives.

La décision relève d’une question de modalité, et non d’une question de score.

Un modèle de décision prend un état et un ensemble de questions nommées et renvoie une probabilité par réponse, sans jetons générés. L'état est l'entrée entière, et le type de l'état est la contrainte déterminante. La fiche de d1-2B liste texte, JSON, images et vidéo. La fiche de Liquid AI d1-omni-600M liste texte avec images, ou texte avec audio — et le code impose l'exclusion : passer à la fois une image et un extrait audio à system_one déclenche une ValueError.

La première question n’est donc pas de savoir quel modèle obtient le meilleur score. C’est de savoir si ce que vous devez juger arrive sous forme de pixels, de texte ou de forme d’onde. Si cela arrive sous forme de forme d’onde, une seule réponse s’impose dans ce duo, et le reste de cette page explique quelle précision vous sacrifiez pour l’obtenir.

Ce que 587 M achètent réellement

Le 600M n’est pas une petite version du d1-2B. Il s’agit d’une construction différente, et le budget mérite d’être détaillé, car il explique à la fois ses forces et son plafond.

• Paramètres — 587 M au total : 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. Chaque modalité passe par les mêmes poids de tronc.

• Base — LFM2.5-Encoder-350M, un encodeur bidirectionnel, avec une tour de vision SigLIP2 empruntée à LFM2.5-VL-450M et un FastConformer à 17 couches pour l’audio.

• Contexte — 16 384 tokens répartis entre les positions texte, image et audio, et un vocabulaire de 65 536 tokens. La fenêtre de d1-2B est de 128K.

• Audio — jusqu’à 30 secondes de parole mono à 16 kHz par requête. La fiche est explicite : le volet audio a été entraîné sur des requêtes entre un locuteur anglophone et un assistant, ce qui constitue une distribution étroite pour un modèle que l’on va diriger vers des enregistrements d’appels.

• Règle des médias — images ou audio, jamais les deux. La carte documente le ValueError plutôt que de vous laisser le découvrir.

• Licence — LFM Open License v1.0, la même structure de seuil que d1-2B : utilisation commerciale sous 10 000 000 $ de chiffre d'affaires annuel.

• Vitesse — non publiée. La fiche ne rapporte aucun chiffre de latence, qualifiant le modèle de version de recherche précoce en cours de développement actif. d1-2B publie 5,7 ms sur un H100 PCIe, 3,8 ms sur un MI325X et 18,6 ms sur un M5 Pro.

Le tableau des mêmes exécutions, et les lignes où l’écart est faible

Les deux modèles figurent dans le tableau de benchmark de la fiche de d1-2B, qui évalue quatre modèles d1 ouverts sur des items identiques avec un scoreur identique. Cela rend la comparaison plus propre que la plupart des comparaisons entre fiches, avec une réserve : la fiche de d1-omni-600M rapporte 15,95 sur Decision Index 0.2.1, tandis que ce tableau rapporte 18,3 sur la version 0.3. La différence tient à l’édition de l’index, et les deux chiffres sont corrects pour leur propre test.

• Decision Index public suite v0.3 — 51,1 pour d1-2B contre 18,3 pour Liquid AI d1-omni-600M.

• DecisionBench (Hanno Labs) v1 — 77,1 contre 58,7.

• Decision Bench (decisionbench.ai) v4 — 85,2 vs 57,9.

• ImajevBench v2.0-lite — 75,5 contre 21,7, l'écart le plus large du côté décisionnel entre les deux.

• WorkflowEvals — 81,6 contre 48,8.

• Moyenne Vision, 18 benchmarks — 70,2 vs 42,8.

• VisualWebBench — 96,2 vs 14,9, ce qui relève moins d’une comparaison que d’une affirmation sur ce qu’un encodeur visuel de 94 M peut porter.

Puis les lignes qui plaident pour la retenue. Typed Decisions est de 61,3 contre 57,5 — un écart de 3,8 points pour un modèle doté d’un tiers des paramètres. POPE, le benchmark d’hallucination d’objets, est de 88,7 contre 82,7. JevBench est de 77,9 contre 58,0, un écart important, mais DecisionBench v4 est de 85,2 contre 57,9, et les deux ensemble indiquent que le 600M est irrégulier plutôt que uniformément faible. Le post de lancement de Liquid AI place lui-même sa moyenne sur sept benchmarks à 78,4, ce qui est élevé pour 587M ; la fiche de d1-2B ne publie pas de moyenne équivalente, donc les deux chiffres ne devraient pas être mis côte à côte.

Le seul chiffre qui ne flatte ni l’un ni l’autre modèle est le chiffre indépendant. Efraín Garay a exécuté Liquid AI d1-omni-600M sur un échantillon de 6 000 requêtes de Decision Index 0.3 et a obtenu 14,0, contre 14,17 du fournisseur sur le même échantillon — une reproduction fidèle. Il a également constaté que 1 758 requêtes dépassaient le budget d’instructions et d’options du modèle et ont été refusées, comptées comme fausses, ce qui représente un coût réel d’une fenêtre de 16 K sur une suite conçue pour des états plus longs.

Là où le 600M est la seule option

Le routage audio est le cas pour lequel le modèle a été conçu, et les exemples de la fiche sont concrets : routage des appels et des messages vocaux, événements sonores, instructions vocales superposées à un état écrit. Rien de tout cela n’est disponible avec d1-2B, à quelque niveau de précision que ce soit, car il ne possède ni encodeur audio ni positions audio dans son schéma d’entrée.

Deux points de données indépendants devraient tempérer l’argumentaire. Le premier est l’évaluation ci-dessus, où le 600M a obtenu une AUC de détection de tirs de 0,580 et une AUC de prévision de pluie de 0,593 sur des tâches en données réelles — à peine au-dessus du hasard, et derrière tous les modèles plus grands testés. Le second est un test pratique qui a mesuré moins de 2 Go de VRAM utilisée et a constaté que le modèle classait la diction et le ton dans l’audio bien plus fiablement que le sens sémantique, avec des questions de type inférence proches du pile ou face. Les deux vont dans le même sens : il s’agit d’un modèle de présélection. Il est bon pour « quel type de chose est-ce ? », et il ne remplace pas un modèle qui comprend ce qui a été dit.

Ce n’est pas une critique d’un checkpoint de 587M. C’est ce que 587M permettent d’obtenir quand 381M de ce total constituent un tronc partagé. La raison de l’utiliser, c’est le coût et l’empreinte — moins de 2 Go de VRAM, un dépôt GGUF depuis le 6 octobre, des builds MLX depuis le 12 octobre, et une décision en une seule passe avant — pas la fidélité.

Une cascade qui utilise les deux

L’erreur consiste à les considérer comme des concurrents. Ce sont deux étapes du même filtre, et le pipeline naturel exécute d’abord le modèle bon marché.

Première étape : Liquid AI d1-omni-600M prend l’élément entrant — une note vocale, un appel au support, une réclamation écrite avec une pièce jointe — et répond à des questions générales. S’agit-il d’un problème de facturation ou d’un problème technique ? L’appelant est-il en colère ? Ce message contient-il réellement une demande ? À moins de 2 Go et en une seule passe, c’est suffisamment économique pour être exécuté sur chaque élément.

Deuxième étape : tout ce que le 600M place près du milieu de son échelle, ou tout élément qui arrive avec une image à lire, est transmis au d1-2B. Le 2B dispose d'une fenêtre de 128K, d'une entrée vidéo et d'environ le triple de la moyenne en vision, et il ne voit que la fraction du trafic que la première étape n'a pas pu trancher.

Les seuils, c’est là que se joue le travail. Les deux cartes renvoient des probabilités, et toutes deux vous disent de calibrer sur vos propres données — la carte de d1-2B le dit en toutes lettres. Une cascade avec une bande intermédiaire non calibrée a deux comportements : soit elle fait tout remonter, auquel cas le 600M n’était que décoratif ; soit elle ne fait rien remonter, auquel cas le 2B ne corrige jamais l’étape qui ne sait pas lire.

Il existe une troisième étape dans la plupart des systèmes réels : le modèle qui rédige la réponse. C’est là qu’une API hébergée entre en jeu, et où OrcaRouter devient pertinent. Aucun des deux modèles Liquid AI n’est servi par nos soins, donc les nœuds de décision restent sur votre propre GPU ; l’étape générative qui consomme leurs étiquettes peut provenir de une seule clé compatible OpenAI couvrant plus de 200 modèles, avec 0 % de marge sur les prix catalogue des fournisseurs et un basculement automatique en cas de défaillance d’un fournisseur en cours de trafic. Le DSL de routage est aussi la manière honnête d’exprimer la cascade elle-même — les deux modèles de décision comme étapes côté GPU, la génération de réponse comme étape hébergée, composées plutôt que collées ensemble dans le code applicatif.

Ce qu’aucun des deux modèles ne fait, et la troisième option

Ni l'un ni l'autre n'écrit de texte. Tous deux renvoient des réponses typées et des probabilités avec zéro jeton de sortie ; si l'étape suivante nécessite de la prose, c'est un autre modèle. Aucun des deux ne gère la vidéo avec audio : d1-2B prend des trames vidéo mais pas de son, le 600M prend le son mais pas en même temps que des images, et le plafond audio de 30 secondes est une limite stricte plutôt qu'une recommandation.

Si l’exigence est véritablement « audio et images dans la même requête », la réponse n’est ni l’un ni l’autre — c’est d1-Omni-2B, le frère de 2,17B que Liquid AI a créé vingt-quatre secondes après d1-2B et qui accepte du texte, des images, des trames vidéo et des clips audio dans une seule liste de médias. Son score Decision Index est de 49,0 sur le même tableau v0.3, sa moyenne en vision est de 67,7, et il présente la même absence de tests indépendants que d1-2B. Il coûte environ quatre fois le nombre de paramètres du 600M, ce qui est le prix à payer pour ne pas avoir à choisir entre les modalités.

Donc la règle est courte. Si l’état contient de la parole et que rien d’autre n’a besoin d’être vu, Liquid AI d1-omni-600M est le seul membre de cette paire capable de fonctionner, et il doit être traité comme un écran. Si l’état est du texte, des images ou de la vidéo et que la réponse doit tenir la route, d1-2B est le modèle — et c’est celui qui dispose d’un chiffre de latence publié, d’une fenêtre de 128K et d’une avance sur le benchmark qui résiste à une lecture ligne par ligne. Si l’état contient les deux, aucun des deux n’est la réponse, et c’est le modèle omni de 2,17B qui l’est.