Kolibri vs Granite 4.2 3B : un pari de sparsité à 78B, et le modèle 3B qui refuse de jouer le même jeu

Placez Kolibri et Granite 4.2 3B côte à côte, et la première observation honnête est que ce n'est pas un combat équitable, et pas dans le sens que vous supposez. Kolibri est le modèle à mélange d'experts de 78,1 milliards de paramètres d'Aleph Alpha, publié le 3 octobre 2026, activant 3,46 milliards de paramètres par token. Granite 4.2 3B est le modèle de raisonnement dense d'environ trois milliards de paramètres d'IBM, dont les poids sont arrivés sur Hugging Face le 7 août 2026, la fiche modèle et le blog technique suivant le 25 août. L'un représente vingt-six fois l'autre en nombre total de paramètres. La raison pour laquelle ils appartiennent à la même décision est que tous deux sont sous Apache 2.0, tous deux sont uniquement textuels, tous deux sont auto-hébergés par conception, et tous deux visaient le même acheteur : une équipe qui veut de l'intelligence documentaire sur du matériel qu'elle contrôle, avec la provenance nécessaire pour survivre à un examen d'approvisionnement. La question intéressante n'est pas de savoir lequel est le meilleur. C'est ce que le budget de paramètres vingt-six fois supérieur achète réellement, et ce qu'il coûte à supporter.

{{something}}Le décalage,{{/something}}

Granite 4.2 3B est un modèle dense autonome post-entraîné à partir de Granite-4.1-3B-Base, qui fait partie de la famille Granite 4.2 qu'IBM a livrée jusqu'en août. Il compte 40 couches avec une attention à requêtes groupées, un contexte natif de 128K qu'IBM étend à 512K dans une cinquième phase de pré-entraînement, et trois modes de réflexion par requête : réflexion complète par défaut, un chemin à faible effort et un chemin sans réflexion. La fiche d'IBM fait preuve d'une franchise inhabituelle sur ce que le 3B n'est pas. Contrairement à ses frères 8B et 30B, il a délibérément omis le bloc spécialisé d'apprentissage par renforcement agentique entraîné dans des environnements SWE-agent, terminal et de recherche, c'est pourquoi IBM ne mentionne aucun score SWE-bench pour lui et présente le modèle comme un spécialiste du raisonnement plutôt qu'un agent.

Kolibri prend le contre-pied sur chaque axe. Cinquante couches, toutes fondées sur un mélange d’experts, 384 experts par couche, dont un partagé et six routés, et un ratio de parcimonie d’environ 22,6 pour 1. Son contexte est nativement de 262 144 tokens, validé jusqu’à 1 048 576, la fiche recommandant de rester à 262 144 ou moins pour les charges de travail sensibles à la latence. Quatre niveaux d’effort de raisonnement. Appel d’outils de style Hermes avec un parseur vLLM livré dans le même dépôt que les poids. Et une empreinte d’environ 78 Go en FP8, la configuration minimale indiquée par la fiche étant de deux cartes A100 80 Go, deux H100 SXM5, une H200, une B200 ou une B300.

• Paramètres — Kolibri : 78 103 074 560 au total, 3 457 573 120 actifs par token. Granite 4.2 3B : environ 3 milliards de paramètres denses, tous les paramètres actifs sur chaque token.

• Contexte — Kolibri : 16 384 entraîné, 65 536 en entraînement intermédiaire, 262 144 natif, 1 048 576 validé. Granite 4.2 3B : 128 k natif, étendu à 512 k.

• Modes de réflexion — Kolibri : aucun, faible, moyen, élevé, définis via le template de chat. Granite 4.2 3B : complet, à faible effort et sans réflexion, par requête.

• Appel d'outils — Kolibri : de style Hermes, avec un parseur fourni. Granite 4.2 3B : oui, mais pas la voie entraînée par RL agentique dont ont bénéficié ses grands frères.

• Langues — Kolibri : l’allemand et l’anglais, par conception et rien d’autre. Granite 4.2 3B : priorité à l’anglais, avec l’entraînement multilingue plus large d’IBM derrière.

• Empreinte — Kolibri : environ 78 Go en FP8, deux GPU minimum. Granite 4.2 3B : environ 6–8 Go en bfloat16, moins de 2 Go quantifié, de classe ordinateur portable.

