IBM beskriver hvordan den bygde de åpne Granite 4.2-resonneringsmodellene

Hva skjedde

IBMs Granite-team publiserte en teknisk beretning om Granite 4.2, en ny familie av tette, dekoder-bare resonneringsspråkmodeller tilgjengelig i 3B, 8B og 30B størrelser under Apache 2.0-lisensen. Modellene støtter tenke- og ikke-tenke-moduser, lavinnsats-resonnement, native tool calling og et kontekstvindu utvidet til 512K tokens under trening. IBM sier at 8B- og 30B-versjonene i tillegg ble opplært til å bruke verktøy, redigere og kjøre kode, betjene terminaler og søke på nettet i sandkassemiljøer.

I en Hugging Face-artikkel publisert 25. august 2026, beskrev IBMs Granite-team Granite 4.2 som den første Granite-familien bygget som tette, dekoder-bare resonneringsmodeller. Familien har tre størrelser: 3B, 8B og 30B parametere. Alle bruker den samme brede arkitekturen, inkludert oppmerksomhet for grupperte søk, roterende posisjonsinnbygging, SwiGLU-forward-lag, RMSNorm og bfloat16-presisjon. Artikkelen sier at modellene ble forhåndstrent fra bunnen av på omtrent 15 billioner tokens gjennom fem faser, med den siste fasen utvidet kontekstvinduet til 512K tokens. Arkitekturtabellen viser en sekvenslengde på 131 072 tokener for modellene, mens treningsstrategien er beskrevet som å utvide konteksten til 512K; kilden forklarer ikke dette skillet i detalj.

Oppskriften etter opplæring er den sentrale endringen IBM beskriver. Overvåket finjustering brukte rundt 7,2 millioner prøver, eller omtrent 100 milliarder tokens, som kombinerte agent- og ikke-agentisk materiale. IBM sier at dataene inkluderte programvareutvikling, verktøykalling, terminalbruk, søk, matematikk, flerspråklig instruksjonsfølging, vitenskap, resonnement og sikkerhetseksempler. Selskapet sier at det normaliserte dataene til et vanlig chat-format, brukte GPT-OSS-120B og Gemma 4 som språkmodelldommere, fjernet eksempler av lav kvalitet eller ugyldige, og brukte heuristisk filtrering og SHA-256-basert deduplisering. For 30B-modellen la IBM til en andre finjusteringsfase som økte andelen agentkodedata samtidig som den beholdt omtrent 16 % avspillingsdata fra den originale blandingen.

Etter finjustering brukte IBM en iscenesatt rørledning for forsterkningslæring. Alle tre modellene fikk grunnleggende forsterkende læring for verifiserbare oppgaver og et siste RLHF-trinn for preferanse og sikkerhet. 8B- og 30B-modellene mottok også agentforsterkende læring i tre stadier: programvareutvikling, terminaldrift og nettsøk. IBM sier at disse stadiene brukte ekte depoter, levende skallmiljøer og nettlesingsverktøy, med belønninger basert på om oppgavene ble fullført. Treningen brukte asynkron GRPO, med separate generasjons- og opplæringsarbeidere, og var avhengig av NeMo-RL og NeMo-Gym. 3B-modellen mottok ikke agent-RL-blokken. Kilden beskriver også kvantiserte utgivelser i FP8, NVFP4, MXFP4 og flere GGUF-formater.

Kildedetaljer: huggingface.co ↗

Hvorfor det betyr noe

Utgivelsen gir uvanlig detaljert innsyn i hvordan en åpent lisensiert modellfamilie kombinerer konvensjonell fortrening med trinnvis forsterkningslæring for verktøybruk. Det gir også utviklere mindre modeller, kvantiserte varianter og OpenAI-kompatible serveringsalternativer som kan gjøre lokale eller selv-hostede resonnementer og agentiske arbeidsflyter mer praktiske. De rapporterte referanseresultatene er imidlertid IBMs egne evalueringer, og kilden etablerer ikke uavhengig replikering, pålitelighet i den virkelige verden eller bred tilgjengelighet utover de beskrevne modellutgivelsene.

Utgivelsen er viktig fordi den gjør treningsprosessen mer inspiserbar enn en typisk modellkunngjøring. IBM gir trinnvise beskrivelser av dataene, belønningssignaler, utrullingsmiljøer og optimaliseringsinnstillinger, inkludert skillet mellom verifiserbare belønninger, dommerbaserte belønninger og agentutfallsbelønninger. Den dokumentasjonen er nyttig for forskere og utviklere som vurderer om verktøybruk bør læres gjennom ordinær instruksjonsinnstilling, forsterkningslæring eller en kombinasjon. Det gjør det også klart at de tre modellstørrelsene ikke bare er skalerte versjoner av hverandre: 8B- og 30B-versjonene får ekstra opplæring beregnet på å lære bort handlinger i miljøer, mens 3B-versjonen følger en kortere vei.

