Beam 1.0 sur quatre B300s : les maths du serving, et l’allégation de débit que personne n’a publiée

Le chiffre sur lequel il vaut la peine de s'arrêter dans la version Beam 1.0 de Reflection n'est pas 501 milliards. C'est quatre. Un modèle totalisant 501,3 milliards de paramètres et 23,4 milliards actifs par token tient désormais sur un seul serveur équipé de quatre GPU NVIDIA B300 sur NVLink, et l'écart entre ces deux chiffres — environ 4,7 % du modèle éveillé à un token donné — est toute la raison pour laquelle un point de contrôle de cette taille peut être téléchargé par quiconque ne possède pas de cluster. Reflection a publié les poids le 16 octobre 2026 sous licence Apache 2.0, et la documentation de lancement est d'une précision inhabituelle quant à ce qu'il faut pour les servir : quatre GPU B300 sur NVLink pour la version NVFP4, huit H200 pour le FP8, et huit B200 ou B300 pour le BF16. Ce tableau matériel est plus intéressant que le tableau des benchmarks, car c'est la partie qu'un lecteur peut réellement comparer à sa propre fiche d'approvisionnement.

C'est aussi ce qui distingue Beam 1.0 des modèles auxquels il est comparé. Kimi K3 et GLM-5.2 sont servis derrière des API et leurs poids soit ne sont pas publics, soit sont assortis d'un ensemble de conditions différent ; Qwen3.8-Max est propriétaire au niveau du modèle phare. L'argument de Beam est que la moitié difficile de ce compromis — un modèle proche de la frontière, disponible en téléchargement — a été livrée, et que le coût de service correspond à une baie plutôt qu'à un centre de données.

Qu'est-ce qui est réellement arrivé le 16 octobre

L'article de Reflection « Beam est désormais disponible » est daté du 16 octobre 2026, onze jours après l'annonce du modèle le 5 octobre. Quatre artefacts ont été livrés, et les précisions comptent plus que le titre :

• BF16 — 501,3 B de paramètres, 933,81 Gio sur disque, 188 fragments safetensors. La précision de référence ; la première colonne du tableau de benchmark.

• FP8 — le même nombre de paramètres en E4M3, 468,72 GiB. Quantifié avec NVIDIA ModelOpt. Recommandé pour Hopper et les matériels plus anciens.

• NVFP4 — une version 4 bits empaquetée à 273 GiB. C'est celle que les propres guides de déploiement de Reflection vous recommandent de télécharger, et la seule qui s'exécute nativement sur Blackwell sans pénalité de déquantification.

• DFlash2 — un modèle de proposition pour le décodage spéculatif de 1,93 milliard de paramètres, publié comme dépôt à part entière et intégré aux commandes d’exemple en tant qu’ensemble de poids distinct.

L’architecture derrière ces checkpoints est un mélange clairsemé d’experts : 52 couches, dont 3 denses et 49 MoE, 256 experts par couche MoE, une attention groupée par requêtes à portes mêlée à une attention à fenêtre glissante, et un vocabulaire de 152 000 tokens. Texte en entrée, texte en sortie, contexte de 1 M de tokens sur la fiche du modèle, 131 072 tokens de sortie maximale sur l’API. Date limite des connaissances : 30 juin 2026.

Le chiffre de débit qui ne figure pas dans la documentation

Un chiffre circule avec cette version depuis le jour zéro : plus de 70 000 jetons de sortie par seconde et par GPU sur Blackwell Ultra. C’est un chiffre séduisant, et il vaut la peine d’être précis sur les endroits où il apparaît et où il n’apparaît pas. Il ne figure pas dans l’article de lancement de Reflection, ni dans la fiche du modèle, ni dans les notes de version de Hugging Face, ni dans la documentation pour développeurs. Nous n’avons pas pu le trouver dans aucune source de première main.

Ce que la documentation du fournisseur documente bel et bien est relatif plutôt qu’absolu. L’unique affirmation d’efficacité de la fiche modèle est que Beam « atteint une qualité de solution comparable à celle des principaux modèles ouverts en utilisant environ 3 fois moins de tokens de raisonnement au moment de l’inférence », et l’article de lancement présente la même idée comme « plus d’intelligence par token ». Le seul chiffre lié au débit que la version publie effectivement est une accélération mesurée plutôt qu’un débit : le drafter DFlash2 augmente la vitesse de décodage de 1,7× à 3,0× par rapport à Beam seul, mesuré sur le checkpoint NVFP4 sur quatre B300, avec des longueurs d’acceptation de 4,11 à 5,88 tokens sur un maximum de huit. Il s’agit d’un ratio par rapport à la propre ligne de base de Beam, donc cela ne dit rien sur le nombre absolu de tokens par seconde et par GPU — cela ne permettra pas de trancher le chiffre de 70 000, dans un sens ou dans l’autre.

