Granite Switch 4.1 30B : IBM réduit douze adaptateurs à deux

Il y a cinq mois, IBM a mis un aperçu de Granite Switch 30B sur Hugging Face, avec douze adaptateurs à l'intérieur et un surcoût en paramètres de 11,68 % par rapport au modèle de base. Le 14 octobre 2026, le modèle final est arrivé — Granite Switch 4.1 30B — et il comporte exactement deux adaptateurs et un surcoût de 3,89 %. Le chiffre phare a baissé des deux tiers, et c'est ça, la sortie.

Pour être précis sur ce qu’on entend par « arrivé », car c’est là qu’une grande partie de la couverture devient approximative : les poids ont été déposés sur le Hub le 14 octobre 2026, et le billet de lancement d’IBM lui-même, Granite Switch 4.1 : Chat, décisions et parole depuis un seul point de terminaison, a été mis en ligne le 15 octobre. Cela s’est produit deux jours avant la rédaction de ces lignes. Il s’agit d’une sortie annoncée, pas d’une mise en ligne discrète que quelqu’un aurait trouvée sur un miroir, et ce n’est pas une remise en ligne de l’aperçu de mai — l’artefact est différent, le nombre d’adaptateurs est différent, et le chemin audio n’existait pas du tout dans l’aperçu. Ce qui suit distingue ce que vous pouvez lire dans le dépôt de ce que seule IBM a déclaré.

Qu'y a-t-il réellement dans le checkpoint ?

Granite Switch 4.1 30B est une composition, et non une nouvelle architecture. Il prend Granite 4.1 30B — un transformateur dense de type décodeur uniquement, avec une fenêtre de 131 072 tokens et un vocabulaire de 100 352 tokens — le gèle, puis y ajoute deux adaptateurs LoRA activés ainsi qu'un encodeur vocal. Le manifeste de build est versionné dans le dépôt à côté des poids, ce qui explique pourquoi chaque affirmation structurelle ci-dessous est lisible plutôt que rapportée.

• guardian-core — aLoRA, rang 16, alpha 64, attaché uniquement aux projections d'attention (k_proj, o_proj, q_proj, v_proj), extrait de la bibliothèque Guardian et dirigé vers les contenus nuisibles, le jailbreaking, la profanité, la violence, le contenu sexuel, les biais sociaux et les comportements contraires à l'éthique. Jeton de contrôle <|guardian-core|>, id 100352.

• décision — aLoRA, rang 64, alpha 128, attaché aux sept projections, y compris le MLP, et entraîné à faire quelque chose de plus restreint que le chat : étant donné un état et une question avec des options étiquetées, renvoyer une distribution de probabilité calibrée sur ces étiquettes en une seule passe avant. Jeton de contrôle <|decision|>, identifiant 100353.

• Parole — granite-speech-5.0-470m-turboctc, un encodeur CTC conformer non autorégressif de 470 M de paramètres, uniquement en anglais, intégré comme voie d’entrée audio plutôt qu’un second service.

L'arithmétique des poids est le nombre le plus net de la version. Base : 28 865 728 512 paramètres. Composé : 29 989 814 272. La différence est de 1 124 085 760 paramètres, soit +3,89 %. Vous n'écrivez pas vous-même les jetons de contrôle — le gabarit de chat les insère lorsque vous passez un adapter_name en argument, ce qui signifie que le changement de capacité est un paramètre de requête plutôt qu'un second déploiement.

La version préliminaire était livrée avec douze adaptateurs. La version finale en livre deux.

C'est une décision qui mérite d'être comprise, car à première vue, elle ressemble à une régression. Le checkpoint de préversion — toujours sur le Hub, toujours sous Apache-2.0, daté du 5 mai 2026 — embarque douze adaptateurs issus de trois Granite Libraries : citation, query rewrite, query clarification, hallucination detection, answerability, factuality detection, policy guardrails, factuality correction, guardian-core, uncertainty, requirement check et context attribution. C'est un ensemble réellement utile, et c'est un ensemble qu'il faut analyser avec soin, car douze adaptateurs signifient douze recettes d'invocation et douze contrats de sortie différents.

