Ivan Nikitin, administrerende direktør og medgründer av Fortytwo – intervjuserie

Ivan Nikitin er administrerende direktør og medgründer av Fortytwo, der han utvikler teknologi for sverm-inferens som samler flere KI-modeller, slik at de kan resonnere og vurdere hverandres arbeid. Bakgrunnen hans omfatter spill, samtalebasert KI, generativ KI og interaktive systemer hos Temporal og Sensorium. Han var med på å grunnlegge Temporal i 2011 sammen med Vlad Larin, som nå er medgründer og teknologidirektør i Fortytwo. Der fikk han erfaring med systemer som kombinerer spesialiserte modeller, og med agentpopulasjoner i utvikling.

Fortytwo utvikler KI-infrastruktur som gjør det mulig for modeller å samarbeide under inferens. Fortytwo Engine bruker en Swarm Decoder til å styre en felles resonneringsprosess mens den utfolder seg, med mål om å øke nøyaktigheten og redusere unødvendig generering av tokener i lange oppgaver. Selskapet tilbyr et API for utviklere gjennom Fortytwo Engine og lokal utrulling gjennom Fortytwo Harbor.

Før du var med på å grunnlegge Fortytwo, brukte du flere år på å utvikle produkter innen samtalebasert KI, generativ KI og interaktive systemer hos Sensorium og Temporal. Hvordan formet disse erfaringene synet ditt på begrensningene ved enkeltstående store språkmodeller, og hvordan førte de til slutt til den svermbaserte tilnærmingen som ligger til grunn for Fortytwo?

En stor del av teamet vårt, meg selv inkludert, begynte med KI gjennom spill. Spill har vært arnestedet for personlig databehandling og moderne KI: Det er på grunn av spill at GPU-en finnes, og spilling var den første seriøse testarenaen for forsterkende læring. Spillverdener ga oss et praktisk miljø for å utvikle agenter som kunne lære, tilpasse seg og konkurrere. I Temporal, som jeg var med på å grunnlegge i 2011 sammen med Vlad Larin, som nå er medgründer og teknologidirektør i Fortytwo, begynte vi med intelligens i utvikling: agentpopulasjoner som konkurrerte under seleksjonspress. Vi var interessert i hvordan en populasjon kunne oppnå mer enn en enkelt agent, forutsatt at det fantes en god mekanisme for å identifisere de sterkeste bidragene og bygge videre på dem. Seleksjon og evaluering ble sentrale elementer i måten vi tenkte på intelligens.

Da transformatormodellene kom, utvidet vi virksomheten til samtalebasert KI og utviklet en plattform for KI-styrte figurer som kunne føre åpne, improviserte samtaler med hukommelse og personlighet. Dette var et par år før ChatGPT, og modellene vi jobbet med, hadde kontekstvinduer på bare 512 til 1 024 tokener. Det var helt uaktuelt å forvente at én tidlig språkmodell pålitelig skulle håndtere alle de ulike kravene til denne opplevelsen. Vi måtte bygge en tilpasset arbeidsflyt med spesialiserte modeller, der hver modell hadde et mer avgrenset ansvarsområde, samt logikken som skulle kombinere bidragene deres. Rangering og utvelgelse av svar ble avgjørende for at hele opplevelsen skulle fungere. Det lærte oss hvor mye kapasitet man kunne få ved å kombinere begrensede modeller i et godt utformet system.

Den andre lærdommen handlet om effektivitet. Vi lærte at spesialiserte modeller kunne trenes og kjøres mer effektivt for klart definerte oppgaver, slik at vi kunne få mer ut av begrenset regnekapasitet. Men det var fortsatt utfordrende å skalere inferensen, med bruksgrenser for API-er på den ene siden og kostnadene ved å drifte modeller selv i stor skala på den andre. Uten tilgang til den mest avanserte regnekapasiteten måtte vi tenke nøye gjennom hvordan vi kunne få mer ut av ressursene vi hadde tilgjengelig. Fortytwo samlet disse lærdommene i visjonen om sverm-inferens: Flere modeller, eller flere instanser av samme modell, bidrar til resonneringen samtidig som de vurderer arbeidet til de andre. Resultatet er at fellesskapet er mer nøyaktig enn hvert enkelt medlem.

