Granite Switch 4.1 30B: IBM riduce gli adattatori da dodici a due

Cinque mesi fa IBM ha pubblicato su Hugging Face un'anteprima di Granite Switch 30B con dodici adattatori al suo interno e un sovrapprezzo di parametri dell'11,68% rispetto al modello base. Il 14 ottobre 2026 è arrivato il modello definitivo — Granite Switch 4.1 30B — e ha esattamente due adattatori e un sovrapprezzo di parametri del 3,89%. Il numero di punta si è ridotto di due terzi, e questo è il rilascio.

Per essere precisi su cosa significhi "arrivato", perché è qui che molta copertura diventa sciatta: i pesi sono arrivati sull'Hub il 14 ottobre 2026, e il post di lancio di IBM stessa, Granite Switch 4.1: Chat, decisioni e voce da un unico endpoint, è stato pubblicato il 15 ottobre. Sono due giorni prima che questo venga scritto. È un rilascio annunciato, non un rilascio silenzioso che qualcuno ha trovato in un mirror, e non è una ripubblicazione dell'anteprima di maggio — l'artefatto è diverso, il numero di adattatori è diverso, e il percorso audio non esisteva affatto nell'anteprima. Quanto segue separa ciò che si può leggere dal repository da ciò che solo IBM ha dichiarato.

Che cosa c'è effettivamente nel checkpoint

Granite Switch 4.1 30B è una composizione, non una nuova architettura. Prende Granite 4.1 30B — un transformer denso decoder-only, finestra di 131.072 token, vocabolario di 100.352 token — lo congela e vi innesta due adattatori LoRA attivati più un encoder vocale. Il manifest di build è archiviato nel repository accanto ai pesi, ed è per questo che ogni affermazione strutturale qui sotto è leggibile anziché riportata.

• guardian-core — aLoRA, rango 16, alpha 64, collegata solo alle proiezioni di attenzione (k_proj, o_proj, q_proj, v_proj), prelevata dalla Guardian Library e indirizzata a danni, jailbreak, volgarità, violenza, contenuti sessuali, bias sociali e comportamenti non etici. Token di controllo <|guardian-core|>, id 100352.

• decisione — aLoRA, rank 64, alpha 128, applicato a tutte e sette le proiezioni, inclusa l'MLP, e addestrato a fare qualcosa di più ristretto rispetto alla chat: dato uno stato e una domanda con opzioni etichettate, restituire una distribuzione di probabilità calibrata su quelle etichette in un singolo forward pass. Token di controllo <|decision|>, ID 100353.

• Voce — granite-speech-5.0-470m-turboctc, un encoder CTC conformer non autoregressivo da 470M di parametri, solo in inglese, integrato come percorso di input audio anziché come secondo servizio.

L'aritmetica dei pesi è il numero più pulito della release. Base: 28.865.728.512 parametri. Composto: 29.989.814.272. La differenza è di 1.124.085.760 parametri, ovvero +3,89%. Non scrivi tu stesso i token di controllo — è il template della chat a inserirli quando passi un argomento adapter_name, il che significa che cambiare capacità è un parametro della richiesta anziché un secondo deployment.

L'anteprima includeva dodici adattatori. La versione finale ne include due.

Questa è la decisione che vale la pena comprendere, perché a prima vista sembra una regressione. Il checkpoint di anteprima — ancora sull'Hub, ancora Apache-2.0, datato 5 maggio 2026 — contiene dodici adattatori provenienti da tre Granite Libraries: citazione, riscrittura delle query, chiarimento delle query, rilevamento delle allucinazioni, rispondibilità, rilevamento della factualità, guardrail di policy, correzione della factualità, guardian-core, incertezza, verifica dei requisiti e attribuzione del contesto. È un pacchetto davvero utile, ed è un pacchetto sul quale devi ragionare, perché dodici adattatori significano dodici ricette di invocazione e dodici contratti di output diversi.

