Kolibri d’Aleph Alpha : ce que l’on sait du modèle ouvert et ce qu’il reste à vérifier

Une présentation prometteuse, mais des détails restent à vérifier

Aleph Alpha présente Kolibri comme un modèle à poids ouverts, particulièrement axé sur l’allemand et l’anglais, et destiné aux organisations qui doivent garder le contrôle du lieu d’exécution de leurs systèmes d’intelligence artificielle. L’entreprise a publié une page consacrée au modèle, un dépôt associé et son propre rapport technique. Ces publications permettent d’identifier le produit et son orientation, mais les informations disponibles ne suffisent pas à confirmer toutes les spécifications qui déterminent généralement si un modèle convient à une installation donnée.

Cette distinction est importante. Une page commerciale peut décrire le positionnement d’un produit ; une fiche de modèle, ses fichiers et sa configuration peuvent aider à vérifier son mode de distribution ; et une évaluation reproductible permet de comparer la qualité et les coûts dans des conditions définies. Il ne s’agit pas de preuves interchangeables. En particulier, qualifier Kolibri de « souverain » ne démontre pas à lui seul qu’une organisation respecte ses obligations légales, ni que tous les composants nécessaires peuvent être installés aux mêmes conditions.

Aleph Alpha décrit Kolibri comme une architecture à mélange d’experts, ou MoE, et met en avant son orientation vers des charges de travail sensibles. Les informations disponibles ne permettent pas de conclure que cette architecture, à elle seule, améliore les résultats ou réduit les coûts dans un environnement réel. Pour l’établir, il faut des mesures réalisées sur des tâches, du matériel et des configurations comparables.

Paramètres et contexte : des chiffres communiqués par le fournisseur

La présentation d’Aleph Alpha décrit Kolibri comme un modèle MoE comptant environ 78 milliards de paramètres au total et près de 3 milliards de paramètres actifs par jeton. Ces chiffres doivent être compris comme des données communiquées par l’entreprise, et non comme des résultats vérifiés de manière indépendante dans la documentation disponible. Des valeurs plus précises circulent également — 78,1 milliards au total et 3,46 milliards actifs —, mais les éléments vérifiables ici ne permettent pas de confirmer un tel degré de précision. Il est donc préférable de ne pas comparer ces chiffres exacts à ceux d’autres modèles comme s’ils avaient été validés selon une fiche homogène.

Dans une architecture MoE, le nombre total de paramètres ne correspond pas nécessairement au nombre de paramètres mobilisés pour chaque jeton. Certains experts sont activés pour une partie de l’entrée, tandis que d’autres ne sont pas utilisés à cette étape. Le nombre de paramètres actifs peut aider à estimer les calculs nécessaires, mais il ne détermine pas à lui seul la mémoire requise : les poids à charger, la quantification, la longueur de l’entrée, la taille du lot et l’implémentation jouent également un rôle.

L’entreprise présente aussi Kolibri comme capable de traiter un contexte pouvant atteindre un million de jetons. La documentation disponible ne permet pas de vérifier les conditions associées à ce chiffre ni la qualité du modèle lorsqu’il s’approche de cette limite. Une fenêtre maximale annoncée ne garantit pas que toutes les informations seront retrouvées avec précision ; elle ne renseigne pas non plus, à elle seule, sur la latence, le coût ou les performances avec de longs documents. Pour une évaluation concrète, les organisations devraient demander la configuration exacte et tester leurs propres documents et tâches.

Poids ouverts ne signifie pas que la licence est clarifiée pour tous les usages

L’expression « poids ouverts » indique que les poids du modèle sont publiés, mais elle ne répond pas automatiquement à toutes les questions juridiques et opérationnelles. Une évaluation responsable doit vérifier quelle licence accompagne les poids, si elle autorise la redistribution et l’usage commercial, et si le code, les données de tokenisation, les outils d’inférence ou les autres fichiers nécessaires sont soumis à des conditions différentes.

Les informations disponibles ne confirment pas que la licence Apache 2.0 couvre tous les éléments nécessaires à l’exécution de Kolibri. Il serait donc imprudent d’affirmer qu’elle s’applique à l’ensemble du modèle ou de considérer que les autorisations nécessaires à chaque usage sont établies. La vérification doit porter sur les conditions publiées avec chaque artefact et chaque version précise du modèle ; un avis juridique peut être nécessaire selon le cas.

Il convient également de définir ce que signifie « ouvert » dans le cadre d’un achat ou d’une évaluation. Pour certaines équipes, le téléchargement des poids suffit à mener des expérimentations ; d’autres ont besoin de droits clairement établis pour modifier le modèle, le redistribuer, l’utiliser dans des produits commerciaux et conserver différentes versions. Ce sont des besoins distincts, qu’il ne faut pas déduire de la seule étiquette utilisée dans l’annonce.

