Granite Switch 4.1 8B : un seul point de contrôle 8B qui dialogue, décide et transcrit

Huit milliards trois cent quatre-vingts millions de paramètres entrent. Huit milliards sept cent soixante-seize millions ressortent. Ces 4,72 % constituent toute la différence entre le modèle de base d'IBM et Granite Switch 4.1 8B, et c'est le chiffre le plus intéressant de cette publication, car dans ce minuscule écart sont logés un classificateur de sécurité, un moteur de décision et un système de reconnaissance vocale — tous répondant depuis un seul point de terminaison, tous lisant et écrivant le même cache KV que le modèle de base aurait de toute façon construit.

Les poids ont été publiés sur Hugging Face le 14 octobre 2026. Le blog de lancement d'IBM, Granite Switch 4.1 : Chat, décisions et parole depuis un seul point de terminaison, a suivi le 15 octobre, ce qu'il vaut la peine de dire clairement d'entrée de jeu : il ne s'agit pas d'une sortie discrète que quelqu'un aurait trouvée dans un miroir. Il s'agit d'une sortie annoncée qui a environ deux jours au moment de la rédaction, et la version de l'histoire qui compte n'est pas « qu'est-ce qu'IBM a affirmé » mais « que pouvez-vous réellement vérifier à partir du checkpoint qui se trouve sur le Hub en ce moment ». Ces deux choses ne sont pas la même chose, et cet article les garde distinctes.

Ce que le checkpoint contient réellement

Granite Switch n’est pas une nouvelle architecture. C’est une composition : un modèle de base gelé, un ensemble d’adaptateurs de rang faible qui peuvent être activés et désactivés par token, et — dans cette version particulière — un encodeur greffé pour l’audio. Le composeur réside dans le dépôt granite-switch et le manifeste de build de ce checkpoint est enregistré à côté des poids, ce qui signifie que chaque affirmation structurelle ci-dessous est lisible directement sur le Hub plutôt que tirée d’un communiqué de presse.

La base est Granite 4.1 8B — décodeur dense uniquement, attention à requêtes groupées avec 32 têtes de requête face à 8 têtes de clé/valeur, SwiGLU, RMSNorm, une fenêtre de 131 072 tokens et un vocabulaire de 100 352 tokens. Le checkpoint composé hérite de tout cela et y ajoute deux adaptateurs LoRA activés :

• guardian-core — rang 16, alpha 64, attaché uniquement aux projections d’attention (k_proj, o_proj, q_proj, v_proj), extrait de la version de Guardian Library et décrit comme détectant les préjudices, le jailbreaking, la vulgarité, la violence, le contenu sexuel, les biais sociaux et les comportements contraires à l’éthique.

• décision — rang 64, alpha 128, attaché aux sept projections, y compris le MLP (down_proj, gate_proj, up_proj), et entraîné à faire quelque chose de plus étroit et de plus étrange : étant donné un état et une question comportant des options étiquetées, renvoyer une distribution de probabilité calibrée sur ces étiquettes d’options en une seule passe avant.

Tous deux sont activés par des jetons de contrôle — <|guardian-core|>et <|decision|> — que le template de conversation insère pour vous lorsque vous passez un adapter_nameargument. Vous n'écrivez pas les jetons vous-même, et ce détail compte plus qu'il n'y paraît : cela signifie que la sélection de l'adaptateur est un paramètre de requête, et non un second modèle à déployer.

Pourquoi le delta du paramètre est si petit

C'est l'arithmétique qui raconte l'histoire. Le modèle de base compte 8 380 551 168 paramètres. Le modèle composé en compte 8 776 400 896. Soit +395,8 millions, ou +4,72 %, pour deux adaptateurs. La raison pour laquelle ce chiffre reste aussi bas tient à une décision de conception appelée normalisation du cache KV : chaque adaptateur voit le cache de clés/valeurs du modèle de base plutôt que de maintenir le sien. Dans une configuration multi-adaptateurs classique, chaque adaptateur supplémentaire constitue un second ensemble d'états d'attention, et la facture mémoire augmente avec le nombre d'adaptateurs entre lesquels vous basculez. Ici, ce n'est pas le cas. Dans son billet de lancement, IBM affirme que le modèle composé utilise « environ la même quantité de VRAM sur un GPU que le modèle de base à lui seul », et même si personne en dehors d'IBM ne l'a encore mesuré, le delta de poids de 4,72 % est cohérent avec cette affirmation — et contrairement à l'affirmation sur la VRAM, le delta de poids n'est qu'un nombre dans un manifeste que vous pouvez lire.

