Granite 4.0 : IBM veut écraser la concurrence sur le terrain de l’inférence

Transformer, Mamba 2, MoE : IBM joue l’hybridation des techniques

Mais une autre architecture, Mamba, a été imaginée pour résoudre ce défaut. Un modèle Mamba n’est pas un réseau de neurones récurrents à proprement parler. C’est un dérivé d’un modèle espace-état (state space model ou SSM).

« Ils [les modèles espace-état] ont été initialement conçus pour prédire l’état suivant d’une séquence continue (comme un signal électrique) en utilisant uniquement les informations provenant de l’état actuel, de l’état précédent et de l’éventail des possibilités (l’espace d’états) », rappelle IBM. Un algorithme largement utilisé dans les scénarios de prédiction.

En 2023, les chercheurs Albert Gu et Tri Dao ont ajouté au SSM un mécanisme de sélection et une méthode de scan. Deux approches qui ont démontré que les SSM pouvaient rivaliser avec les Transformer pour la génération de langage. Mamba 2 est une optimisation de cette architecture. Elle a d’abord été mise en pratique par A21Labs. Mistral AI l’a testé avec Codestral Mamba.

Celle-ci présente l’avantage d’une mise à l’échelle linéaire de la puissance de calcul (« si la séquence dans la fenêtre de contexte double, les ressources de calcul nécessaires doublent »), tout en restant compatible avec les Transformers. C’est d’ailleurs une capacité essentielle. Les modèles Mamba « pur-jus » ont davantage de mal à exploiter les informations présentes dans le contexte.

C’est la stratégie retenue par IBM. Les modèles Granite 4.0-H-Micro, H-Tiny et H-Small combinent des couches Mamba 2 avec des blocs Transformer avec un ratio 9 pour 1. Plus précisément, pour quatre couches d’attention, les trois modèles disposent de 36 blocs Mamba 2.

 Si Granite 4.0-H-Micro combine une architecture Transformer dense avec Mamba 2, H-Tiny et H-Small repose sur un couple « Transformer MoE/Mamba 2 ».

Dans cette configuration, IBM peut utiliser tous les mécanismes d’optimisation populaires (activation SWIGLU, RMSNorm, MoE avec experts partagés, mécanisme NoPe pour étendre la fenêtre de contexte) des transformers avec des composants Mamba 2. « Le meilleur des deux mondes », croient les chercheurs de Big Blue.

Faire baisser la consommation de VRAM de 70 %

Ainsi, Granite-4.0-H-Tiny inclut 64 experts, dont seulement 6 activés à l’inférence. H-Small en contient 72 pour 10 experts sélectionnés lors des traitements. Surtout, H-Tiny n’active qu’un milliard de ses 7 milliards de paramètres à l’inférence, quand H-Small en enclenche 9 milliards pour 32 au total. H-Micro utilise pleinement ses 3 milliards de paramètres, comme Granite-Micro, un modèle dense, sans Mamba 2.

 Plus concrètement, H-Tiny n’a besoin que de 8 Go de VRAM pour s’exécuter en FP8. H-Small nécessite 33 Go de VRAM dans la même configuration, soit un GPU Nvidia L40S (48 Go de VRAM). Selon IBM, H-Tiny n’aurait besoin que de 15 Go de VRAM pour exécuter 8 sessions concurrentes et un total de 128 000 tokens (la fenêtre de contexte maximale des modèles Granite 4.0). Granite 3.3 8B, un modèle dense aurait besoin de 90 Go de VRAM pour exécuter la même tâche. En clair, plus besoin de louer des clusters de Nvidia H100. Une instance A10 ou une RTX 3090 suffit (24 Go de VRAM) pour lancer un projet. Avec Granite-H-Micro, il suffirait d’un Raspberry Pi doté de 8 Go de RAM.

Le groupe a également fait en sorte de rendre ses modèles hybrides compatibles avec les GPU AMD MI-300X et les puces NPU Hexagon de Qualcomm.

Et IBM d’assurer test à l’appui que H-Tiny et H-Small peuvent consommer jusqu’à 70 % de VRAM de moins que les autres modèles Transformers « open weight », dont Qwen 3 8B et 32B, mais aussi Llama 3.2-8B Instruct et Phi-4. Ces LLM sont déjà optimisés pour consommer moins de ressources de calcul que leurs homologues propriétaires. Autre comportement intéressant, la vitesse d’inférence croît avec le volume de tokens ingérés.

Un entraînement plus opaque et probablement bien plus carboné

