Une carte hero générée, intitulée « Glimpse vs Kolibri », avec pour sous-titre « le dépenser à l'entraînement, ou le dépenser pendant que vous réfléchissez ». Deux cartes aux coins arrondis sont disposées côte à côte. La carte de gauche porte le libellé « Elorian Glimpse » et affiche « sorti le 16 octobre 2026 », « aperçu hébergé, sans poids », « revient à une fenêtre de 0,9 seconde de vidéo en pleine réflexion », « nombre de paramètres et fenêtre de contexte non publiés », « 0,60 $ / 3,00 $ par million de tokens ». La carte de droite porte le libellé « Kolibri » et affiche « sorti le 3 octobre 2026 », « poids Apache 2.0, auto-hébergeable », « 78,1 B de paramètres au total, 3,46 B actifs par token », « contexte natif de 262 144 tokens, 1 M validé », « allemand et anglais uniquement, par choix ». Une ligne de pied de page indique « chiffres de Glimpse déclarés par le fournisseur et non reproduits ; chiffres de Kolibri issus de la fiche de modèle publiée d'Aleph Alpha ». Le logo OrcaRouter est intégré en bas à droite.
Engineering & Research

Glimpse vs Kolibri : deux façons d’acheter plus de calcul par token

Auteur

Elias Hawthorne

Date de publication

Derniers modèles · 20Voir tous les modèles →
Benchmarks : Artificial Analysis · mis à jour quotidiennement
Retour à tous les articles

E​lorian G​limpse et K​olibri sont deux réponses à la même question économique — comment obtenir plus de capacité par unité de calcul — et ils se situent aux extrémités opposées de celle-ci. Glimpse, publié par Elorian le 16 octobre 2026, achète sa capacité au moment de l'inférence : il effectue une première passe sur un clip à environ 8 images par seconde, puis dépense du calcul supplémentaire en réexaminant neuf dixièmes de seconde choisis à environ 14 images par seconde avant de répondre. Kolibri, publié par Aleph Alpha le 3 octobre 2026, achète sa capacité au moment de l'architecture : 78,1 milliards de paramètres au total, dont seulement environ 3,46 milliards sont actifs par token, si bien que presque chaque paramètre du modèle est un paramètre que vous ne payez jamais pour évaluer.

Les deux ne sont pas interchangeables, et la raison n’est pas la qualité. L’un est un aperçu hébergé, sans poids, sans nombre de paramètres publié ni fenêtre de contexte publiée. L’autre est un téléchargement sous Apache 2.0 dont la fiche de modèle indique son nombre d’experts, son calendrier d’attention, ses formats numériques, la couverture linguistique de son tokenizer et la facture d’électricité exacte de son entraînement. Les comparer revient en réalité à comparer deux stratégies, et la question intéressante est de savoir quelle stratégie survit au contact de votre charge de travail.

Un ratio de 22 contre 1 face à un ratio que personne n'a publié

Kolibri est un modèle à mélange d'experts clairsemé, et cette parcimonie est extrême, même selon les critères actuels. Cinquante couches, chacune étant un mélange d'experts, 384 experts par couche, dont un partagé et six routés. Cela donne un ratio total/actifs d'environ 22,6 pour 1 — un modèle qui embarque 78 milliards de paramètres mais n'en évalue qu'environ 3,5 milliards pour un token donné. Aleph Alpha alterne cela selon un schéma de 4 pour 1 avec des blocs d'attention à requêtes groupées, ce qui permet de rendre abordable le contexte natif de 262 144 tokens : un chemin d'un million de tokens est validé, et le cache KV est conservé en FP8 pour que l'extrémité longue de cette fenêtre tienne en mémoire plutôt que dans un tableur.

Les choix de format numérique sont divulgués à un degré inhabituel. Les poids sont en FP8 par blocs de 128 × 128. Le cache KV est en FP8. Les embeddings, la tête de modèle de langage, les couches de normalisation et le routeur restent en bfloat16 — les parties où les dommages de quantification se manifesteraient dans les décisions de routage plutôt que dans les pertes. Quatre niveaux d’effort sont exposés. L’appel d’outils suit le format Hermes avec un parseur vLLM, ce qui signifie qu’il s’intègre dans une pile d’agents existante plutôt que de nécessiter une intégration sur mesure.