Matériel et déploiement : ne pas présumer qu’une seule GPU suffit

La possibilité d’exécuter un modèle sur sa propre infrastructure peut être utile aux organisations qui doivent maîtriser l’accès, la localisation des données ou la connectivité. Aleph Alpha décrit des options de déploiement de sa plateforme, notamment des modes locaux et isolés. Cette description peut aider à étudier les architectures d’installation, mais elle ne constitue pas une spécification complète de Kolibri et ne garantit pas que n’importe quelle configuration locale répondra aux exigences d’une organisation.

Il n’est pas confirmé que Kolibri puisse être exécuté avec le niveau de qualité et de performance requis sur une seule GPU B200 ou H200, ni dans quelles conditions de quantification, de longueur de contexte ou de taille de lot cela serait possible. La disponibilité de ces accélérateurs ne démontre pas non plus qu’une configuration soit économiquement viable ou adaptée à la production. Avant de planifier les capacités nécessaires, il faut des instructions reproductibles, des mesures de consommation mémoire et des essais sur une configuration équivalente à celle qui est envisagée.

L’évaluation doit aller au-delà d’une simple démonstration montrant que le modèle se charge. Il faut mesurer la latence, la concurrence, le coût par tâche, la stabilité, le comportement avec de longues entrées et les besoins de stockage. Il est également utile de définir ce qui se passe si le matériel n’est pas disponible, comment les poids seront mis à jour et quels contrôles permettent de consigner et de limiter les accès.

Souveraineté et réglementation : une capacité de contrôle, pas un certificat de conformité

Un déploiement souverain peut désigner une plus grande capacité à décider où le système est exécuté et qui contrôle l’infrastructure. Ces caractéristiques peuvent être précieuses, mais elles ne prouvent pas automatiquement qu’un usage donné respecte la réglementation sur la protection des données, les règles de la commande publique, les obligations sectorielles ou les politiques de sécurité internes.

La conformité dépend du système dans son ensemble et de son usage : données traitées, finalité, contrôles d’accès, journaux, supervision humaine, gestion des incidents, fournisseur d’infrastructure et conditions contractuelles, entre autres. Même lorsque les poids fonctionnent sur des serveurs internes, les organisations doivent examiner les dépendances et les flux de données. Et si une plateforme propose un mode isolé, sa configuration et son exploitation doivent tout de même être vérifiées.

Aleph Alpha destine son offre aux charges de travail sensibles et aux secteurs réglementés. Cette orientation relève du positionnement du fournisseur ; elle ne constitue pas une évaluation indépendante démontrant que la solution convient à chaque organisme ou secteur. La bonne question n’est pas seulement de savoir si le modèle peut être hébergé localement, mais aussi quels contrôles concrets offre la solution complète et quelles preuves en documentent l’efficacité.

Ce qui manque pour établir une comparaison solide

Les informations publiques recensées ne fournissent pas ici assez de résultats reproductibles pour comparer la qualité de Kolibri en allemand et en anglais à celle d’autres modèles. Elles ne permettent pas non plus d’évaluer rigoureusement ses performances sur des tâches à contexte long ou dans des domaines réglementés. Pour le faire, il faudrait connaître les jeux d’évaluation, les versions testées, les paramètres d’inférence et les résultats, ainsi que les limites et les cas d’échec éventuels.

Les organisations qui envisagent le modèle peuvent considérer sa publication comme un point de départ, et non comme une conclusion d’achat. Elles devraient d’abord définir les tâches et les critères de réussite, puis vérifier la version et ses conditions d’utilisation, avant d’effectuer des tests sur une infrastructure représentative, avec des données et des contrôles adaptés. Pour comparer plusieurs fournisseurs, il importe de maintenir les tâches constantes et de consigner les configurations : de petites différences de contexte, de quantification ou d’instructions peuvent modifier les résultats.

Au vu des éléments disponibles, la conclusion doit rester mesurée : Kolibri est présenté comme un modèle MoE axé sur l’allemand, l’anglais et les déploiements souverains, et Aleph Alpha a publié ses propres documents sur le produit. Les chiffres précis des paramètres, le contexte effectivement exploitable, l’application d’Apache 2.0 à tous les composants, l’exécution sur une seule B200 ou H200 et l’adéquation démontrée aux environnements réglementés nécessitent encore des vérifications ciblées. Distinguer ce qui est annoncé de ce qui est démontré permet d’évaluer l’offre sans transformer le discours sur la souveraineté en garantie qui n’est pas encore établie.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.