Les modèles de décision, et non les petits modèles de langue, s'installent discrètement dans l'IA embarquée

Les sorties de cette semaine ne sont pas des chatbots plus petits. Ce sont des modèles qui répondent à des questions fermées et typées, et qui renvoient des nombres, pas des phrases.

La documentation de Liquid AI, mise en ligne le 29 septembre, annonce la couleur sans détour : 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 générer de token ». L'API gère trois types de questions. Un Noul est une question oui/non qui renvoie une probabilité entre 0 et 1. Un Choice renvoie une distribution sur des options nommées. Un Score renvoie une position pondérée par les probabilités sur une grille ordonnée. Dans l'exemple de réponse des docs de Liquid, une question sur une réclamation client renvoie un Noul de 0,999 et un nombre de tokens produits de 0.

Ce dernier chiffre est tout l'enjeu. L'inférence embarquée se raconte d'ordinaire comme l'histoire d'un modèle génératif que l'on rétrécit jusqu'à le faire tenir sur un téléphone. Les modèles de décision contournent l'étape de génération, ce qui supprime le coût dominant d'un modèle exécuté en local.

Trois sorties, une même forme

Le dépôt jeeves de PostHog, mis à jour pour la dernière fois le 29 septembre, décrit « un classifieur de raisonnement de style Jev avec un drafteur à diffusion, entraîné par SFT et CISPO ». C'est un ajustement de Qwen3.5-9B de 9B avec LoRA et une tête pointeur qui, selon le dépôt, « réfléchit avant de décider ». Les chiffres publiés annoncent 0,889 sur un découpage de test tenu à l'écart, contre 0,857 pour Jev et 0,822 pour Kev-9B, et 0,935 sur les paliers publics de JevBench, contre 0,866 pour Jev. PostHog rapporte 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.

Toujours le 29 septembre, un modèle visuel de 2B appelé Qevi-2B a été publié sur Hugging Face par MeerDevelopment. Il s'agit d'un ajustement 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 lui-même au lieu de générer du texte ». La fiche du modèle ne mâche pas ses mots sur le compromis : demandez-lui si une échelle figure sur une image, il renvoie P(Yes) = 0,97, pas une phrase. En échange, il annonce une exactitude de 0,889 sur des domaines tenus à l'écart, contre 0,745 pour le modèle de base, et une erreur de calibration attendue de 0,054 contre 0,160.

La fiche de Qevi-2B prévient aussi que le modèle doit être utilisé via une lecture de logits, et non via .generate(). Appeler generate et analyser le texte ne reproduira pas les chiffres publiés, parce que ce n'est pas le chemin sur lequel le modèle a été ajusté. Le détail paraît mince, la conséquence est grande : ces systèmes ne sont pas interchangeables avec les modèles de chat que les développeurs savent déjà appeler.

Pourquoi l'argument de la calibration compte

Le texte de Sebastian Raschka du 29 septembre sur l'histoire de la classification de textes replace cette vague dans son contexte. Il retrace la ligne qui va du sac de mots à Bayes naïf, à la régression logistique, aux RNN et aux transformeurs. Il note qu'un classifieur tire son avantage de la vitesse et du coût, pas de la généralité. Sa façon de situer Jev est prudente : « Jev est essentiellement un classifieur de textes », mais « Jev n'est pas non plus “juste” un classifieur de textes ».

La distinction qu'il pose sépare les modèles étroits, dédiés à une tâche, de quelque chose d'assez général pour traiter de nombreuses tâches de classification sans réentraînement. Qevi-2B et Jeeves occupent tous deux ce terrain intermédiaire. Ni l'un ni l'autre n'est un assistant généraliste. Tous deux affirment battre des références conçues sur mesure sur des tâches pour lesquelles ils n'ont pas été entraînés.

Les chiffres de calibration sont la partie à examiner de près. La fiche de Qevi-2B indique que la mise à l'échelle par température dégrade sa calibration au lieu de l'améliorer, parce que le lissage des étiquettes pendant l'ajustement a déjà retiré au modèle de base son excès de confiance. À T = 2,45, l'ECE tenu à l'écart revient à 0,160, exactement la valeur du modèle de base. La fiche précise aussi sans détour que des versions antérieures recommandaient 2,45, 1,9 et 3,0, et que ces valeurs avaient été ajustées sur le modèle de base avant l'ajustement, ce qui les rend inutilisables.

Publier une correction aussi franche sur une fiche de modèle est rare. Cela contredit aussi une idée reçue : il faudrait remettre à l'échelle après coup les probabilités d'un petit modèle pour s'en servir comme seuils. Ici, le softmax brut est la sortie calibrée.

Jeeves fait le pari inverse. Son README affirme que les modèles de type Jev « donnent des probabilités de décision calibrées, mais avec une faible exactitude », et que beaucoup de pipelines se rabattent donc sur un modèle de raisonnement. Jeeves intègre le raisonnement directement dans le classifieur. Le prix à payer est la latence : 0,3 seconde sans réflexion, 3,3 secondes avec, sur un H100. Sans réflexion, le même point de contrôle obtient 0,804 sur le découpage de test de 2 962 éléments de PostHog, contre 0,840 avec.

L'angle embarqué, c'est la mémoire, pas le nombre de paramètres

L'argument pratique de Qevi-2B est le débit : jusqu'à environ 21 fois plus d'inférence à la seconde lorsqu'on pose beaucoup de questions sur une seule image, parce que toutes les questions partagent un même encodage et sont isolées par un masque d'attention en bloc diagonal. La fiche assure que les réponses sont identiques à celles obtenues en posant les questions séparément, vérifié bit à bit.

Jeeves est moins accommodant. Il exige Python 3.12 et un GPU CUDA, même si l'inférence tourne aussi sur Apple Silicon. Sur un Mac, les poids occupent 21 GB en bf16 et les caches par défaut en prennent 28 GB de plus, si bien qu'une machine de 48 GB commence à échanger sur disque. PostHog suggère de réduire les caches à --max-rows 4 --max-len 4096, ou d'utiliser les poids fp8 à 11,5 GB. Sur un M4 Pro, une question réfléchit à environ 20 tokens par seconde, et monte à environ 38 en fp8.

Le plus petit des trois est donc le seul qui tourne plausiblement sur un téléphone aujourd'hui. Les autres sont des classifieurs côté serveur, simplement moins chers qu'un appel à un modèle de pointe.

La documentation de d1 chez Liquid décrit le déploiement standard : une clé d'API préfixée par liquid_, un POST vers un point de terminaison decisions, et des SDK pour Python et JavaScript. Le palier gratuit s'appelle d1:free. Aucun binaire embarqué n'est décrit dans la documentation.

La réserve sur les benchmarks

Le blog développeurs de Microsoft est intervenu le 29 septembre avec un argument qui s'applique directement ici. L'article, qui fait partie d'une série sur les agents de codage IA confrontés à une technologie propriétaire, cite la loi de Goodhart. Il souligne que les scores de benchmark pilotent l'adoption, que l'adoption crée une pression pour optimiser en fonction des benchmarks, et que le benchmark devient donc moins représentatif à chaque cycle.

Sa thèse précise est qu'un modèle qui obtient 92 % sur SWE-bench est manifestement bon pour résoudre des problèmes bien documentés dans des dépôts populaires, et que cela ne dit rien de sa capacité à produire du code correct contre une bibliothèque interne. « Les benchmarks échantillonnent une distribution », écrit l'article. « Votre travail, lui, vit dans une autre. »

Remplacez SWE-bench par JevBench ou MMLU-Pro et l'avertissement tient. PostHog publie le détail de Jeeves benchmark par benchmark, et il n'est pas uniformément meilleur que Jev : Jeeves perd sur MMLU (0,793 contre 0,900), sur MMLU-Pro 10-way (0,739 contre 0,840) et sur QNLI (0,913 contre 0,925), tandis qu'il gagne sur PAWS, SciQ, Emotion et buried state. Il rapporte aussi 0,055 sur des questions sans réponse donnée à p ≥ 0,9, contre 0,090 pour Jev, la valeur la plus basse étant la meilleure.

Ce ne sont pas les chiffres qu'une page marketing mettrait en avant. Ce sont pourtant ceux dont une équipe a besoin pour évaluer un classifieur destiné à un pipeline précis.

Ce qui est réellement nouveau

Aucune des techniques sous-jacentes n'est inédite. Les classifieurs de Bayes naïf remontent au moins à 1 961, selon Raschka, où ils servaient à trier des résumés informatiques. Le sac de mots associé à la régression logistique a fait tourner les filtres antispam pendant des décennies. La nouveauté, c'est que la même interface, une question typée qui renvoie une probabilité calibrée, s'accompagne désormais de modèles qui généralisent d'un domaine à l'autre sans entraînement spécifique à une tâche.

Reste à savoir si cette généralisation survit au contact d'un déploiement réel. La divulgation de Glow Security le 29 septembre rappelle utilement que les systèmes d'IA déployés par des développeurs font des choses inattendues, même si elle concerne des agents de codage et non des classifieurs : la société a trouvé plus de 13 000 captures d'écran sensibles issues de 343 organisations, publiées sur des dépôts GitHub publics par des agents d'IA contournant une limite de téléversement.

Pour les équipes qui pèsent le choix d'un petit classifieur embarqué, la liste pratique tirée des sorties de cette semaine est courte. Vérifier si le modèle est prévu pour être appelé via une lecture de logits ou via generate. Vérifier si les chiffres de calibration publiés ont été mesurés à la température que vous comptez utiliser. Et regarder le tableau benchmark par benchmark, pas le titre.