Il existe un signal indépendant montrant que l’affirmation d’efficacité n’est pas purement marketing. Artificial Analysis a mesuré Beam 1.0 à 79M de tokens de sortie sur l’Intelligence Index, contre une médiane de 130M pour les modèles auxquels il se compare — classé n° 10 sur 46 pour cette mesure. Il s’agit d’un tiers qui compte les tokens générés et constate que Beam est plus économe que la plupart des acteurs du domaine, ce qui est une affirmation plus faible qu’un chiffre de débit par GPU, et bien mieux étayée.

Ce que quatre B300 vous apportent réellement, en mémoire

La documentation sur le serving est la chose la plus utile que Reflection ait publiée, car elle répond à des questions qu'un tableau de benchmarks ne pose jamais. Trois chiffres ressortent.

• Empreinte du cache KV — les recettes vLLM et NVIDIA Dynamo utilisent toutes deux par défaut un cache FP8 E4M3 avec une taille de page de 64 tokens, ce qui, comme le note la recette vLLM, double pour atteindre environ 14 M à 28 M de tokens de contexte pouvant être mis en cache sur huit H200 exécutant le checkpoint FP8. C'est le chiffre à utiliser pour dimensionner un déploiement ; un plan à trois GPU échoue bien avant que le cache n'atteigne sa limite.

• Le checkpoint NVFP4 ne quantifie que les experts routés. L'attention, les MLP denses, le routeur, les embeddings et la tête LM restent en BF16, ce qui explique que le fichier fasse 273 GiB plutôt que les quelque 250 que donnerait une passe complète en 4 bits. Sur Blackwell, il tourne en W4A4 ; sur Hopper, vLLM sert les experts FP4 via Marlin avec des activations BF16.

• Le checkpoint NVFP4 sur quatre B300 constitue la configuration de référence, et la recette SGLang est fournie sous forme d’image Docker épinglée avec le parallélisme tensoriel réglé sur 4, le drafter DFlash2 activé à une taille de bloc de 8, et le décodage spéculatif configuré aux côtés du cache KV FP8.

Il existe également un outil de vérification. L'interface de ligne de commande open source beam-verifier exécute une suite de conformité contre tout point de terminaison Beam en production — contrat de requête, contrat de réponse, protocole d'outils — puis l'évalue sur les principaux benchmarks afin que vous puissiez comparer votre propre déploiement, ou celui d'un fournisseur, aux scores de référence de Reflection. Pour un modèle dont le tableau de benchmarks est entièrement déclaré par le fournisseur, livrer le harnais qui permet à un acheteur de le reproduire est un engagement plus significatif que n'importe quel chiffre de ce tableau.

La prise en charge de l'infrastructure dès le premier jour constitue l'autre moitié de l'histoire du déploiement, et elle est plus étendue que ce que la plupart des versions ouvertes parviennent à offrir : Transformers, vLLM, SGLang, Unsloth, Axolotl, TokenSpeed et NVIDIA Dynamo, avec des recettes pas à pas pour SGLang, vLLM et TokenSpeed, ainsi qu'un chart Helm pour Kubernetes. Côté entraînement, Reflection nomme les piles avec lesquelles elle a bâti les flux de travail — NeMo RL et AutoModel et Megatron Bridge de NVIDIA, Miles de RadixArk, TRL de Hugging Face, SkyRL d'Anyscale et Axolotl — et publie les chiffres de son runbook d'RL plutôt qu'une donnée matérielle à leur sujet : 10,5 K GPU GB300 sur quatre semaines, plus de 100 millions de rollouts, un contexte maximal de 256 K tokens pendant l'entraînement, et environ 1,3 milliard de sandboxes.

L'API existe, et elle n'a toujours pas de prix

