Reflection lance Beam : un modèle MoE ouvert de 501B de paramètres sous licence Apache 2.0

Reflection, un nouveau laboratoire américain, a publié sur Hugging Face son premier modèle, Beam. C'est un MoE de 501 milliards de paramètres, dont 23 milliards actifs par token, avec une entrée texte, un contexte de 1M de tokens et une licence Apache 2.0. Il est optimisé pour le code et les tâches agentiques. La cible est claire : les équipes qui veulent un modèle d'échelle frontier sur leur propre matériel, dans leur propre cloud, avec la possibilité de le fine-tuner à leur main.

La sortie s'accompagne d'un harness maison écrit en Rust, ouvert comme le modèle lui-même. Reflection et Hugging Face ont préparé ensemble des recettes pour l'inférence, le SFT et le RL. La prise en charge de transformers, vLLM et SGLang est assurée dès le jour zéro. Pour le RL en paramètres complets, les équipes sont invitées à passer par Miles.

Où Beam fait des économies, et où arrive la facture mémoire

C'est le compromis classique des MoE parcimonieux : on calcule comme avec un petit modèle, mais on paie la mémoire d'un grand. Beam compte 52 couches. Les trois premières sont denses, et les 49 autres sont remplacées par des blocs de 256 experts, dont 8 sont routés par token.

Chaque expert est un MLP SwiGLU de taille intermédiaire 2560, soit environ 39M de paramètres, et l'ensemble des experts concentre 98,4% des poids. Il n'y a pas d'expert partagé. Le routeur reprend le schéma de DeepSeek-V3 avec une restriction par groupes : scores sigmoïdes, 8 groupes de 32 experts, sélection des 4 meilleurs groupes, puis top-8 à l'intérieur de ceux-ci.

Les sorties des experts sont normalisées et mises à l'échelle d'un facteur 2,5.

En BF16, le checkpoint pèse environ 1 To. Le format NVFP4 pour Blackwell le ramène à environ 280 Go, une partie des paramètres restant en BF16 pour préserver la précision. Une version FP8 existe pour Hopper et Ampere. Deux B200 de 180 Go contiennent formellement les poids, mais sans place pour le KV-cache. Les auteurs recommandent donc quatre B200 (720 Go). Conviennent aussi un nœud 8×B200, deux B300 de 288 Go et même 8×RTX Pro 6000. Sur H200, il faut au minimum 16 cartes : avec 8 GPU, les poids à 139 Go par GPU ne laissent pas de place sur 141 Go.

Attention hybride et résidus atypiques

Le cache est le second poste de dépense, et Beam s'y montre soigneux. Sur 52 couches, 43 utilisent une fenêtre glissante de 512 tokens avec RoPE. Seules 9 (une couche sur six, plus la dernière) regardent tout le contexte, sans encodage positionnel.

À la place, la requête est multipliée par un scaler à croissance lente (1 + (pos + 1) / 2048) ** 0.1. Il joue le rôle de température et empêche le softmax de se « diluer » sur les longues distances.

Le cache croît de 36 Kio par token au lieu de 208 Kio. Sur le contexte complet de 1M, cela donne 36,08 Gio contre 208 Gio ; sur 128K, 4,6 Gio contre 26 Gio. Ces chiffres valent pour une séquence en BF16.

L'attention repose sur du GQA avec 48 têtes de requête et 8 têtes KV, une RMSNorm sur les requêtes et les clés, ainsi qu'une porte sigmoïde apprenable pour chaque canal de tête. Le détail le plus inhabituel est le flux résiduel. À l'étape k, la sortie de la sous-couche est ajoutée avec un poids de 1/sqrt(k), tandis que le flux accumulé est multiplié par sqrt((k-1)/k). La somme des carrés des poids vaut un, l'échelle du flux reste constante, et après 104 additions, l'embedding et chaque sous-couche contribuent à parts égales. Les logits passent par un tanh-softcap à ±30 en FP32.

Ce que montrent les benchmarks et comment le faire tourner

Les chiffres proviennent de l'équipe de Reflection, pour BF16 / FP8 / NVFP4 :

• SWE-bench Verified : 81,6% / 80,2% / 80,7%
• SWE-bench Pro v1 : 66,1% / 65,9% / 65,6%
• SWE-bench Pro v2-Hard : 76,5% / 78,4% / 78,6%
• SWE-bench Multilingual : 78,3% / 78,1% / 77,5%
• Terminal Bench v2.1 : 80,1% / 78,9% / 78,2%
• DeepSWE v1.1 : 43,3% / 43,0% / 42,7%
• AIME 2026 : 97,7% / 98,0% / 97,5%
• GPQA Diamond : 90,6% / 90,3% / 89,3%
• LiveCodeBench : 88,3% / 88,1% / 87,4%
• HLE sans outils : 36,0% / 36,0% / 34,8% ; avec outils : 51,1% pour les trois
• MCP Atlas : 80,8% / 81,5% / 80,5%
• BrowseComp avec gestion du contexte : 76,8% / 76,7% / 75,6%
• DeepSearchQA : 80,5% / 79,6% / 81,1%
• LongBench v2 : 67,5% / 67,6% / 67,2%
• IFBench : 79,6% / 80,7% / 79,2%
• AA-LCR : 78,2% / 79,4% / 78,7%

Principal enseignement du tableau : le passage au NVFP4 ne coûte en moyenne que des fractions de pour cent, et des poids deux fois plus légers rendent l'auto-hébergement réaliste.

Le modèle propose cinq niveaux de raisonnement (low, medium par défaut, high, xhigh, max). L'option preserve_thinking conserve le raisonnement d'un tour à l'autre, et l'appel d'outils s'appuie sur une grammaire distincte de type XML. Le tokenizer embarque un template de réponse, et parse_response sépare raisonnement, réponse et appels sans regex, en convertissant les arguments vers les types définis dans les schémas d'outils. Pour accélérer l'inférence, le décodage spéculatif DFlash2 est disponible : un modèle brouillon propose jusqu'à 15 tokens, et Beam les vérifie en une seule passe.

En pratique, le lancement se présente ainsi. Dans vLLM, la version BF16 démarre avec tensor-parallel-size 16 sur deux nœuds 8×H200, tandis que dans SGLang, la version NVFP4 tient sur 4 B300 avec un contexte de 1 048 576. Dans transformers (version 5.20.1 et supérieure), l'expert parallelism fonctionne : les experts sont répartis à raison d'un par appareil, tandis que l'attention, les couches denses et les embeddings sont répliqués (8B de paramètres, 16 Go). Le nombre d'appareils doit diviser 256. Pour ceux qui n'ont pas de Blackwell, des Inference Providers serverless sont proposés. Reflection distribuera en outre $10 000 de crédits Hub pour les meilleurs projets : démos, quantifications, jeux de données synthétiques, environnements de RL ou benchmarks.