Ivan Nikitin, vd och medgrundare av Fortytwo – intervjuserie

Ivan Nikitin är vd och medgrundare av Fortytwo, där han utvecklar teknik för svärminferens som sammanför flera AI-modeller så att de kan resonera och utvärdera varandras arbete. Hans bakgrund omfattar spel, konversationsbaserad AI, generativ AI och interaktiva system på Temporal och Sensorium. År 2011 grundade han Temporal tillsammans med Vlad Larin, som nu är medgrundare och CTO på Fortytwo. Där fick han erfarenhet av populationer av agenter som utvecklas över tid och system som kombinerar specialiserade modeller.

Fortytwo utvecklar AI-infrastruktur som gör det möjligt för modeller att samarbeta under inferensen. Företagets Fortytwo Engine använder en Swarm Decoder för att styra ett gemensamt resonemangsförlopp medan det pågår, med målet att öka träffsäkerheten och minska onödig generering av token vid långa uppgifter. Företaget erbjuder utvecklare ett API via Fortytwo Engine och driftsättning lokalt via Fortytwo Harbor.

Innan du var med och grundade Fortytwo ägnade du flera år åt att utveckla produkter inom konversationsbaserad AI, generativ AI och interaktiva system på Sensorium och Temporal. Hur formade de erfarenheterna din syn på begränsningarna hos enskilda stora språkmodeller, och hur ledde de dig till slut fram till den svärmbaserade metod som Fortytwo bygger på?

En stor del av vårt team, jag själv inräknad, kom in i AI-världen via spel. Spel har varit en grogrund för persondatorer och modern AI: de är anledningen till att GPU:n finns, och spel var den första seriösa testmiljön för förstärkningsinlärning. Spelvärldar gav oss en praktisk miljö där vi kunde utveckla agenter som lärde sig, anpassade sig och tävlade. På Temporal, som jag grundade tillsammans med Vlad Larin 2011, och där han nu är medgrundare och CTO på Fortytwo, började vi med intelligens under utveckling: populationer av agenter som tävlade under selektionstryck. Vi intresserade oss för hur en population kunde åstadkomma mer än en enskild agent, förutsatt att det fanns en bra metod för att identifiera och bygga vidare på dess starkaste bidrag. Selektion och utvärdering blev centrala för vårt sätt att tänka kring intelligens.

När transformermodellerna kom började vi också arbeta med konversationsbaserad AI och byggde en plattform för AI-drivna karaktärer som kunde föra öppna samtal utan manus och med minne och personlighet. Det var ett par år före ChatGPT, och modellerna vi arbetade med hade kontextfönster på bara 512 till 1 024 token. Det var inte realistiskt att förvänta sig att en enda tidig språkmodell på ett tillförlitligt sätt skulle klara alla de olika krav som upplevelsen ställde. Vi var tvungna att bygga en anpassad pipeline av specialiserade modeller, där var och en hade ett mer avgränsat ansvarsområde, och logik för att kombinera deras bidrag. Att rangordna och välja svar blev avgörande för att få hela upplevelsen att fungera. Det lärde oss hur mycket förmåga som kunde skapas genom att kombinera begränsade modeller i ett väl utformat system.

Den andra lärdomen handlade om effektivitet. Vi lärde oss att specialiserade modeller kunde tränas och köras mer effektivt för väldefinierade uppgifter, vilket gjorde att vi kunde åstadkomma mer med begränsade beräkningsresurser. Men att skala upp inferensen var fortfarande en utmaning, med användningsbegränsningar för API:er å ena sidan och kostnaden för egen drift i stor skala å den andra. Eftersom vi inte hade tillgång till beräkningskapacitet i framkant var vi tvungna att noga överväga hur vi kunde få de tillgängliga resurserna att räcka längre. Fortytwo förenade de här lärdomarna i visionen om svärminferens: flera modeller, eller flera instanser av samma modell, bidrar till resonemanget samtidigt som de bedömer varandras arbete. Resultatet är att kollektivet är mer träffsäkert än någon av dess enskilda medlemmar.

