TL;DR. IBM a entraîné Granite 4.1 sur environ 15 000 milliards de tokens via un pipeline de cinq phases et quatre étapes de renforcement — dont une dédiée à récupérer la régression mathématique introduite par l'RLHF. Résultat publié sur Hugging Face : un modèle dense à 8 milliards de paramètres qui correspond ou dépasse régulièrement son prédécesseur MoE à 32 milliards.
Le cahier des charges et le problème à résoudre
IBM a défini pour Granite 4.1 un périmètre d'usage enterprise strict : licence Apache 2.0, douze langues — anglais, allemand, espagnol, français, japonais, portugais, arabe, tchèque, italien, coréen, néerlandais, chinois —, fenêtre de contexte capable d'absorber des corpus documentaires lourds, et trois variantes de déploiement : 3B, 8B et 30B paramètres.
Le vrai défi n'était pas de choisir une taille de modèle. C'était de faire coexister dans un même jeu de poids des compétences structurellement antagonistes : raisonnement mathématique, génération de code, instruction-following multilingue, appel d'outils et comportement conversationnel. Dans un entraînement non structuré, chaque objectif tend à dégrader les autres. IBM a donc séquencé l'entraînement en phases distinctes plutôt que de tout apprendre simultanément.
L'architecture et les choix de pipeline
Sur le plan architectural, IBM a retenu un transformeur décodeur dense avec Grouped Query Attention, Rotary Position Embeddings, activations SwiGLU, normalisation RMSNorm, et embeddings d'entrée/sortie partagés. Des choix techniquement classiques — la différenciation se joue dans la structure du pipeline, pas dans l'architecture de base.
Le pré-entraînement couvre environ 15 000 milliards de tokens selon la documentation IBM publiée sur Hugging Face, répartis en cinq phases séquentielles :
- Phase 1 — 10 000 milliards de tokens : corpus général (web, code, mathématiques, technique)
- Phase 2 — 2 000 milliards : accent mathématiques (35 %) et code (30 %)
- Phase 3 — 2 000 milliards : annealing haute qualité avec données de chaîne de pensée
- Phase 4 — 500 milliards : raffinement sur CommonCrawl haute qualité (40 %)
- Phase 5 : extension long-contexte de 32K à 128K puis 512K tokens, alimentée par des livres et des dépôts de code
Le supervised fine-tuning a mobilisé 4,1 millions d'échantillons curatés via un cadre LLM-as-Judge multi-dimensionnel avec déduplication globale. L'entraînement s'est appuyé sur 16 nœuds équipés de 4× GPU GB200 dans un cluster NVIDIA GB200 NVL72 hébergé chez CoreWeave, avec interconnexion NVLink et InfiniBand NDR 400 Gb/s — l'infrastructure est documentée dans la publication IBM.
Les compromis acceptés
Le pipeline de renforcement est là où les vraies tensions apparaissent. IBM a structuré quatre étapes séquentielles de RL via une méthode GRPO on-policy à perte DAPO :
- RL multi-domaine : mathématiques, sciences, logique, instruction-following, sorties structurées, Text2SQL, raisonnement temporel, chat, apprentissage en contexte
- RLHF : chat générique avec modèle de récompense multilingue
- RL identité et calibration de connaissances : auto-identification du modèle
- RL mathématiques : récupération explicite de la baisse de performance introduite par l'étape RLHF
Cette quatrième étape est le compromis honnête de la documentation : améliorer le comportement conversationnel via l'RLHF dégrade les performances quantitatives. IBM l'a mesuré, l'a nommé, et lui a dédié une étape de récupération. Peu de labs documentent cela aussi explicitement dans leurs publications publiques.
Sur l'efficience de déploiement, la quantification FP8 réduit l'empreinte disque et la mémoire GPU de 50 % selon le billet IBM — un levier concret pour les organisations qui ne disposent pas de clusters de la taille de CoreWeave.
Les résultats publiés
Sur le modèle Granite 4.1-8B Instruct, IBM publie les scores suivants :
- GSM8K (raisonnement mathématique) : 92,49 %
- HumanEval pass@1 (code) : 87,20 %
- MMLU (connaissance générale) : 73,84 %
- IFEval (instruction-following) : 87,06 %
- BFCL V3 (appel d'outils) : 68,27 %
- RULER à 128K tokens (long contexte) : 73,0 %
Le résultat structurant : le modèle 8B dense correspond ou surpasse régulièrement Granite 4.0-H-Small — un modèle MoE de 32 milliards de paramètres avec 9 milliards actifs. Un modèle quatre fois plus compact, avec une fraction du coût d'inférence, qui tient la comparaison sur l'ensemble du benchmark.
Ces validations ont elles-mêmes un coût rarement nommé. D'après l'analyse publiée par la coalition EvalEval sur Hugging Face en avril 2026, un seul run GAIA sur un modèle frontier coûte 2 829 dollars avant mise en cache, et un run PaperBench représente environ 9 500 dollars par agent. IBM a nécessairement absorbé des coûts d'évaluation de cet ordre à chaque gate de son pipeline.
Trois leçons applicables ailleurs
- La régression est un artefact d'ingénierie documentable, pas une anomalie. L'RLHF améliore la qualité conversationnelle tout en dégradant le raisonnement mathématique : c'est une tension connue de l'optimisation multi-objectif. Nommer la régression, la mesurer, et lui allouer une étape de récupération dédiée — c'est une pratique que tout pipeline LLM en production devrait reproduire.
- Le nombre de paramètres n'est plus le signal de qualité principal. Un modèle dense 8B entraîné avec discipline de pipeline surpasse un MoE de 32B entraîné différemment. La qualité des données, la structure des phases et la conception des étapes RL pèsent davantage que le volume brut de paramètres.
- L'évaluation est maintenant un coût d'infrastructure à part entière. Selon les données EvalEval, les benchmarks agentiques ne se compriment qu'à un facteur 2 à 3,5×, contre 100 à 200× pour les benchmarks statiques. Toute organisation qui ne budgète pas ses évaluations comme une ligne de coût informatique sous-estime le vrai coût de son déploiement LLM.
Trois leviers pour votre organisation
- Auditez vos étapes de fine-tuning domaine par domaine. Si votre modèle subit une adaptation conversationnelle ou un RLHF, mesurez explicitement la régression sur les tâches analytiques et techniques. Un score dégradé non mesuré est un bug silencieux en production.
- Réévaluez le critère « nombre de paramètres » dans vos évaluations de fournisseurs. Avant de spécifier un modèle 30B+ dans votre architecture, validez les benchmarks des modèles 7-8B récents sur votre cas d'usage spécifique. Le cas Granite 4.1-8B contre Granite 4.0-32B MoE en est l'illustration directe.
- Budgétez vos évaluations au même titre que vos GPU. Selon EvalEval, un run HAL complet coûte environ 40 000 dollars. Ce coût n'est pas optionnel si votre organisation veut comparer honnêtement des modèles en conditions opérationnelles réelles — intégrez-le dans vos projections dès le choix du modèle.
Quelle régression silencieuse se cache aujourd'hui dans votre pipeline de fine-tuning ?
Si ce décryptage vous parle, je publie une analyse de ce calibre chaque jour sur l'innovation digitale et l'IA en entreprise. 👉 Recevez la prochaine directement dans votre boîte mail — l'inscription prend dix secondes, et chaque édition est lue avant 9h par des dirigeants de PME, d'ETI et d'institutions belges.
Sources
💬 Retrouvez et commentez ce post sur LinkedIn.
Cet article fait partie du Neurolinks AI & Automation blog.
Lire en: English | neerlandais