IBM Granite 4.2 gjør lokale AI-agenter mer praktiske

IBM Granite 4.2 gjør lokale AI-agenter mer praktiske for utviklere og bedrifter som vil beholde kontrollen selv. Den nye modellfamilien kommer i 3B, 8B og 30B, har åpne modellvekter under Apache 2.0 og er bygget for reasoning, tool calling og arbeidsflyter med flere steg.

IBM retter Granite 4.2 mot et konkret behov: en modell du kan laste ned, kjøre på egen infrastruktur og tilpasse til en avgrenset jobb uten at hvert dokument og hvert API-kall må gjennom en ekstern leverandør. Poenget er kontroll og forutsigbar drift, ikke en påstand om at en liten lokal modell plutselig slår de største skymodellene.

Ars Technica omtaler lanseringen som et svar på den økende interessen for lokale LLM-er. Det treffer godt. Men det mest nyttige er kombinasjonen av lokal drift, justerbar reasoning og agenttrening i størrelser som gjør det mulig å velge modell etter oppgave. Det er langt mer interessant enn enda en tabell med poengsummer.

Hva er IBM Granite 4.2?

Granite 4.2 er en familie med tre dense, decoder-baserte språkmodeller på 3, 8 og 30 milliarder parametere. Alle tre har reasoning, tool calling og 128 000 tokens innebygd kontekst. Modellkortet for 8B beskriver også utvidelse til 512 000 tokens, men det er viktig å skille dette fra den innebygde kontekstlengden på 128 000.

IBM bygger videre på Granite 4.1, som jeg omtalte da 3B-, 8B- og 30B-modellene kom i april. Denne gangen ligger tyngdepunktet på reasoning og agentarbeid. Modellen kan planlegge før den svarer, velge verktøy og håndtere en serie avhengige steg i stedet for bare å produsere en pen tekstblokk.

Alle modellene er publisert under Apache 2.0. Det gir utviklere og virksomheter brede rettigheter til å laste ned, endre og bruke modellene kommersielt. IBMs offisielle Granite 4.2-repositorium samler modellnavn, eksempler, kvantiserte varianter, evalueringsresultater og dokumentasjon.

Hvorfor betyr lokal drift noe?

Lokal drift betyr at modellen kan kjøre på din egen PC, server eller private infrastruktur. Du bestemmer hvor dataene ligger, når modellen oppdateres og hvilke verktøy den får tilgang til. For en bedrift som arbeider med interne dokumenter, kundedata eller kode, kan det være viktigere enn å ha den aller sterkeste modellen på markedet.

Det gir også mer forutsigbare kostnader ved høy bruk. En nedlastet modell sender ikke en ny tokenregning hver gang en agent leser samme kodebase eller kontrollerer hundre dokumenter. Maskinvare, strøm, drift og vedlikehold er selvsagt ikke gratis, men regnestykket blir et annet enn ved ren API-bruk.

Lokalt betyr heller ikke automatisk trygt. En agent med terminaltilgang kan fremdeles slette feil fil, lekke data til et verktøy eller følge en ondsinnet instruksjon i et dokument. Du må fortsatt begrense rettigheter, logge handlinger, kontrollere verktøyene og teste arbeidsflyten. Forskjellen er at du faktisk kan eie flere av disse kontrollpunktene selv. For mange er det hele poenget.

8B og 30B får den tyngste agenttreningen

Alle tre modellene fikk en grunnleggende runde med reinforcement learning for matematikk, vitenskap, koding, reasoning og tool calling. 8B og 30B fikk i tillegg en egen agentisk treningsfase rettet mot programvareutvikling, terminalarbeid og søkebaserte arbeidsflyter, ifølge IBM Researchs lansering 25. august 2026.

Det skillet bør styre modellvalget. 3B kan bruke verktøy og er lettest å få inn på begrenset maskinvare, men IBM har ikke gitt den samme spesialiserte agenttreningen som de to større modellene. Skal modellen navigere en kodebase, kjøre kommandoer, søke etter informasjon og kontrollere resultatet over flere steg, er 8B det naturlige startpunktet.

30B er alternativet for tyngre reasoning og mer krevende kodearbeid, men det er en dense modell. Alle parameterne er aktive under kjøring, så maskinvarekravet blir langt høyere enn modellnavnet alene kanskje antyder. Den modellen hører hjemme på en kraftig arbeidsstasjon eller server. For mange små og mellomstore bedrifter vil 8B være det mer realistiske kompromisset mellom kapasitet, fart og kostnad.

Reasoning kan skrus opp og ned

Granite 4.2 har tre moduser: full reasoning, reasoning av og en low-effort-modus med kortere tenking. Dette lar deg velge mellom mer grundig problemløsning og raskere svar fra samme modell. IBMs modellkort for Granite 4.2 8B beskriver full reasoning som standard, mens direkte modus hopper over reasoning-delen.

Det høres ut som en liten bryter, men er svært nyttig i produksjon. En agent trenger ikke bruke en lang reasoning-runde for å klassifisere en enkel henvendelse eller hente ett felt fra et dokument. Når den skal planlegge en migrering, feilsøke kode eller velge riktig rekkefølge på flere verktøy, kan du gi den mer rom.

