Kolibri : les paramètres actifs ne sont qu’une partie du budget de déploiement

Le 3 octobre, Aleph Alpha a publié Kolibri, un modèle à mélange d’experts aux poids ouverts, axé sur l’allemand et l’anglais, sous licence Apache 2.0. Sa fiche indique 78B paramètres au total et 3.46B paramètres actifs par token. Ces chiffres décrivent différentes parties du même modèle ; le plus petit ne signifie pas que le téléchargement ou le modèle déployé ne représente que 3.46B. [1] [2]

La discussion publique sur Reddit comprend des questions sur le matériel personnel et l’annonce d’un contexte d’un million de tokens. Elles soulèvent une question utile avant un achat : quelle ressource un chiffre mis en avant décrit-il réellement ? Selon nous, une décision de déploiement nécessite des budgets distincts pour le calcul par token, les poids résidents et l’état des requêtes. Aucun ne peut remplacer les deux autres.

La fiche du modèle FP8 décrit une empreinte d’environ 78 GB pour les poids. La version BF16, publiée séparément, indique environ 156 GB. Ce sont des estimations de l’éditeur pour les poids, pas une promesse qu’une machine disposant exactement de cette mémoire pourra servir la charge prévue. La précision modifie le budget de stockage, tandis que la parcimonie concerne le calcul sélectionné pour chaque token. [2] [3]

La fiche précise que le modèle complet doit être conservé en mémoire, même si seule une partie est active à un instant donné. Un expert inutilisé pour un token peut être nécessaire pour un autre. Une planification utile de la capacité inclut donc les poids, les caches de requêtes, les tampons d’exécution et une marge opérationnelle ; diviser le nombre total de paramètres par la fraction active n’est pas une méthode valable pour dimensionner la mémoire. [2]

Le transfert de poids vers un autre niveau de mémoire ou une quantification supplémentaire peuvent ouvrir d’autres possibilités de déploiement, mais une option plausible n’est pas une configuration testée. Les transferts, les changements de précision et les différents kernels peuvent modifier la latence ou la qualité. Traitez toute proposition sur un appareil grand public comme une expérience dotée de ses propres critères d’acceptation, plutôt que de déduire sa compatibilité du nombre de paramètres actifs.

La fiche de Kolibri distingue un contexte natif d’entraînement de 262,144 tokens d’une validation étendue à 1,048,576. Elle recommande de ne pas dépasser 262,144 pour les tâches complexes ou les services sensibles à la latence et au débit. La section du rapport consacrée au contexte long décrit aussi une dégradation dépendant de la tâche au-delà de la longueur d’entraînement. Examinez ensemble la limite étendue, la recommandation et les éléments probants sur la charge de travail. [2] [4]

Supposons qu’une équipe souhaite permettre à plusieurs personnes d’interroger de longs documents simultanément. Pouvoir accepter une requête très longue ne démontre pas combien de requêtes de ce type le serveur peut traiter correctement. L’état des requêtes se dispute la mémoire, et le traitement des entrées, les ressources de calcul. Mesurez le délai avant la première réponse, le temps total et la demande simultanée avec les documents réels, plutôt que de transformer un contexte maximal en promesse de niveau de service.

Cela n’enlève pas son utilité au contexte long. Réunir les éléments probants liés peut réduire la fragmentation. La question est de savoir si les contenus supplémentaires conservés améliorent assez la tâche pour justifier leur coût en ressources. Comparez une entrée compacte et pertinente avec le document complet, puis vérifiez l’exactitude de la réponse et des passages qui l’étayent.

Le rapport d’Aleph Alpha mesure le débit de service sur un nœud équipé de huit B200 avec des entrées synthétiques. Il explore les configurations parallèles admissibles, mesure près de la limite de concurrence du cache KV et présente la configuration de décodage la plus rapide mesurée. Il estime aussi le débit du texte décodé à partir du nombre d’octets par token, qui dépend du tokeniseur. Ces conditions sont essentielles pour interpréter la comparaison entre qualité et coût. [4]

Le débit de décodage à forte concurrence peut être pertinent pour un service très sollicité ou un traitement comportant beaucoup de génération. Il n’indique pas directement à un utilisateur isolé combien de temps prendra une requête documentaire. Le traitement de l’entrée, les files d’attente, la longueur du raisonnement et la vérification de la sortie influencent cette expérience. Le rapport signale aussi l’hypothèse selon laquelle l’inférence en FP8 préserve les scores des évaluations de référence ; ne traitez pas cette hypothèse comme un résultat universel d’équivalence entre précisions. [4]

Le raccourci inverse est tout aussi peu utile : une empreinte plus importante des poids ne prouve pas une mauvaise efficacité économique. Un modèle parcimonieux peut exploiter efficacement la capacité résidente si suffisamment de tâches adaptées l’occupent. Comparez les tâches achevées acceptables par unité de coût sous la charge attendue, en incluant les périodes creuses, plutôt que de désigner un gagnant à partir d’un seul des nombres de paramètres.

Le dépôt d’inférence publié fournit un plugin vLLM avec une architecture et des analyseurs de raisonnement et d’appels d’outils propres à Kolibri. Son README indique actuellement que chaque version prend en charge une seule version mineure de vLLM ; au moment de cette vérification, il s’agissait de 0.29. Les poids ouverts donnent accès au modèle, mais n’établissent pas sa compatibilité avec toute application d’inférence ni avec sa version installée. [5]

Consignez ensemble la révision du modèle, la précision, les versions du plugin et de l’environnement d’exécution, la limite de contexte et les réglages des analyseurs. Testez la séparation entre raisonnement et texte final, l’analyse des arguments des outils, le traitement des entrées longues et une requête interrompue. Un client qui accepte le format de réponse n’est qu’une partie d’une intégration fonctionnelle. Cette spécification facilite aussi l’évaluation d’une mise à jour ou d’un retour à une version antérieure.

Pour une équipe travaillant sur des documents en allemand ou en anglais, commencez par des requêtes représentatives et vérifiez les réponses indépendamment à partir des éléments fournis. Pour une équipe de développement, incluez les schémas réels des outils et les sorties que l’application doit traiter. Pour les responsables d’infrastructure, comparez les périodes chargées et creuses attendues. Le positionnement bilingue justifie d’évaluer les tâches dans ces langues, mais ne prouve pas une supériorité sur toutes les tâches de chacune d’elles.

Un petit essai devrait répondre à trois questions : la sortie atteint-elle le seuil de qualité, la machine prévue peut-elle soutenir la charge nécessaire et l’équipe peut-elle maintenir la pile d’inférence ? Utilisez les mêmes documents, exigences de sortie et règles d’acceptation pour comparer les alternatives. Comptez les nouvelles tentatives et les résultats rejetés dans le coût.

Kolibri est une nouvelle option utile, car ses documents publiés permettent aux équipes d’examiner ces compromis. Ses 3.46B paramètres actifs décrivent un calcul parcimonieux ; les poids plus volumineux et l’état des requêtes restent de véritables obligations de déploiement. L’avancée pratique est un autre modèle à tester pour une tâche définie, pas la preuve que les contraintes de mémoire, le travail opérationnel ou les vérifications indépendantes des sorties ont disparu.