Kolibri vs Intern-Decision 4B : l'un rédige des documents, l'autre refuse d'écrire quoi que ce soit.

La chose la plus utile à remarquer à propos de Kolibri et Intern-Decision-4B, c'est qu'ils ne sont pas le même genre d'objet, et que traiter cela comme une comparaison modèle contre modèle serait une erreur de catégorie. Kolibri est le modèle de langage à mélange d'experts de 78,1 milliards de paramètres d'Aleph Alpha, publié le 3 octobre 2026, qui active 3,46 milliards de paramètres par token et écrit du texte en allemand et en anglais. Intern-Decision-4B est un modèle de décision structuré multimodal de 4,54 milliards de paramètres de l'équipe InternLM, mis en ligne sur Hugging Face le 26 septembre 2026, dont la fiche indique clairement qu'il « n'appelle pas generate() et n'échantillonne pas de texte libre » du tout. L'un produit de la prose. L'autre produit une distribution de probabilité sur les options que vous fournissez, en une seule passe avant, et est incapable d'écrire une phrase. Ils ne deviennent concurrents que dans une seule situation étroite, et savoir exactement de quelle situation il s'agit se trouve être la chose la plus utile dans l'une comme dans l'autre de ces publications.

Deux versions, deux affirmations laconiques entièrement différentes

La fiche de Kolibri est la spécification d’un grand modèle de langage clairsemé : 50 couches, toutes en mélange d’experts, 384 experts par couche avec un partagé et six routés, un contexte natif de 262 144 tokens validé jusqu’à 1 048 576, quatre niveaux d’effort de raisonnement, un appel d’outils de style Hermes avec un parseur vLLM fourni, des poids FP8 en blocs 128×128 et des conditions Apache 2.0. Son entraînement a utilisé 20 000 milliards de tokens sur 768 NVIDIA B200 pendant 21 jours — 392 000 heures GPU pour 6,4×10²³ FLOPs rapportés et une consommation estimée à 9,5×10² MWh, y compris la surcharge du centre de données, à l’exclusion de l’ajustement supervisé et de l’apprentissage par renforcement. La configuration de service minimale de la fiche est de deux cartes A100 80 GB, deux H100 SXM5, un H200, un B200 ou un B300, et l’empreinte FP8 est d’environ 78 GB. C’est un élément d’infrastructure sérieux, et il répond aux questions en générant du texte.

Intern-Decision-4B est un objet de nature opposée, et la fiche est d’une franchise rafraîchissante à ce sujet. C’est un fine-tune de Qwen3.5-4B dans lequel la tour de vision et le projecteur sont gelés et seul le backbone linguistique est entraîné. Vous lui passez un état, un schéma de questions nommées, et éventuellement jusqu’à huit images, et il renvoie une distribution sur les réponses candidates pour chaque question, en une seule fois. Le mécanisme est inhabituel et mérite d’être décrit précisément : les options sont mappées sur des symboles d’un seul token allant de A à Z, de a à z et de 0 à 9 — 62 candidats, donc un maximum de 62 options par question — le prompt est rendu avec un espace réservé par champ, et le modèle lit les logits à la position immédiatement avant chaque espace réservé. Le softmax est calculé uniquement sur les logits des symboles autorisés pour ce champ, une température propre au checkpoint calibre le résultat, et les symboles sont reconvertis en vos valeurs d’option d’origine sous forme de JSON typé. Il n’y a pas de boucle de décodage, ni d’échantillonnage, ni de prose.

• Sortie — Kolibri : texte généré librement en allemand ou en anglais, appels d'outils, traces de raisonnement. Intern-Decision-4B : réponses JSON typées avec une probabilité par option.

Paramètres — Kolibri : 78 103 074 560 au total, 3 457 573 120 actifs. Intern-Decision-4B : 4,54 milliards répartis sur quatre fragments safetensors en bfloat16, avec une tour de vision gelée.

• Entrée — Kolibri : texte uniquement. Intern-Decision-4B : texte plus jusqu'à huit images.

• Capacité de question — Intern-Decision-4B : jusqu'à 62 options par champ, en une seule passe avant, avec les types de questions « choice », « score » et « noul » (oui/non). Kolibri : illimité en principe, un token à la fois en pratique.

• Langue — Kolibri : l’allemand et l’anglais par construction. Intern-Decision-4B : tout ce que Qwen3.5-4B embarque, avec toutes les suites d’évaluation publiées en anglais.

• Latence — Intern-Decision-4B : 44,16 ms en moyenne, 44,03 ms en médiane et 44,60 ms au P95 par requête sur une seule RTX 4090, selon sa propre mesure. Kolibri : aucun chiffre publié par requête, absolument aucun.