L'adaptateur de décision est la moitié intéressante

Extraire une distribution de probabilités d'un modèle de langage n'a rien de nouveau ; ce qui mérite d'être compris, c'est de le faire en une seule passe avant avec un vocabulaire fixe d'étiquettes d'options, et d'obtenir des nombres suffisamment calibrés pour agir dessus. La recette d'invocation est documentée dans la fiche : une invite système fixe de moteur de décision, un État : tour évalué sur la base gelée, puis un ### DÉCISION tour présentant la question et des options étiquetées par un seul jeton. Vous demandez ensuite au serveur les logprobs de ces identifiants de jetons d'étiquette précis — vLLM les expose via logprob_token_ids — puis vous en prenez l'exponentielle. L'exemple documenté renvoie quelque chose comme A : 0,982, B : 0,0035, C : 0,014.

Il y a ici un véritable accroc d'ingénierie que la version marketing de cette publication passe sous silence. vLLM plafonne logprob_token_ids à 128 ids par requête. Si votre question de décision comporte plus de 128 options, vous obtenez une erreur HTTP 400, et la solution consiste à découper les ids de label en blocs de 128, à émettre une requête par bloc avec un prompt identique, et à concaténer — car les logprobs renvoyés portent sur l'ensemble du vocabulaire, la valeur de chaque label est indépendante du bloc qui l'a demandée, de sorte qu'un seul softmax sur l'ensemble complet des labels est mathématiquement identique à un appel sans plafond. Cela représente une requête supplémentaire par 128 options. C'est un détail véritablement utile, et c'est exactement le genre de chose qui n'existe que dans le dépôt.

Le seul chiffre publié associé à cet adaptateur est l'indice de décision (JEV), édition v0.3, sous-ensemble rapide public de 1 068 lignes : Note globale 42,9, Connaissances 29,1, Langue 48,9, Recherche 49,8, Outils 59,8, Arts 18,0. Considérez cela comme déclaré par le fournisseur, car c'est bien le cas : IBM l'a exécuté, l'a publié, et aucun tiers ne l'a reproduit. Il vaut aussi la peine de regarder la forme plutôt que le chiffre phare — 59,8 sur les Outils à côté de 18,0 sur les Arts, c'est un profil très inégal, et la fiche elle-même avertit que les probabilités d'option sont « un a priori pour éclairer une décision, non une classification certifiée » sur des domaines pour lesquels l'adaptateur n'a pas été entraîné.

La transcription automatique de la parole est bien réelle, et plus restreinte que ne le laisse entendre le titre.

Le chemin audio intègre Granite Speech 5.0 TurboCTC, un encodeur CTC à conformeur non autorégressif de 470 M de paramètres, et transcrit l'audio entrant avant d'épisser la transcription dans le contexte de conversation à la place de la partie de contenu audio. L'appeler ne modifie pas la forme de la requête : il s'agit d'une input_audio partie de contenu sur un chat completion classique, et la transcription s'exécute sur le même endpoint que la conversation et les décisions, il n'y a donc pas de second serveur vocal à déployer.

Les mises en garde, toutes issues de la fiche d'IBM elle-même plutôt que d'un détracteur : l'encodeur est uniquement en anglais, sa sortie est en minuscules et sans ponctuation, il n'y a pas de pilotage au moment du décodage, et — celle qui devrait vous arrêter — l'encodeur vocal et le LLM ne sont pas entraînés conjointement. Il n'existe aucune projection entraînée qui les couple. Une erreur de transcription peut donc modifier silencieusement ce à quoi le modèle, ou un adaptateur, répond. Si vous construisez quoi que ce soit où une erreur de transcription a des conséquences, cette phrase constitue à elle seule toute la revue de sécurité.

