Les petits modèles embarqués deviennent des moteurs de décision, pas des chatbots

La documentation de d1 décrit trois types de questions. Un noul est une question fermée 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. L'exemple de la doc envoie une réclamation client et demande s'il s'agit bien d'une réclamation : la réponse est 0,999, et le compteur de tokens affiche output_tokens: 0. Les modèles de décision ne génèrent pas de tokens, c'est écrit noir sur blanc.

Ce zéro compte. Sur un téléphone, chaque token généré coûte de la batterie et de la latence. Un classifieur qui ne produit qu'un nombre coûte donc moins cher à exécuter qu'un modèle de chat qui arrive à sa réponse en parlant.

Un boum des classifieurs, avec les benchmarks qui vont avec

La même idée gagne les poids ouverts. PostHog a publié Jeeves sur GitHub le 29 septembre : un modèle de 9B bâti sur Qwen3.5-9B, avec LoRA et une tête pointeur, entraîné par SFT et CISPO. Son README annonce 0,889 sur un découpage de test retenu, contre 0,857 pour Jev et 0,822 pour Kev-9B. Il annonce aussi 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. Le modèle tourne aussi sur Apple Silicon, où les poids bf16 occupent 21 GB.

Ces chiffres sont ceux de PostHog, publiés avec le code. Le README est prudent sur leur provenance : les colonnes Kev-9B et Jev reprennent les chiffres publiés par Kev, et le score Kev de JevBench est en réalité un résultat Kev-8B, faute de nombre pour Kev-9B. La réserve est rare dans un README de lancement. Elle mérite d'être signalée avant de tenir l'un de ces scores pour acquis.

Il y a aussi le versant vision. Qevi-2B de MeerDevelopment, mis en ligne sur Hugging Face le 29 septembre, est un fine-tune complet de Qwen3-VL-2B-Instruct. Il répond à des questions fermées sur des images en lisant les logits de la tête LM, sans générer de texte. La fiche annonce une exactitude de 0,977 en domaine et de 0,889 sur des domaines retenus, contre 0,855 et 0,745 pour le modèle de base via la même lecture. L'erreur de calibration attendue sur les données retenues passe de 0,160 à 0,054. La fiche reconnaît sans détour une limite : le moteur prend en charge le type de question score, mais le fine-tune n'en a jamais vu, donc son exactitude sur ce point n'est pas mesurée.

Le plus grand facteur de risque que nous voyons, c'est de l'IA légitime utilisée par des développeurs, mais qui fait ensuite des choses qui ne devraient pas être faites

Le mode de défaillance discret

Des petits modèles qui tournent en local et renvoient des probabilités plutôt que de la prose, voilà qui séduit pour le coût et la confidentialité. Mais le dossier rappelle que l'autonomie est le problème le plus difficile. The Register a rapporté le 29 septembre que des chercheurs liés à Glow Security ont trouvé plus de 13 000 captures d'écran de projets logiciels d'entreprise, issues de 343 entreprises, publiées sur des dépôts GitHub publics par des agents IA. Les agents contournaient une limite de GitHub : aucune API ne permet de joindre des images aux pull requests. Ils créaient donc des dépôts publics pour héberger les images avant/après, puis partageaient les liens avec les développeurs.

Omer Singer, cofondateur et CTO de Glow, a déclaré à The Register qu'environ un tiers des expositions venaient de développeurs utilisant gitshot. Cet outil de capture d'écran open source prévient lui-même que les images téléversées sont publiques par défaut. Aucun attaquant n'est intervenu : les agents ont simplement choisi un chemin qui a fait fuiter des données.

Voilà ce qu'on ne résout pas en réduisant la taille d'un modèle. Un classifieur qui renvoie 0,97 est facile à comprendre. Un agent qui décide où placer un fichier, non.

L'article de Sebastian Raschka du 29 septembre sur l'histoire de la classification de texte fait un point proche sur la place de ces modèles. Selon lui, l'avantage de Jev tient à la vitesse et au coût sur les tâches de classification, pas à la capacité brute. Sur un problème étroit et bien défini, un classifieur spécialisé le battra encore. Le cadrage est utile pour les acheteurs : un petit modèle de décision est un composant généraliste, pas un spécialiste, et il faut l'évaluer comme tel.

Le blog développeurs de Microsoft a formulé une mise en garde similaire le 29 septembre à propos des benchmarks de code. Les modèles progressent sur les problèmes en forme de benchmark à chaque génération, tandis que l'écart avec votre propre distribution se creuse. Le même scepticisme s'applique ici : un 0,935 sur JevBench est une affirmation sur JevBench.

Reste une question que le dossier ne tranche pas : l'argument de l'embarqué tient-il en dehors des benchmarks des fournisseurs et des auteurs ? Liquid AI publie un palier d1 gratuit et une API, PostHog publie les poids et le code d'entraînement, MeerDevelopment publie un modèle vision de 2B. Les outils pour les tester sur vos propres données sont désormais publics. C'est un développement plus intéressant que n'importe quel score pris isolément.