IBMs Granite 4.2-modeller lærer at tænke og handle i miljøer

IBM har frigivet Granite 4.2, deres første familie af tætte, kun‑dekoder‑baserede resonnerings‑sprogsmodeller, i tre størrelser: 3B, 8B, og 30B parametre. Annonceret den 25. august 2026 med vægte udgivet under Apache 2.0‑licensen, giver udgivelsen hver Granite‑model en skiftbar tænknings‑tilstand og sender de to større størrelser gennem forstærkningslæring i ægte software‑udviklings‑, terminal‑ og web‑søgningsmiljøer.

I en teknisk gennemgang af opbygningen beskriver Granite‑teamet hos IBM en pipeline, der starter med fortræning fra bunden på cirka 15 billioner tokens, med en fem‑fase‑plan der udvider kontekstvinduet til 512K tokens. Supervisioneret finjustering følger på omkring 7,2 millioner prøver af kæde‑af‑tanke, resonnering og agent‑trajectory‑data. Udgivelsens kerne er dog, hvad der kommer efter: en fler‑trins forstærknings‑lærings‑pipeline, hvor hver fase er en separat træningskørsel, der sigter mod én funktion, varm‑startet fra den foregående fasens checkpoint.

Alle tre størrelser kører grundlæggende RL på verificerbare belønninger — matematikopgaver med kontrollerbare svar, kode bedømt af skjulte enhedstests, instruktion‑følgende opgaver med formatkontrol — plus korte “booster”‑faser for specifikke færdigheder. Kun 8B‑ og 30B‑modellerne fortsætter ind i den agent‑blok: tre faser, hvor modellen handler i et levende miljø og belønnes ud fra om opgaven faktisk blev løst. I software‑udviklingsfasen, drevet af OpenHands‑rammen, redigerer modellen rigtige repositories og bestå kun hvis den skjulte test‑suite bestås. Terminal‑fasen placerer den i en levende shell med op til 64 miljø‑turns per rollout. Søge‑fasen får den til at besvare multi‑hop‑spørgsmål gennem levende web‑søge‑kald, bedømt af en LLM‑dommer.

Hver model afslutter derefter med RLHF for præference og sikkerhed, hvilket også anvender en straf på resonneringslængde for at afskrække de omstændelige kæder, som tidligere faser kan producere.

Hvordan skiftbar tænkning ser ud i praksis

Hver Granite 4.2‑model eksponerer tre drifts‑tilstande gennem sin chat‑skabelon. Tænkningstilstand, som er standard, genererer en fuld tankekæde inden for dedikerede tags før det endelige svar. Ikke‑tænkningstilstand svarer direkte. En lav‑indsats‑indstilling ligger mellem de to og bruger et kort resonneringsbudget på lette spørgsmål. I samtaler med flere omgange fjernes tidligere runders tænkning som standard for at spare på konteksten.

Indbygget værktøjskald er integreret i den samme skabelon: modellen resonnerer om, hvilket værktøj der skal kaldes og hvorfor, før den udsender kaldet, i OpenAI‑funktion‑kald‑formatet, så den kan kobles ind i agent‑rammer, der leveres gennem vLLM eller SGLang uden ekstra adaptere. Ifølge Granite 4.2‑modelsamlingen er alle tre vægte offentligt downloadbare, og 30B‑modelkortet bekræfter, at flagsskibet blev efter‑trænet fra Granite 4.1 30B‑basen. Modellerne er testet på tværs af 12 sprog, herunder engelsk, tysk, japansk, arabisk, koreansk og kinesisk.

Tallene IBM rapporterer

IBM evaluerede familien inden for agent‑kodning, generel værktøjsbrug, resonnering, chat og lang kontekst ved hjælp af en ramme bygget på NeMo Evaluator SDK. Tallene nedenfor er virksomhedens egne rapporterede tal.

• SWE-Bench Verificeret: 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 videnskab: 66.41 (30B), 64.14 (8B), 54.80 (3B)
• RULER lang kontekst ved 128K: 81.38 (30B), 71.41 (8B), 55.30 (3B)

Mønstret svarer til træningsdesignet. Resultaterne stiger konsekvent med størrelsen inden for matematik, videnskab og kode‑resonnering, og de agent‑kodnings‑benchmark, der afhænger af 8B‑ og 30B‑modellernes eksklusive agent‑RL‑blok, viser den største forskel mellem størrelserne. 3B‑modellen, som ikke kører nogen af miljø‑faserne, er overhovedet ikke rapporteret på SWE-Bench‑ eller Terminal-Bench‑suite’erne.

Træning af agenter uden et værdinetværk

RL‑maskineriet er værd at kigge nærmere på, fordi det er hvor størstedelen af udgivelsens ingeniørarbejde ligger. Hver fase trænes med asynkron GRPO, en gruppe‑relativ policy‑optimeringsmetode, der scorer hvert svar mod den gennemsnitlige belønning fra de andre prøver trukket for samme prompt, hvilket eliminerer det separate værdinetværk, som mange RL‑pipelines kræver. Generering og træning kører på separate GPU‑puljer, der aldrig blokerer hinanden: arbejdere fortsætter med at sample trajektorier ind i en delt buffer, og træneren streamer opdaterede vægte tilbage midt i rollout. En sikkerhedsgrænse forhindrer generatorer i at glide mere end én opdatering bagud, og afkortet importance‑sampling begrænser virkningen af forældede tokens.

Miljøerne tilsluttes via NeMo‑Gym, som præsenterer verifikatorer, værktøjer og sandkasser bag en ensartet grænseflade, mens NeMo‑RL driver træningsløkken på Megatron‑Core med vLLM‑generering. Den praktiske konsekvens er, at en regel‑baseret matematik‑checker og en fuld repository‑sandkasse ser identisk ud for træningsløkken, hvilket gør den staged curriculum gennemførlig. IBM trænede modellerne på en NVIDIA GB200 NVL72‑klynge hostet af CoreWeave, med et 72‑GPU NVLink‑domæne og 400 Gb/s InfiniBand‑fabric.

IBM leverede også kvantiserede varianter af familien: FP8 uden kalibrering, NVFP4 og MXFP4 kalibreret på 2.000 prøver fra SFT‑datasættet, samt fjorten GGUF‑formater via llama.cpp til reduceret hukommelses‑deployment.

Hvor Granite 4.2 passer ind i IBMs sortiment

Udgivelsen fortsætter en bevidst arbejdsfordeling i IBMs åbne modelstrategi. Tidligere Granite‑generationer blev positioneret som stærke instruktion‑følgende assistenter; virksomheden lancerede Granite Speech 5.0 samme dag, i en separat meddelelse med fokus på transkriptionshastighed. Granite 4.2 er sprog‑model‑linjens tur til eksplicit resonnering, og den kommer med den fulde trænings‑opskrift, data‑blandings‑proportioner og per‑fase hyperparametre udgivet sammen med vægtene.

Alle tre modeller, de kvantiserede varianter, GitHub‑repositoryet og dokumentationen er tilgængelige under Apache 2.0, hvor 30B‑flagsskibet er dimensioneret til en enkelt multi‑GPU‑servicenode, og 3B er rettet mod lettere deployment‑scenarier, hvor den skiftbare tænknings‑funktion stadig gælder.