Granite Switch 4.1 30B ne mantiene due e aggiunge un encoder vocale. Il compromesso che IBM ha fatto è leggibilità in cambio di copertura: il modello finito è un modello di chat che sa anche rispondere a una domanda decisionale con una probabilità e trascrivere l'audio, e sono tre cose che chi chiama può tenere a mente tutte insieme. Gli altri dieci adapter non sono scomparsi: sono ancora pubblicati, ancora componibili, e il composer nel repository granite-switch ti costruirà un checkpoint con qualsiasi sottoinsieme tu voglia, inclusi tutti e dodici. Quello che è cambiato è ciò che arriva attivato per impostazione predefinita.

Che è un costo reale, e vale la pena nominarlo invece di minimizzarlo: se aspettavi che gli adattatori di rilevamento delle allucinazioni e di attribuzione del contesto dell'anteprima raggiungessero un checkpoint 1.0, non è questo. È un modello più ristretto con un overhead inferiore, e sono gli strumenti di composizione a colmare il divario.

L'adattatore decisionale è la metà che non è un modello di chat

Estrarre una distribuzione di probabilità da un modello linguistico non è una novità. Farlo in un solo passaggio in avanti rispetto a un insieme fisso di etichette di opzione, con numeri calibrati abbastanza bene da poterci instradare su, è la parte che va spiegata. La ricetta documentata è un system prompt fisso di un motore decisionale, un Stato: turno valutato sulla base congelata, poi un ### DECISIONE turno che presenta la domanda e le opzioni etichettate con un singolo token. Si richiedono i logprobs esattamente di quegli id dei token di etichetta e se ne calcola l'esponenziale. L'esempio riportato nella scheda stessa restituisce qualcosa come A: 0.982, B: 0.0035, C: 0.014 — e la parte interessante è che provengono da un normale endpoint di completamento, non da un classificatore.

C'è una complicazione ingegneristica che l'annuncio omette. Il meccanismo logprob-token-id ha un limite di 128 id per richiesta, quindi una domanda decisionale con più di 128 opzioni fallisce del tutto. La soluzione documentata consiste nel suddividere gli id delle etichette in blocchi di 128, inviare una richiesta per blocco con un prompt identico e concatenare — il che è matematicamente identico a una chiamata senza limite, perché i logprobs restituiti coprono l'intero vocabolario e il valore di ciascuna etichetta non dipende quindi da quale blocco l'abbia richiesto. Una richiesta in più ogni 128 opzioni. È il tipo di dettaglio che esiste solo all'interno di un repository.

L'unico numero pubblicato allegato all'adapter è il Decision Index, edizione v0.3, subset pubblico fast di 1.068 righe: Overall 50.1, con Knowledge 32.4, Language 58.6, Retrieval 49.8, Tools 76.5 e Arts 26.4. Leggete la forma più che il dato di testa — 76.5 su Tools accanto a 26.4 su Arts è un profilo molto disomogeneo, e vi dice più su dove questo adapter è sicuro da indirizzare di quanto non faccia il dato complessivo. IBM riporta anche che servire l'adapter in locale e dietro un endpoint vLLM ospitato concordava entro circa 0,6 punti, il che è un utile controllo di sanità sul percorso di serving anche se IBM ha eseguito entrambe le metà.

Riconoscimento vocale, e l'avvertenza che IBM ha inserito nella propria scheda

Il percorso audio fa passare la trascrizione attraverso l'encoder integrato e la inserisce nel contesto della chat al posto della parte di contenuto audio, così una richiesta con audio appare come una normale chat completion con un input_audio come parte. Nessun secondo server vocale, nessun secondo budget di latenza.

I limiti provengono tutti dalla documentazione di IBM stessa, non da uno scettico: solo inglese, output in minuscolo e senza punteggiatura, nessuna guida in fase di decodifica e — quello che dovrebbe farvi rallentare — il codificatore vocale e il modello linguistico non sono addestrati congiuntamente. Non esiste alcuna proiezione addestrata che li colleghi. Una trascrizione errata può quindi cambiare ciò a cui risponde il modello, o l'adattatore decisionale, e nulla nella pipeline lo segnalerà. Se state distribuendo qualcosa in cui un errore di trascrizione ha conseguenze, quella frase è il vostro intero modello di minaccia.