Fortytwo Engine bruker flere modeller med åpne vekter til å styre én resonneringsprosess og kontrollere hverandre mens svaret genereres. Hvordan skiller denne tilnærmingen seg fra konvensjonelle multiagentsystemer, modellensembler eller det å ganske enkelt kjøre flere modeller og velge det beste svaret etterpå?

Det viktigste skillet er at sverm-inferens er bygget direkte inn i inferensmotoren vi har utviklet. Vi kaller den Swarm Decoder: Flere modelldeltakere former fortløpende ett enkelt resonneringsforløp mens det genereres. Evaluering og styring skjer som en del av denne prosessen, slik at modellene kan påvirke retningen før svaret er ferdig.

Alternativene fungerer annerledes. I ensembler på svarnivå genererer modellene separate svar som deretter rangeres, velges ut eller kombineres. Fortytwos opprinnelige arkitektur, som ble implementert i 2025, rangerte ferdige svar etter vurderinger fra de andre modellene. Dette økte svarenes nøyaktighet betydelig, men førte til økt latenstid og ekstra beregningskostnader. Mange konvensjonelle multiagentsystemer fordeler arbeidet mellom agenter og bruker en orkestrator og meldinger på naturlig språk til å samordne bidragene deres. Slike overleveringer kan kreve flere inferenskall, at konteksten gjentas, og beslutninger om hvilken informasjon som skal sendes fra én agent til en annen. I Swarm Decoder skjer det ingen overleveringer: Deltakerne arbeider med ett og samme resonneringsforløp, og det eneste de utveksler, er en vurdering av hvilken retning som er best.

Swarm Decoder er utformet for å fange opp svake antakelser mens svaret genereres, før det legges betydelig arbeid i å bygge videre på dem. Målet er å redusere feil, tilbakesporing og unødvendig generering. Effektivitetsgevinsten oppstår når kontrollen forhindrer mer arbeid enn den medfører. Derfor fører den heller ikke til økt latenstid: Kjøringen følger en mer direkte vei, slik at Engine fullfører oppgaver raskere enn den samme modellen gjør alene, og med færre tokener totalt, når alle modellene som deltar, regnes med.

Du har trukket fram modelldrift under langvarige oppgaver som et stort problem. Hva er det egentlig som forårsaker denne driften, og hvordan viser den seg i praktiske bruksområder som programvareutvikling, forskning eller autonome KI-agenter?

Drift oppstår når en models kontekst gradvis slutter å handle om oppgaven. Under en lang kjøring fylles konteksten opp med modellens egne svar, verktøyresultater, filinnhold og nye forsøk. Den opprinnelige instruksjonen utgjør en stadig mindre del av det modellen retter oppmerksomheten mot, og modellens tidligere feil blir nå en del av grunnlaget for resonnementet. Dermed forsterkes feilene i stedet for å oppheve hverandre. I tillegg trenes dagens resonneringsmodeller med forsterkende læring for å fullføre oppgaver, og de lærer snarveier som ser ut som fullføring: å hoppe over verktøykallet, erklære oppgaven som løst eller oppsummere i stedet for å kontrollere. Vi kaller det latskap, og de fremste modellene gjør det like ofte som modeller med åpne vekter. Den grunnleggende årsaken er at én enkelt modell ikke har noen ekstern kontroll. Den vurderer sitt eget arbeid, og modeller er dårlige til å reflektere nøyaktig over seg selv.

I programvareutvikling viser det seg ved at agenten retter feilen du beskrev, men bryter begrensningen du oppga i den første meldingen, skriver en test som består uten videre, eller leser den samme filen fire ganger fordi den har mistet oversikten over hva den allerede har lært. I forskning ser man det når en lang kjøring glir fra spørsmålet du stilte, over til spørsmålet det er enklest å svare på, og ender med en generisk oppsummering. For autonome agenter er det den kostbare varianten: avsporinger, gjentatte verktøykall, omveier og en tokenregning på flere ganger det oppgaven krevde.