• Licence — toutes deux en Apache 2.0, toutes deux sans avenant d'usage acceptable ni seuil d'utilisateurs actifs mensuels.

• Serving — Kolibri : le plugin vLLM aleph-alpha-inference ou l'image de conteneur publiée. Granite 4.2 3B : vLLM, SGLang, Transformers, GGUF et Ollama sous granite4.2:3b.

Ce que les 75 milliards de paramètres supplémentaires apportent

Trois choses, et il est utile d’être précis sur celles qui sont établies et celles qui sont alléguées.

Le premier est allemand. C'est la différence réelle la plus marquée entre les deux modèles, et ce n'est pas une ligne de benchmark. Aleph Alpha a construit Kolibri autour d'un corpus bilingue allemand-anglais, visant environ 20 pour cent d'allemand dans un pré-entraînement de 20 billions de tokens, et a terminé avec un pool allemand de 2,4 billions de tokens dont 80 pour cent ont été sélectionnés ou générés par le laboratoire lui-même. La fiche explique pourquoi cela a demandé du travail : les jeux de données allemands ouverts dédupliqués ne fournissaient que 390 milliards de tokens, un ordre de grandeur en dessous, alors le laboratoire a réajusté un filtre Common Crawl spécifiquement pour l'allemand et a reformulé des documents allemands existants en entrées d'encyclopédie, en dialogues et en passages. Le détail du filtre est celui à retenir. Un pipeline standard de données linguistiques supprime les documents contenant trop de mots longs, et la prose administrative allemande dépasse régulièrement la limite anglaise de longueur moyenne des mots — ainsi les paramètres par défaut suppriment discrètement le registre dans lequel écrit l'administration publique. IBM n'a pas construit Granite pour ce corpus. Granite 4.2 3B gérera l'allemand ; il n'a pas été conçu autour du registre juridique et administratif allemand, et aucun classement ne vous dira la différence.

Le second est un contexte long qui survit à de vrais documents. Le plafond de 512K de Granite est véritablement élevé, mais les deux modèles y sont parvenus différemment et la conception positionnelle de Kolibri est l’argument de contexte long le plus conventionnel. Considérez les chiffres RULER d’IBM — 67,52 à 64K et 55,30 à 128K dans les documents publiés de la famille 4.2 — comme la divulgation honnête de la dégradation de la qualité de récupération à 128K, et rappelez-vous que Kolibri n’a aucune courbe de dégradation publiée équivalente.

Le troisième est la marge de manœuvre brute en matière de raisonnement, et c'est ici que la réponse honnête est « pas autant que ne le suggère le rapport de paramètres ». Le pipeline d'entraînement de Kolibri lui a valu une phase de pré-entraînement de 20 000 milliards de tokens sur 768 NVIDIA B200 pendant 21 jours, et le propre tableau comparatif d'Aleph Alpha, avec Kolibri au niveau d'effort de raisonnement élevé, le place à 75,5 sur la moyenne anglaise et à 70,8 sur la moyenne allemande d'une comparaison de quatorze modèles — où il perd face à un modèle dense de 27 milliards de paramètres d'Alibaba sur la plupart des lignes. Les chiffres phares du Granite 4.2 3B sont les siens : AIME 2025 à 78,33, GPQA à 54,80, LiveCodeBench v6 à 69,71 et MMLU-Pro à 67,84, tous rapportés par IBM et non reproduits. Des suites différentes, des harnais différents, des fournisseurs différents. Il n'existe nulle part de chiffre issu d'un même harnais pour cette comparaison, et nous n'allons pas en inventer un.

Là où chacun gagne réellement

Exécutez Granite 4.2 3B si votre contrainte, c’est la machine. Avec 6 à 8 Go en bfloat16, ou moins de 2 Go quantifié, il tient sur un ordinateur portable, un seul GPU de station de travail, ou un boîtier edge isolé qui ne verra jamais deux H100. Il est servi par cinq runtimes différents, dont Ollama et GGUF, ce qui compte lorsque la cible de déploiement est l’ordinateur portable de quelqu’un d’autre plutôt que votre propre rack. Et sa fiche est inhabituellement digne de confiance, précisément parce qu’IBM a écrit noir sur blanc ce qu’il a laissé de côté. Un fournisseur qui refuse de revendiquer des résultats SWE-bench pour un 3B vous dit où le modèle s’arrête.

