d1-Omni-2B : ce que le modèle de décision 2B le plus discret de Liquid AI embarque — et ce qu'il laisse de côté

Le dépôt Hugging Face de LiquidAI/d1-Omni-2B a été créé à 19h30 UTC le 24 octobre 2026. Le premier billet de blog de Liquid AI à mentionner le modèle par son nom a été publié le 27 octobre. Pendant ces trois jours, le dépôt était public et complet — une fiche technique complète, 4,33 Go de safetensors BF16, du code Transformers fonctionnel — et rien de ce que le fournisseur a publié n'indiquait son existence. Lorsque la mention est enfin arrivée, il s'agissait de deux paragraphes et d'un tableau de quatre lignes au sein du lancement d'une famille de six modèles, et non d'un lancement à part. Telle est la forme de cette publication, et c'est le cadre honnête pour tout ce qui suit : les poids sont inspectables, les affirmations sont celles du fournisseur, et les éléments qu'un acheteur obtiendrait normalement d'une annonce — un prix, un point de terminaison hébergé, un benchmark indépendant — ne sont pas encore là.

L'écart de cinq jours entre les poids et les mots

L’histoire des modèles de décision de Liquid AI a été racontée deux fois, et {{1}}d1-Omni-2B{{/1}} n’apparaît dans aucun des deux récits. Le 7 octobre, l’entreprise a publié « {{2}}Open d1 : modèles de décision en périphérie pour le texte, la vision et l’audio{{/2}} », qui présentait exactement deux checkpoints ouverts : {{3}}d1-3B{{/3}}, un modèle vision et texte de 3,12 Md de paramètres, et {{4}}d1-omni-600M{{/4}}, un modèle de 587 M qui prenait en entrée du texte avec des images ou du texte avec jusqu’à 30 secondes d’audio. Cet article est toujours en ligne, et il ne contient toujours aucun modèle 2B.

La gamme 2B est arrivée selon un calendrier différent. Le 21 octobre, le checkpoint de base LFM3-Omni-2B est apparu sur Hugging Face. Le 24 octobre, à vingt-quatre secondes d'intervalle, Liquid AI a créé des dépôts pour d1-2B et d1-Omni-2B. L'article de lancement de LFM3 du 27 octobre a ensuite nommé la famille : six modèles d'environ 2B paramètres, quatre couvrant le texte, la vision, l'audio et l'omni, et, selon les propres mots de l'article, « les deux derniers sont des modèles de décision spécialisés à partir des modèles vision et omni ». Cette phrase constitue l'annonce. Il n'y a eu ni publication distincte sur d1-Omni-2B, ni page de tarification, ni citation de partenaire de lancement, ni mise à jour de l'article du 7 octobre.

Ainsi, le modèle n'est pas dépourvu de documentation — le dépôt est l'un des petits checkpoints les mieux documentés que Liquid AI ait publiés, et la page de documentation du fournisseur consacrée aux modèles de décision le répertorie aux côtés de d1-2B et d1-omni-600M. Il est peu mis en avant. Cette distinction est importante, car elle vous indique quelles affirmations ont fait l'objet d'une revue de lancement et lesquelles n'en ont pas fait l'objet.

Lire la carte comme une fiche technique

En faisant abstraction du cadrage, le checkpoint est simple. d1-Omni-2B est un modèle de décision post-entraîné construit sur LFM3-Omni-2B, et ce n’est pas un modèle de conversation : il n’écrit aucun texte et ne produit aucune parole, et chaque appel renvoie output_tokens: 0.

• Paramètres — 2,17 Md, fourni sous la forme d'un seul fichier safetensors BF16 de 4,33 Go.

• Architecture — le socle LFM3 : 24 couches, dont 13 sont des convolutions courtes à portes, 5 sont de l’attention à fenêtre glissante avec une fenêtre de 256 tokens, et 6 sont de l’attention globale. L’article de la famille décrit ce mélange tri-hybride comme le résultat d’une recherche d’architecture hardware-in-the-loop menée sur 14 combinaisons d’appareils et de backends.

• Contexte et vocabulaire — 128K tokens et un vocabulaire de 128 000 tokens partagé avec le reste de LFM3.

• Entrée — un état pouvant être du texte ou n’importe quelle valeur JSON, ainsi que des images, des trames vidéo et des clips audio, plus un nombre quelconque de questions nommées, écrites ou parlées. L’API de la carte accepte tout cela dans une seule media liste, ce qui constitue une différence notable par rapport au checkpoint 587M : d1-omni-600M est documenté comme texte avec images ou texte avec audio, et non les deux à la fois.

• Sortie — des réponses typées avec probabilités. Oui/non, un choix parmi des options nommées, un score ordonné, une valeur lue dans un document avec son segment, un nombre avec un intervalle p10–p90, une boîte englobante, ou chaque instance d’un objet avec un décompte.

