Oubliez les mastodontes : place aux modèles affûtés. IBM lance toute une famille de modèles Granite 4.0, construits sur une architecture mixte de Mamba et de Transformer. Une évolution qui signe une nouvelle montée en puissance des petits LLMs ouverts vraiment productifs. Entre raisonnement long-contexte et exécution multi-agents, IBM trace une voie crédible vers une IA industrielle, personnalisable, auditable et économe.
Les petits modèles sont les grandes stars de l’année 2025. Non seulement ils permettent de concrétiser une grande variété de scénarios IA à l’Edge jusqu’ici trop complexes à concrétiser pour causes de contraintes de latence ou de règlementation, mais ils sont aussi bien plus faciles à « tuner » ou partiellement réentraîner avec des données propres à l’entreprise pour augmenter la pertinence contextualisée des réponses et limiter les hallucinations. D’autant que « petits » modèles ne veut pas dire « moins capables », puisqu’ils sont désormais parfois capables de raisonnement avancé et même de capacités multimédias. Par ailleurs, ils évoluent également plus vite que les modèles frontières.
Parmi les petits modèles en vogue, la famille Granite d’IBM, publié en open weight, a beaucoup attiré l’attention des chercheurs IA ces derniers mois. Et l’on attendait avec une certaine impatience la nouvelle génération.
L’attente est terminée. Et IBM change d’échelle avec Granite 4.0, sa nouvelle génération de modèles « open weight » publiée sous licence Apache 2.0 et pensée d’abord pour l’exécution en production : moins de mémoire, plus de sessions concurrentes, fenêtres de contexte longues et un cadre de confiance audité.
La gamme se compose de quatre modèles : Granite-4.0-H-Small (32 Md de paramètres, 9 Md actifs), Granite-4.0-H-Tiny (7 Md, 1 Md actif), Granite-4.0-H-Micro (3 Md, hybride dense) et Granite-4.0-Micro (3 Md, transformer « classique »). Tous visent l’inférence frugale sur des GPU bien moins coûteux que les configurations habituelles des LLMs.
Une architecture hybride Mamba-Transformer
Dans la même logique que celle suivie par Mistral AI, IBM tente de faire progresser le cœur des modèles en explorant d’autres voies que les Transformers (le fameux T de GPT). Pour Granite 4.0, IBM a suivi une approche hybride originale qui combine majoritairement des couches Mamba-2, issues des modèles « state-space », avec une petite fraction de blocs Transformer.
Pourquoi ? Essentiellement parce que la self-attention des Transformers voit ses besoins de calcul et de mémoire croître au carré de la longueur du contexte, ce qui fait exploser la VRAM et la latence quand on allonge les fenêtres ou quand on multiplie les sessions. À l’inverse, Mamba-2 traite la séquence de façon séquentielle avec une complexité linéaire et une mémoire qui ne dépend pratiquement pas de la taille du contexte ; l’ordre y est implicite, ce qui permet à IBM de supprimer totalement les encodages positionnels. Et ce qui permet de proposer des « petits modèles » qui ne sont pas de grands dévoreurs de mémoire.
Dans Granite 4.0, les deux approches sont intercalées dans un ratio d’environ 9 pour 1 : les blocs Mamba capturent efficacement la dynamique globale sur de longues séquences, tandis que les blocs Transformer affinent des interactions locales plus nuancées. Résultat : des fenêtres très longues peuvent être servies avec bien moins de mémoire et une latence plus basse, IBM indiquant un entraînement sur des échantillons allant jusqu’à 512 k tokens et des performances validées jusqu’à 128 k, avec à la clé des gains de RAM de plus de 70 % sur des charges à long contexte et multi-sessions.
Résultat, un Raspberry Pi 5 avec 8 Go de RAM peut inférer le modèle Granite-4.0-H-Micro sans difficulté. Pour les modèles plus développés, plus besoin de monter de clusters H100 ou plus. Des cartes GPU RTX suffisent pour démarrer des POC, tout en gardant de la marge pour monter en charge.
Des priorités « agentiques »
Chez Granite 4.0, « agentique » signifie qu’un modèle ne se contente pas de prédire du texte : il comprend une consigne précise, choisit les étapes utiles, appelle des outils externes et s’appuie sur des sources pour répondre de façon vérifiable. Des capacités agentiques forgées sur 3 piliers :
Le premier pilier est le suivi d’instructions. Concrètement, le modèle respecte des contraintes de format, de ton, de longueur ou de schéma de sortie (par exemple un JSON conforme à un contrat). Pour un DSI, c’est la différence entre une réponse « qui sonne juste » et une production exploitable par un workflow d’automatisation : un ticket ServiceNow rempli correctement, un résumé normalisé, un champ calculé sans ambiguïté.
Deuxième pilier, l’appel d’outils (« function calling ») permet d’exposer au modèle un catalogue de fonctions — interroger un ERP, créer une demande d’achat, lancer une recherche sécurisée, calculer un KPI, appeler une API — avec des arguments typés. Le modèle doit décider s’il faut utiliser un outil, lequel, et avec quels paramètres, puis intégrer le résultat à sa réponse. Il en résulte avec Granite 4.0 moins de boucles de rattrapage, des transitions propres entre langage naturel et systèmes métiers, des traces auditables sur qui a appelé quoi, quand et avec quelles données.
Enfin, le Troisième pilier est l’apparition d’un fonctionnement RAG en multi-tours. Le modèle apprend à formuler une requête documentaire efficace, à citer ses sources, à maintenir le fil de la conversation sur plusieurs échanges et à ajuster ses recherches si les documents initiaux ne suffisent pas. Combiné aux fenêtres de contexte très longues de Granite 4.0, cela permet d’obtenir des assistants IA qui « gardent en tête » un dossier, justifient chaque affirmation par une référence, et réduisent mécaniquement les hallucinations.
Au final tout ceci signifie aussi moins de VRAM pour servir plus de sessions, moins d’échecs silencieux, et des réponses qui passent du statut d’aide ponctuelle à celui de composant fiable d’un processus métier.
Face aux Qwen 3, Llama ou aux très grands modèles propriétaires, Granite 4.0 mise moins sur la « connaissance encyclopédique » brute que sur l’exécution fiable de tâches d’entreprise (instructions, outils, RAG) au meilleur coût par tâche. Des premiers retours et mesures publiques montrent que certains concurrents gardent l’avantage sur des épreuves de connaissances générales, multilingues, maths et programmation, tandis que Granite prend l’ascendant sur des cas au cœur des workflows agentiques.
Données, entraînement et transparence
La famille Granite 4.0 est pré-entraînée sur un corpus d’environ 22 000 milliards de tokens, mêlant jeux de données ouverts (DataComp-LM, GneissWeb, TxT360, Wikipédia) et données orientées usages métiers, avant un post-entraînement couvrant langage, code, math, multilingue, sécurité, tool-calling et RAG.
Côté gouvernance, Granite est présenté comme la première famille de modèles ouverts certifiée ISO/IEC 42001:2023 pour le système de management de l’IA. Tous les checkpoints sont signés cryptographiquement, un programme de bug bounty avec HackerOne offre jusqu’à 100 000 $, et IBM offre une indemnisation « non plafonnée » sur watsonx.ai en cas de réclamation de propriétés intellectuelles liée aux contenus générés.
Déploiement et roadmap
Les modèles sont disponibles immédiatement dans watsonx.ai et via un large réseau de fournisseurs ou plateformes de modèles as a service : Hugging Face, Docker Hub, Kaggle, LM Studio, NVIDIA NIM, Replicate, Ollama, et les hubs Dell ; l’arrivée sur AWS SageMaker JumpStart et Azure AI Foundry est également annoncée comme imminente. IBM indique avoir opéré différentes optimisations pour vLLM et Transformers HF (avec des travaux en cours sur llama.cpp et MLX) et veillé à un support matériel étendu, y compris le support des AMD Instinct MI300X et des NPU Hexagon de Qualcomm pour accélérer l’inférence « on-device ».
IBM prévoit déjà des variantes « Thinking » optimisées pour le raisonnement complexe d’ici l’automne, ainsi que des tailles « Medium » et « Nano » pour étendre le spectre des déploiements. Reste un enjeu d’écosystème : pour déplacer les usages au-delà des Transformers, il faudra des runtimes « durcis » aussi fluides côté NVIDIA qu’AMD, des blueprints coût-par-tâche publiés et des intégrations profondes aux frameworks d’orchestration existants. En attendant, Granite 4.0 offre une voie pragmatique pour réduire le coût d’inférence sans renoncer à la qualité là où elle compte : dans les systèmes outillés et gouvernés des datacenters d’entreprise.
puis