Granite Switch 4.1 30B en conserve deux et y ajoute un encodeur vocal. Le compromis qu'IBM a fait, c'est la lisibilité contre la couverture : le modèle final est un modèle de conversation qui peut aussi répondre à une question de décision avec une probabilité et transcrire de l'audio, et ce sont trois choses qu'un interlocuteur peut garder en tête en même temps. Les dix autres adaptateurs n'ont pas disparu — ils sont toujours publiés, toujours composables, et le composeur du dépôt granite-switch vous construira un checkpoint avec le sous-ensemble que vous voulez, y compris les douze. Ce qui a changé, c'est ce qui est activé par défaut.

C'est un coût bien réel, et il vaut mieux le nommer plutôt que de le passer sous silence : si vous attendiez que les adaptateurs de détection d'hallucinations et d'attribution de contexte de la préversion atteignent un point de contrôle 1.0, ce n'est pas cela. C'est un modèle plus restreint, avec une surcharge plus faible, et c'est l'outillage de composition qui comble l'écart.

L’adaptateur de décision est la moitié qui n’est pas un modèle de chat

Extraire une distribution de probabilités d'un modèle de langage n'a rien de nouveau. Le faire en une seule passe avant sur un ensemble fixe d'étiquettes d'options, avec des nombres calibrés suffisamment bien pour router dessus, est la partie qui demande explication. La recette documentée est un prompt système fixe de moteur de décision, un tour État : évalué sur la base gelée, puis un tour ### DÉCISION présentant la question et des options étiquetées par un seul token. Vous demandez les logprobs correspondant exactement à ces ids de tokens d'étiquettes et vous exponentiez. L'exemple de la fiche elle-même renvoie quelque chose comme A : 0,982, B : 0,0035, C : 0,014 — et la partie intéressante est que ceux-ci provenaient d'un point de terminaison de complétion normal, et non d'un classifieur.

Il y a un détail d’ingénierie que l’annonce passe sous silence. Le mécanisme logprob-token-id plafonne à 128 ID par requête, de sorte qu’une question de décision comportant plus de 128 options échoue purement et simplement. Le correctif documenté consiste à scinder les ID d’étiquettes en blocs de 128, à envoyer une requête par bloc avec un prompt identique, puis à concaténer — ce qui est mathématiquement identique à un appel sans plafond, car les logprobs renvoyés couvrent l’ensemble du vocabulaire et la valeur de chaque étiquette ne dépend donc pas du bloc qui l’a demandée. Une requête supplémentaire par 128 options. C’est le genre de détail qui n’existe qu’à l’intérieur d’un dépôt.

Le seul chiffre publié associé à l’adaptateur est le Decision Index, édition v0.3, sous-ensemble public rapide de 1 068 lignes : Score global 50,1, avec Connaissances 32,4, Langage 58,6, Récupération 49,8, Outils 76,5 et Arts 26,4. Observez la forme plutôt que le chiffre phare — un 76,5 en Outils à côté d’un 26,4 en Arts constitue un profil très inégal, et cela vous en dit plus sur les endroits où cet adaptateur peut être appliqué sans risque que le chiffre global. IBM indique aussi que servir l’adaptateur en local et derrière un point de terminaison vLLM hébergé a donné des résultats concordant à environ 0,6 point près, ce qui constitue un contrôle de cohérence utile du chemin de service, même si IBM a exécuté les deux parties.

Transcription automatique de la parole, et la mise en garde qu'IBM a inscrite dans sa propre fiche

Le chemin audio fait passer la transcription dans l'encodeur intégré et l'insère dans le contexte de chat à la place de la partie de contenu audio, de sorte qu'une requête avec audio ressemble à une complétion de chat normale avec une input_audio partie. Pas de second serveur vocal, pas de second budget de latence.

