IBM révèle comment elle a construit Granite 4.1 : 15 trillions de tokens, contexte de 512K et focus sur la qualité

Le 29 avril 2026, IBM a publié une analyse détaillée sur le blog Hugging Face sur la manière dont la famille Granite 4.1 a été créée. L'entreprise a révélé non seulement l'architecture des modèles, mais aussi tout le pipeline : de la composition des ensembles de données et du contexte long au filtrage des données SFT et à l'apprentissage par renforcement multi-étapes.

Comment la Série Granite 4.1 est Structurée

Granite 4.1 est une famille de modèles denses « decoder-only » avec 3B, 8B et 30B paramètres. Dans les trois variantes, IBM utilise la même logique de base : Grouped Query Attention, Rotary Position Embeddings, SwiGLU, RMSNorm et embeddings partagés d'entrée et de sortie.

La principale différence est l'échelle — le nombre de couches, la taille de l'état caché et les paramètres MLP. Cette approche permet de comparer les modèles au sein de la même famille sans réductions dues à une philosophie architecturale différente. La thèse principale d'IBM est que la qualité d'un petit modèle est déterminée non seulement par le budget computationnel, mais aussi par la discipline dans le travail avec les données.

Par conséquent, Granite 4.1 a été construit en tant que modèles denses et non MoE, et le pari a été placé sur des changements soigneux dans les mélanges de données pendant l'entraînement. Tous les modèles sont publiés sous licence Apache 2.

0, et les versions instruct supportent 12 langues, dont l'anglais, l'allemand, l'espagnol, le japonais, l'arabe, le chinois et le portugais.

Cinq Étapes d'Entraînement

Le pré-entraînement de Granite 4.1 a commencé à zéro et a couvert environ 15 trillions de tokens. IBM a divisé le processus en cinq phases : d'abord le modèle construit une base linguistique large sur les données Web, puis renforce les mathématiques et le code, après quoi il passe progressivement à des échantillons de meilleure qualité et spécialisés. Dans les phases ultérieures, des trajectoires de raisonnement long, des données synthétiques et des ensembles d'instructions sont ajoutés au mélange, et finalement un entraînement séparé se produit pour gérer un contexte très long.

• Phase 1 : 10 trillions de tokens de pré-entraînement général, où environ 59% du mélange provient de CommonCrawl.
• Phase 2 : encore 2 trillions de tokens avec une augmentation nette de la part des mathématiques et du code — jusqu'à 35% et 30% respectivement.
• Phase 3 : 2 trillions de tokens d'annealing de haute qualité, où apparaissent chain-of-thought, données synthétiques et d'instruction.
• Phase 4 : encore 0,5 trillions de tokens mettant l'accent sur le mélange de plus haute qualité et réduction du taux d'apprentissage à zéro.
• Phase 5 : extension du contexte long, qui élargit la fenêtre de 4K à 32K, 128K et ensuite à 512K.

Pour éviter que le contexte long ne casse les performances sur les requêtes courtes, IBM fusionne le modèle après chaque étape LCE. Pour l'expansion finale à 512K dans les versions 8B et 30B, un mélange de livres et de référentiels de code a été utilisé. Sur les modèles de base, cela a donné des résultats notables sur RULER : la variante 8B maintient des métriques élevées même à 128K, et 30B va encore plus haut. C'est un signal important pour les équipes qui ont besoin non seulement de réponses de chat, mais aussi de travail avec des documents longs, des journaux et de grands fragments de code.

Ajustement Fin et Qualité

Après le pré-entraînement, IBM a exécuté l'ensemble de données SFT à travers une boucle stricte de contrôle qualité. Environ 4,1 millions d'exemples ont été intégrés à la sélection finale, mais avant cela, chaque réponse a été vérifiée via un schéma LLM-as-Judge et un ensemble de règles déterministes. Le modèle évaluateur a examiné le respect des instructions, la correction, l'exhaustivité, la concision, le naturel et l'étalonnage, tandis que les raisons strictes de rejet incluaient les hallucinations, les fausses prémisses et les erreurs de calcul.

De plus, la normalisation, la validation du schéma, les filtres de longueur et la déduplication globale ont été appliqués. À l'étape RL, IBM ne s'est pas limitée à un seul passage. L'entreprise a utilisé GRPO on-policy avec DAPO loss et a collecté quatre étapes séquentielles : RL multi-domaine, RLHF pour l'utilité générale et le dialogue, RL d'identité et d'étalonnage des connaissances, et puis RL mathématique séparé, qui restaure et améliore les compétences mathématiques après RLHF.

Selon IBM, le RLHF seul a ajouté en moyenne environ 18,9 points sur AlpacaEval par rapport aux points de contrôle SFT. Le résultat le plus remarquable est que le modèle instruct Granite 4.1 8B se compare systématiquement à Granite 4.

0-H-Small 32B-A9B et le dépasse sur plusieurs benchmarks. En parallèle, IBM a lancé des variantes FP8, qui réduisent de moitié environ les exigences en mémoire et espace disque.

Ce Que Cela Signifie

IBM a démontré que concourir dans les LLMs open-source est possible non seulement par la taille du modèle, mais par la qualité de la recette d'entraînement. Pour les entreprises, cela fait de Granite 4.1 un candidat pratique : latence prévisible sans traces de raisonnement long, contexte long, licence ouverte et coûts d'exécution plus faibles par rapport aux systèmes plus lourds.