• Licence — les deux sous Apache 2.0 ; Intern-Decision-4B est livré avec le fichier de licence Qwen conservé à ses côtés.

Pourquoi un scorer 4B existe tout court

L'argument en faveur d'Intern-Decision-4B n'est pas qu'il est petit. C'est que demander une probabilité à un grand modèle génératif n'est pas la même chose que d'en mesurer une, et la différence est mesurable.

La propre table de référence de la fiche défend l'argument avec un degré inhabituel de transparence sur soi. Sur sept suites de précision, Intern-Decision-4B obtient une moyenne de 90,02 — contre 88,74 pour la référence la plus solide à laquelle il se compare, un modèle appelé Jev. Mais la précision est la moitié sans intérêt. La table rapporte également le score de Brier et l'erreur de calibration attendue, et là, le constat est plus sévère. Le 4B affiche un Brier de 0,347 et une ECE de 0,065, contre 0,358 et 0,095 pour Jev. C'est chez ses petits frères que l'histoire de la calibration devient véritablement instructive. Intern-Decision-2B obtient une moyenne de 84,68, bien devant le 0.8B à 79,38 — et pourtant son ECE de 0,100 est pire que celle du 0.8B, 0,066, et pire que celle du 4B, 0,065, avec un Brier de 0,437 contre 0,530 pour le 0.8B. Le plus précis des deux petits modèles est le moins honnête quant à sa propre confiance. Si vous aviez supposé que la calibration s'améliore avec la précision, ou avec le nombre de paramètres, ce tableau est le contre-exemple sur les deux plans.

Un second diagnostic distinct couvre 96 cas construits avec des distributions de référence exactes plutôt que des étiquettes dures échantillonnées — tirages aléatoires, événements composés, historique conditionnel, énigmes probabilistes. L'erreur du modèle 4B sur ce pilote est passée de 0,628 à 0,550 sur la métrique rapportée, tandis que le modèle de comparaison se situait à 0,595. La fiche précise explicitement que ce pilote n'a pas servi à ajuster ni à sélectionner la température publiée ; la température de 1,992418 du 4B a été ajustée séparément sur un ensemble de calibration. L'équipe InternLM a également livré le benchmark lui-même dans le dépôt GitHub — le générateur déterministe, les références et le scoreur hors ligne — ce qui signifie que l'affirmation de calibration est du rare type qu'un tiers peut réellement réexécuter plutôt que de croire sur parole.

Rien dans la publication de Kolibri n’offre d’équivalent. Son tableau comparatif indique l’exactitude sur les tâches pour quatorze modèles sur un unique harnais de fournisseur, et l’exactitude est ce sur quoi un modèle génératif peut être mesuré. Il n’y a aucun chiffre de calibration, aucun Brier ni ECE nulle part dans la documentation, et aucun moyen de lui demander « la probabilité que cette clause contractuelle soit exécutoire » sans échantillonner une phrase et la lire.

La seule couture où ils se rencontrent vraiment

Placez les deux côte à côte dans un vrai pipeline et les contours deviennent évidents. Un flux de travail documentaire allemand a besoin des deux moitiés, et aucun des deux outils ne couvre la moitié de l'autre.

Kolibri est la moitié qui lit et écrit. Une équipe dotée de contrats allemands ou de documentation technique obtient une fenêtre native de 262 144 tokens, un cache KV FP8, un tokenizer bilingue qu'Aleph Alpha annonce à 4,90 octets moyens par token sur du texte web allemand, et l'appel d'outils Hermes — c'est-à-dire un modèle capable de résumer un document déposé, de rédiger une réponse et de piloter une boucle d'outils. Ce qu'il ne peut pas faire, c'est vous indiquer son propre niveau de confiance d'une manière que vous pouvez auditer, car tout ce qu'il émet est une chaîne échantillonnée.

Intern-Decision-4B est la moitié qui décide. Étant donné une page de texte allemand et un ensemble fixe d'options, il renvoie une distribution calibrée en 44 millisecondes sur un seul GPU grand public, sans étape de génération et donc sans aucune variance d'échantillonnage. Ce qu'il ne peut pas faire, c'est produire le texte allemand au départ, et ses suites d'évaluation publiées sont en anglais — son comportement en allemand est hérité de la base Qwen3.5-4B plutôt qu'entraîné pour cela, ce qui constitue une véritable limitation pour un déploiement en langue allemande et une limitation que personne n'a évaluée.