Apache 2.0-lisensen og utgivelsen av kvantiserte varianter kan utvide de praktiske alternativene for organisasjoner som ønsker å kjøre modeller under sin egen infrastruktur. Artikkelen beskriver støtte for Transformers, vLLM og SGLang, et OpenAI-kompatibelt endepunkt, og integrasjonsinstruksjoner for OpenCode, Pi og OpenHands. Disse funksjonene kan redusere tilpasningsarbeidet for team som allerede bruker kompatible server- og agentrammer. De viser ikke i seg selv at modellene kan kjøre økonomisk på vanlig forbrukermaskinvare. Kilden identifiserer storskala opplæring på en NVIDIA GB200 NVL72-klynge hostet av CoreWeave og gir omfattende distribuert opplæringsdetaljer, men den gir ikke komplette slutningskostnadssammenligninger eller maskinvarekrav for hver kvantisert modell.

IBMs rapporterte resultater tyder på at kapasiteten øker med modellstørrelsen, spesielt på de oppførte resonnementene, langkontekst- og agentkodingsevalueringene. Kilden rapporterer for eksempel SWE-Bench Verified-score på 47,67 for 8B og 57,00 for 30B, RULER 128K-score på 71,41 og 81,38, og AIME25-score på 86,67 og 89,17. Disse tallene er nyttige som en oversikt over selskapets evalueringspåstander, men de er ikke uavhengige bevis. Artikkelen beskriver ikke en tredjepartsrevisjon, konfidensintervaller, forurensningsanalyse, sammenlignende testing mot gjeldende alternativer eller driftsfeilmodusene som oppstår i miljøene. Den fastslår heller ikke hvordan modellene oppfører seg når verktøy returnerer villedende informasjon eller når oppgaver har sikkerhetsmessige konsekvenser.

Hva du skal se neste

Nøkkelspørsmålene er om Granite 4.2s rapporterte evner holder stand i uavhengig testing, hvor mye ytelse som går tapt i FP8-, FP4- og GGUF-variantene, og hvor pålitelig 8B- og 30B-modellene fungerer i mindre kontrollerte miljøer. Brukere bør også undersøke lisensierings- og distribusjonsdetaljer, maskinvarekrav, sikkerhet for verktøysamtaler og grensene for modellenes langkontekst og agentytelse før de behandler referansepoeng som produksjonsbevis.

Uavhengige evalueringer bør være første oppfølging. Anmeldere må reprodusere de oppførte benchmarkene der det er mulig, sammenligne modellene med systemer av samme størrelse, inspisere evalueringsspørsmålene og finne ut om treningsdataene overlapper med testsett. Agentiske resultater fortjener spesielt nøye gransking fordi suksessratene kan avhenge sterkt av selen, valg av lager, skjulte tester, nettleserverktøy og oppgavegrenser. IBMs kilde rapporterer miljøene og noen konfigurasjonsdetaljer, men den gir ikke nok informasjon her til å fastslå hvor representative de er for produksjonsarbeid.

Implementeringsbegrensninger er en annen viktig ukjent. Kilden sier at Granite 4.2 kan betjenes gjennom OpenAI-kompatibel infrastruktur og tilbyr flere kvantiseringsformater, men den oppgir ikke minnekrav, gjennomstrømning, latens, energibruk eller kvalitetsforringelse for hver variant. 512K kontekstpåstanden trenger også praktisk testing: lang kontekstkapasitet er ikke det samme som pålitelig gjenfinning eller resonnement over hver del av en veldig lang input. Utviklere bør måle ytelse på sine egne arbeidsbelastninger og verifisere hvordan tenkekontroller, historieavkorting og verktøy-anrops-parsing oppfører seg i den valgte serveringsstakken.

Spørsmål om sikkerhet og styring forblir også åpne. IBM sier at det siste RLHF-stadiet inkluderer preferanseoptimalisering, motstand mot jailbreak, passende avslag og en straff for altfor detaljerte resonnementer. Artikkelen gir ikke detaljerte sikkerhetsresultater, avslag-feilrater, personvernanalyse, sikkerhetstesting eller bevis om atferd utenfor treningsmiljøene. Den sier heller ikke om tankekjedeinnhold alltid eksponeres, filtreres eller håndteres forskjellig på tvers av grensesnitt. Før du bruker Granite 4.2 i følgeapplikasjoner, vil organisasjoner trenge sin egen testing av verktøytillatelser, datahåndtering, umiddelbar injeksjon, reviderbarhet og menneskelig gjennomgang. Den umiddelbare betydningen av utgivelsen er derfor både modellene i seg selv og den mer transparente redegjørelsen for ingeniørvalgene bak dem; omfanget av deres virkelige fordel gjenstår å fastslå.

Relaterte guider og quizer