Kolibri, expliqué : Aleph Alpha lance un modèle allemand-anglais de 78 milliards de paramètres sous Apache 2.0

Aleph Alpha a publié Kolibri le 3 octobre 2026, un modèle à mélange d'experts de 78,1 milliards de paramètres qui active 3,46 milliards de paramètres par token, dispose d'une fenêtre de contexte validée de 1 048 576 tokens et est livré avec l'intégralité de ses poids sur Hugging Face sous licence Apache 2.0. Le laboratoire de Heidelberg l'a publié le jour de la Réunification allemande, accompagné d'un rapport technique, d'une fiche modèle en allemand et en anglais, et d'un compte rendu exceptionnellement détaillé de la manière dont la chose a été entraînée. Le modèle auquel il est comparé tout au long de la documentation d'Aleph Alpha elle-même est Kolibri Origin — le prédécesseur de 30,6 milliards de paramètres et 3,27 milliards de paramètres actifs qui a achevé son pré-entraînement le 11 juin 2026 et n'a jamais été rendu public. Deux modèles, à trois mois d'intervalle, et la distance entre eux est ce qu'il y a de plus intéressant dans cette publication.

Ce qui rend Kolibri digne d’une lecture attentive, ce n’est pas qu’il soit le modèle le plus puissant disponible. Dans les propres tableaux comparatifs d’Aleph Alpha, il ne l’est pas, et nous y reviendrons. Ce qui est notable, c’est qu’un laboratoire européen ait livré un modèle à poids ouverts à cette échelle, avec le pipeline d’entraînement, la provenance des données et le chiffre de consommation énergétique publiés en parallèle, et ait choisi la licence Apache 2.0 plutôt qu’une licence de recherche sur mesure. Pour les équipes dont les règles d’approvisionnement commencent par « où vont les données », cette combinaison est le produit.

La fiche technique, et les deux chiffres qui comptent

Tout ce qui suit provient de la fiche de modèle qu’Aleph Alpha a publiée avec les poids ; rien de tout cela n’a encore été reproduit de façon indépendante, et il n’existe pas de ligne Artificial Analysis pour Kolibri au moment de la rédaction.

• Paramètres totaux — 78 103 074 560, avec 3 457 573 120 actifs par token, soit un rapport d’environ 22,6 pour 1.

• Architecture — un transformeur à 50 couches, toutes les couches en mélange d'experts, 384 experts par couche avec 1 partagé et 6 routés, et un ratio de 4:1 entre attention à fenêtre glissante et attention à requêtes groupées sur l'ensemble de la pile.

• Contexte — entraîné sur 16 384 tokens, entraîné en phase intermédiaire sur 65 536, et étendu à 262 144 en natif. Comme l'encodage positionnel n'est appliqué que dans les couches à fenêtre glissante, Aleph Alpha déclare que la fenêtre peut être étendue sans mise à l'échelle des positions, et a validé la qualité et l'efficacité de service jusqu'à 1 048 576 tokens. La fiche recommande de rester à 262 144 ou en dessous pour les travaux sensibles à la latence et pour les tâches complexes.

• Précision — poids FP8 en blocs de 128×128 avec activations quantifiées dynamiquement, évaluées avec un cache KV en FP8 ; les embeddings, la tête LM, les normes et le routeur MoE restent en bfloat16.

• Raisonnement — quatre niveaux d’effort : aucun, faible, moyen et élevé, définis via le modèle de chat.

• Appel d'outils — oui, à la manière d'Hermes, avec un parseur vLLM livré dans le même dépôt que les poids.

• Langues — l’allemand et l’anglais, et rien d’autre. C’est présenté comme un choix de conception plutôt qu’un oubli.

• Entraînement — 20 billions de tokens de pré-entraînement sur un corpus bilingue filtré, environ 62,5 % d'anglais, 23,9 % d'allemand et 13,6 % de code, ainsi que 3,44 billions de tokens de mi-entraînement et 201 milliards pour l'extension du contexte long.

• Calcul — 768 NVIDIA B200s répartis sur 96 nœuds HGX, 21 jours de pré-entraînement pour 511 heures et 392 000 heures GPU, à un débit déclaré de 6,4 × 10²³ FLOPs. L’entraînement intermédiaire a ajouté cinq jours et 90 000 heures GPU ; l’extension de contexte long a ajouté 13 heures et 10 000 heures GPU.

• Énergie — 9,5×10² MWh estimés, incluant les surcoûts du centre de données, couvrant le pré-entraînement, l’entraînement intermédiaire et l’entraînement à long contexte, mais excluant le fine-tuning supervisé et l’apprentissage par renforcement.

• Licence — Apache 2.0. Aucun avenant relatif à l'usage acceptable, aucun seuil d'utilisateurs actifs mensuels, aucune condition commerciale distincte.

Deux de ces lignes sont celles qu’un acheteur devrait lire deux fois. Le nombre de paramètres actifs est ce que vous payez à l’inférence, et 3,46 milliards d’actifs sur 78 milliards au total, c’est un ratio de parcimonie agressif — c’est la raison même pour laquelle un modèle de cette taille peut être servi, ne serait-ce que sur deux GPU. Et le chiffre de contexte est annoncé comme 262 144 natif avec 1 048 576 validé, ce qui est une affirmation plus prudente que le simple « contexte de 1 M » que vous verrez dans la plupart des couvertures de cette sortie.

Deux modèles, à trois mois d'intervalle

Kolibri est le deuxième modèle issu de ce qu'Aleph Alpha appelle son Model Factory, et la chronologie qu'elle a publiée est la partie de l'annonce que la plupart de la couverture médiatique omet.

Le travail sur la chaîne de traitement d’entraînement a commencé en janvier 2026. Kolibri Origin a terminé son pré-entraînement à l’échelle cible le 11 juin 2026 — 30,6 milliards de paramètres au total, 3,27 milliards actifs, une fenêtre de contexte de 65 536 jetons, 7,51 billions de jetons d’entraînement, 50 couches dont deux denses et 48 MoE, et un seul mode de raisonnement. Il a été validé en interne et n’a jamais été diffusé publiquement. Kolibri a terminé son pré-entraînement le 11 septembre 2026.

• Paramètres — 30,6 B au total et 3,27 B actifs, contre 78,1 B au total et 3,46 B actifs.

• Contexte — 8 192 jetons de contexte de pré-entraînement sur Origin, contre 16 384 sur Kolibri, atteignant nativement 262 144.

• Données — 7,51 billions de tokens de pré-entraînement sur Origin, contre 20 billions, issus d'un vivier brut de plus de 200 billions que le pipeline a filtré, dédupliqué et sélectionné.

• Architecture — deux couches denses plus 48 couches MoE sur Origin, contre 50 couches MoE, avec une conception d'attention modifiée, un nombre d'experts triplé, une sparsité accrue et un algorithme de routage remplacé.

• Raisonnement — un mode sur Origin, contre aucun, faible, moyen et élevé sur Kolibri.

• Sortie — pas de sortie publique pour Origin, le 3 octobre 2026 pour Kolibri.

Les chiffres qui évoluent le plus sont ceux des suites de tâches, où le même harnais d’évaluation a noté les deux modèles. Sur la moyenne allemande de la suite post-entraînement, Origin a obtenu 46,4 et Kolibri 70,8 ; sur la moyenne anglaise, 54,1 contre 75,5. Sur AIME 2025 en allemand, 73,5 contre 87,5. Sur les benchmarks internes de type proxy client que le fournisseur publie comme un ensemble sectoriel, la suite pour les fournisseurs automobiles est passée de 0,72 à 0,99, les semi-conducteurs de 0,35 à 0,80, le secteur public allemand de 0,54 à 0,75, la technologie d’entraînement industriel de 0,31 à 0,60 et l’aérospatiale de 0,14 à 0,59.

Ces chiffres sectoriels internes sont produits par les fournisseurs sur des suites d’évaluation conçues par les fournisseurs et pensées pour leurs clients ; considérez-les donc comme une description de l’intention plutôt que comme un score. Ce qui justifie de les publier, c’est qu’ils expliquent ce pour quoi le modèle a été optimisé : non pas un classement, mais un ensemble de documents propres à des secteurs réglementés.

L’allemand est ici un choix de conception, pas une balise de langue.

La plupart des fiches de modèle « multilingues » désignent un mélange d’entraînement qui incluait par hasard un peu d’allemand. Celle-ci est construite à l’inverse, et la fiche est précise sur les mécanismes.

Aleph Alpha a découvert, à partir de petites expériences avec des modèles proxy, qu’environ 20 pour cent de données allemandes dans le mélange produisaient les meilleurs résultats, ce qui, pour un entraînement de 20 000 milliards de tokens, signifiait trouver 4 000 milliards de tokens allemands. Les jeux de données allemands ouverts, dédupliqués et filtrés, lui ont fourni 390 milliards — soit un ordre de grandeur en dessous de l’objectif. Elle a comblé l’écart de trois manières : en réajustant un filtre Common Crawl spécifiquement pour l’allemand, ce qui a produit 1 300 milliards de tokens organiques uniques ; en reformulant des documents allemands existants en entrées de style encyclopédique, en dialogues questions-réponses et en passages de texte, ce qui a produit environ 1 000 milliards de tokens supplémentaires et est devenu la plus grande source allemande ; et par la traduction, utilisée uniquement dans Kolibri Origin et abandonnée pour Kolibri. L’allemand a fini sous la forme d’un pool unique de 2 400 milliards de tokens, dont 80 pour cent ont été sélectionnés ou générés en interne, représentant 21,3 pour cent des tokens de pré-entraînement après suréchantillonnage.

Le détail du filtre mérite d’être cité, car c’est le genre de chose qui n’apparaît que dans un laboratoire ayant réellement fait de l’entraînement sur de l’allemand. Un pipeline standard de données linguistiques écarte les documents contenant trop de mots longs — or la prose administrative allemande dépasse régulièrement la limite anglaise de longueur moyenne des mots, si bien que les paramètres par défaut suppriment discrètement le registre dans lequel écrit l’administration publique. La conséquence commerciale évidente est qu’un modèle entraîné sur un filtre anglais standard n’a pour ainsi dire aucun vocabulaire juridico-administratif allemand, et aucun benchmark ne vous le dira.

Le tokenizer a droit au même traitement. Aleph Alpha a entraîné un tokenizer bilingue allemand-anglais doté d'un vocabulaire de 128 000 tokens, à l'aide d'une nouvelle méthode qu'elle appelle UniBPE, laquelle conserve la fusion ascendante du byte-pair encoding mais sélectionne les fusions selon un objectif unigramme. Sur du texte web allemand, il annonce 4,90 octets en moyenne par token, devant GPT-5 à 4,35, Gemini à 4,13, Qwen3.5–3.8 à 4,17, GLM 5.3 à 3,93, DeepSeek V4 à 3,72 et Kimi K3 à 3,28 — des chiffres tous rapportés par les fournisseurs dans leur propre comparatif. Plus de texte par token signifie moins de tokens par tâche, ce qui est un effet direct sur le coût d'inférence plutôt qu'une affirmation de qualité, et c'est le genre de gain d'efficacité qui se cumule à l'échelle d'une charge de travail de traitement de documents.

Ce que la table du fournisseur ne tranche pas

Aleph Alpha a publié une comparaison de post-entraînement portant sur quatorze modèles, et elle est plus utile que la plupart des tableaux de lancement parce qu’elle ne flatte pas le sujet.

Sur le même harnais, avec Kolibri à un effort de raisonnement élevé, Qwen3.8 27B obtient 80,2 sur la moyenne anglaise contre 75,5 pour Kolibri, et 79,9 sur la moyenne allemande contre 70,8. Il arrive aussi en tête sur GPQA Diamond, LiveCodeBench v6, SWE-Bench Verified et les deux benchmarks de contexte long. Nemotron 3 Super 120B-A12B obtient 73,0 en anglais contre 75,5 pour Kolibri — plus proche, et en avance sur AIME 2025. Gemma 4 26B-A4B IT obtient 71,9 et 66,3 sur les deux moyennes.

Donc, le résumé honnête de cette sortie n’est pas « à la pointe de l’art ». C’est que Kolibri se situe au milieu d’un éventail de modèles qui activent entre trois et douze milliards de paramètres par token, qu’il bat clairement les modèles bien plus petits, et qu’il perd face à un modèle dense de 27 milliards de paramètres d’Alibaba sur la plupart des lignes de son propre tableau, tout en activant environ un huitième des paramètres. Le cadrage d’Aleph Alpha pour cela est la frontière de Pareto de la qualité par rapport aux tokens décodés par seconde et par GPU — aucun des modèles comparés ne fournit plus de qualité à coût de service égal, ni la même qualité à coût inférieur. C’est là l’affirmation à interroger, et c’est une affirmation d’économie du service, pas une affirmation de capacité.

Aucun de ces chiffres n'est vérifié de manière indépendante. Il n'existe aucune entrée Artificial Analysis pour Kolibri, aucune réplication par un tiers du cadre d'évaluation, et les benchmarks verticaux sont construits par le fournisseur. La comparaison est en outre structurellement généreuse envers Kolibri dans une direction et peu généreuse dans une autre : les quatorze modèles ont tous été exécutés via le propre harnais d'Aleph Alpha avec des prompts et des paramètres few-shot identiques, ce qui est la bonne façon de procéder, mais cela reste le harnais d'un seul laboratoire. Considérez chaque chiffre de cette section comme rapporté par le fournisseur jusqu'à ce que quelqu'un d'autre l'exécute.

Ce dont vous avez besoin pour l’exécuter

Kolibri n'est pas un modèle que l'on teste sur un ordinateur portable. Les poids FP8 représentent une empreinte mémoire du modèle d'environ 78 Go, et la configuration minimale côté carte est de deux cartes A100 80 Go, deux H100 SXM5, un H200, un B200 ou un B300 ; la configuration recommandée est de deux H100 SXM5, deux H200, un B200 ou un B300.

Le servir implique d'installer le paquet aleph-alpha-inference, qui fournit le plugin Kolibri pour vLLM et fixe la version de vLLM prise en charge, ou de récupérer l'image de conteneur ghcr.io/aleph-alpha/aleph-alpha-inference. À partir de là, il s'agit d'un appel vLLM standard avec le cache KV FP8, l'analyseur de raisonnement Kolibri et l'analyseur d'appels d'outils Kolibri. Les contextes au-delà de 262 144 tokens nécessitent un flag maximum-model-length explicite et une surcharge de position-embedding. Les paramètres d'échantillonnage recommandés sont temperature 1.0, top-p 0.97 et top-k 128.

La surface d’API est compatible avec OpenAI, ce qui compte plus qu’il n’y paraît : l’effort de raisonnement est transmis via le template de chat sous forme de valeur reasoning_effort, et les appels d’outils sont émis dans le champ standard tools. Une équipe qui parle déjà le format chat-completions peut pointer son code existant vers un point de terminaison Kolibri sur une machine située dans ses propres locaux, sans couche d’encapsulation.

Ce que Kolibri n'a pas encore

Quatre absences méritent d’être énoncées clairement, car la couverture du lancement tend à les passer sous silence.

• Aucune évaluation indépendante. Artificial Analysis n'a pas de page de modèle pour Kolibri, et aucun tiers n'a publié de reproduction du tableau de benchmarks du fournisseur.

• Aucun endpoint hébergé fourni par le vendeur. La publication se compose des poids et d’un rapport technique ; il n’existe aucun SKU d’API Aleph Alpha pour Kolibri dans le matériel publié avec le modèle.

• Aucune route sur OrcaRouter, ni chez aucun agrégateur que nous nommerions. Nous avons sondé le catalogue sous toutes les orthographes du préfixe du fournisseur et du nom du modèle, et Kolibri n'y figure pas — donc si vous voulez l'appeler, vous téléchargez 78 GB et exécutez vous-même un point de terminaison vLLM. Nous préférons le dire plutôt que de laisser entendre que nous le servons.

• Pas d’entrée multimodale. Du texte en entrée, du texte en sortie, deux langues. C’est le compromis que le laboratoire a fait en faveur de la profondeur plutôt que de l’étendue, et pour un déploiement de traitement de documents, c’est probablement le bon, mais c’est une véritable limite.

Si ce dont vous avez réellement besoin aujourd'hui est un petit modèle de mélange d'experts que vous pouvez appeler sans acheter deux GPU, le palier Gemma 4 MoE est ce qui s'en approche le plus déjà disponible sur un point de terminaison routé, à 0,06 $ par million de tokens d'entrée et 0,33 $ par million de tokens de sortie sur la variante 26B-A4B, avec une fenêtre de 262 144 tokens. Pour quiconque compare à cela un déploiement souverain auto-hébergé de 78B, la comparaison utile ne réside pas dans les lignes de benchmark — c'est 78 Go de VRAM et une discussion d'achat face à un poste facturé au token. OrcaRouter route ce palier sur une seule clé compatible OpenAI, avec le prix catalogue du fournisseur répercuté et rien ajouté, ce qui est le moyen le moins cher de déterminer si la charge de travail justifie de posséder le matériel.

Kolibri lui-même est l'artefact le plus intéressant. Un modèle allemand-anglais de 78 milliards de paramètres sous Apache 2.0, avec le pipeline de données, la méthode de tokenisation, le chiffre de consommation énergétique et un récit d'itération de trois mois publiés aux côtés des poids, constitue un type de publication différent de la mise à disposition habituelle des poids — la divulgation fait partie du produit, et non d'un billet de blog à son sujet. Savoir si l'affirmation de Pareto tient la route est désormais une question pour les personnes disposant de deux H100 et d'un chronomètre, et la réponse ne viendra pas de quiconque a rédigé la fiche du modèle.