Vi kan tallfeste det. Vi kjørte Qwen 3.8 27B på 450 DeepSWE-oppgaver – reelt programvareutviklingsarbeid med bruk av verktøy over lange kontekster – én gang alene og én gang gjennom Fortytwo Engine. Alene brukte modellen i gjennomsnitt 16,3 millioner tokens per kjøring, 7,4 milliarder totalt. Gjennom Engine brukte den samme modellen i gjennomsnitt 12,3 millioner tokens per kjøring, 5,6 milliarder totalt – 24,7 % færre – og løste flere av oppgavene: 47,8 % mot 42,2 %. Ingenting ved modellen ble endret. De fire millionene tokens per kjøring som forsvant, skyldtes drift: gjentatt lesing, nye forsøk og omveier som én enkelt modell må ta fordi ingen fanger opp feilsporene mens de oppstår. Svermen fanger dem opp, så modellen slipper å bruke tokens på dem.

Tidligere lot Fortytwo modeller vurdere hverandres ferdige svar, mens dagens arkitektur lar dem påvirke resonneringsprosessen mens den fortsatt pågår. Hva lærte dere av den tidligere tilnærmingen, og hvorfor fungerer styring i sanntid bedre?

Arkitekturen fra 2025 viste at vi kan oppnå egenskaper på nivå med de fremste modellene gjennom horisontal skalering – ved å ta i bruk flere modeller som samarbeider, i stedet for å satse på den største. En sverm av modeller med åpne vekter, som rangerte hverandres fullstendige svar, slo den beste enkeltmodellen i svermen med opptil 17 prosentpoeng. Den var dessuten robust på måter én enkelt modell ikke er: overfor støyende ledetekster, innsatte instruksjoner og et flertall av feilaktige svar.

Det arkitekturen ikke kunne gjøre, var å gripe inn. Rangering av ferdige svar fungerer for ett enkelt spørsmål, men agentkjøringer består av hundrevis av trinn med verktøykall imellom, og de avgjørende feilene skjer tidlig og forsterkes. Når vurderingen skjer til slutt, har hver modell allerede pådratt seg hele tokenkostnaden, og vurderingsmodellen kan bare velge mellom forløp som allerede har utviklet seg i ulike retninger. Det betydde også at kostnaden for svermen økte med antallet modeller, noe som fungerer for ett vanskelig spørsmål, men er feil løsning for en kodeagent.

Styring i sanntid løser begge problemene. Kontinuerlig rangering legger seleksjonspress gjennom hele kjøringen, slik at et feilspor korrigeres der det oppstår, før det sprer seg. Svermen nøyer seg aldri med et slapt forsøk, fordi et slappere forsøk taper mot et grundigere i rangeringen. Derfor gir den samme mekanismen oss nå både høyere nøyaktighet og færre tokens.

I testene deres med Qwen 3.8 27B rapporterer Fortytwo at modellen brukte 24,7 % færre tokens i 450 DeepSWE-kjøringer, samtidig som resultatene ble bedre på seks referansetester. Hva skjer inne i svermen som gjør at den kan forbedre resultatene og samtidig redusere tokenforbruket?

Kontrollen i svermen har en liten, fast kostnad. Kostnaden ved å rette opp feilene den forhindrer, øker med oppgavens lengde, fordi hvert feilspor som ikke korrigeres, koster alt som bygges videre på det. Jo lengre oppgaven er, desto mer er det derfor å spare. DeepSWE ligger i den lange enden av dette spekteret, og det er derfor besparelsen utgjør nesten en fjerdedel av alle tokens.