• Langues — seize. La reconnaissance vocale couvre le même ensemble, à l’exception du hindi, du thaï, du vietnamien et de l’indonésien, ce qu’il convient de signaler, car la partie texte les mentionne.

• Licence — LFM Open License v1.0. L'utilisation commerciale est autorisée pour un chiffre d'affaires annuel inférieur à 10 000 000 $ ; au-delà, le texte de la licence indique que l'utilisation commerciale « n'est pas concédée sous licence en vertu du présent Accord ».

L'audio est l'affirmation qui mérite d'être testée

La raison de choisir ce checkpoint plutôt que d1-2B, c’est l’audio. Liquid AI le positionne pour « le routage des appels et des messages vocaux, ainsi que les événements sonores », et la fiche du modèle contient l’unique élément de preuve qu’un communiqué de lancement aurait normalement mis en avant : une comparaison entre oral et écrit sur les mêmes éléments.

• Routage et triage des demandes professionnelles (DecisionBench, Hanno Labs v1) — 83,4 à l’écrit, 78,2 à l’oral.

• Cas de service client (décisions dactylographiées) — 50,5 à l’écrit, 48,0 à l’oral.

• JevBench v1.4.1, les lignes qu'une voix peut prononcer — 87,6 à l'écrit, 89,0 à l'oral, ce qui signifie que l'exécution orale a obtenu un score légèrement supérieur, du bruit plutôt qu'un gain.

• Événements sonores (ESC-50) — 84,5, sans équivalent écrit.

• Identification de la langue parlée (FLEURS, 43 langues) — 92.5.

Ces chiffres appuient l'argumentaire. Le reste de la section audio est la partie qui indique où ne pas construire, et elle est d'une franchise inhabituelle pour une fiche fournisseur. Les états courts parlés chutent de 42,0 à l'écrit à 22,8 à l'oral. Les passages Belebele en huit langues tombent de 83,6 à 41,8. La fiche indique clairement que les longs passages parlés perdent une grande partie de leur précision, « surtout en dehors des langues à écriture latine », et oriente plutôt vers d1-2B toute personne dépourvue d'entrée audio, dont elle affirme qu'il est plus performant sur le texte et les boîtes individuelles, signale plus souvent les valeurs manquantes et est mieux calibré.

Lues ensemble, ces lignes décrivent un modèle performant sur des énoncés courts et routables dans les principales langues, et bien plus faible dès qu’il s’agit de maintenir un long état parlé. Le triage en centre d’appels convient. Une réunion enregistrée de quarante minutes, non.

Le tableau d’affichage appartient au fournisseur, et l’index a changé de version.

Chaque chiffre de performance de ce modèle est propre à Liquid AI. La fiche est explicite sur la méthode : les quatre modèles d1 ont été évalués sur les mêmes éléments avec le même barème, de sorte que certains chiffres diffèrent légèrement des fiches individuelles dont ils proviennent. Elle ne dit pas qu’un tiers a reproduit l’un de ces résultats, et aucune évaluation indépendante de d1-Omni-2B n’existe au moment de la rédaction.

• Decision Index public suite, v0.3 — 49,0 pour d1-Omni-2B, contre 51,1 pour d1-2B, 49,0 pour d1-3B et 18,3 pour d1-omni-600M.

• DecisionBench (Hanno Labs) v1 — 76,4, contre 77,1, 73,1 et 58,7 respectivement.

• decisionbench.ai v4 — 84,7, contre 85,2, 83,6 et 57,9.

• ImajevBench v2.0-lite — 72,3, contre 75,5, 64,0 et 21,7.

• Le propre tableau de benchmarks du fournisseur, avec plus d'une centaine de benchmarks — 61,8, contre 63,2, 58,8 et aucune note pour le 600M.

• Moyenne de vision sur 18 benchmarks d'images — 67,7, contre 70,2, 65,4 et 42,8.

Un piège se cache au milieu de tout cela. L’article du 7 octobre indiquait d1-omni-600M à 15,95 sur Decision Index v0.2.1. La nouvelle fiche l’indique à 18,3 sur la v0.3. Ce sont des suites différentes et l’écart n’est pas un gain de capacité ; ne soustrayez pas l’un de l’autre. La seule comparaison équitable est celle que la fiche a réellement effectuée, avec les quatre modèles réévalués sur les mêmes éléments.

La tendance qui demeure après le recalcul des scores est que d1-Omni-2B se situe juste en dessous de d1-2B sur presque tous les points, et nettement au-dessus de la génération précédente. Liquid AI le présente comme surpassant d1-3B sur son tableau de décision et sur 16 des 18 benchmarks d’images avec 70 % des paramètres, ce qui est exact pour le tableau tel qu’imprimé et constitue aussi une comparaison avec un modèle que la famille a désormais remplacé.

Ce à quoi le dépôt ne répond pas

Cinq questions restent ouvertes, et aucune d’entre elles ne trouve de réponse dans la lecture des poids.