Les limites proviennent toutes de la documentation d'IBM elle-même plutôt que d'un sceptique : anglais uniquement, sortie en minuscules et sans ponctuation, aucun pilotage au moment du décodage, et — celle qui devrait vous ralentir — l'encodeur vocal et le modèle de langage ne sont pas entraînés conjointement. Il n'existe aucune projection entraînée qui les couple. Une erreur de transcription peut donc changer ce à quoi le modèle, ou l'adaptateur de décision, réagit, et rien dans le pipeline ne le signalera. Si vous déployez quoi que ce soit où une erreur de transcription a des conséquences, cette phrase constitue tout votre modèle de menace.

Confirmé, signalé par le fournisseur, non vérifié

• Confirmé depuis le dépôt — identité du modèle de base, les deux rangs d’adaptateurs et leurs modules cibles, les identifiants des jetons de contrôle, le nombre de paramètres composé et le delta de +3,89 %, la fenêtre de 131 072 jetons, la licence Apache-2.0, et la fenêtre de prise en charge épinglée (Transformers 5.16–5.17, vLLM 0.26–0.28, PyTorch 2.11+).

• Rapporté par le fournisseur, non reproduit — les chiffres 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 selon laquelle le modèle composé consomme à peu près la même quantité de VRAM que le modèle de base, l’assertion selon laquelle l’adaptateur Guardian surpasse plusieurs modèles décisionnels fermés nommés sur des tâches liées à la sécurité, et la remarque en passant du billet de lancement selon laquelle une version personnalisée de Granite Switch 3B a fait tourner Doom à 60–100 décisions par seconde, contre 10 décisions par seconde rapportées. IBM indique que davantage de données arriveront « dans les semaines à venir », ce qui revient à admettre que les preuves dont on dispose aujourd’hui sont minces.

• Personne n’a vérifié — tout le reste. Aucune évaluation par des tiers, aucune entrée dans un classement, aucune mesure indépendante de latence ou de débit, aucun point de terminaison IBM hébergé. Le dépôt affiche une poignée de likes et, au moment de la rédaction, pratiquement aucun téléchargement. Deux jours d’existence et très peu lu.

Où cela se situe dans une pile

Granite Switch 4.1 30B est une histoire d'auto-hébergement. La fiche répertorie Hugging Face Transformers et vLLM, impose une fenêtre de version étroite, et le checkpoint fonctionne sur les deux sans conversion. Il n'existe pas de point de terminaison géré, donc la première étape pratique est un GPU et un conteneur.

Pour être franc sur le reste : aucun modèle Granite ne figure aujourd'hui au catalogue d'OrcaRouter, donc si vous voulez ce checkpoint, la voie passe par la publication d'IBM et votre propre matériel. Ce que la plateforme vous offre, c'est la décision qui l'entoure — plus de 200 modèles derrière une seule clé avec basculement automatique, prix catalogue des fournisseurs répercuté avec 0 % de marge — ce qui compte le plus dans exactement cette situation. Un checkpoint vieux de deux jours et sans évaluation indépendante est un candidat, pas un titulaire en place, et ce qu'il y a de moins coûteux à faire avec un candidat, c'est de le garder à côté du modèle déjà en production et de comparer sur votre propre trafic au lieu de reconfigurer un chemin de production autour de lui.

La question ouverte

Le pari derrière Granite Switch, c’est que la composition l’emporte sur l’échelle pour une catégorie précise de tâches — les applications qui répondent, décident et transcrivent, où trois modèles signifient trois déploiements, trois latences et trois factures. Partager un seul cache KV entre les adaptateurs et payer 3,89 % pour cela relève d’une ingénierie véritablement inhabituelle, et c’est la partie de cette version qui comptera encore dans un an.

Ce qui n'est pas réglé, c'est de savoir si la réponse composée est bonne. Le profil publié de l'adaptateur de décision est inégal, le chemin vocal est uniquement en anglais et n'est pas entraîné conjointement, et le modèle a deux jours, sans exécution indépendante à l'appui. Lisez le manifeste de build, composez votre propre sous-ensemble et évaluez l'adaptateur de décision par rapport à votre propre jeu d'étiquettes avant de faire confiance au 50,1 de qui que ce soit.