Donc, la réponse d’ingénierie honnête pour un flux de travail réglementé en langue allemande est qu’il s’agit de deux étapes d’un même pipeline, et non de deux candidats pour un même emplacement. La question pratique est de savoir où chacun s’exécute. Kolibri a besoin de deux H100 ou d’un B200 et d’environ 78 Go. Intern-Decision-4B a besoin d’une RTX 4090 et traite une requête en moins de 45 millisecondes. L’asymétrie de coûts est d’environ deux ordres de grandeur sur le matériel, et elle pointe vers une conception où un petit évaluateur s’exécute en continu sur chaque cas et où le grand générateur n’est invoqué que lorsqu’un cas a réellement besoin de prose. C’est une configuration moins coûteuse et plus facile à auditer que d’acheminer chaque cas à travers le modèle 78B pour obtenir une réponse qu’il faut ensuite interpréter.

La réalité d'hébergement pour les deux, et à quoi sert la couche

Aucun des deux modèles n'est disponible en tant qu'API hébergée, et nous avons vérifié plutôt que de supposer. Intern-Decision-4B n'a pas de point de terminaison fournisseur ; la publication se compose de poids, d'un dépôt GitHub et d'un Space Hugging Face. Ses compteurs de téléchargements et de likes ont évolué depuis le milieu de la semaine, ce qui montre que les gens l'adoptent, mais il n'existe toujours aucune voie d'appel payante que nous puissions nommer.

Kolibri n'a pas non plus de SKU d'API Aleph Alpha — la publication consiste en des poids, un rapport technique et une image de conteneur à ghcr.io/aleph-alpha/aleph-alpha-inference. Et il n'est pas non plus sur OrcaRouter : nous avons sondé le catalogue sous toutes les orthographes du préfixe de fournisseur et du nom du modèle, et il renvoie « not found », ce que nous préférons dire plutôt que de sous-entendre le contraire.

Ce qu'une couche de routage change ici, ce n'est pas l'accès à ces deux modèles, c'est l'économie de la décision d'acheter ou non le matériel pour l'un comme pour l'autre. Le test honnête avant achat pour la moitié générative consiste à exécuter la charge de travail sur un petit palier mixture-of-experts déjà routé — la variante Gemma 4 26B-A4B à 0,06 $ par million de tokens d'entrée et 0,33 $ par million de tokens de sortie, avec une fenêtre de 262 144 tokens et une entrée texte, image et vidéo — sur une clé compatible OpenAI au prix catalogue du fournisseur sans rien ajouter, et à voir si la charge de travail de documents allemands a réellement besoin de 78 milliards de paramètres avant que les GPU soient commandés. La moitié décisionnelle n'a pas de raccourci de ce genre, car le comportement de distribution calibrée est tout l'intérêt du modèle et aucun palier routé ne le fait. Mais c'est en soi le constat : cela vous dit que le scoreur 4B est la partie que vous hébergerez véritablement vous-même, et que le générateur est la partie qui mérite d'être retestée face à quelque chose que vous pouvez louer cet après-midi.

Qu'est-ce qui le réglerait

Deux mesures, et aucune des deux n'existe encore.

Le premier est Intern-Decision-4B sur des entrées en allemand. Toutes les suites publiées sont en anglais et le modèle est un fine-tune d’une base multilingue, donc sa calibration en allemand est inconnue — et la calibration est précisément la propriété qui ne se transfère pas gratuitement d’une langue à l’autre. Une version allemande du pilote de distribution à 96 cas serait l’artefact le plus informatif que quiconque pourrait publier sur ce modèle.

Le second est le coût par décision de Kolibri. Son argument d’économie de service est une frontière de Pareto entre la qualité et les tokens décodés par seconde par GPU, et il n’existe aucune page Artificial Analysis pour Kolibri ni aucune réplication tierce du harnais. Tant que personne ne l’exécute, « 78 milliards de paramètres » est une spécification plutôt qu’un coût, et l’argument en faveur du maintien d’un évaluateur de 44 millisecondes en amont de celui-ci reste un argument de conception plutôt qu’un argument mesuré.

D’ici là, la bonne façon d’interpréter ce duo n’est pas d’y voir une compétition. Intern-Decision-4B est la version la plus intéressante techniquement des deux, car la sortie structurée tenant compte de la calibration est une capacité que presque aucun modèle génératif n’offre, et sa fiche permet de vérifier cette affirmation. Kolibri est la version la plus lourde de conséquences, car un laboratoire européen qui livre un modèle Apache 2.0 de 78 milliards de paramètres avec le pipeline de données publié en parallèle constitue un événement de chaîne d’approvisionnement plutôt qu’un événement de modèle. Ni l’un ni l’autre ne remplace l’autre. Les équipes qui ont besoin des deux doivent planifier pour les deux et dimensionner le matériel en conséquence, et c’est dans l’infrastructure qui les entoure que l’effort d’ingénierie se concentre réellement.