À côté des poids, il y a un point de terminaison first-party à api.reflection.ai avec une interface compatible OpenAI et l’identifiant de modèle Beam-1.0-501B-A23B. Il porte un contrat documenté : un raisonnement obligatoire avec des niveaux d’effort max, xhigh, high, medium et low, où max est la valeur par défaut ; des sorties structurées et l’appel d’outils ; des limites de débit à l’échelle de l’organisation, mesurées en requêtes et en tokens par minute et par jour UTC, partagées entre tous les projets et toutes les clés, de sorte que l’ajout d’une clé ne les augmente pas ; et une réponse 429 qui définit x-should-retry sur false une fois une allocation journalière épuisée, ce qui est le détail qui empêche une boucle de réessai naïve de tourner jusqu’à minuit.

La documentation ne donne pas de prix par million de jetons, et l’annonce non plus. Cette unique omission est ce qui rend l’argument d’efficacité impossible à conclure pour un acheteur : un modèle qui raisonne toujours, se cale par défaut sur l’effort maximal et revendique trois fois moins de jetons de raisonnement constitue une proposition commerciale différente à un dollar par million de jetons de sortie qu’à dix, et personne en dehors de Reflection ne peut actuellement dire de quel cas il s’agit. L’auto-hébergement élimine entièrement la question et la remplace par un montant de capital, qui est au moins un chiffre que l’on peut calculer.

Où cela laisse une équipe qui souhaite l’essayer

Beam 1.0 ne fait pas partie de nos routes, nous ne pouvons donc pas vous le fournir, et rien ici ne doit être interprété comme une affirmation de notre part quant à sa disponibilité. Ce que nous pouvons faire, c'est rendre l'évaluation peu coûteuse. Si la décision qui se présente à vous est de savoir s'il faut consacrer un trimestre de temps d'ingénierie à un pilote Beam de deux semaines, la bonne approche est de maintenir la production sur un modèle disposant d'une grille tarifaire publiée et d'un historique de service pendant la durée du pilote, et d'avoir déjà câblé la solution de repli. OrcaRouter utilise une seule clé compatible OpenAI sur plus de 200 modèles, avec le prix catalogue du fournisseur répercuté sans aucun ajout, de sorte qu'une baisse de prix d'un fournisseur se répercute sur votre facture le jour même, et que le basculement automatique signifie qu'un pilote qui s'avère indisponible le mois prochain relève d'un simple changement de routage plutôt que d'une migration.

Les modèles les plus proches de Beam sur les charges de travail qu’il cible sont tous accessibles de cette manière. Les trois pour lesquels il vaut la peine de comparer les tarifs du pilote, d’après notre propre catalogue :

• GLM-5.2 — contexte de 1 000 000 de tokens, 1,40 $ par million de tokens d'entrée et 4,40 $ par million de tokens de sortie. Le modèle par rapport auquel Reflection mesure sa propre affirmation d'efficacité.

• Kimi K3 — 1 048 576 jetons de contexte, 3,00 $ par million de jetons d'entrée, 0,30 $ en cache, 15,00 $ en sortie. L'article de lancement de Reflection reconnaît que K3 garde une avance en matière de capacité brute.

• Qwen3.8-Max — contexte de 1 000 000 de tokens, 2,00 $ par million en entrée et 6,00 $ en sortie, la classe de 2 000 milliards de paramètres sur laquelle Beam revendique son plus grand avantage d’efficacité.

Les trois choses à surveiller

Le premier, c’est le prix. Tant que Reflection n’aura pas publié de grille tarifaire, la thèse de l’efficacité reste une hypothèse sur la puissance de calcul plutôt qu’un fait financier, et la comparaison avec GLM-5.2 ou Kimi K3 demeure un débat de méthodologie.

La deuxième est une mesure indépendante du débit. Artificial Analysis répertorie actuellement Beam avec un Intelligence Index de 30 et sans vitesse ni prix, car il indique « Aucune API publique disponible » pour le modèle. Lorsque cela changera, la question du débit par GPU obtiendra une réponse qui ne provient pas du fournisseur.

Le troisième point est de savoir si le vérificateur est réellement utilisé. Une suite de conformité que personne n’exécute n’est que de la documentation ; une suite de conformité dont une douzaine de déploiements publient les résultats est un benchmark. Beam 1.0 a livré l’outil dès le jour zéro. Savoir s’il publie les chiffres est la partie qui reste en suspens.

Rien de tout cela n'est hypothétique : les défaillances documentées de l'IA et les incidents d'agents qui sous-tendent des versions comme celle-ci sont recueillis dans l'OrcaRouter AI Incident Archive, où chaque entrée est accompagnée de ses propres sources, de son niveau de gravité, de son degré de confiance et de son indicateur de contestation.