Fortytwo Engine använder flera modeller med öppna vikter för att styra ett enda resonemangsförlopp och kontrollera varandra medan svaret genereras. Hur skiljer sig den här metoden från konventionella multiagentsystem, modellensembler eller att helt enkelt köra flera modeller och sedan välja det bästa svaret?

Den viktigaste skillnaden är att svärminferens är direkt inbyggd i inferensmotorn som vi utvecklade. Vi kallar den Swarm Decoder: flera modelldeltagare formar kontinuerligt en enda resonemangsbana medan den genereras. Utvärdering och styrning sker inom ramen för den processen, vilket gör att modellerna kan påverka dess riktning innan svaret är färdigt.

Alternativen fungerar på andra sätt. I en ensemble på svarsnivå genererar modellerna separata svar som sedan rangordnas, väljs ut eller kombineras. Fortytwos ursprungliga arkitektur, som implementerades 2025, använde kamratrangordning av färdiga svar. Det förbättrade svarens träffsäkerhet avsevärt, men ledde till högre latens och större beräkningskostnader. Många konventionella multiagentsystem delar upp arbetet mellan agenter och använder en samordnare och meddelanden på naturligt språk för att styra deras bidrag. Sådana överlämningar kan kräva ytterligare inferensanrop, upprepad kontext och beslut om vilken information som ska föras vidare från en agent till en annan. I Swarm Decoder sker inga överlämningar: deltagarna arbetar med en och samma resonemangsbana och det enda de utbyter är en bedömning av vilken riktning som är bäst.

Swarm Decoder är utformad för att upptäcka svaga antaganden under genereringen, innan man lägger mycket arbete på att bygga vidare på dem. Målet är att minska antalet misstag, behovet av att backa och onödig generering; effektivitetsvinsten uppstår när kontrollen förhindrar mer arbete än den kräver. Därför uppstår inte heller någon latensökning: körningen följer en mer direkt väg, så Engine slutför uppgifter snabbare än samma modell skulle göra på egen hand och med färre token totalt, räknat för alla modeller som deltar.

Du har lyft fram att modellglidning under långvariga uppgifter är ett stort problem. Vad är det egentligen som orsakar den här glidningen, och hur yttrar den sig i praktiska tillämpningar som mjukvaruutveckling, forskning eller autonoma AI-agenter?

Modellglidning uppstår när modellens kontext gradvis slutar handla om uppgiften. Under en lång körning fylls kontexten av modellens egna svar, verktygsresultat, filinnehåll och nya försök. Den ursprungliga instruktionen utgör en allt mindre del av det modellen uppmärksammar, och dess tidigare misstag blir nu en del av underlaget den resonerar utifrån. Därför byggs felen på i stället för att ta ut varandra. Dessutom tränas dagens resonemangsmodeller med förstärkningsinlärning för att slutföra uppgifter, och de lär sig genvägar som ser ut som att de slutför uppgiften: att hoppa över verktygsanropet, hävda att de är klara eller sammanfatta i stället för att kontrollera. Vi kallar det lättja, och ledande modeller gör det lika ofta som modeller med öppna vikter. Grundorsaken är att en enskild modell saknar extern kontroll. Den bedömer sitt eget arbete, och modeller är dåliga på att självutvärdera korrekt.

Inom mjukvaruutveckling märks det när agenten åtgärdar buggen du beskrev men bryter mot begränsningen du angav i det första meddelandet, skriver ett test som klaras utan vidare eller läser samma fil fyra gånger eftersom den tappat reda på vad den redan lärt sig. Inom forskning handlar det om en lång körning som glider från frågan du ställde till den fråga som är enklast att besvara och sedan återkommer med en generisk sammanfattning. För autonoma agenter blir det dyrt: utvikningar, upprepade verktygsanrop, omtag och en tokenkostnad som är flera gånger högre än vad uppgiften krävde.

