IBM dévoile la fabrication de Granite 4.1 : 15 000 milliards de tokens, 512K de contexte et un pari sur la qualité

IBM a levé le voile sur les coulisses de Granite 4.1, une famille de LLM open source de 3B, 8B et 30B paramètres. Les modèles ont été entraînés sur 15 000 milliards de tokens en cinq phases, leur contexte a été étendu à 512K, puis ils ont été affinés par SFT et par un RL en plusieurs étapes. L'affirmation principale d'IBM : la version 8B rattrape ou dépasse déjà l'ancien MoE de 32B, tout en restant sous licence Apache 2.0.

Traité par IA depuis Hugging Face Blog ; édité par Hamidun News
IBM dévoile la fabrication de Granite 4.1 : 15 000 milliards de tokens, 512K de contexte et un pari sur la qualité
Source : Hugging Face Blog. Collage: Hamidun News.
Écouter l'article
Fiche synthèse et chiffres clés
ParamètreDonnées
Source primaireHugging Face Blog ↗
Rédacteur en chef
Phase 110 000 milliards de tokens de pré-entraînement général, avec environ 59 % du mélange issu de CommonCrawl.
Phase 22 000 milliards de tokens supplémentaires, avec une forte hausse de la part des mathématiques et du code, à 35 % et 30 % respectivement.
Phase 32 000 milliards de tokens d'annealing de haute qualité, où apparaissent des données chain-of-thought, synthétiques et d'instructions.

Le 29 avril 2026, IBM a publié sur le blog de Hugging Face une analyse détaillée de la création de la famille Granite 4.1. L'entreprise ne dévoile pas seulement l'architecture des modèles, mais tout le pipeline : de la composition des datasets et du contexte long jusqu'au filtrage des données de SFT et au reinforcement learning en plusieurs étapes.

Comment la série est conçue

Granite 4.1 est une famille de modèles denses decoder-only de 3B, 8B et 30B paramètres. Les trois variantes reposent sur la même logique de base : Grouped Query Attention, Rotary Position Embeddings, SwiGLU, RMSNorm et embeddings d'entrée et de sortie partagés. Les différences tiennent surtout à l'échelle : nombre de couches, taille des états cachés et paramètres du MLP. Cette approche permet de comparer les modèles au sein d'une même gamme sans tenir compte de philosophies d'architecture différentes.

La thèse centrale d'IBM : la qualité d'un petit modèle ne dépend pas seulement du budget de calcul, mais aussi de la rigueur dans le traitement des données. C'est pourquoi Granite 4.1 a été conçu comme des modèles denses plutôt que MoE, avec un pari sur un changement soigneux des mélanges de données au fil de l'entraînement. Tous les modèles sont publiés sous licence Apache 2.0, et les versions instruct prennent en charge 12 langues, dont l'anglais, l'allemand, l'espagnol, le japonais, l'arabe, le chinois et le portugais.

Cinq phases d'entraînement

Le pré-entraînement de Granite 4.1 a été réalisé à partir de zéro et a porté sur environ 15 000 milliards de tokens. IBM a découpé le processus en cinq phases : le modèle acquiert d'abord une large base linguistique sur des données web, renforce ensuite les mathématiques et le code, puis passe progressivement à des échantillons de meilleure qualité et plus spécialisés. Dans les dernières phases, le mélange intègre de longues trajectoires de raisonnement, des données synthétiques et des datasets d'instructions, et la phase finale entraîne séparément le modèle à gérer un contexte très long.

  • Phase 1 : 10 000 milliards de tokens de pré-entraînement général, avec environ 59 % du mélange issu de CommonCrawl.
  • Phase 2 : 2 000 milliards de tokens supplémentaires, avec une forte hausse de la part des mathématiques et du code, à 35 % et 30 % respectivement.
  • Phase 3 : 2 000 milliards de tokens d'annealing de haute qualité, où apparaissent des données chain-of-thought, synthétiques et d'instructions.
  • Phase 4 : 0,5 millier de milliards de tokens supplémentaires, centrés sur le mélange de meilleure qualité, avec un learning rate ramené à zéro.
  • Phase 5 : long-context extension, qui élargit la fenêtre de 4K à 32K, 128K, puis 512K.

Pour que le contexte long ne dégrade pas la qualité sur les requêtes courtes, IBM fusionne (merge) le modèle après chaque étape de LCE. Pour l'extension finale à 512K dans les versions 8B et 30B, elle a utilisé un mélange de livres et de dépôts de code. Sur les modèles de base, cela a donné des résultats notables sur RULER : la variante 8B conserve une métrique élevée même à 128K, et la 30B va encore plus haut. C'est un signal important pour les équipes qui ont besoin de plus que des réponses de chat : travail sur de longs documents, des logs et de gros fragments de code.

Post-entraînement et qualité

Après le pré-entraînement, IBM a fait passer le dataset de SFT par un contrôle qualité strict. La sélection finale compte environ 4,1 millions d'exemples, mais chaque réponse a d'abord été vérifiée par un schéma LLM-as-Judge et un ensemble de règles déterministes. Le modèle évaluateur examinait le respect de l'instruction, l'exactitude, l'exhaustivité, la concision, le naturel et la calibration, et les motifs de rejet stricts incluaient les hallucinations, les fausses prémisses et les erreurs de calcul. Normalisation, validation de schéma, filtres de longueur et déduplication globale ont aussi été appliqués.

À l'étape du RL, IBM ne s'est pas contentée d'une seule passe. Elle a utilisé du GRPO on-policy avec DAPO loss et assemblé quatre étapes successives : RL multidomaine, RLHF pour l'utilité générale et le dialogue, RL d'identité et de calibration des connaissances, puis un RL mathématique distinct qui restaure et améliore les compétences en maths après le RLHF. Selon IBM, le RLHF seul a ajouté en moyenne environ 18,9 points sur AlpacaEval par rapport aux checkpoints de SFT.

Le résultat le plus marquant : le modèle instruct Granite 4.1 8B se compare de façon constante à Granite 4.0-H-Small 32B-A9B et le dépasse sur plusieurs tests. En parallèle, IBM a publié des variantes FP8, qui réduisent environ de moitié les besoins en mémoire et en espace disque.

Ce que cela signifie

IBM a montré que, parmi les LLM open source, on peut rivaliser 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 pragmatique : latence prévisible sans longues traces de raisonnement, contexte long, licence ouverte et coût d'exécution inférieur à celui de systèmes plus lourds.

Dossier

Questions clés sur cet article

Comment la série est conçue?

Granite 4.1 est une famille de modèles denses decoder-only de 3B, 8B et 30B paramètres. Les trois variantes reposent sur la même logique de base : Grouped Query Attention, Rotary Position Embeddings, SwiGLU, RMSNorm et embeddings d'entrée et de sortie partagés. Les différences tiennent surtout à l'échelle : nombre de couches, taille des états cachés et paramètres du MLP. Cette approche permet de comparer les modèles au sein d'une même gamme sans tenir compte de philosophies d'architecture différentes. La thèse centrale d'IBM : la qualité d'un petit modèle ne dépend pas seul

Que sait-on sur Cinq phases d'entraînement ?

Le pré-entraînement de Granite 4.1 a été réalisé à partir de zéro et a porté sur environ 15 000 milliards de tokens. IBM a découpé le processus en cinq phases : le modèle acquiert d'abord une large base linguistique sur des données web, renforce ensuite les mathématiques et le code, puis passe progressivement à des échantillons de meilleure qualité et plus spécialisés. Dans les dernières phases, le mélange intègre de longues trajectoires de raisonnement, des données synthétiques et des datasets d'instructions, et la phase finale entraîne séparément le modèle à gérer un cont

Que sait-on sur Post-entraînement et qualité ?

Après le pré-entraînement, IBM a fait passer le dataset de SFT par un contrôle qualité strict. La sélection finale compte environ 4,1 millions d'exemples, mais chaque réponse a d'abord été vérifiée par un schéma LLM-as-Judge et un ensemble de règles déterministes. Le modèle évaluateur examinait le respect de l'instruction, l'exactitude, l'exhaustivité, la concision, le naturel et la calibration, et les motifs de rejet stricts incluaient les hallucinations, les fausses prémisses et les erreurs de calcul. Normalisation, validation de schéma, filtres de longueur et déduplicati

ZK
Zhemal Khamidun — CPO d'Alpina Digital, product manager d'AlpinaGPT. Conçoit des produits IA depuis 2019. Hamidun News est un projet personnel devenu un agrégateur en production avec plus de 6 000 lecteurs.
✦ Unified AI Workspace · Nomad

Test Frontier LLMs & Autonomous Agents in One Workspace

Run Claude Opus 5.5, GPT-6, Gemini 3.1, and DeepSeek side-by-side in Nomad AI (nomadnet.ai) — unified model routing, deep research, and multimodal workflows under one subscription.

Try Nomad AI →Launch Nomad Agent
Qu'en pensez-vous ?
Chargement des commentaires…