G​limpse ne publie rien de tout cela. Aucun nombre de paramètres. Aucune structure d’experts à proprement parler, aucune fenêtre de contexte, aucun schéma de quantification, aucun modèle de base nommé — seulement l’expression « post-entraîné sur un modèle de base à poids ouverts », qui ne précise pas lequel. Ce qu’il publie à la place, c’est la trace : une première passe à environ 8 images par seconde, une lecture hésitante, un retour à 0,9 seconde du clip à environ 14 images par seconde, et, dans un second exemple, un bord de fenêtre suivi à partir d’environ 2,2 secondes dans un clip jusqu’à ce qu’il s’arrête presque à 5,13 secondes.

Toutes les deux sont des déclarations concernant le calcul. Celle de K​olibri indique où va le calcul lorsque le modèle se charge. Celle de G​limpse indique où va le calcul pendant que le modèle réfléchit. Une seule d'entre elles s'accompagne d'un nombre.

A screenshot of the Hugging Face model card for Aleph Alpha's Kolibri, showing the model name and organisation, the Apache 2.0 licence, the total and active parameter counts, the 262,144-token context window, the mixture-of-experts layer and expert configuration, the FP8 weight and KV-cache formats, and the German and English language coverage. The page is rendered in English.

Les feuilles publiées, côte à côte

• Taille — K​olibri : 78 103 074 560 paramètres au total, 3 457 573 120 actifs. G​limpse : non publié, avec « nettement plus petit et moins cher que les systèmes de pointe auxquels il se mesure » comme seule indication de taille donnée par E​lorian.

• Accès — Poids Apache 2.0 pour K​olibri, téléchargeables et auto-hébergeables. Aucun pour G​limpse, qui se limite à une API et à un chat, avec inscription gratuite.

• Contexte — 262 144 tokens natifs pour K​olibri, avec 1 048 576 validés. Non publié pour G​limpse, ce qui constitue la lacune la plus embarrassante, puisque sa capacité phare est la lecture de vidéos.

• Langues — allemand et anglais pour Kolibri, qu'Aleph Alpha présente comme un choix de conception plutôt qu'une limitation. Glimpse ne publie absolument aucune couverture linguistique.

• Prix — 0,60 $ par million de jetons d'entrée et 3,00 $ par million de jetons de sortie pour G​limpse — et le mécanisme implique que les jetons de sortie sont là où la réanalyse apparaît, donc la trace est le reçu. K​olibri n'a pas de grille tarifaire, car le coût, c'est le matériel.

• Évaluation indépendante — pratiquement aucune pour l'un comme pour l'autre. Ni l'un ni l'autre ne dispose d'un banc d'essai tiers reproduisant ses chiffres, et les deux séries de chiffres publiées proviennent du fournisseur lui-même.

Le run d'entraînement qu'Aleph Alpha a publié dans son intégralité

C'est ici que K​olibri se démarque de presque toutes les sorties de l'année, et cela vaut la peine de s'y pencher, car cela vous dit ce que la sparsité a coûté à construire.

Le corpus de pré-entraînement comptait 20 billions de tokens, répartis approximativement en 62,5 % d'anglais, 23,9 % d'allemand et 13,6 % de code. L'entraînement intermédiaire en a ajouté 3,44 billions, et une étape de contexte long a apporté 201 milliards. L'exécution a mobilisé 768 accélérateurs NVIDIA B200 sur 96 nœuds HGX, a duré 21 jours et 511 heures de temps réel, et a consommé environ 392 000 heures-GPU — 6,4×10²³ opérations en virgule flottante, pour un budget énergétique d'environ 9,5×10² mégawattheures.

Ces chiffres sont le prix honnête d’un modèle à 3,46 milliards de paramètres actifs qui se comporte comme quelque chose de bien plus grand. Ils sont aussi impossibles à reproduire pour quiconque en dehors d’un laboratoire bien financé, et c’est précisément l’argument en faveur des poids ouverts : le coût d’entraînement est payé une fois par l’entreprise qui publie la fiche, et tout le monde en aval obtient l’artefact pour le prix du téléchargement.

A self-built scoreboard graphic titled 'Kolibri — the training run, as published' with the subheading 'Every figure from Aleph Alpha's own model card'. A single column lists seven rows: 'Pre-training corpus: 20 trillion tokens — 62.5% English, 23.9% German, 13.6% code', 'Mid-training: 3.44 trillion tokens, plus 201 billion in a long-context stage', 'Hardware: 768 NVIDIA B200 accelerators across 96 HGX nodes', 'Duration: 21 days, 511 hours of wall clock', 'Compute: about 392,000 GPU-hours; 6.4 × 10^23 floating-point operations', 'Energy: about 9.5 × 10^2 megawatt-hours', 'Artefact: Apache 2.0 weights, self-hostable'. A footer line reads 'All figures vendor-published by Aleph Alpha and unreproduced by any third party. Glimpse has published no comparable training disclosure: no base model, no token count, no compute budget.' The OrcaRouter logo sits in the bottom-right corner.

Le prédécesseur est instructif. K​olibri Origin comptait 30,6 milliards de paramètres, dont 3,27 milliards actifs, un contexte de 65 536 tokens et 7,51 billions de tokens d’entraînement — et il n’a jamais été publié. Le modèle publié n’est pas une première tentative ; c’est la seconde, et l’écart entre les deux correspond à peu près à l’écart entre un prototype et un produit.

Rien de comparable n’existe pour G​limpse. E​lorian dit seulement que le modèle a été post-entraîné par une petite équipe disposant de quelques centaines de GPU. Aucun modèle de base n’est nommé, aucun nombre de tokens, aucune description des données, aucune divulgation de calcul. C’est une différence légitime entre publier un checkpoint et livrer un endpoint — on divulgue ce que l’on remet — mais cela signifie que les deux versions ne peuvent pas être comparées sur le plan économique au-delà de la grille tarifaire, car une seule d’entre elles a publié ses coûts.

La cellule vide du nombre de paramètres

Voici le piège dans cette comparaison, et il joue en faveur de G​limpse.

Il est facile de lire les 3,46 milliards de paramètres actifs de K​olibri et de conclure que G​limpse — hébergé, bon marché par token, visant une capacité étroite — doit être petit, ou doit être bon marché à exécuter, ou doit être un fine-tuning de quelque chose de modeste. Rien de tout cela ne s'ensuit. Le nombre de paramètres de G​limpse n'a jamais été publié. Sa fenêtre de contexte n'a jamais été publiée. Son modèle de base n'a jamais été nommé. La seule affirmation de taille dans l'article de lancement est comparative et non quantifiée. Là où le comportement ne révèle pas la taille, et que le comportement de ce modèle est un calendrier d'échantillonnage plutôt qu'une architecture, le nombre de paramètres pourrait être presque n'importe quoi et rien de publié ne le contredirait.

Ainsi, la cellule du nombre de paramètres reste vide, et tout chiffre que l'on cite pour la taille de G​limpse ce mois-ci est une estimation déguisée en spécification. Dans l'autre sens aussi, d'ailleurs : le ratio de 22,6 pour 1 de K​olibri ne vous indique pas son coût d'inférence sur votre matériel, car des poids FP8 en blocs de 128×128 ont besoin d'un support d'accélérateur spécifique pour représenter un gain plutôt qu'une étape de conversion.

Là où chaque stratégie échoue

La contrainte de Kolibri, c'est la couverture linguistique, et elle est délibérée. L'allemand et l'anglais, rien d'autre. Pour une entreprise européenne dont le trafic est germanophone, c'est un atout — le mélange d'entraînement est pondéré en faveur d'une langue que la plupart des modèles ouverts traitent comme une erreur d'arrondi. Pour tout autre, c'est un non catégorique, et aucune fenêtre de contexte, quelle que soit sa taille, ne compense.

Sa deuxième contrainte est l'arithmétique du contexte long. Un chemin d'un million de tokens est validé, ce qui est vraiment considérable. Mais un chemin validé n'est pas la même chose qu'un chemin non dégradé ; à ces longueurs, la précision de récupération de presque tous les modèles chute bien avant la fin de la fenêtre, et aucune évaluation publiée n'indique où la courbe de Kolibri s'infléchit. Considérez la fenêtre comme une capacité que vous pouvez allouer plutôt que comme une précision que vous pouvez présumer.

La contrainte de Glimpse est de forme inverse : une capacité étroite, sans rien autour. Si la question est de savoir ce qui s'est passé en une fraction de seconde de vidéo, Glimpse vise directement cela. Si la question est ce qu'une scène implique plutôt que ce qu'elle énonce, le retour en arrière n'aide pas — sur Humanity's Sixth Sense, le benchmark qu'Elorian a publié avec Scale AI neuf jours avant la sortie du modèle, Glimpse obtient 46,36 contre 53,6 pour GPT-6 Astra, et l'analyse des échecs du benchmark lui-même attribue 94 % des erreurs étiquetées à la perception et à l'inférence plutôt qu'au raisonnement. Regarder davantage ne signifie pas mieux comprendre, et le tableau du fournisseur lui-même en est la preuve.