Vi kan sätta en siffra på det. Vi körde Qwen 3.8 27B genom 450 DeepSWE-uppgifter – verkligt mjukvaruutvecklingsarbete med verktygsanvändning och långa kontexter – dels på egen hand, dels via Fortytwo Engine. På egen hand använde modellen i genomsnitt 16,3 miljoner token per körning, 7,4 miljarder totalt. Via Engine använde samma modell i genomsnitt 12,3 miljoner token per körning, 5,6 miljarder totalt – 24,7 % färre – och den löste fler av uppgifterna: 47,8 % jämfört med 42,2 %. Modellen förändrades inte alls. De fyra miljoner token per körning som försvann var modellglidning: omläsningarna, de upprepade försöken och omvägarna som en enskild modell måste ta eftersom ingen fångar upp dess felsteg medan de sker. Svärmen fångar upp dem, så modellen behöver aldrig betala för dem.

Tidigare lät Fortytwo modeller utvärdera varandras färdiga svar, medan den nuvarande arkitekturen låter dem påverka resonemangsprocessen medan den fortfarande pågår. Vad lärde ni er av det tidigare tillvägagångssättet, och varför är styrning i realtid effektivare?

Arkitekturen från 2025 visade att vi kan nå kapacitet på nivå med de främsta modellerna genom horisontell skalning – genom att låta fler modeller delta i stället för att jaga den största modellen. En svärm av modeller med öppna vikter som rangordnade varandras fullständiga svar slog den bästa enskilda modellen i svärmen med upp till 17 procentenheter. Den var också robust på sätt som en enskild modell inte är: mot brusiga promptar, injicerade instruktioner och en majoritet felaktiga svar.

Vad den arkitekturen inte kunde göra var att ingripa. Att rangordna färdiga svar fungerar för en enskild fråga, men agentkörningar omfattar hundratals steg med verktygsanrop däremellan, och de avgörande misstagen sker tidigt och byggs på. Om bedömningen görs i slutet har varje modell redan betalat hela tokenkostnaden, och domaren kan bara välja mellan förlopp som redan har skiljt sig åt. Det innebar också att svärmens kostnad ökade med antalet modeller, vilket fungerar bra för en svår fråga men är fel lösning för en kodningsagent.

Styrning i realtid löser båda problemen. Kontinuerlig rangordning innebär att ett urvalstryck tillämpas under hela körningen, så ett felaktigt vägval korrigeras där det uppstår, innan det sprids vidare. Svärmen nöjer sig aldrig med ett slarvigt försök, eftersom ett slarvigare försök får sämre resultat i rangordningen än ett noggrannare. Därför ger samma mekanism oss nu både högre träffsäkerhet och färre token.

I era tester med Qwen 3.8 27B uppger Fortytwo att ni använder 24,7 % färre token i 450 DeepSWE-körningar, samtidigt som resultaten förbättras på sex benchmarktester. Vad händer i svärmen som gör att den kan förbättra resultaten och samtidigt minska tokenförbrukningen?

Svärmens kontroller har en liten, fast kostnad. Återhämtningen de förebygger blir däremot mer omfattande ju längre uppgiften är, eftersom varje felaktigt vägval som inte korrigeras kostar allt arbete som byggs ovanpå det. Ju längre uppgiften är, desto mer går det alltså att spara. DeepSWE ligger i den långa änden av det spannet, vilket är anledningen till att besparingen uppgår till nästan en fjärdedel av alla token.

När det gäller träffsäkerheten handlar det om ojämn intelligens. Modellförbättringar är vanligtvis ojämnt fördelade: en modell kan resonera på doktorandnivå inom ett område och producera rent nonsens inom ett annat, eftersom finjustering, RL och annan efterträning förbättrar modellen på de data den tränats på, samtidigt som förbättringarna avtar när verkliga uppgifter skiljer sig allt mer från dessa data. Swarm Decoder ändrar inte modellen. Den förbättrar själva resonemanget på ett konsekvent sätt, så de sex benchmarktesterna är inte sex områden vi har optimerat för, utan sex tillfällen då vi har mätt samma sak. Sammantaget blir modellen smartare och mer uppmärksam, och när kollegor kontrollerar varje steg känns det som om den lägger mycket mer kraft på din uppgift. Det är också därför vi kan prissätta Engine enligt basmodellens pris per token: kunden betalar inte för en större budget, utan för en kortare väg till rätt svar.

Utvecklare av AI blir alltmer bekymrade över inferenskostnaderna när resonemangsmodeller genererar längre tokenkedjor. Tror du att det i längden kan vara lika viktigt att effektivisera själva resonemangsprocessen som att göra enskilda modeller mindre, snabbare eller billigare?

Ja, och jag skulle hävda att det redan är den viktigare hävstången. Att göra modeller mindre, snabbare och billigare sänker priset per token. Men ingen köper token. De köper en färdig uppgift, och i agenternas era har antalet token per uppgift skjutit i höjden: en resonemangsmodell som arbetar med en verklig kodningsuppgift använder miljontals token, och en stor andel av dem går åt till att gå tillbaka och göra om. En minskning med 25 % av antalet token per uppgift är värd exakt lika mycket som en prissänkning på 25 %, men den kan dessutom kombineras med varje förbättring av hårdvara, kvantisering och kärnor, och vi kan tillämpa detta på alla modeller med öppna vikter på marknaden.

Branschen har tre hävstänger. Bättre modeller, vilket handlar om träning och är dyrt. Billigare token, vilket handlar om hårdvara och drift, och där utvecklingen går mot en utjämning eftersom alla har samma GPU:er. Och färre token per uppgift, vilket handlar om hur inferensen körs och knappt har utforskats. Hittills har skalning inneburit större modeller och längre tankekedjor, och båda innebär att en modell ska göra allt i ett enda förlopp. Vi tror att nästa utvecklingsdimension är kollektiv: flera modeller resonerar tillsammans, med omdömet fördelat mellan dem, så att själva förloppet blir kortare och mer tillförlitligt. Det är en annan sorts skalning än skalning av antalet parametrar eller beräkningar vid testtillfället, och det är den vi satsar på. Vi ser det som kollegor framför parametrar.

Fortytwo Engine är kompatibel med OpenAI API och kör samtidigt modeller med öppna vikter. Hur viktigt var det att vara kompatibel med befintliga AI-utvecklingsmiljöer, och hur enkelt kan utvecklare flytta en applikation från ett konventionellt API med en enda modell till en svärmarkitektur?

Kompatibilitet är avgörande. Agentekosystemet – kodningsagenter, körmiljöer, ramverk och utvärderingsverktyg – bygger på OpenAI API-formatet. För utvecklare som använder Fortytwo Engine är bytet därför som att byta inferensleverantör: för en kompatibel app, agent, körmiljö eller tjänst krävs vanligtvis bara en ändring av konfigurationen: slutpunkten, API-nyckeln och modellvalet.

Det som förändras är beteendet, inte integrationen. Skillnaden märks vid långa agentkörningar, där tokenförbrukningen och träffsäkerheten vid första försöket avgör kostnaden: samma modell slutför uppgifter snabbare via Engine, använder färre token och klarar fler av uppgifterna rätt. Mitt råd är att behandla det som vilket modellbyte som helst: kör den utvärdering du redan använder för din agent, jämför antalet token per uppgift och framgångsgraden, och behåll det alternativ som ger bäst resultat.

Tack för en fantastisk intervju. Läsare som vill utforska svärminferens och hur kollegial utvärdering kan effektivisera resonemang bör besöka Fortytwo.