Les petits modèles de décision passent en local avec Liquid AI, PostHog et Qevi

Trois petits modèles spécialisés dans une tâche sont sortis à quelques heures d'intervalle, le 29 septembre. Tous reposent sur la même idée : abandonner la génération de texte, lire les probabilités directement dans le modèle et faire tourner l'ensemble sur du matériel que l'on contrôle.

La page de documentation de Liquid AI présente d1 comme « une nouvelle classe de modèle d'IA conçue pour les décisions structurées ». Au lieu de générer des tokens un par un, un modèle de décision « évalue une situation et renvoie des probabilités calibrées sur un ensemble fixe de résultats, en un seul appel et sans produire le moindre token ». L'exemple fourni par l'entreprise affiche usage.output_tokens: 0 pour une requête de détection de réclamation qui a renvoyé une valeur noul de 0,999.

Trois formes de questions, aucun texte généré

Liquid répartit les questions de décision en trois types. Un noul est une question fermée qui renvoie une probabilité entre 0 et 1, ce que la documentation décrit comme « un booléen sur une échelle continue ». Un choice renvoie une distribution sur des options nommées, par exemple {"billing": 0.65, "technical": 0.30, "account": 0.05}. Un score renvoie une position pondérée par les probabilités sur une grille ordonnée : une question d'urgence à trois niveaux peut ainsi revenir à 1,85, entre « Medium » et « High ».

La documentation précise que noul et score ne sont pas interchangeables. Un noul à 0,5 signifie une incertitude maximale entre oui et non et « ne dit rien du degré ni de l'intensité ». Si le code doit comparer à un seuil sur un continuum, la doc renvoie vers score. S'il s'agit d'une condition booléenne, vers noul. L'API prend un état et une ou plusieurs questions nommées, et répond à toutes en un seul appel. Des bibliothèques clientes existent pour Python (typesafe-sdk) et JavaScript (@typesafe-ai/sdk), et les clés commencent par liquid_.

La page de Liquid est une documentation, pas un article de benchmark : elle ne donne aucun chiffre de précision pour d1. Cela compte, car la même semaine a produit deux modèles qui publient des chiffres, et l'écart entre eux est instructif.

Jeeves ajoute du raisonnement à la formule Jev

Le dépôt GitHub de PostHog consacré à Jeeves le décrit comme « un classifieur de style Jev avec raisonnement et un drafteur par diffusion, entraîné avec SFT et CISPO ». C'est un modèle de 9B construit sur Qwen3.5-9B avec LoRA et une tête pointeur, plus un drafteur par diffusion par blocs de 4, et tout le code et les données d'entraînement. Le dépôt affirme qu'il dépasse Kev-9B et Jev sur des données de test qu'il n'a jamais vues, avec 0,889 contre 0,822 et 0,857, et sur les niveaux publics de JevBench avec 0,935 contre 0,866 pour Jev.

Le dépôt publie un tableau plus complet, et il n'est pas flatteur partout. Jeeves obtient 0,746 sur les tâches de transfert couvrant MMLU-Pro et l'état enfoui, sous les 0,800 de Jev. Sur MMLU, il tombe à 0,793 contre 0,900 pour Jev, et sur MMLU-Pro 10-way à 0,739 contre 0,840. Il gagne sur PAWS (0,875 contre 0,788), sur les structures de règles tenues à l'écart (1,000 contre 0,885) et sur les politiques contrastives (1,000 contre 0,963). Il répond aussi aux questions insolubles avec une p de 0,9 ou plus moins souvent que Jev, 0,055 contre 0,090, une valeur plus basse étant meilleure.

Le dépôt note aussi que sans réflexion, le même point de contrôle obtient 0,804 sur sa partition de test de 2 962 éléments, contre 0,840 avec réflexion. La latence est le prix à payer : environ 0,3 seconde par requête sans réflexion, et une médiane de 3,3 secondes avec, sur un seul H100 en précision fp8. Sur un M4 Pro, une question réfléchit à environ 20 tokens par seconde. Les poids occupent 21 GB en bf16, et les caches par défaut ajoutent 28 GB de plus. D'où la recommandation du README d'utiliser des réglages de cache plus petits sur un Mac de 48 GB.

Une réserve figure dans le tableau lui-même. Aucun résultat JevBench de Kev-9B n'est publié, et les deux lignes marquées d'un astérisque concernent Kev-8B sur Qwen3 : une partie de la comparaison se fait donc contre un autre modèle que ne le suggère l'en-tête de colonne.

Qevi-2B applique la même astuce aux images

La fiche de Qevi-2B sur Hugging Face décrit un fine-tuning complet de Qwen3-VL-2B-Instruct qui répond à des questions fermées et typées sur des images « en lisant les logits du modèle plutôt qu'en générant du texte ». Demandez si une échelle figure sur une photo, il renvoie P(Yes) = 0,97, pas une phrase. La fiche précise sans détour qu'il ne s'agit pas d'un modèle de conversation. Elle avertit aussi qu'appeler .generate() puis analyser le texte ne reproduira pas les chiffres publiés, car ce n'est pas le chemin sur lequel le modèle a été affiné.

La lecture tient en une trentaine de lignes de code transformers ordinaire, sans trust_remote_code. Face à Qwen3-VL-2B-Instruct de base passé par le même chemin de lecture, Qevi-2B passe de 0,855 à 0,977 de précision en domaine et de 0,745 à 0,889 sur 12 domaines tenus à l'écart. L'erreur de calibration attendue sur les données tenues à l'écart tombe de 0,160 à 0,054. La fiche indique que l'avantage de vitesse atteint environ 21 fois lorsqu'on pose beaucoup de questions sur une même image. Un masque d'attention bloc-diagonal permet en effet à plusieurs questions de partager un seul encodage de l'image, vérifié bit à bit contre un traitement séparé.

La fiche met en garde contre la mise à l'échelle de température que recommandaient les versions antérieures : à T = 2,45, l'ECE hors domaine est de 0,160, soit pratiquement le chiffre du modèle de base, et « tout le gain de calibration est annulé ».

Il y a une seconde note d'honnêteté. Le corpus d'entraînement ne contient que des questions noul et choice. Le moteur prend en charge score et le modèle de base traite ces questions en zero-shot, mais le fine-tuning n'en a jamais vu une seule. La fiche indique donc que la précision et la calibration de score ne sont pas mesurées et doivent être considérées comme non testées.

Pourquoi l'angle embarqué revient sans cesse

L'article de Sebastian Raschka du 29 septembre sur l'histoire de la classification de texte est utile ici, car il montre ce à quoi ces modèles renoncent. Il note que les derniers modèles GPT et à poids ouverts peuvent accomplir les mêmes tâches de classification que Jev tout en étant bien plus généraux, mais qu'un modèle de style Jev a pour lui la vitesse et le coût. À l'autre extrémité, « pour un problème étroit et bien défini, Jev ne classera probablement rien de mieux, de plus vite ou de moins cher qu'un classifieur spécialisé ». L'argument de vente, c'est le terrain intermédiaire : plus général qu'un modèle spécialisé, moins cher qu'un modèle de pointe.

L'article de Raschka remonte la filiation jusqu'aux représentations en sac de mots alimentant le naïve Bayes, la régression logistique, les SVM et XGBoost. Il note que le filtre anti-spam de Gmail était soi-disant un modèle naïve Bayes sur sac de mots. La différence, aujourd'hui, c'est que le classifieur est un modèle de langue affiné avec une tête de probabilité calibrée, et qu'il peut être livré sous forme de poids plutôt qu'appelé comme un service.

C'est là que l'argument du local mord. Jeeves tourne sur CUDA en bf16 ou fp8, et aussi sur Apple Silicon via MPS, avec une version fp8 qui réduit les poids à 11,5 GB et fait passer le débit de réflexion sur un M4 Pro d'environ 20 à environ 31 tokens par seconde. Le dépôt indique que la précision et la NLL n'ont pas changé de façon mesurable sur les questions de développement. Un dépôt PostHog/jeeves-fp8 pré-quantifié est publié, ce qui divise à peu près par deux la taille du téléchargement.

Qevi-2B est plus petit encore, avec 2B de paramètres : le genre d'encombrement qui tient dans un ordinateur portable ou un téléphone plutôt que dans une baie. La documentation de Liquid décrit un modèle qui évalue l'état et les questions en un seul appel, sans aucun token de sortie. C'est cette propriété qui rend le coût par requête prévisible.

Les mesures restent maigres

Rien de tout cela n'est sans problème. La recherche adjacente la plus récente, un article arXiv soumis le 28 septembre par Cameron Berg et Caspar Kaiser, a montré que sur sept modèles à poids ouverts issus de cinq familles, des schémas d'activation cachés liés à la valence gouvernent de façon prévisible les choix ultérieurs, même lorsque tous les tokens visibles sont identiques. Les auteurs écrivent que l'on ne sait toujours pas si ces traces s'accompagnent d'une expérience subjective pertinente pour le bien-être du modèle. C'est un rappel : lire l'état interne d'un modèle est désormais un patron de conception, pas seulement un outil de diagnostic.

L'objection pratique vient du blog de développeurs de Microsoft, publié le 29 septembre. Le billet soutient que les benchmarks publics disent peu de chose sur votre propre charge de travail. Il cite la loi de Goodhart et fait remarquer que les tâches SWE-bench proviennent de dépôts publics, si bien que le recouvrement avec les données d'entraînement est inévitable et grandit à chaque génération. Un modèle qui obtient 92 % sur SWE-bench, écrit-il, est manifestement bon pour résoudre des problèmes bien documentés dans des dépôts populaires, et cela ne dit rien de votre bibliothèque interne.

La même logique vaut pour les modèles de décision. Le tableau de Jeeves montre qu'il perd face à Jev sur MMLU et MMLU-Pro tout en gagnant sur les structures de règles tenues à l'écart. La réponse à « lequel est le meilleur » dépend donc entièrement de la distribution d'où viennent vos tickets, vos images ou vos documents. Liquid ne publie aucun chiffre de précision pour d1. La fiche de Qevi-2B classe score parmi les éléments non testés. Les chiffres qui existent sont surtout déclarés par les équipes qui livrent les modèles, sur des partitions qu'elles ont choisies.

Ce qui est nouveau cette semaine, ce n'est pas que de petits classifieurs existent. C'est que trois équipes distinctes les ont livrés avec la même idée d'interface, des probabilités calibrées sur un ensemble de réponses fixe en une seule passe avant, et les ont rendus assez petits pour tourner sans centre de données. Les benchmarks publiés ne permettent pas encore de savoir si cela suffit à déloger le schéma du modèle de pointe avec repli que décrit le README de Jeeves.