Granite Switch 4.1 8B: un unico checkpoint 8B che conversa, decide e trascrive

Otto miliardi e trecentottanta milioni di parametri entrano. Otto miliardi e settecentosettantasei milioni escono. Quel 4,72% è tutta la differenza tra il modello base di IBM e Granite Switch 4.1 8B, ed è il numero più interessante del rilascio, perché stipati in quella minuscola frazione ci sono un classificatore di sicurezza, un motore decisionale e un riconoscitore vocale — tutti rispondono da un unico endpoint, tutti leggono e scrivono la stessa cache KV che il modello base avrebbe comunque creato.

I pesi sono arrivati su Hugging Face il 14 ottobre 2026. Il blog di lancio di IBM stesso, Granite Switch 4.1: chat, decisioni e parlato da un unico endpoint, è seguito il 15 ottobre, e vale la pena dirlo chiaramente fin dall'inizio: non si tratta di un rilascio silenzioso che qualcuno ha scovato in un mirror. È un rilascio annunciato che, al momento in cui scriviamo, ha all'incirca due giorni di vita, e la versione della storia che conta non è «cosa ha dichiarato IBM», ma «cosa puoi effettivamente verificare dal checkpoint che in questo momento si trova sull'Hub». Queste due cose non sono la stessa cosa, e questo articolo le tiene ben distinte.

Cosa contiene effettivamente il checkpoint

Granite Switch non è una nuova architettura. È una composizione: un modello di base congelato, un insieme di adattatori a basso rango che possono essere attivati e disattivati per token e — in questa particolare build — un encoder aggiunto per l'audio. Il compositore risiede nel granite-switch repository e il manifest di build per questo checkpoint è registrato accanto ai pesi, il che significa che ogni affermazione strutturale riportata di seguito è leggibile direttamente dall'Hub anziché essere presa da un comunicato stampa.

La base è Granite 4.1 8B — denso decoder-only, grouped-query attention con 32 teste di query rispetto a 8 teste chiave/valore, SwiGLU, RMSNorm, una finestra di 131.072 token e un vocabolario di 100.352 token. Il checkpoint composto eredita tutto ciò e aggiunge due adattatori LoRA attivati:

• guardian-core — rango 16, alpha 64, collegato solo alle proiezioni di attenzione (k_proj, o_proj, q_proj, v_proj), estratto dalla release della Guardian Library e descritto come in grado di rilevare danni, jailbreaking, volgarità, violenza, contenuti sessuali, bias sociali e comportamenti non etici.

• decisione — rango 64, alpha 128, applicato a tutte e sette le proiezioni, compreso l'MLP (down_proj, gate_proj, up_proj), e addestrato a fare qualcosa di più ristretto e più strano: dato uno stato e una domanda con opzioni etichettate, restituire in un'unica passata in avanti una distribuzione di probabilità calibrata su quelle etichette delle opzioni.

Entrambi sono attivati da token di controllo — <|guardian-core|> e <|decision|> — che il template della chat inserisce per te quando passi un adapter_name argomento. Non scrivi tu stesso i token, e questo dettaglio conta più di quanto sembri: significa che la selezione dell'adattatore è un parametro della richiesta, non un secondo modello da distribuire.

Perché il delta del parametro è così piccolo?

È l'aritmetica a raccontare la storia. Il modello base ha 8.380.551.168 parametri. Il modello composto è di 8.776.400.896. Si tratta di +395,8 milioni, ovvero +4,72%, per due adattatori. Il motivo per cui il numero resta così basso è una decisione di progettazione chiamata normalizzazione della KV-cache: ogni adattatore vede la cache chiave/valore del modello base invece di mantenerne una propria. In una configurazione multi-adattatore convenzionale, ogni adattatore aggiuntivo è un secondo insieme di stati di attenzione, e il conto della memoria cresce con il numero di adattatori tra cui si passa. Qui non è così. L'affermazione di IBM nel post di lancio è che il modello composto occupa «approssimativamente la stessa quantità di VRAM su una GPU che il modello base occuperebbe da solo», e sebbene nessuno al di fuori di IBM l'abbia ancora misurato, il delta dei pesi del 4,72% è coerente con essa — e, a differenza dell'affermazione sulla VRAM, il delta dei pesi è solo un numero in un manifest che si può leggere.

L'adattatore decisionale è la metà interessante

Estrarre una distribuzione di probabilità da un modello linguistico non è una novità; farlo in un'unica passata in avanti con un vocabolario fisso di etichette delle opzioni, e ottenere numeri calibrati abbastanza da poter agire su di essi, è la parte che vale la pena capire. La ricetta di invocazione è documentata nella scheda: un prompt di sistema fisso per il 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. Poi chiedi al server i logprob di esattamente quegli ID dei token etichetta — vLLM lo espone tramite logprob_token_ids — e calcoli l'esponenziale. L'esempio documentato restituisce qualcosa come A: 0.982, B: 0.0035, C: 0.014.

C'è una vera complicazione ingegneristica qui che la versione marketing di questa release salta. vLLM limita logprob_token_ids a 128 id per richiesta. Se la tua domanda decisionale ha più di 128 opzioni ottieni un HTTP 400, e la soluzione è suddividere gli id delle etichette in blocchi di 128, inviare una richiesta per blocco con un prompt identico e concatenare — poiché i logprobs restituiti coprono l'intero vocabolario, il valore di ciascuna etichetta è indipendente da quale blocco lo abbia richiesto, quindi un singolo softmax sull'insieme completo delle etichette è matematicamente identico a una chiamata senza limite. Si tratta di una richiesta extra ogni 128 opzioni. È un dettaglio davvero utile, ed è esattamente il tipo di cosa che esiste solo nel repo.