Et à l’entraînement ? Cette fois-ci, IBM n’a pas utilisé son supercalculateur Blue Vela, ni même l’infrastructure de l’entreprise.

« Nous avons entraîné les modèles de langage Granite 4.0 à l’aide d’un cluster NVIDIA GB200 NVL72 hébergé chez CoreWeave », indiquent les chercheurs d’IBM. « La communication intrarack s’effectue via le domaine NVLink à 72 GPU, tandis qu’un réseau InfiniBand NDR 400 Gb/s Fat-Tree non bloquant assure la communication interrack. Ce cluster fournit une infrastructure évolutive et efficace pour l’entraînement de nos modèles sur des milliers de GPU ».

En juin 2025, IBM et CoreWeave présentaient un test MLPerf avec 2496 GB200. Bien loin des 768 GPU H100 utilisé pour entraîner Granite 3.0 et les préversions de Granite 4.0. Contrairement à l’accoutumée, Big Blue n’a pas présenté le bilan carbone pour la collection. Le groupe avait jusque là fait preuve d’exemplarité en la matière (bien que ces informations ne sont pas aisément accessibles).

Il faut dire que la collection Granite 4.0 a été entraînée avec 22 000 milliards de tokens, contre 10 000 milliards de tokens pour Granite 3.0. À son habitude, IBM révèle les noms des jeux de données ouverts utilisés lors du préentraînement : DataComp-LM, GneissWeb, TxT360, Wikipédia. Mais une plus grande partie des données est issue de sources inconnues ou propriétaires.

« Nos données d’apprentissage supervisé proviennent principalement de trois sources clés : des ensembles de données accessibles au public sous licence permissive, des données synthétiques internes ciblant des capacités spécifiques, et une sélection de données vérifiées par des humains », lit-on depuis le dépôt Hugging Face d’IBM.

Tout comme le groupe ne détaille pas les ajustements de son pipeline d’entraînement « amélioré ». Si ce n’est que les LLM ont été entraînés avec une fenêtre de contexte de 512 000 tokens, réduite à 128 000 tokens. Qui peut le plus peut le moins.

Granite 4.0 : IBM étaie ses ambitions commerciales

Ce sont là les signes de la professionnalisation d’IBM. Les modèles Granite ne sont plus uniquement des projets de recherche. Le géant de l’IT a d’ailleurs prévu de lancer ses modèles de raisonnement plus tard cet automne. D’autres variantes (Granite 4.0 Medium et Nano) sont en cours d’entraînement.

Les signes s’accumulent permettant d’affirmer qu’IBM veut en découdre sur le marché de l’IA d’entreprise. La société met en avant les trois seuls benchmarks où Granite 4.0 H-Small et Micro brillent : HELM IFEval de Stanford, Function Calling Leaderboard (BFCLv3) et MTRAG. Le premier est relatif au suivi d’instructions, le second à l’appel d’outils et le troisième aux usages RAG. Chaque fois, ces deux LLM obtiendraient de meilleurs résultats que les modèles Llama 4, Qwen3 et GPT-OSS 120B. En revanche, les résultats présents sur la page Hugging Face tendent à démontrer que les LLM d’Alibaba et d’OpenAI sont meilleurs pour les tâches de connaissances générales, multilingues, de mathématiques et de programmation. Les premiers tests des internautes semblent confirmer cette observation.

Mais au vu de la tendance autour des agents IA, c’est davantage un positionnement stratégique. Et la preuve que le fournisseur a orienté son entraînement pour les tâches les plus populaires en entreprise. D’autant qu’IBM proposera sans doute à ses clients de les fine-tuner.

Autre preuve, les modèles Granite 4.0 sont disponibles depuis Watsonx, Hugging Face, Dell Pro AI Studio, Dell Enterprise Hub, Docker Hub, Kaggle, LM Studio, Nvidia NIM, Ollama, Opaque et Replicate. La disponibilité sur Amazon SageMaker JumpStart et Azure AI Foundry ne devrait pas tarder. Aussi IBM a travaillé avec les communautés derrière vLLM, llama.cpp, NexaML et MLX pour faire en sorte que son architecture hybride soit largement prise en charge par les frameworks open source. La compatibilité reste toutefois plus limitée qu’avec d’autres LLM.

Enfin, IBM a fait passer la certification ISO42001 à son système de livraison des checkpoints (Artificial Intelligence Management System, AIMS). Ils sont signés par cryptographie pour en assurer la provenance.