Når det gjelder nøyaktighet, handler det om ujevn intelligens. Forbedringer i modeller er vanligvis ujevnt fordelt: Man kan få resonnering på doktorgradsnivå på ett område og fullstendig nonsens på et annet, fordi finjustering, forsterkende læring (RL) og annen ettertrening forbedrer en modell på dataene den er trent på, mens forbedringene avtar etter hvert som reelle oppgaver beveger seg bort fra disse dataene. Swarm Decoder endrer ikke modellen. Den forbedrer selve resonneringen på en konsekvent måte, så de seks referansetestene ikke er seks områder vi har optimalisert for, men seks steder der vi har målt det samme. Alt i alt blir modellen smartere og mer oppmerksom, og når jevnbyrdige modeller kontrollerer hvert trinn, virker det som om den legger langt mer arbeid i oppgaven din. Derfor kan vi også prise Engine etter grunnmodellens pris per token: Kunden betaler ikke for et større budsjett, men for en kortere vei til det riktige svaret.

Utviklere av KI blir stadig mer opptatt av inferenskostnadene etter hvert som resonneringsmodeller genererer lengre tokenkjeder. Tror du at det å gjøre selve resonneringsprosessen mer effektiv på sikt kan bli like viktig som å gjøre enkeltmodeller mindre, raskere eller billigere?

Ja, og jeg vil hevde at det allerede er den viktigste faktoren. Når modeller gjøres mindre, raskere og billigere, synker prisen per token. Men ingen kjøper tokens. De kjøper en ferdig utført oppgave, og i agentenes tidsalder har antallet tokens per oppgave økt voldsomt: En resonneringsmodell bruker millioner av tokens på en reell programmeringsoppgave, og en stor andel av dem går med til å gå tilbake og gjøre om på ting. En reduksjon på 25 % i antall tokens per oppgave er nøyaktig like mye verdt som et prisavslag på 25 %, men kommer i tillegg til alle forbedringer i maskinvare, kvantisering og kjerner. Og vi kan bruke dette på alle åpne modeller med tilgjengelige vekter på markedet.

Bransjen har tre virkemidler. Bedre modeller, som krever trening og er kostbart. Billigere tokens, som handler om maskinvare og inferensdrift, og hvor utviklingen går mot utjevning fordi alle har de samme GPU-ene. Og færre tokens per oppgave, som handler om hvordan inferensen kjøres, og som knapt er utforsket. Så langt har skalering betydd større modeller og lengre tankerekker, og begge deler innebærer at én modell skal gjøre alt i én og samme prosess. Vi tror den neste utviklingsretningen er kollektiv: Flere modeller resonnerer sammen, med vurderingsevnen fordelt mellom dem, slik at selve prosessen blir kortere og mer pålitelig. Dette er en annen type skalering enn skalering av antall parametere eller beregning ved inferenstid, og det er denne vi satser på. Vi ser på det som samarbeidende modeller fremfor flere parametere.

Fortytwo Engine er kompatibel med OpenAI API og kjører samtidig modeller med åpne vekter. Hvor viktig var kompatibilitet med eksisterende KI-utviklingsmiljøer, og hvor enkelt kan utviklere flytte en applikasjon fra et konvensjonelt API med én modell til en svermarkitektur?

Kompatibilitet er avgjørende. Agentøkosystemet – kodeagenter, kjøreoppsett, rammeverk og evalueringsverktøy – er bygget rundt OpenAI API-formatet. For utviklere som bruker Fortytwo Engine, er overgangen derfor som å bytte fra én inferensleverandør til en annen: For en kompatibel app, agent, et kjøreoppsett eller en tjeneste kreves det som regel bare én endring i konfigurasjonen: endepunktet, API-nøkkelen og modellvalget.

Det som endres, er atferden, ikke integrasjonen. Forskjellen blir tydelig ved lange agentkjøringer, der tokenforbruk og treffsikkerhet ved første forsøk avgjør kostnaden: Den samme modellen fullfører oppgavene raskere gjennom Engine, bruker færre tokens og løser flere av oppgavene riktig. Jeg anbefaler å behandle dette som ethvert annet modellbytte: Kjør evalueringen du allerede bruker på agenten din, sammenlign antall tokens per oppgave og suksessraten, og behold løsningen som gir best resultat.

Takk for et flott intervju. Lesere som ønsker å utforske sverminferens og hvordan evaluering mellom modeller kan gjøre resonneringen mer effektiv, bør besøke Fortytwo.