L'unico numero pubblicato associato a questo adattatore è il Decision Index (JEV), edizione v0.3, sottoinsieme pubblico rapido di 1.068 righe: Complessivo 42.9, Conoscenza 29.1, Lingua 48.9, Recupero 49.8, Strumenti 59.8, Arti 18.0. Consideralo come dichiarato dal fornitore, perché lo è: IBM l'ha eseguito, l'ha pubblicato e nessuna terza parte l'ha riprodotto. Vale anche la pena leggere la forma invece del titolo — 59.8 su Strumenti accanto a 18.0 su Arti è un profilo molto disomogeneo, e la scheda stessa avverte che le probabilità delle opzioni sono "un valore a priori per informare una decisione, non una classificazione certificata" su domini per i quali l'adattatore non è stato addestrato.

La trascrizione vocale è reale, e più limitata di quanto il titolo suggerisca.

Il percorso audio incorpora Granite Speech 5.0 TurboCTC, un encoder CTC conformer non autoregressivo da 470 milioni di parametri, e trascrive l'audio in arrivo prima di inserire la trascrizione nel contesto della chat al posto della parte di contenuto audio. La sua chiamata non modifica la struttura della richiesta: è unainput_audio parte di contenuto in un normale completamento chat, e la trascrizione viene eseguita sullo stesso endpoint di chat e decisioni, quindi non c'è un secondo server vocale da avviare.

Le avvertenze, tutte quante provenienti dalla scheda di IBM stessa e non da un critico: l'encoder è solo in inglese, il suo output è in minuscolo e senza punteggiatura, non c'è alcun controllo in fase di decodifica e — quella che dovrebbe farvi fermare — l'encoder vocale e l'LLM non sono addestrati congiuntamente. Non esiste alcuna proiezione addestrata che li accoppi. Una trascrizione errata può quindi cambiare silenziosamente ciò a cui il modello, o un adattatore, risponde. Se state costruendo qualcosa in cui un errore di trascrizione ha delle conseguenze, quella frase è l'intera revisione di sicurezza.

Ciò che è confermato, ciò che è dichiarato dal fornitore, ciò che nessuno ha verificato

• Confermato dal repo — identità del modello base e numero di layer, i due ranghi degli adapter e i loro moduli target, gli id dei token di controllo, il numero di parametri composti, la finestra di 131.072 token, la licenza Apache-2.0 e le versioni documentate di vLLM e Transformers che la scheda richiede.

• Segnalato dal fornitore, non riprodotto — i punteggi del Decision Index, l'affermazione che Granite Speech 5.0 TurboCTC sia il modello ASR più veloce nella classifica OpenASR, l'affermazione "stessa VRAM del modello base" e l'inciso nel post di lancio secondo cui un modello personalizzato Granite Switch da 3B gioca a Doom a 60–100 decisioni al secondo contro le 10 al secondo riportate per un modello decisionale chiuso. IBM afferma che pubblicherà ulteriori dati "nelle prossime settimane", il che è un'ammissione che le prove attuali sono scarse.

• Nessuno ha verificato — tutto il resto. Non esiste alcuna valutazione indipendente, nessuna presenza su classifiche di terze parti, nessuna API ospitata da IBM e nessuna misurazione pubblicata di latenza o throughput da parte di qualcuno che non sia IBM. Il repository su Hub mostra qualche dozzina di download e una manciata di like: questo modello ha due giorni di vita ed è in gran parte ancora da leggere.

Quanto costa farlo funzionare e dove si inserisce OrcaRouter

Granite Switch 4.1 8B è, al momento, una questione di self-hosting. La scheda elenca HuggingFace Transformers e vLLM come backend, fissa una finestra di supporto piuttosto ristretta (Transformers 5.16–5.17, vLLM 0.26–0.28) e il checkpoint funziona con entrambi senza modifiche al codice. Non c'è alcun endpoint gestito a cui puntare, il che per la maggior parte dei team significa una GPU e un container prima della prima richiesta.

Parlando chiaro sul resto: Granite Switch oggi non è nel catalogo di OrcaRouter, e nemmeno lo è qualsiasi altro modello Granite — quindi se vuoi questo checkpoint, la strada è la release del fornitore stesso e il tuo hardware, non noi. Quello che OrcaRouter ti offre è la decisione che ci sta attorno. La piattaforma instrada oltre 200 modelli dietro un'unica chiave con failover automatico, e applica il prezzo di listino del provider con 0% di ricarico, quindi quando un modello che stai valutando ottiene davvero un endpoint ospitato, confrontarlo con l'incumbent sul tuo traffico è una modifica di configurazione anziché un secondo contratto. Questo conta soprattutto proprio in questa situazione: un checkpoint vecchio di due giorni senza valutazione indipendente è un candidato, non un incumbent, e la cosa poco costosa da fare con un candidato è tenerlo in un confronto affiancato invece di riconfigurare un percorso di produzione attorno a esso.

La questione aperta

Granite Switch 4.1 8B è una scommessa sul fatto che la composizione batta la scala per una specifica classe di lavoro: applicazioni che devono rispondere, decidere e trascrivere, dove eseguire tre modelli significa tre deployment, tre latenze e tre fatture. L'ingegneria per rendere quella scommessa economica — cache KV condivisa, commutazione di adapter per token, token di controllo risolti nel template della chat — è davvero insolita, 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 dell'adattatore decisionale è irregolare, il percorso vocale è solo in inglese e non è addestrato congiuntamente, e il tutto ha due giorni di vita senza alcuna esecuzione indipendente alle spalle. Leggi il manifest di build, esegui tu stesso il comando compose e fai il benchmark dell'adattatore decisionale sul tuo set di etichette prima di credere al 42,9 di chiunque.