Ce qui est confirmé, ce qui est déclaré par le fournisseur, ce que personne n’a vérifié

• Confirmé depuis le dépôt — l'identité du modèle de base et le nombre de couches, les deux rangs d'adaptateurs et leurs modules cibles, les identifiants des jetons de contrôle, le nombre de paramètres composé, la fenêtre de 131 072 jetons, la licence Apache-2.0, et les versions documentées de vLLM et Transformers demandées par la fiche.

• Signalé par le fournisseur, non reproduit — les scores du Decision Index, l'affirmation selon laquelle Granite Speech 5.0 TurboCTC est le modèle ASR le plus rapide du classement OpenASR, l'affirmation d'une « même VRAM que le modèle de base », et la remarque incidente du billet de lancement selon laquelle un modèle Granite Switch 3B personnalisé fait tourner Doom à 60–100 décisions par seconde, contre 10 par seconde annoncées pour un modèle de décision propriétaire. IBM indique qu'elle publiera davantage de données « dans les semaines à venir », ce qui revient à admettre que les preuves actuelles sont minces.

• Personne ne l'a vérifié — tout le reste. Il n'existe aucune évaluation indépendante, aucune entrée dans un classement tiers, aucune API hébergée par IBM, et aucune mesure de latence ou de débit publiée par quiconque n'étant pas IBM. Le dépôt sur le Hub affiche quelques dizaines de téléchargements et une poignée de mentions J'aime : ce modèle a deux jours et n'a guère été lu.

Ce que cela coûte à exécuter, et où OrcaRouter s'intègre

Granite Switch 4.1 8B relève pour l’instant de l’auto-hébergement. La fiche répertorie HuggingFace Transformers et vLLM comme backends, fixe une fenêtre de prise en charge assez étroite (Transformers 5.16–5.17, vLLM 0.26–0.28), et le checkpoint fonctionne avec les deux sans modification du code. Il n’existe aucun point de terminaison managé vers lequel pointer, ce qui, pour la plupart des équipes, implique un GPU et un conteneur avant la première requête.

Pour être francs sur le reste : Granite Switch ne figure pas aujourd'hui au catalogue d'OrcaRouter, et aucun autre modèle Granite non plus — donc si vous voulez ce checkpoint, la voie passe par la version publiée par le fournisseur et votre propre matériel, pas par nous. Ce qu'OrcaRouter vous apporte, c'est la décision qui l'entoure. La plateforme route plus de 200 modèles derrière une seule clé, avec basculement automatique, et rétrocède le prix catalogue du fournisseur avec 0 % de marge, donc lorsqu'un modèle que vous évaluez obtient bel et bien un point de terminaison hébergé, le comparer au modèle en place sur votre propre trafic relève d'un simple changement de configuration plutôt que d'un second contrat. Cela compte d'autant plus dans cette situation précise : un checkpoint vieux de deux jours, sans évaluation indépendante, est un candidat, pas un titulaire, et la chose la moins coûteuse à faire avec un candidat est de le garder dans une comparaison côte à côte plutôt que de reconfigurer un chemin de production autour de lui.

La question ouverte

Granite Switch 4.1 8B est le pari que la composition l’emporte sur l’échelle pour une catégorie précise de tâches : les applications qui doivent répondre, décider et transcrire, où faire tourner trois modèles signifie trois déploiements, trois latences et trois factures. L’ingénierie qui rend ce pari peu coûteux — cache KV partagé, commutation d’adaptateurs par token, jetons de contrôle résolus dans le template de chat — est réellement inhabituelle, et c’est la partie de cette version qui comptera encore dans un an.

Ce qui n'est pas encore tranché, c'est de savoir si la réponse composée est bonne. Le profil publié de l'adaptateur de décision est irrégulier, la voie vocale est uniquement en anglais et n'est pas entraînée conjointement, et l'ensemble n'a que deux jours, sans exécution indépendante derrière lui. Lisez le manifeste de build, exécutez vous-même la commande compose, et évaluez les performances de l'adaptateur de décision sur votre propre jeu d'étiquettes avant de croire au 42,9 de qui que ce soit.