Exécutez Kolibri si le corpus est l'élément central et que le matériel est disponible. Une équipe disposant de contrats en langue allemande, de documentation technique ou de dossiers administratifs, d'un nœud bi-GPU déjà en place et exigeant que les poids ne quittent jamais les locaux correspond exactement au public visé par cette version. La fenêtre native de 262 144 tokens, le cache KV en FP8, les quatre niveaux d'effort et le chemin d'appel d'outils Hermes pointent tous vers des flux de travail documentaires plutôt que vers le chat. Le tokenizer bilingue s'inscrit dans la même logique : Aleph Alpha rapporte une moyenne de 4,90 octets par token sur du texte web allemand, contre 4,35 pour GPT-5 et 3,28 pour Kimi K3, toutes mesures effectuées par les fournisseurs sur leur propre corpus, et un plus grand nombre de caractères par token a un effet direct sur le coût d'inférence plutôt qu'il ne constitue un score. Si cela se vérifie, l'effet se cumule sur chaque page traitée.

L’asymétrie que personne ne met en avant, ce sont les données. IBM a publié les poids de Granite 4.2 3B et un exposé technique détaillé sur la façon dont le modèle a été construit, mais pas les données d’entraînement. Aleph Alpha a publié le pipeline, la provenance des données et le chiffre de consommation énergétique en même temps que les poids de Kolibri — 20 000 milliards de tokens de pré-entraînement, 9,5×10² MWh, y compris les coûts indirects des centres de données et à l’exclusion de l’affinage supervisé et de l’apprentissage par renforcement. Pour une équipe qui doit répondre à la question « d’où vient le texte de ce modèle », cette différence n’a rien de cosmétique.

La réalité du routage pour les deux

Aucun des deux modèles ne figure aujourd’hui dans un catalogue hébergé. Kolibri n’a pas du tout de SKU d’API de fournisseur — la version publiée se compose de poids et d’un rapport technique — et Granite 4.2 3B est distribué sous forme de poids pour cinq piles d’exécution, sans point de terminaison hébergé d’IBM. Tous deux relèvent de l’auto-hébergement, et la question pratique pour la plupart des équipes n’est pas de savoir lequel adopter, mais si la charge de travail justifie de posséder l’un ou l’autre.

C'est là qu'une couche de routage justifie sa place, même pour les modèles qu'elle n'héberge pas. Nous avons passé au crible le catalogue OrcaRouter sous toutes les orthographes des deux noms de modèles, et ni Kolibri ni Granite 4.2 3B ne s'y trouvent : nous ne prétendrons donc pas le contraire. Ce qu'OrcaRouter vous offre, c'est le moyen économique de vérifier si la décision matérielle est justifiée avant de la prendre : dirigez un chemin de test vers un petit palier de mélange d'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 voyez si votre charge de travail de documents allemands a réellement besoin de ce que Kolibri fournit, sur une seule clé compatible OpenAI, au prix catalogue du fournisseur sans rien de plus. Si oui, vous achetez les GPU avec des preuves plutôt qu'avec une intuition. Si non, vous venez d'économiser une commande de matériel.

Le verdict, et ce qui pourrait le changer

Ce n'est pas un affrontement avec un vainqueur. Kolibri et Granite 4.2 3B répondent à des questions différentes à des niveaux de prix différents, et le seul classement honnête est celui par contrainte : si la contrainte est matérielle, Granite 4.2 3B est le seul des deux à être qualifié. Si la contrainte est un travail documentaire en registre réglementaire allemand sur site, Granite 4.2 3B n'a jamais été dans la course et Kolibri est l'artefact le plus intéressant — une publication légitime de 78B en open-weights, Apache 2.0, avec le pipeline de données et le tokenizer publiés aux côtés des poids.

Deux choses permettraient de trancher la comparaison. Une exécution indépendante de Kolibri sur une tâche de questions-réponses documentaire en allemand testerait la promesse pour laquelle cette version a réellement été conçue, car aucun classement ne la mesure actuellement. Et une reproduction indépendante des chiffres de raisonnement de Granite 4.2 3B vous dirait si une machine de classe portable peut tenir son rang sur le sous-ensemble de votre charge de travail qui n'a jamais eu besoin de 78 milliards de paramètres. D'ici à ce que l'un des deux se concrétise, achetez selon vos contraintes, pas selon le nombre de paramètres.