Confermato, segnalato dal fornitore, non verificato

• Confermato dal repository — identità del modello base, entrambi i rank degli adattatori e i relativi moduli target, gli ID dei token di controllo, il numero di parametri composti e il delta del +3,89%, la finestra di 131.072 token, la licenza Apache-2.0 e la finestra di supporto bloccata (Transformers 5.16–5.17, vLLM 0.26–0.28, PyTorch 2.11+).

• Segnalato dal fornitore, non riprodotto — i dati del Decision Index, l'affermazione che Granite Speech 5.0 TurboCTC sia il modello ASR più veloce nella classifica OpenASR, l'affermazione che il modello composto consumi all'incirca la stessa VRAM del modello base, l'asserzione che l'adattatore Guardian superi diversi modelli decisionali chiusi citati per nome in attività legate alla sicurezza, e l'inciso nel post di lancio secondo cui una build personalizzata di Granite Switch da 3B ha giocato a Doom a 60–100 decisioni al secondo contro le 10 al secondo dichiarate. IBM afferma che ulteriori dati arriveranno "nelle prossime settimane", il che è un'ammissione che le prove attuali sono scarse.

• Nessuno ha controllato — tutto il resto. Nessuna valutazione di terze parti, nessuna voce in classifica, nessuna misurazione indipendente di latenza o throughput, nessun endpoint IBM ospitato. Il repository mostra una manciata di like e, al momento della stesura, praticamente nessun download. Due giorni di vita e in gran parte non letto.

Dove si colloca in uno stack

Granite Switch 4.1 30B è una storia di self-hosting. La card elenca Hugging Face Transformers e vLLM, fissa una finestra di versione ristretta, e il checkpoint funziona su entrambi senza conversione. Non esiste un endpoint gestito, quindi il primo passo pratico è una GPU e un container.

Parliamo chiaro sul resto: oggi nessun modello Granite è nel catalogo OrcaRouter, quindi se vuoi questo checkpoint, la strada è il rilascio di IBM e il tuo hardware. Quello che la piattaforma ti offre è la decisione che ci sta attorno — oltre 200 modelli dietro un'unica chiave con failover automatico, prezzo di listino del provider passato attraverso con 0% di ricarico — il che conta soprattutto proprio in questa situazione. Un checkpoint di due giorni senza alcuna valutazione indipendente è un candidato, non un incumbent, e la cosa economica da fare con un candidato è tenerlo accanto al modello già in produzione e confrontare sul tuo traffico, invece di ricablare un percorso di produzione attorno a esso.

La questione aperta

La scommessa dietro Granite Switch è che la composizione batte la scala per una specifica classe di lavoro — applicazioni che rispondono, decidono e trascrivono, dove tre modelli significano tre deployment, tre latenze e tre bollette. Condividere una singola cache KV tra gli adattatori e pagare il 3,89% per farlo è un pezzo di ingegneria davvero insolito, ed è la parte di questo rilascio che conterà ancora tra un anno.

Ciò che non è ancora stabilito è se la risposta composta sia buona. Il profilo pubblicato del decision adapter è disomogeneo, il percorso vocale è solo in inglese e non è addestrato congiuntamente, e il modello ha due giorni e non ha alcuna esecuzione indipendente alle spalle. Leggi il build manifest, componi il tuo sottoinsieme e confronta le prestazioni del decision adapter con il tuo set di etichette prima di fidarti del 50,1 di chiunque.

Anche confronti come questo sono il punto in cui emergono le modalità di guasto: gli incidenti AI documentati e i fallimenti degli agenti dietro i modelli di questa classe sono raccolti in l'OrcaRouter AI Incident Archive, dove ogni voce riporta le proprie fonti, la gravità, il grado di confidenza e il flag di contestazione.