IBM ha rilasciato Granite 4.2, una nuova famiglia di modelli linguistici dense e decoder-only orientata esplicitamente al reasoning, disponibile nelle versioni da 3, 8 e 30 miliardi di parametri. I modelli sono distribuiti con licenza Apache 2.0 e condividono la stessa impostazione architetturale e una pipeline di addestramento articolata in pre-training, supervised fine-tuning e reinforcement learning multistadio. Ogni modello può operare in modalità thinking, nella quale produce un processo di ragionamento prima della risposta finale, in modalità non-thinking per fornire direttamente il risultato oppure attraverso una modalità low-effort, pensata per utilizzare un budget di ragionamento ridotto nelle richieste meno complesse. Nelle conversazioni multi-turn, il ragionamento prodotto nei turni precedenti viene rimosso automaticamente dalla cronologia utilizzata dal modello per limitare il consumo della finestra di contesto.
Granite 4.2 utilizza un’architettura Transformer dense con Grouped Query Attention, Rotary Position Embedding, MLP con attivazione SwiGLU, RMSNorm, embedding separati per input e output e precisione bfloat16. La versione 3B utilizza 40 layer e una dimensione degli embedding pari a 2.560, mentre il modello 8B mantiene 40 layer portando gli embedding a 4.096; il modello 30B arriva invece a 64 layer. I modelli sono stati pre-addestrati da zero su circa 15 mila miliardi di token attraverso cinque fasi successive: le prime dedicate al pre-training generale, quelle intermedie a una progressiva selezione di dati di qualità superiore e l’ultima all’estensione delle capacità long-context fino a una finestra di 512.000 token.
Dopo il pre-training, IBM ha applicato un supervised fine-tuning su circa 7,2 milioni di esempi, equivalenti a circa 100 miliardi di token complessivi, dei quali circa 65 miliardi effettivamente utilizzati per l’ottimizzazione. Il 31,6% del corpus SFT è costituito da dati agentici e il restante 68,4% da dati non agentici. All’interno della componente agentica prevale il software engineering, che rappresenta il 69% dei dati, seguito da tool calling, utilizzo del terminale, matematica, ricerca e task di azione. Le traiettorie sono state costruite utilizzando diversi framework e agent harness, tra cui OpenHands, OpenCode, Terminus-2, SWE-agent, OpenResearcher, MiniSWE, OpenSeeker, Gemini CLI, Hermes, Codex e Goose. La componente non agentica comprende invece instruction following, coding, matematica, contenuti multilingua, scienze, reasoning e sicurezza.
Prima dell’addestramento, i dati SFT sono stati normalizzati nel formato OpenAI Chat e sottoposti a più fasi di controllo qualità. IBM ha utilizzato anche GPT-OSS-120B e Gemma 4 come modelli giudici per eliminare esempi di qualità insufficiente, informazioni inventate, interazioni con strumenti non valide e chiamate a funzioni non presenti nella relativa definizione degli strumenti. Il dataset è stato inoltre sottoposto a deduplicazione locale e globale mediante hash SHA-256. Per il modello da 30B è stata aggiunta una seconda fase di supervised fine-tuning concentrata sul coding agentico, aumentando il peso dei dati SWE, coding e delle traiettorie degli agenti, pur mantenendo circa il 16% del corpus precedente come replay data.
Il passaggio centrale della pipeline è il reinforcement learning multistadio. Invece di eseguire un singolo ciclo di RL, IBM ha suddiviso l’addestramento in una sequenza di fasi indipendenti, ognuna dedicata a una specifica capacità e inizializzata dal checkpoint prodotto dalla fase precedente. Tutti e tre i modelli affrontano un reinforcement learning fondamentale basato prevalentemente su ricompense verificabili, comprendente matematica, dimostrazione formale, coding competitivo con test nascosti, problemi scientifici, instruction following, output strutturati, tool calling e reasoning. A queste fasi vengono aggiunti brevi “booster” dedicati, tra gli altri aspetti, all’instruction following e al codice.
Le versioni 8B e 30B proseguono poi con un blocco specifico di agentic reinforcement learning, assente nel modello 3B. In questa fase il modello non viene premiato semplicemente per aver generato una risposta corretta, ma deve agire all’interno di ambienti reali, utilizzare strumenti, osservare i risultati delle proprie azioni e continuare fino al completamento effettivo dell’attività. Il curriculum procede attraverso tre ambienti distinti: software engineering, terminale e ricerca sul web. Nel primo caso OpenHands inserisce il modello all’interno di repository software reali isolati in sandbox: Granite deve leggere il codice, modificarne i file, eseguire i test e risolvere il problema, ricevendo la ricompensa soltanto se supera una suite di test nascosti.
Nella fase terminal agent il modello opera invece all’interno di una shell reale attraverso Harbor e Terminus-2. Deve pianificare sequenze di comandi, leggerne l’output, correggere eventuali errori e completare attività operative multi-step, con rollout che possono arrivare fino a 64 interazioni con l’ambiente. La fase search agent è dedicata alla ricerca: il modello deve rispondere a domande complesse e multi-hop utilizzando chiamate reali a strumenti di ricerca web, raccogliendo informazioni attraverso più passaggi e combinandole nella risposta finale. Poiché questo tipo di attività non può sempre essere valutato tramite una verifica deterministica, la correttezza finale viene giudicata da un modello linguistico.
L’intera pipeline utilizza asynchronous GRPO, Group Relative Policy Optimization. Generazione delle traiettorie e aggiornamento del modello vengono eseguiti su pool di GPU separati: i generatori continuano a produrre campioni in un buffer condiviso mentre il trainer esegue gli aggiornamenti e distribuisce progressivamente i nuovi pesi, senza interrompere il processo di generazione. Il sistema limita i generatori a non rimanere indietro di più di un aggiornamento rispetto al trainer e utilizza truncated importance sampling per contenere l’effetto dei token prodotti da versioni leggermente precedenti della policy. I vantaggi vengono calcolati in maniera relativa rispetto alle altre risposte generate per lo stesso prompt, evitando così la necessità di una value network separata.
Gli ambienti di addestramento vengono esposti attraverso NeMo-Gym, che uniforma strumenti, verificatori e sandbox, mentre NeMo-RL gestisce il ciclo di training utilizzando Megatron-Core e vLLM. In questo modo, dal punto di vista della pipeline di reinforcement learning, un semplice verificatore matematico e un repository software completo possono essere trattati attraverso la stessa interfaccia. I modelli sono stati addestrati su infrastruttura NVIDIA GB200 NVL72 ospitata da CoreWeave, con domini NVLink da 72 GPU e rete InfiniBand da 400 Gb/s.
Al termine delle fasi di reinforcement learning, tutti i modelli passano attraverso RLHF per l’allineamento alle preferenze e per la sicurezza. IBM utilizza un generative reward model insieme a segnali specifici dedicati, tra gli altri aspetti, alla resistenza ai jailbreak e alla gestione appropriata dei rifiuti. In questa fase viene applicata anche una penalizzazione della lunghezza del reasoning, per evitare che il modello mantenga catene di ragionamento eccessivamente verbose apprese durante le fasi precedenti.
Granite 4.2 integra inoltre il tool calling direttamente nel chat template. Il modello può ragionare sulla scelta dello strumento da utilizzare e produrre successivamente la relativa chiamata nel formato OpenAI function calling, consentendo l’integrazione con sistemi agentici serviti attraverso vLLM o SGLang senza la necessità di adapter specifici. Le tre versioni sono state valutate in dodici lingue, tra cui inglese, tedesco, giapponese, arabo, coreano e cinese.
Nei risultati comunicati da IBM, Granite 4.2 30B raggiunge 57,00 su SWE-Bench Verified contro 47,67 del modello 8B, mentre su Terminal-Bench 2.1 i valori sono rispettivamente 29,24 e 20,56. Nel benchmark matematico AIME25 il 30B ottiene 89,17, l’8B 86,67 e il 3B 78,33; su GPQA, dedicato a quesiti scientifici avanzati, i risultati sono 66,41, 64,14 e 54,80. Nei test RULER sul long context a 128K token, i tre modelli raggiungono rispettivamente 81,38, 71,41 e 55,30. Il 3B non viene riportato su SWE-Bench e Terminal-Bench perché non attraversa le fasi di reinforcement learning negli ambienti agentici riservate alle due versioni maggiori.
IBM distribuisce anche versioni quantizzate dei modelli, comprese varianti FP8 senza calibrazione, NVFP4 e MXFP4 calibrate utilizzando 2.000 campioni provenienti dal dataset SFT e quattordici formati GGUF destinati all’esecuzione tramite llama.cpp con requisiti di memoria inferiori. I pesi dei tre modelli, le varianti quantizzate, il repository GitHub e la documentazione vengono pubblicati con licenza Apache 2.0. Il modello 30B è dimensionato per l’esecuzione su un singolo nodo di serving multi-GPU, mentre il 3B punta a deployment più leggeri mantenendo comunque le modalità thinking, non-thinking e low-effort e il supporto nativo agli strumenti.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI)