Ivan Nikitin, administrerende direktør og medstifter af Fortytwo – interviewserie

Ivan Nikitin er administrerende direktør og medstifter af Fortytwo, hvor han udvikler teknologi til sværminferens, der samler flere AI-modeller, så de kan ræsonnere og evaluere hinandens arbejde. Hans baggrund spænder over spil, konversationsbaseret AI, generativ AI og interaktive systemer hos Temporal og Sensorium. I 2011 var han med til at grundlægge Temporal sammen med Vlad Larin, der nu er medstifter og teknologidirektør hos Fortytwo. Her opbyggede han erfaring med populationer af agenter i udvikling og systemer, der kombinerer specialiserede modeller.

Fortytwo udvikler AI-infrastruktur, der gør det muligt for modeller at samarbejde under inferens. Virksomhedens Fortytwo Engine bruger en Swarm Decoder til at styre en fælles ræsonneringsproces, efterhånden som den udfolder sig, med det formål at øge præcisionen og reducere unødvendig generering af tokens ved lange opgaver. Virksomheden tilbyder udviklere en API gennem Fortytwo Engine og mulighed for lokal installation gennem Fortytwo Harbor.

Før du var med til at grundlægge Fortytwo, brugte du flere år på at udvikle produkter inden for konversationsbaseret AI, generativ AI og interaktive systemer hos Sensorium og Temporal. Hvordan formede de erfaringer dit syn på, hvor individuelle store sprogmodeller kommer til kort, og førte de i sidste ende til den sværmbaserede tilgang, der ligger til grund for Fortytwo?

En stor del af vores team, inklusive mig selv, kom ind i AI gennem spil. Spil har været en vugge for både personlige computere og moderne AI: Det er på grund af spil, at GPU’en findes, og spil var det første seriøse testområde for forstærkningslæring. Spilverdenen gav os et praktisk miljø til at udvikle agenter, der kunne lære, tilpasse sig og konkurrere. Hos Temporal, som jeg var med til at grundlægge i 2011 sammen med Vlad Larin, der nu er medstifter og teknologidirektør hos Fortytwo, begyndte vi med intelligens i udvikling: populationer af agenter, der konkurrerede under selektionspres. Vi var interesserede i, hvordan en population kunne opnå mere end en enkelt agent, hvis der fandtes en god metode til at identificere og bygge videre på dens stærkeste bidrag. Selektion og evaluering blev centrale elementer i vores måde at tænke på intelligens på.

Da transformermodellerne kom, udvidede vi vores arbejde til konversationsbaseret AI og udviklede en platform med AI-drevne figurer, der kunne føre åbne, uscriptede samtaler med hukommelse og personlighed. Det var et par år før ChatGPT, og de modeller, vi arbejdede med, havde kontekstvinduer på blot 512 til 1.024 tokens. Det var udelukket at forvente, at én tidlig sprogmodel på pålidelig vis kunne håndtere alle de forskellige krav til oplevelsen. Vi måtte udvikle en skræddersyet pipeline af specialiserede modeller, der hver havde et mere afgrænset ansvarsområde, samt den logik, der skulle til for at kombinere deres bidrag. Rangering og udvælgelse af svar blev afgørende for, at hele oplevelsen kunne fungere. Det lærte os, hvor stor en kapacitet man kan skabe ved at kombinere begrænsede modeller i et veldesignet system.

Den anden lære handlede om effektivitet. Vi fandt ud af, at specialiserede modeller kunne trænes og anvendes mere effektivt til velafgrænsede opgaver, så vi kunne opnå mere med begrænsede beregningsressourcer. Det var dog stadig en udfordring at skalere inferensen, både på grund af grænser for API-forbrug og omkostningerne ved selv at hoste modeller i stor skala. Uden adgang til beregningskapacitet i frontlinjen måtte vi nøje overveje, hvordan vi kunne få mere ud af de tilgængelige ressourcer. Fortytwo samlede disse erfaringer i visionen om sværminferens: Flere modeller eller flere instanser af den samme model bidrager til ræsonneringen, samtidig med at de vurderer deres kollegers arbejde. Resultatet er, at kollektivet er mere præcist end hvert enkelt af dets medlemmer.

Fortytwo Engine bruger flere modeller med åbne vægte til at styre én ræsonneringsproces og kontrollere hinanden, mens svaret bliver genereret. Hvordan adskiller denne tilgang sig fra traditionelle multiagentsystemer, modelensembler eller ganske enkelt at køre flere modeller og derefter vælge det bedste svar?

Den afgørende forskel er, at sværminferens er indbygget direkte i den inferensmotor, vi har udviklet. Vi kalder den Swarm Decoder: Flere modeldeltagere former løbende én ræsonneringsbane, efterhånden som den genereres. Evaluering og styring foregår som en del af processen, så modellerne kan påvirke dens retning, før et svar er færdigt.

Alternativerne fungerer på en anden måde. I et ensemble, der arbejder på svarniveau, genererer modellerne separate svar, som derefter rangeres, udvælges eller kombineres. Fortytwos oprindelige arkitektur, der blev implementeret i 2025, brugte kollegial rangering af færdige svar. Det øgede svarenes præcision betydeligt, men medførte ekstra latenstid og beregningsomkostninger. Mange traditionelle multiagentsystemer fordeler arbejdet mellem agenter og bruger en orkestrator og beskeder i naturligt sprog til at styre deres bidrag. Sådanne overleveringer kan kræve ekstra inferenskald, gentagelse af kontekst og beslutninger om, hvilke oplysninger der skal videregives fra én agent til en anden. I Swarm Decoder er der ingen overleveringer: Deltagerne arbejder på én ræsonneringsbane, og det eneste, de udveksler, er en vurdering af, hvilken retning der er bedst.

Swarm Decoder er designet til at opdage svage antagelser under genereringen, før der bruges væsentlig indsats på at bygge videre på dem. Målet er at reducere fejl, tilbageskridt og unødvendig generering; effektivitetsgevinsten opstår, når kontrollen forhindrer mere arbejde, end den selv kræver. Derfor er der heller ingen latenstidsstraf: Kørslen følger en mere direkte vej, så Engine løser opgaver hurtigere end den samme model alene og bruger færre tokens i alt, når alle deltagende modeller medregnes.

Du har fremhævet modeldrift under langvarige opgaver som et stort problem. Hvad er det egentlig, der forårsager driften, og hvordan viser den sig i praktiske anvendelser som softwareudvikling, forskning eller autonome AI-agenter?

Drift opstår, når en models kontekst gradvist holder op med at handle om opgaven. Under et langt forløb fyldes konteksten med modellens egne output, værktøjsresultater, filindhold og gentagne forsøg. Den oprindelige instruktion kommer til at fylde en stadig mindre del af det, modellen retter sin opmærksomhed mod, og dens egne tidligere fejl bliver nu en del af det input, den ræsonnerer ud fra. Derfor ophobes fejlene i stedet for at udligne hinanden. Dertil kommer, at nutidens ræsonneringsmodeller trænes med forstærkningslæring til at fuldføre opgaver, og de lærer genveje, der ser ud som om, opgaven bliver fuldført: at springe værktøjskaldet over, erklære succes eller opsummere i stedet for at kontrollere. Vi kalder det dovenskab, og de mest avancerede modeller gør det lige så ofte som modeller med åbne vægte. Den grundlæggende årsag er, at en enkelt model ikke har nogen ekstern kontrol. Den bedømmer sit eget arbejde, og modeller er dårlige til at reflektere præcist over sig selv.

Inden for softwareudvikling viser det sig ved, at agenten retter den fejl, du beskrev, men bryder den begrænsning, du nævnte i den første besked, skriver en test, der består uden videre, eller læser den samme fil fire gange, fordi den har mistet overblikket over, hvad den allerede har lært. Inden for forskning viser det sig som et langt forløb, hvor agenten bevæger sig fra det spørgsmål, du stillede, til det spørgsmål, der er lettest at besvare, og vender tilbage med en generisk opsummering. I autonome agenter er det den dyre version: sidespor, gentagne værktøjskald, tilbageskridt og en tokenregning, der er flere gange større, end opgaven krævede.

Vi kan sætte tal på det. Vi lod Qwen 3.8 27B gennemføre 450 DeepSWE-opgaver – reelt softwareudviklingsarbejde med brug af værktøjer over lange kontekster – én gang på egen hånd og én gang via Fortytwo Engine. På egen hånd brugte modellen i gennemsnit 16,3 millioner tokens pr. kørsel og 7,4 milliarder i alt. Via Engine brugte den samme model i gennemsnit 12,3 millioner tokens pr. kørsel og 5,6 milliarder i alt, altså 24,7 % færre, og den løste flere af opgaverne: 47,8 % mod 42,2 %. Der blev ikke ændret noget ved modellen. De fire millioner tokens pr. kørsel, der forsvandt, skyldtes drift: genlæsningerne, de gentagne forsøg og tilbageskridtene, som en enkelt model er nødt til at foretage, fordi ingen opdager dens fejlslagne afstikkere, mens den er i gang. Sværmen opdager dem, så modellen aldrig behøver at bruge tokens på dem.

Tidligere lod Fortytwo modeller evaluere hinandens færdige svar, mens den nuværende arkitektur gør det muligt for dem at påvirke ræsonneringsprocessen, mens den stadig udfolder sig. Hvad lærte I af den tidligere tilgang, og hvorfor er styring i realtid mere effektiv?

Arkitekturen fra 2025 viste, at vi kan opnå kapaciteter på niveau med de mest avancerede modeller ved at skalere horisontalt – altså ved at inddrage flere modeller frem for at gå efter den største. En sværm af modeller med åbne vægte, der rangerede hinandens færdige svar, klarede sig op til 17 procentpoint bedre end den bedste enkeltmodel i sværmen, og den var robust på måder, en enkelt model ikke er: over for støjende prompts, indsprøjtede instruktioner og et flertal af forkerte svar.

Det, arkitekturen ikke kunne, var at gribe ind. Det fungerer at rangere færdige svar på et enkelt spørgsmål, men agentforløb består af hundredvis af trin med værktøjskald imellem, og de afgørende fejl sker tidligt og forplanter sig. Når vurderingen først sker til sidst, har hver model allerede betalt den fulde tokenpris, og bedømmeren kan kun vælge mellem forløb, der allerede er gået i forskellige retninger. Det betød også, at sværmens omkostninger steg med antallet af modeller – hvilket er fint ved ét svært spørgsmål, men ikke egner sig til en kodeagent.

Styring i realtid løser begge problemer. Kontinuerlig rangering lægger et selektionspres på gennem hele forløbet, så et forkert spor korrigeres dér, hvor det opstår, før det forplanter sig. Sværmen nøjes aldrig med et dovent forsøg, for et mindre grundigt forsøg rangerer lavere end et mere omhyggeligt. Derfor giver den samme mekanisme os nu både højere nøjagtighed og færre tokens.

I jeres test med Qwen 3.8 27B rapporterer Fortytwo, at der blev brugt 24,7 % færre tokens på tværs af 450 DeepSWE-kørsler, samtidig med at resultaterne blev forbedret på tværs af seks benchmarks. Hvad foregår der i sværmen, som gør det muligt at forbedre ydeevnen og samtidig reducere tokenforbruget?

Sværmens kontrol har en lille, fast omkostning; den genopretning, den forebygger, vokser med opgavens længde, fordi hvert forkert spor, der ikke bliver korrigeret, koster alt det arbejde, der bygger videre på det. Jo længere opgaven er, desto mere er der derfor at spare, og DeepSWE ligger i den lange ende af spektret. Derfor ender besparelsen på næsten en fjerdedel af alle tokens.

Nøjagtigheden handler om ujævn intelligens. Modelforbedringer er typisk ujævnt fordelt: Man får ræsonnering på ph.d.-niveau inden for ét område og det rene nonsens inden for et andet, fordi finjustering, forstærkningslæring (RL) og anden eftertræning forbedrer en model på de data, den blev trænet på, mens gevinsterne bliver mindre, efterhånden som virkelige opgaver bevæger sig væk fra disse data. Swarm Decoder ændrer ikke selve modellen. Den forbedrer selve ræsonneringen på en ensartet måde, så de seks benchmarks ikke er seks områder, vi har optimeret til; de er seks steder, hvor vi har målt det samme. Samlet set er modellen klogere og mere opmærksom, og når jævnaldrende modeller kontrollerer hvert trin, føles det, som om den lægger langt mere arbejde i din opgave. Derfor kan vi også prissætte Engine efter basismodellens pris pr. token: Kunden betaler ikke for et større budget, men for en kortere vej til det rigtige svar.

AI-udviklere er i stigende grad bekymrede over inferensomkostningerne, efterhånden som ræsonneringsmodeller genererer længere tokenkæder. Tror du, at en mere effektiv ræsonneringsproces i sig selv i sidste ende kan blive lige så vigtig som at gøre de enkelte modeller mindre, hurtigere eller billigere?

Ja, og jeg vil hævde, at det allerede er den største løftestang. Når modeller bliver mindre, hurtigere og billigere, falder prisen på et token. Men ingen køber tokens. De køber en opgave, der er løst, og i agenternes tidsalder er antallet af tokens pr. opgave eksploderet: En ræsonneringsmodel bruger millioner af tokens på en reel kodningsopgave, og en stor del af dem går med at gå tilbage over allerede tilbagelagte skridt. En reduktion på 25 % i antallet af tokens pr. opgave er præcis lige så meget værd som en prisnedsættelse på 25 %, men den lægges oven i alle forbedringer inden for hardware, kvantisering og kerner, og vi kan anvende den på enhver model med åbne vægte på markedet.

Branchen har tre håndtag. Bedre modeller, hvilket handler om træning og er dyrt. Billigere tokens, hvilket handler om hardware og drift, og hvor udviklingen er ved at konvergere, fordi alle har de samme GPU’er. Og færre tokens pr. opgave, hvilket handler om, hvordan inferens afvikles, og som næsten ikke er udforsket. Hidtil har skalering betydet større modeller og længere ræsonneringskæder, og begge dele kræver, at én model klarer alt i ét forløb. Vi mener, at den næste dimension er kollektiv: Flere modeller ræsonnerer sammen, og vurderingsevnen fordeles mellem dem, så selve forløbet bliver kortere og mere pålideligt. Det er en anden form for skalering end skalering af parametre eller beregning ved testtid, og det er den, vi satser på. Vi tænker på det som peers frem for parametre.

Fortytwo Engine er kompatibel med OpenAI API, samtidig med at den kører modeller med åbne vægte. Hvor vigtigt var det at sikre kompatibilitet med eksisterende AI-udviklingsstakke, og hvor nemt kan udviklere flytte en applikation fra et konventionelt API med én model til en sværmarkitektur?

Kompatibilitet er afgørende. Agentøkosystemet – kodeagenter, agentrammer, frameworks og evalueringsværktøjer – er bygget op omkring OpenAI API-formatet. For udviklere, der bruger Fortytwo Engine, svarer skiftet derfor til at gå fra én inferensudbyder til en anden: For en kompatibel app, agent, agentramme eller tjeneste kræver det typisk kun én ændring af konfigurationen: endpointet, API-nøglen og valget af model.

Det, der ændrer sig, er adfærden, ikke integrationen. Forskellen viser sig ved lange agentforløb, hvor tokenforbruget og nøjagtigheden i første forsøg afgør omkostningerne: Den samme model bliver hurtigere færdig gennem Engine, bruger færre tokens og løser flere opgaver korrekt. Mit råd er at behandle det som ethvert andet modelskift: Kør den evaluering, du allerede bruger på din agent, sammenlign antallet af tokens pr. opgave og succesraten, og behold den løsning, der klarer sig bedst.

Tak for et godt interview. Læsere, der gerne vil udforske inferens med sværme og se, hvordan evaluering mellem modeller kan forbedre ræsonneringens effektivitet, bør besøge Fortytwo.