Reflection présente Beam, un modèle ouvert pour le code et les agents, dont l’efficacité reste à vérifier

Ce que Reflection a annoncé et ce que l’on sait de la disponibilité

Reflection AI a présenté Beam comme son premier modèle à poids ouverts, destiné à la programmation, au raisonnement et aux tâches agentiques faisant appel à des outils. L’entreprise le décrit comme un modèle à mélange d’experts, ou MoE, comptant 501 milliards de paramètres au total et 23 milliards de paramètres actifs par jeton. Ces caractéristiques viennent de l’annonce de l’entreprise et ne constituent pas, à elles seules, une évaluation indépendante de ses capacités.

Dans sa publication, Reflection affirme que Beam fait l’objet d’évaluations finales et de tests de sécurité, et qu’il est possible de demander un accès anticipé. L’entreprise a également annoncé la publication des poids, d’un rapport technique, d’une fiche de modèle et de ressources pour les développeurs plus tard en octobre 2026. Les documents fournis ne permettent de vérifier ni la date exacte de publication ni la disponibilité effective. Il ne convient donc pas de présenter les poids comme un téléchargement public déjà accessible.

L’annonce présente Apache 2.0 comme la licence prévue pour les poids. Toutefois, les éléments disponibles ne comprennent ni copie publiée de ces poids ni texte d’une licence déjà applicable. Cette licence doit être considérée comme un engagement annoncé jusqu’à ce qu’elle puisse être vérifiée dans le dépôt ou dans les fichiers effectivement distribués.

Ce que signifient les paramètres actifs dans un modèle MoE

Un modèle MoE répartit son réseau en groupes de paramètres spécialisés, appelés experts. Un mécanisme de routage sélectionne ceux qui interviennent pour chaque jeton. Pour Beam, les 501 milliards désignent la taille totale des paramètres, tandis que les 23 milliards actifs correspondent, selon Reflection, à la partie qui participe au calcul de chaque jeton. Ces deux chiffres ne sont pas deux façons interchangeables d’exprimer la taille du modèle.

Activer moins de paramètres par jeton peut réduire une partie du calcul de génération par rapport à une architecture qui utiliserait tous ses paramètres à chaque étape. Cela ne signifie pas que le modèle complet ne nécessite en mémoire que l’équivalent de 23 milliards de paramètres. Son exécution dépend aussi du stockage des poids, de la précision numérique, de la mémoire de travail, de la longueur du contexte, du matériel et de l’implémentation. Sans ces données et mesures, la proportion de paramètres actifs ne détermine ni le coût total ni la vitesse en production.

Le nombre de paramètres ne suffit pas non plus à juger la qualité. Les données et l’entraînement, la conception de l’architecture, la qualité des outils et le protocole d’évaluation comptent également. Le nombre de paramètres actifs aide à comprendre un éventuel avantage de calcul par jeton, mais il faut le mettre en regard de résultats comparables et de coûts observés dans un système réel.

Ce que montrent les comparaisons et leurs limites

Reflection met l’accent sur les capacités de programmation, de raisonnement et d’exécution de tâches agentiques. Dans le tableau publié par l’entreprise, Beam obtient 80,1 à Terminal-Bench v2.1, contre 81,0 pour GLM 5.2 et 86,6 pour Qwen 3.8-Max. À SWE-Bench Verified, le tableau affiche 80,9 pour Beam et ne donne les résultats des autres modèles que lorsqu’ils sont disponibles. Il s’agit de résultats communiqués par Reflection, et non d’un classement universel des modèles.

Pour être comparables, les chiffres doivent porter sur la même version de chaque modèle, le même jeu de tests et la même version du benchmark, avec les mêmes outils, limites de jetons, nombre de tentatives et méthode de notation. Le tableau du fournisseur mentionne également une mise à jour datée du 8 octobre 2026. Chaque chiffre doit donc être associé à la version et à la date correspondantes ; il est imprudent de combiner les résultats de tableaux ou de versions différents.

Les éléments fournis ne contiennent aucune reproduction indépendante des résultats de Beam. La publication primaire indique ce qu’affirme Reflection, mais ne remplace pas une évaluation externe. En outre, un bon résultat à un test de programmation ne prouve pas un avantage en programmation en général, dans l’utilisation d’outils ou dans la fiabilité d’agents déployés. Les conclusions doivent rester limitées aux tâches et aux conditions évaluées.

La promesse de réduction du calcul est une estimation, pas une mesure en conditions de service

Reflection affirme que Beam obtient des scores comparables à ceux de GLM 5.2 dans des tests avancés de raisonnement en utilisant trois à quatre fois moins de calcul d’inférence. L’entreprise explique qu’elle estime les opérations de génération en multipliant approximativement par deux le nombre de paramètres actifs et le nombre moyen de jetons générés par tentative. Elle compte à la fois les jetons de raisonnement et la réponse finale, et s’appuie sur des données d’évaluation externes pour les autres modèles.

La méthode décrite par Reflection exclut le traitement initial de l’entrée, les opérations d’attention qui dépendent du contexte et les frais de service du modèle. La proportion annoncée ne représente donc ni une mesure complète du coût d’inférence ni une facture d’exploitation. Elle ne permet pas non plus d’affirmer qu’une entreprise paiera trois à quatre fois moins : les coûts dépendent notamment de l’infrastructure, du taux d’utilisation, de la longueur des requêtes et de la configuration du déploiement.

Pour valider cet avantage, il faudrait des mesures reproductibles réalisées sur les mêmes tâches et dans les mêmes conditions : entrées et sorties comparables, versions identifiées, matériel et précision documentés, limites de contexte, charge concurrente et comptabilisation du calcul, de la latence et de l’exploitation. En attendant, la conclusion rigoureuse est que Reflection communique une estimation favorable selon une méthode délimitée, et non que l’efficacité en production est démontrée.

Poids ouverts, licence et points à vérifier pour suivre l’annonce

L’expression « poids ouverts » décrit une forme de distribution du modèle, mais ne garantit pas à elle seule que tous ses composants soient ouverts ni que son utilisation soit libre de toute restriction. Il faut vérifier séparément la disponibilité des fichiers, la licence applicable, la documentation et les conditions d’utilisation. Ici, Reflection a annoncé une distribution des poids sous Apache 2.0, mais les éléments fournis ne permettent pas de confirmer qu’une version ainsi licenciée a déjà été publiée.

Il convient aussi de distinguer l’API hébergée de l’accès aux poids. Une API permet d’envoyer des requêtes à un service exploité par le fournisseur ; le téléchargement des poids peut permettre une exécution sur sa propre infrastructure, sous réserve des exigences techniques et juridiques applicables. La publication décrit un accès anticipé sur inscription et prévoit la mise à disposition ultérieure des poids et des outils, mais ne prouve pas que toutes ces possibilités soient déjà accessibles au public.

Pour actualiser l’information, les vérifications prioritaires sont la publication effective des fichiers, le texte exact de la licence qui les accompagne, ainsi qu’une fiche technique et un rapport précisant les versions et les configurations. Il faudra également des évaluations indépendantes des tâches de programmation, de raisonnement et d’utilisation d’outils. En attendant ces éléments, les capacités et la réduction du calcul doivent être attribuées à Reflection, et la disponibilité décrite comme annoncée, non comme acquise.

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.