Denne kontrollen kan gjøre både svartid og ressursbruk mer forutsigbar. Samtidig må du måle på dine egne oppgaver. Reasoning er ingen garanti for at svaret er riktig, og en lang tankerekke kan bruke mye tid på å gå svært grundig i feil retning. Det er resultatet og kontrollen etterpå som teller.

128K kontekst er bra, men ikke gratis

Alle tre Granite 4.2-modellene støtter 128 000 tokens innebygd. Det er nok til store dokumentpakker, lange samtaler og betydelige deler av en kodebase. 8B-modellkortet oppgir også en utvidet grense på 512 000 tokens, men lang kontekst krever mye minne og gir ikke automatisk bedre svar.

Når konteksten vokser, vokser også KV-cachen som modellen bruker for å holde styr på tidligere tokens. En kvantisert modellfil kan derfor se liten og hyggelig ut på disken, mens faktisk minnebruk blir langt høyere når du setter konteksten til maksimum. Dette er en klassisk felle ved lokale modeller: nedlastingsstørrelsen er ikke det samme som samlet minnebehov under arbeid.

Start med den kontekstlengden oppgaven faktisk trenger. God dokumentuthenting og presis avgrensning slår ofte å dumpe alt inn i prompten. Hvis en agent bare trenger fem relevante kontraktsavsnitt, blir den ikke klokere av å få hele arkivet på fanget. Den blir bare dyrere og tregere på din egen maskin.

Hva kan du faktisk kjøre lokalt?

IBM har gjort modellene tilgjengelige gjennom blant annet Hugging Face, Ollama, LM Studio, vLLM og SGLang. IBM viser også til OpenRouter, som gir en enkel API-vei når du vil prøve modellen uten å sette opp lokal server først. Det finnes dessuten offisielle GGUF-varianter for llama.cpp-baserte verktøy. For 3B viser Hugging Face en Q4_K_M-fil på omtrent 2,24 GB, mens full BF16 ligger rundt 7,32 GB. Kjøretid, kontekst og cache kommer i tillegg.

3B er derfor inngangen for laptop, mindre server eller lette bakgrunnsoppgaver. 8B passer bedre når du vil prøve reasoning og agentarbeid på en kraftig forbruker-GPU. 30B krever betydelig mer minne, særlig med lang kontekst. Kvantisering kan redusere behovet, men kan også påvirke kvaliteten. Test den kvantiseringen du faktisk skal bruke, ikke bare originalmodellen i et modellkort.

Du trenger heller ikke velge enten lokalt eller sky for alt. En praktisk arkitektur kan la en liten lokal modell klassifisere, hente dokumenter og gjøre enkle verktøykall, mens en større modell bare får de vanskelige oppgavene. Det gir bedre kontroll over data og kostnader enn å sende absolutt alt til den dyreste modellen hver gang.

Benchmarks er ikke en innkjøpsbeslutning

IBM publiserer resultater for reasoning, instruksjonsfølging, tool calling, terminalarbeid og agentisk koding. Tallene kan brukes til å finne ut hvilke modeller som fortjener en nærmere test, men de forteller ikke om Granite 4.2 klarer din kodebase, dine dokumenter eller dine sikkerhetskrav.

Leverandøren har dessuten valgt evalueringsoppsettet og sammenligningene selv. Det betyr ikke at resultatene er verdiløse, men de er ikke et nøytralt bevis på at Granite er best. Jeg ville heller laget et lite sett med virkelige oppgaver: korrekt verktøyvalg, strukturert JSON, kildebruk, feilretting og evnen til å stoppe når modellen er usikker.

For en agent er stabilitet viktigere enn ett imponerende toppresultat. Mål hvor ofte den fullfører hele oppgaven, hvor mange menneskelige inngrep den trenger, hvor lang tid den bruker og hvilke feil som slipper gjennom. En lokal 8B-modell som løser en avgrenset jobb stabilt kan være mer verdifull enn en større modell som er fantastisk én gang og kreativ på feil måte den neste.

Hvem bør prøve Granite 4.2?

Granite 4.2 passer best for utviklere, IT-miljøer og bedrifter som har en konkret lokal arbeidsflyt å teste. Det kan være intern dokumentsøk, kodeassistanse, behandling av henvendelser eller en agent som bruker et begrenset sett med verktøy. Har du bare behov for vanlig chat noen ganger i uken, er en skytjeneste enklere.

Start med 8B hvis målet er agentarbeid og maskinvaren tåler det. Bruk 3B når lavt ressursbehov og høy fart er viktigere enn maksimal kapasitet. Vurder 30B først når du har en oppgave som faktisk forsvarer minnebruken. Og uansett størrelse: kjør modellen i en begrenset sandkasse før den får tilgang til ekte filer, terminal og interne systemer.

Min foreløpige dom er derfor ganske enkel. Granite 4.2 ser ut som et seriøst og praktisk tilskudd til lokale AI-oppsett, særlig i 8B-utgaven. Apache 2.0, flere reasoning-moduser og egen agenttrening trekker i riktig retning. Men IBM må bevise verdien i ekte arbeidsflyter, ikke bare på egne grafer. Last ned riktig størrelse, gi den en avgrenset jobb og mål om den faktisk leverer.

Ofte stilte spørsmål