• Accès hébergé et tarif. L'article sur LFM3 indique que les modèles de base et post-entraînés sont disponibles sur Hugging Face, le Playground et l'API Liquid AI. Le tableau de la documentation des modèles de décision, toutefois, classe d1-Omni-2B comme à poids ouverts et réserve ses lignes réservées à l'hébergement à d1.1 et d1-ultra, et la page du modèle sur Hugging Face précise que « ce modèle n'est déployé par aucun fournisseur d'inférence ». Aucun prix par appel pour ce checkpoint n'est publié où que ce soit que cet article ait pu trouver, donc considérez l'accès hébergé comme plausible mais non confirmé.

• Données d’entraînement. La fiche ne fournit ni corpus, ni composition, ni description du jeu de données. Elle mentionne des tests sur des extraits et des voix « qu’aucune ligne d’entraînement ne contient », ce qui implique qu’un ensemble d’entraînement existe et ne dit rien sur ce qu’il contient.

• Quantisation. Le dépôt principal est livré en BF16, et Liquid AI publie trois versions sœurs : MLX fp16, MLX 8 bits et un export ONNX. Il n’existe pas de GGUF du fournisseur, bien que la bibliothèque d1-omni d’Ollama porte un tag 2b à 4,4 Go et 125K de contexte, et la taille est suffisamment proche du checkpoint BF16 pour qu’elle ne semble pas correspondre à une quantification agressive.

• Évaluation indépendante. Aucune. Tous les chiffres ci-dessus sont produits par le fournisseur, avec son propre évaluateur sur sa propre carte.

• S'il remplace d1-omni-600M. La fiche recommande d1-2B plutôt que ce modèle lorsqu'il n'y a pas d'audio, et recommande ce modèle plutôt que d1-2B lorsqu'il y en a. Elle ne dit rien sur l'avenir du checkpoint 587M, et Liquid AI ne l'a pas déprécié.

Le faire tourner, et ce que cela coûte en matériel

Le chemin d’inférence repose sur Transformers 5.19 ou une version ultérieure avec trust_remote_code, et l’appel s’effectue via model.system_one(state, questions, media). Il n’y a aucun paramètre d’échantillonnage à définir, car rien n’est échantillonné. La compilation prend environ une minute lors des premiers appels ; ensuite, la carte indique 5,8 ms pour une question et 7,7 ms pour trois sur une H100 PCIe, 3,7 ms et 5,6 ms sur une AMD MI325X, et 21,1 ms et 28,9 ms sur une Apple M5 Pro. Un état de 5K tokens coûte 52 ms sur la H100. Le traitement par lots est ce qui apporte le débit : 1 154 états par seconde sur la H100 et 1 697 sur la MI325X avec 64 états en un seul appel.

Pour un modèle de cette catégorie, ces chiffres constituent l’argument. Il ne rivalise pas avec un modèle de chat sur la qualité ; il rivalise avec le fait même d’exécuter un modèle de chat. Une passe avant de 5,8 ms qui renvoie une probabilité calibrée représente un poste de coût différent d’un appel génératif qui renvoie un paragraphe qu’il faut ensuite analyser.

Là où la décision se termine et où le reste du pipeline commence

Un modèle comme celui-ci effectue un seul saut. Il transforme un ticket, un enregistrement d’appel ou une image de caméra en une étiquette et un score de confiance, puis quelque chose doit agir sur cette étiquette — rédiger la réponse, escalader le cas, appeler l’API. Aucun modèle Liquid AI ne figure au catalogue d’OrcaRouter, c’est donc à ce second saut que se situe réellement notre produit : les modèles génératifs qui consomment la décision passent par une clé unique compatible OpenAI couvrant plus de 200 modèles, au prix catalogue de chaque fournisseur, répercuté avec 0 % de marge, avec bascule automatique en cas d’échec lorsqu’une requête tombe sur un fournisseur qui connaît un moment difficile. Le modèle de décision est la partie bon marché, rapide et déterministe. Cela vaut la peine de connecter la partie coûteuse et non déterministe à quelque chose qui peut réessayer.

Qu'est-ce qui réglerait ça

Trois éléments feraient passer d1-Omni-2B de « prometteur » à « recommandable », et aucun ne nécessite un autre article de blog. Le premier est une exécution indépendante de la suite audio sur du matériel que le fournisseur ne contrôle pas — l’écart de 22,8 contre 42,0 sur les états courts parlés est le chiffre le plus susceptible de bouger sous le microphone de quelqu’un d’autre. Le deuxième est un prix publié pour l’accès hébergé, sans lequel le calcul construire-ou-acheter ne peut être achevé. Le troisième est une comparaison directe avec d1-2B sur les mêmes tâches comportant de l’audio, car la recommandation de la fiche elle-même — n’utiliser le 2B omni que lorsque l’entrée contient de l’audio — est la phrase la plus utile qu’elle contient, et c’est aussi celle que personne n’a testée en dehors de Liquid AI.