Il existe également une classe de problèmes qu'aucun des deux n'aborde : celle où la réponse doit être un seuil. Glimpse écrit de la prose. Kolibri lit et écrit. Ni l'un ni l'autre n'est conçu pour renvoyer un nombre calibré par option, et si c'est ce dont le pipeline a besoin, l'instrument est d'une forme de modèle entièrement différente.

Là où une couche de routage mérite sa place — et là où elle ne la mérite pas

Les deux modèles se trouvent de part et d'autre d'une frontière que le routage peut déplacer et d'une qu'il ne peut pas déplacer.

La frontière qu'il déplace, c'est le coût et la résilience du mélange des voies. Une équipe qui fait tourner Kolibri sur ses propres accélérateurs pour le trafic en langue allemande et un modèle hébergé pour tout le reste dispose de deux chemins de code, de deux modes de défaillance et de deux jeux d'identifiants. OrcaRouter réduit cela à une seule clé devant plus de 200 modèles, avec un DSL de routage qui décide quelle requête part vers quelle voie et un basculement automatique qui maintient une requête en vie lorsque la voie auto-hébergée est saturée ou indisponible. Les prix catalogue des fournisseurs sont répercutés sans rien ajouter par token, de sorte que la moitié hébergée de ce mélange coûte ce que facture son fournisseur et suit le prix de ce fournisseur dès qu'il change.

La frontière qu'il ne déplace pas, c'est la garde, et ici K​olibri dispose d'un avantage qu'aucune couche de routage ne peut fabriquer. Ses poids sont téléchargeables. Si le corpus ne peut pas quitter les locaux, un checkpoint Apache 2.0 est le seul des deux à s'exécuter là où vivent les données, et aucune évaluation de l'un ou l'autre modèle n'y change rien. Aucun des deux modèles ne figure non plus dans notre catalogue — K​olibri est un téléchargement et G​limpse est l'API et l'interface de chat propres à E​lorian — il s'agit donc d'une déclaration sur notre façon de router, et non d'une prétention à les servir.

Comment décider sans référentiel commun

Il n'existe aucun tableau des scores qui classe ces deux modèles, et ce n'est pas parce que l'un d'eux est nouveau. Le tableau d'E​lorian mesure la perception des vidéos et des images par rapport à GPT-6 Astra ; la fiche d'A​leph Alpha évalue l'éventail académique habituel ainsi que la récupération à long contexte. Ils n'ont aucune tâche en commun, donc la seule comparaison qui compte est celle avec votre propre charge de travail.

Trois questions permettent de trancher plus vite que n’importe quel tableau.

Les données doivent-elles rester sur du matériel que vous contrôlez ? Si oui, K​olibri est le seul candidat ici, la licence est Apache 2.0, et la couverture allemand-anglais correspond à votre déploiement ou l’exclut immédiatement.

Le mode de défaillance est-il temporel — l’identité d’un objet à travers une occlusion, un panoramique versus un cut, un événement dans une fenêtre inférieure à la seconde ? Si oui, G​limpse est le seul des deux modèles dont le mécanisme annoncé y répond, l’inscription gratuite rend l’essai peu coûteux, et la trace vous en apprend plus que le score : lancez vos propres clips et vérifiez si le modèle est jamais revenu à l’intervalle qui a décidé la réponse.

La charge de travail est-elle à contexte long mais pas à vidéo longue — un corpus documentaire, un ensemble de documents de dépôt, une piste d'audit ? Si oui, la fenêtre native de 262 144 jetons de K​olibri, avec un chemin validé à un million de jetons, est le nombre pertinent, et aucune évaluation publiée de l'un ou l'autre modèle ne permet de trancher si elle résiste à la courbe de dégradation à ces longueurs. Ce point doit être mesuré, sur vos données, avant que l'une ou l'autre décision ne puisse être prise en toute sécurité.

A screenshot of the OrcaRouter models catalogue at orcarouter.ai/models, showing the searchable model index with a model count across providers, capability filters for modality, context length, input price and access tier, and the start of the per-model listing. Neither Kolibri nor Elorian Glimpse appears in the index. The page is rendered in English.

Les défaillances documentées de l’IA et les incidents d’agents à l’origine de versions comme celle-ci sont recueillis dans l’OrcaRouter AI Incident Archive, où chaque entrée comporte ses propres sources, sa gravité, sa note de confiance et un indicateur de contestation.