IBMs Granite 4.2-modeller lär sig att tänka och agera i miljöer

IBM har släppt Granite 4.2, sin första familj av täta, enbart avkodningsbaserade resonemangsspråkmodeller, i tre storlekar: 3B, 8B och 30B parametrar. Den tillkännagavs den 25 augusti 2026 med vikter publicerade under Apache 2.0-licensen, och lanseringen ger varje Granite-modell ett växlande tänkarläge samt låter de två större storlekarna genomgå förstärkningsinlärning i riktiga mjukvaruutvecklings-, terminal- och webbsökningsmiljöer.

I en teknisk genomgång av byggprocessen beskriver Granite-teamet på IBM en pipeline som börjar med förträning från grunden på ungefär 15 biljoner token, med ett femfasigt schema som utökar kontextfönstret till 512K token. Därefter följer övervakad finjustering på cirka 7,2 miljoner exempel av kedja‑av‑tanke, resonemang och agent‑bana‑data. Lanseringens huvudfokus är dock vad som kommer efter: en flerstegs‑förstärkningsinlärningspipeline där varje steg är ett separat träningskörning som riktar in sig på en förmåga, med varmstart från föregående stegs kontrollpunkt.

Alla tre storlekar kör grundläggande RL på verifierbara belöningar — matematikproblem med kontrollerbara svar, kod som bedöms av dolda enhetstester, uppgifter som följer instruktioner med formatkontroller — samt korta ”boost‑steg” för specifika färdigheter. Endast 8B‑ och 30B‑modellerna fortsätter in i det agentiska blocket: tre steg där modellen agerar i en levande miljö och belönas baserat på om uppgiften faktiskt löstes. I mjukvaruutvecklingssteget, drivet av OpenHands‑ramverket, redigerar modellen riktiga kodarkiv och klarar endast om den dolda testsviten passerar. Terminalsteget placerar den i ett levande skal med upp till 64 miljöomgångar per körning. Sökningssteget får den att besvara flerstegs‑frågor via levande webbsökningar, bedömda av en LLM‑domare.

Varje modell avslutas sedan med RLHF för preferens och säkerhet, vilket också tillämpar ett straff på resonemangslängden för att motverka de utförliga kedjor som tidigare steg kan producera.

Hur växlande tänkande ser ut i praktiken

Varje Granite 4.2-modell visar tre driftsätt via sin chattmall. Tänkarläget, som är standard, genererar en fullständig kedja av tankar inom dedikerade taggar innan det slutgiltiga svaret. Icke‑tänkarläget svarar direkt. En låg‑insats‑inställning ligger mellan de två och använder en kort resonemangsbudget för enkla frågor. I flerstegs‑konversationer tas tidigare turers tänkande bort som standard för att spara kontext.

Inbyggt verktygsanrop är integrerat i samma mall: modellen resonerar om vilket verktyg som ska anropas och varför innan den avger anropet, i OpenAI:s funktionsanropsformat, så den kan kopplas in i agentiska ramverk som körs via vLLM eller SGLang utan extra adaptrar. Enligt Granite 4.2-modellsamlingen är alla tre vikter offentligt nedladdningsbara, och 30B-modellkortet bekräftar att flaggskeppet eftertränades från Granite 4.1 30B‑basen. Modellerna har testats på 12 språk, inklusive engelska, tyska, japanska, arabiska, koreanska och kinesiska.

Siffrorna IBM rapporterar

IBM utvärderade familjen inom agentisk kodning, generell verktygsanvändning, resonemang, chatt och långt kontext, med ett ramverk byggt på NeMo Evaluator SDK. Nedanstående poäng är företagets egna rapporterade siffror.

• SWE-Bench Verifierad: 57.00 (30B), 47.67 (8B)
• Terminal-Bench 2.1: 29.24 (30B), 20.56 (8B)
• AIME25 matematik: 89.17 (30B), 86.67 (8B), 78.33 (3B)
• GPQA vetenskap: 66.41 (30B), 64.14 (8B), 54.80 (3B)
• RULER långt kontext vid 128K: 81.38 (30B), 71.41 (8B), 55.30 (3B)

Mönstret stämmer överens med träningsdesignen. Poängen ökar konsekvent med storlek inom matematik, vetenskap och kodresonemang, och de agentiska kodningsbenchmarkarna som är beroende av 8B‑ och 30B‑modellernas exklusiva agentiska RL‑block visar den största skillnaden mellan storlekarna. 3B‑modellen, som inte kör någon av miljöstegen, rapporteras inte alls i SWE‑Bench‑ eller Terminal‑Bench‑sviterna.

Träna agenter utan ett värdenätverk

RL‑mekaniken förtjänar en närmare granskning eftersom den är där majoriteten av lanseringens ingenjörsarbete ligger. Varje steg tränas med asynkron GRPO, en grupprelativ policyoptimeringsmetod som betygsätter varje svar mot medelbelöningen för de andra proverna som dras för samma prompt, vilket eliminerar det separata värdenätverket som många RL‑pipelines kräver. Generering och träning körs på separata GPU‑pooler som aldrig blockerar varandra: arbetare fortsätter att sampla trajektorier till en gemensam buffert, och tränaren strömmar uppdaterade vikter tillbaka mitt i en körning. En skyddsmekanism hindrar generatorer från att drifta mer än en uppdatering bakom, och trunkerad viktighets‑sampling begränsar effekten av föråldrade token.

Miljöerna ansluts via NeMo-Gym, som presenterar verifierare, verktyg och sandlådor bakom ett enhetligt gränssnitt, medan NeMo-RL driver träningsloopen på Megatron-Core med vLLM‑generering. Den praktiska konsekvensen är att en regelbaserad matematikkontroll och en fullständig kodarkiv‑sandlåda ser identiska ut för träningsloopen, vilket möjliggör att den stegvisa läroplanen kan köras. IBM tränade modellerna på ett NVIDIA GB200 NVL72‑kluster hostat av CoreWeave, med en 72‑GPU NVLink‑domän och 400 Gb/s InfiniBand‑fabric.

IBM levererade också kvantiserade varianter av familjen: FP8 utan kalibrering, NVFP4 och MXFP4 kalibrerade på 2 000 prover från SFT‑datasetet, samt fjorton GGUF‑format via llama.cpp för minnesreducerad distribution.

Var Granite 4.2 passar in i IBMs sortiment

Lanseringen fortsätter en medveten arbetsfördelning i IBMs öppna modellstrategi. Tidigare Granite‑generationer positionerades som starka instruktions‑följande assistenter; företaget presenterade Granite Speech 5.0, som släpptes samma dag, i ett separat tillkännagivande med fokus på transkriptionshastighet. Granite 4.2 är språkmodellseriens tur för explicit resonemang, och den levereras med hela träningsreceptet, data‑blandningsförhållandena och hyperparametrar per steg publicerade tillsammans med vikterna.

Alla tre modeller, de kvantiserade varianterna, GitHub‑arkivet och dokumentationen är tillgängliga under Apache 2.0, där 30B‑flaggskeppet är dimensionerat för en enda multi‑GPU‑servicenod och 3B är avsedd för lättare distributioner där växlings‑tänkesläget fortfarande gäller.