Granite 4.2 di IBM: denso per intero, il contesto da 512K si ferma a 128K nel motore

Il 25 agosto 2026, alle 17:17 UTC, IBM ha pubblicato su Hugging Face i pesi di Granite 4.2: tre modelli — 3, 8 e 30 miliardi di parametri — pensati per il lavoro d’agente in azienda, licenza Apache 2.0, nessun esperto nascosto nell’architettura. È la generazione che porta il ragionamento nativo nella famiglia Granite, e la prima a dichiarare un contesto esteso fino a 512.000 token. Abbiamo scaricato le schede, i file di configurazione e il repository GitHub che le accompagna per capire quanto di quella dichiarazione arriva davvero al motore che serve il modello. Verifichiamo qui, alla data del 29 agosto.

I fatti, in ordine

Pubblicazione: spazio dei nomi riservato il 7 agosto 2026; pesi e scheda caricati il 25 agosto alle 17:17:32 UTC (30B) e 17:17:24 UTC (8B) — l’orario che coincide con la data di rilascio dichiarata dalla scheda stessa. Organizzazione ibm-granite: nessuna spunta di verifica (isVerified: false), ma piano enterprise su Hugging Face, 232 modelli già pubblicati e 5.254 follower — una storia editoriale lunga, non un account nuovo.
Licenza: Apache 2.0, dichiarata nei metadati (license: apache-2.0) e confermata dal file LICENSE nel repository GitHub del progetto — 201 righe, testo integrale della licenza. Nessun secondo file di restrizioni trovato, né nella scheda né nel repository: niente soglia di fatturato, niente esclusione di settori, niente obbligo di trattativa separata per la redistribuzione commerciale.
Adozione, oggi: 1.791 download e 86 like per il 30B, 2.604 download e 50 like per l’8B — numeri di un rilascio di quattro giorni.
Architettura: GraniteForCausalLM, decoder-only, densa — nessun campo di instradamento a esperti nella configurazione di nessuna delle tre taglie.
Contesto: max_position_embeddings: 131072 nel file di configurazione di tutte e tre le taglie — 128K, non oltre. La scheda, nella stessa pagina, dichiara altro.

Denso per intero: quanto pesa, davvero

Gli ultimi modelli verificati in questa rubrica erano quasi tutti a esperti: una minoranza di parametri attivi per token, il resto comunque da tenere in memoria per servire richieste diverse nello stesso lotto. Granite 4.2 non ha questo problema, e non ha il suo vantaggio: GraniteForCausalLM è un transformer denso, ogni parametro lavora su ogni token. Il file model.safetensors.index.json del 30B dichiara 58.553.540.608 byte di pesi in bf16; diviso per due byte a parametro — quanto occupa ciascun numero in questo formato — il conto, nostro, dà 29,28 miliardi di parametri, coerente con l’etichetta 30B del nome commerciale. Per l’8B, sugli stessi 16.761.102.336 byte dichiarati dall’indice, il calcolo dà 8,38 miliardi.

Per l’uso in locale IBM pubblica anche versioni quantizzate: FP8, NVFP4, MXFP4 e una serie completa di GGUF, da Q8_0 a Q2_K. Verificato via intestazione HTTP: il 30B in Q4_K_M pesa 17.721.455.328 byte — 16,5 GiB, sta su una scheda da 24 GB con margine per un contesto moderato; in Q8_0, quasi senza perdita, arriva a 31.111.705.312 byte, 29,0 GiB. L’8B in Q4_K_M pesa 5.347.917.952 byte, 5,0 GiB: gira su un portatile con una scheda dedicata di fascia media. Un avvertimento della scheda riguarda chi pensa di combinare quantizzazione e contesto lungo: le versioni NVFP4 e MXFP4 sono calibrate con GPTQ su duemila campioni, e «Max context length is 2K during calibration.», la lunghezza massima del contesto durante la calibrazione è 2K — da tenere presente prima di fidarsi di questi formati oltre poche migliaia di token.

Il contesto che la scheda promette, e quello che il config consegna

Qui la scheda si contraddice da sola. La tabella in cima a ogni pagina dichiara: «Natively Supports 128K (Long-context extension to 512K)», supporta nativamente 128K, estensione a contesto lungo fino a 512K. Il blog tecnico spiega da dove viene il numero: il pre-addestramento segue cinque fasi, e la quinta, dichiara IBM, «extending the context window to 512K tokens», estendendo la finestra di contesto a 512K token — un fatto della base di addestramento, non necessariamente del checkpoint pubblicato.

Il file di configurazione di tutte e tre le taglie — quello che un motore di inferenza legge davvero — dichiara max_position_embeddings: 131072 e rope_scaling: null: 128K, senza estensione configurata. I comandi di avvio riportati nella stessa pagina lo confermano: vllm serve usa --max-model-len 131072, SGLang usa --context-length 131072. Nessuno arriva a 512K. Un indizio, solo sul 30B, tradisce un copia-incolla rimasto indietro: il config dichiara rope_theta: 50000000, cinque volte il valore di 3B e 8B (10.000.000, verificato negli stessi file) — un parametro che si alza proprio per sostenere contesti più lunghi — mentre la prosa della scheda, identica sulle tre pagine, continua a scrivere θ = 10,000,000 anche per il 30B.

Quanto costerebbe servire 512K token non è un dettaglio minore: la cache di attenzione di un modello denso cresce con ogni token trattenuto. Per il 30B — 64 strati e 8 teste chiave-valore letti nel config, 128 dimensioni per testa ricavate dividendo la dimensione nascosta per il numero di teste, bf16 — il conto, nostro, dà 256 KiB di cache per token. Ai 131.072 token che il config consegna, sono già 32 GiB per una singola richiesta; ai 524.288 dichiarati in addestramento servirebbero 128 GiB per una sola sessione, prima ancora dei pesi. Probabilmente anche per questo il checkpoint pubblicato si ferma a un quarto di quel numero.

Come si comporta da agente

Solo l’8B e il 30B ricevono l’addestramento per l’uso di strumenti: il blog è esplicito — «The 3B model runs none of these.», il modello da 3B non esegue nessuna di queste fasi — riferendosi a tre ambienti di rinforzo agentico: un agente che legge codice ed esegue test in ambiente isolato, uno che pianifica ed esegue comandi shell, uno che interroga il web su più passaggi. Sono capacità addestrate, non descritte soltanto: il modello impara a proporre l’esecuzione.

Quanto lunga possa essere una di quelle traiettorie è scritto in due posti, con due numeri diversi. La scheda dice che i rollout «can span up to 200 tool-calling turns», possono arrivare a 200 turni di chiamata a strumenti. Il blog tecnico pubblica invece la tabella stadio per stadio della catena da 30B: per lo stadio Terminal indica 64 turni di rollout, e il massimo dell’intera tabella è 128, allo stadio SWE 2. Lo stesso blog precisa che quella colonna «counts the environment interactions GRPO itself sees per rollout», conta le interazioni con l’ambiente che l’algoritmo di rinforzo vede a ogni rollout — che non è necessariamente la stessa grandezza. Nessuna delle due cifre l’abbiamo verificata in esecuzione. Quanto in là il modello possa spingersi da solo resta comunque una decisione di chi lo distribuisce.

Quello che non sappiamo

Non abbiamo eseguito il modello sui nostri strumenti né misurato i benchmark: le tabelle di valutazione sono calcolate da IBM, con l’harness NeMo Evaluator scelto da IBM. Il repository GitHub del progetto contiene una cartella disclosures, pensata per pubblicare metadati strutturati allineati al modulo di documentazione del GP AI Code of Practice europeo, e richiama il primo posto di IBM nel Foundation Model Transparency Index di Stanford — un piazzamento che risulta confermato da fonti indipendenti. Ma la cartella, oggi, contiene solo un avviso: «currently being prepared and will be published in this repository soon», attualmente in preparazione, saranno pubblicati in questo repository a breve. Non esistono ancora. Non abbiamo verificato in modo indipendente il punteggio Stanford, né la cifra di 15.000 miliardi di token di pre-addestramento che il blog dichiara.

Come lo risolviamo noi

Per un modello come questo, con licenza pulita e comportamento d’agente addestrato, la domanda che conta non è se installarlo, ma con quali permessi: quale shell può davvero toccare, quali repository può davvero modificare, quali richieste web può davvero fare, prima che un operatore lo autorizzi caso per caso. È lo stesso principio con cui teniamo insieme modelli, dati, contratti e decisioni in un modello operativo unico, dove agenti AI eseguono con un operatore al comando — mai da soli sul perimetro che conta. On-premise su macchine autonome che non richiedono integrazione profonda nella rete del cliente, oppure cloud dedicato con data center in Italia: sempre con gestione condivisa, per grandi imprese, difesa e pubblica amministrazione.

Vedi il servizio · Parlane con un tecnico

Dovete decidere quanta autonomia dare a un agente prima che tocchi un repository o una shell di produzione? Mezz’ora con un nostro esperto, senza costi: portiamo la mappa dei permessi che la scheda non scrive.