Recursive Flint 40B-A2.5B: En kodmodell byggd för att vara snabb först

Talet som avgör om Recursive Flint 40B-A2.5B är värt din diskplats är inte 54,9 %. Det är 2,5. Recursives första kodmodell med öppna vikter har 39,8 miljarder parametrar och aktiverar ungefär 2,5 miljarder av dem för varje token den skriver, och nästan varje annat beslut i lanseringen – attention-layouten, kvantiseringsreceptet, den anpassade Metal-kärnan, inferensmotorn – följer av just den kvoten. Flint släpptes den 21 oktober 2026 under Apache 2.0, vilket innebär att den är en dag gammal när detta skrivs och befinner sig i fönstret där en lansering fortfarande är nyheter snarare än historia. Eftersom en dagsgammal benchmarktabell är ett löfte snarare än en mätning håller vi produktionsregistret separat: AI Incident Archive loggar hur påståenden från modeller och leverantörer har stått sig när de väl används i verklig trafik.

Kortversionen för alla som fattar beslut just nu: det är en gles mixture-of-experts-modell byggd för att vara det snabbaste i sin viktklass på en bärbar dator, den redovisar tre agentiska kodningspoäng som alla är leverantörsrapporterade och inte reproducerade, och det är den första modellen från ett företag vars uttalade syfte är att automatisera forskningen som bygger modeller. Alla tre fakta spelar roll, och den tredje är den som fortfarande kommer att vara intressant om ett år.

Vad som faktiskt levererades

Fyra repositorier, inte ett. Huvudrepositoriet RecursiveSI/flint innehåller BF16-checkpointen, konfigurationen, tokenizern, chattmallen och ett SGLang-serveringskit, och det skapades den 21 oktober 2026 kl. 14:20 UTC. Tre kvantiserade varianter ligger bredvid det, alla stämplade samma eftermiddag: en int4-safetensors-build, en int4-GGUF och en NVFP4-GGUF. Varje storlek nedan mättes från repositoriernas egna fillistningar i stället för att citeras från tillkännagivandet.

• BF16-referens – 79,59 GB över 37 filer, i 15 safetensors-delar på cirka 5,37 GB vardera. Detta är finjusteringsartefakten, och den du inte vill ladda ner för inferens.

• NVFP4 GGUF — 22,86 GB i en enda fil, den minsta publicerade kompletta inferensbygget.

• Int4 GGUF — 25,99 GB, en q4_1-kvantisering som är större än NVFP4-filen, vilket är omvänt mot namngivningsordningen och värt att känna till innan du väljer efter filnamn.

• Int4-safetensors – 22,58 GB, för körtidsmiljöer som föredrar shardade vikter framför en enda GGUF.

Licensen är Apache 2.0, och modellkortet tillägger distinktionen att villkoren för värdbaserat API och datapraxis är separata från vikternas licens – den vanliga uppdelningen, sagt rakt ut i stället för begravt.

Arkitekturen är ett argument om minnesbandbredd

På en laptop är avkodningen av en token inte i första hand ett beräkningsproblem. Det är ett problem med att flytta vikter från minnet till de aritmetiska enheterna tillräckligt snabbt, vilket är anledningen till att en dens modell med 40 miljarder parametrar är långsam oavsett hur bra chippen är: varje token läser varje vikt. Flints svar är att läsa nästan inga av dem.

• Sparsity — 256 routade experter per MoE-lager med 6 valda per token, plus en alltid aktiv delad expert. Av 49 lager är 2 täta och 47 MoE, så alla utom de två första utför villkorligt arbete.

• Aktiva parametrar – 39,8B totalt, ungefär 2,5B aktiva per token om man räknar med utdatahuvudet, vilket är där beteckningen "40B-A2.5B" kommer ifrån. Enbart den aktiva kroppen är cirka 2,2B.

Attention – 35 lager med glidande fönster vid ett fönster på 513 token (det aktuella tokenet plus 512 föregående) varvat med 14 full-attention-lager. Endast 32 query-huvuden och 4 key-value-huvuden, med huvuddimension 128, så att KV-cachen förblir tillräckligt liten för att långa agentsessioner ska vara praktiska.

• Positionskodning — rotary-inbäddningar på sliding-window-lagren och inga alls på full-attention-lagren, ett val som modellkortet anger utan att förklara. QK RMSNorm per huvud och inlärda attention sinks per huvud gör det stabilitetsarbete som positionskodning normalt delar.

• Kontext – 262 144 token dokumenterade, och modellkortet är tydligt med att detta omfattar prompt och genererad utdata tillsammans. Tillkännagivandet annonserar "upp till 512k" och rekommenderar sedan att man håller sig inom 256k för kodning. Båda uttalandena kommer från samma leverantör, ett stycke ifrån varandra.

Den intressanta detaljen är hur formen valdes. Recursive säger att dess Eureka Machine – en automatiserad forskningsloop som föreslår idéer, implementerar dem, testar dem och kombinerar det som fungerar – utgick från en baslinje på 35 miljarder parametrar med 3 miljarder aktiva och sökte igenom expertkonfigurationer och bredder. Konfigurationen 40B/2,5B som resulterade var, med tillkännagivandets egna formulering, "prognostiserad att erbjuda den bästa kombinationen av hastighet och kodningsprestanda bland de konfigurationer som vår Eureka Machine testade". Prognostiserad, inte bevisad genom en jämförelse av färdiga modeller. Det är ett normalt sätt att välja en arkitektur när träningskörningar är dyra, och det är också ett påstående som en senare checkpoint tyst skulle kunna motsäga.

De tre poängen och fotnoterna som hör till dem

Flint får 54,9 % på Terminal-Bench 2.1, 89,7 % på SWE-bench Pro v2 och 74,2 % på SWE-bench Verified. De siffrorna finns i modellkortet som utvärderingar vid lansering, och ingen tredje part har publicerat en mätning av den här modellen – Artificial Analysis modellindex, den vanliga oberoende granskaren för en lansering som denna, har ingen Flint-post alls per den 22 oktober. Så allt nedan är Recursive som mäter Recursive.

Det som leverantören faktiskt redovisar om sin egen metodik är mer än vad de flesta lanseringsinlägg frivilligt delar med sig av, och det förändrar hur siffrorna bör läsas:

• Terminal-Bench 2.1 — körs med Terminus 2-harness, med internetåtkomst aktiverad, och lösningar som erhållits genom webbhämtning räknas som misslyckanden. Den sista justeringen är ett avsiktligt handikapp, och modellkortet anger att andra utvecklares publicerade resultat kanske inte tillämpar den, vilket gör en jämförelse på lika villkor med tredjepartssiffror svårare snarare än lättare.

• SWE-bench Pro v2 och SWE-bench Verified – körs med mini-swe-agent och helt utan internetåtkomst, en svårare inställning än agenter som kan söka i dokumentationen under uppgiftens gång.

• Försök och timeouter – genomsnittligt pass@1 över minst fem försök, med timeouter för agenten på upp till fem timmar. Genomsnitt över fem försök är ett rimligt protokoll; timeouter på fem timmar innebär att detta är poäng för en agent som du är villig att låta köra, inte för en autokomplettering.

• Sampling — temperatur {{1}}1.0{{/1}}, top-p {{2}}0.95{{/2}}, top-k {{3}}20{{/3}} i varje utvärdering, och serveringspaketet tillämpar dessa standardvärden när en förfrågan utelämnar dem.

En leverantörs benchmarktabell är också ett uttalande om vilka jämförelsemodeller den har valt. Recursives eget diagram jämför Flint med Qwen 3.5, Qwen 3.6, Qwen 3.8, Laguna XS 21, Muse Glimmer och Gemma 4 – lokala modeller som passar liknande hårdvara, vilket är den ärliga jämförelsegruppen för en laptopmodell och också en grupp utvald för att få sparsitetsargumentet att se bra ut. Påståendet som görs är snävt och försvarbart: Flint leder MoE-modeller under 50 miljarder totala parametrar inom agentisk kodning och mäter sig med täta modeller på 25 till 40 miljarder samtidigt som den körs mycket snabbare. Det är inte ett påstående om frontier-modeller för kodning, och Recursive gör inte något sådant – tillkännagivandet säger rakt ut att Flint "kan behöva mer vägledning än de större slutenkälliga kodningsmodeller du är van vid."

Hastighet: vad 2× faktiskt mäts mot

Recursive rapporterar mer än 125 tokens per sekund på en M4 Pro MacBook Pro och mer än 150 tokens per sekund på en 64 GB NVIDIA RTX Spark vid korta kontexter, och beskriver det som upp till dubbelt så snabbt som jämförbara modeller och mer än fem gånger snabbare än densa modeller med 25 till 40 miljarder parametrar och liknande kodningspoäng. Metodfotnoten i hastighetsdiagrammet är den del som är värd att läsa: genomsnittliga tokens per sekund under en session på 128 000 tokens, exklusive prefill, där en konkurrent mättes vid 124k i stället för den fulla längden.

Att prefill utesluts är standardpraxis för decode-benchmarking, och det spelar fortfarande roll här, eftersom prefill är precis där en kodagent lägger sin tid när den dumpar ett repository i kontextfönstret. Ett tal som bara mäter decode-halvan av en 128k-session kommer att smickra vilken modell som helst med gles aktivering, och Flints hela design är gles aktivering. Inget av det gör siffran felaktig. Det gör den till en decode-siffra, och den bör jämföras med andra decode-siffror snarare än med hur lång tid din agent tar att slutföra en uppgift.

Kvantiseringsreceptet är den mest överförbara delen

De flesta texter om kvantisering handlar om hur mycket noggrannhet som gick förlorad. Den här handlar om ett beslut som gick i motsatt riktning mot konventionen.

Recursive kvantiserade utdatalagret – lm_head – till 4 bitar. Det strider mot gängse praxis, och anledningen är specifik för glesa modeller: med bara 2,5 miljarder aktiva parametrar utgör utdatalagret en stor andel av de vikter som läses för varje enskild token, så att lämna det på 16 bitar begränsar hur snabbt modellen kan gå. Att återvinna noggrannheten krävde ett offline-distillationssteg där den kvantiserade modellen tränas på sina egna försampelade svar från ett coreset som den själv upptäckte, med 16-bitsmodellen som lärare – ett upplägg som Recursive säger nästan halverade antalet träningssteg jämfört med sin baslinje för kvantiseringsmedveten träning.

Det publicerade resultatet är att den slutliga NVFP4-modellen ligger inom 0,7 poäng från 16-bitarsmodellen i hela benchmarksviten. Det är ett leverantörspåstående, och det är en sådan typ av påstående som är lätt att kontrollera i efterhand och dyrt att förfalska, vilket gör det till ett användbart påstående att hålla dem fast vid. Den praktiska konsekvensen är filstorlekarna ovan: en nedladdning på 22,86 GB som kör en modell med 39,8 miljarder parametrar på en maskin med 48 GB enhetligt minne.

På Apple Silicon finns det ett andra lager i det. Recursive's Eureka Machine tog fram specialiserade kärnor för lågbitprojektioner, MoE-operationer, attention och promptbearbetning, inklusive en Metal-megakärna som slår samman hela dekodningens forward-pass till en enda dispatch på M4- och M5-chipar. Att slå samman dekodningspasset är den typ av optimering som bara lönar sig när man kontrollerar modellarkitekturen, kvantiseringsformatet och kärnan tillsammans – vilket är den egentliga tesen med det här släppet, mer än någon enskild benchmark-siffra.

Hur du kör det, och vad varje väg kostar dig

Det finns två distinkta distributionsscenarier och de är inte utbytbara mot varandra.

• Server-GPU:er – BF16-checkpointen levereras med ett SGLang-serveringspaket som riktar sig mot en B300 eller en H200 per replika, exponerar en OpenAI-kompatibel slutpunkt på port 30000 med modellnamnet flint, och innehåller en exempelklient för resonemang och verktygsanrop. Detta är den enda vägen som stöds för fullprecisionsvikterna; modellkortet säger rakt ut att Transformers-modelleringskod ännu inte ingår.

• Lokala maskiner — llama.cpp, Ollama, Unsloth, LM Studio, vLLM och SGLang anges alla som stödda, vilket är ovanligt brett för en modell på lanseringsdagen och är skillnaden mellan en checkpoint och en användbar artefakt.

• rec-motorn – Recursives egen inferensmotor, installerad i ~/.local/bin, kräver en M4 Pro, M5 Pro eller M5 Max med minst 48 GB enhetligt minne och cirka 30 GB ledigt diskutrymme, och tillhandahåller ett OpenAI-kompatibelt API lokalt. Dess README hävdar 1,4× till 2,6× llama.cpp:s token-genomströmning på en M4 Pro med 4-bitarsvikter, över prompter på 1 000 till 252 000 token med 1 024 uttoken, fem körningar per kontextlängd, exklusive prefill. Den är uttryckligen optimerad för användning i en enda session – kör flera agenter samtidigt och dokumentationen hänvisar dig någon annanstans.

Praktiska anteckningar som avgör om en session går bra: kontextfönstret delas mellan prompt och utdata, svåra problem kräver en utdatabudget på minst 32 768 token inklusive resonemang, och returnerad reasoning_content måste bevaras i konversationshistoriken, annars försämras verktygsanvändning över flera turer. Recursives egen vägledning för komplexa uppgifter är att dela upp arbetet i mindre deluppgifter med explicita instruktioner, vilket är ett ärligt råd som också kan läsas som en beskrivning av modellens tak.

Vad är genuint obevisat

Tre saker, i fallande ordning efter hur mycket de bör påverka ett beslut.

{{1}}Det första är oberoende mätning.{{/1}} Det finns ingen. Inte en låg poäng på en resultattavla, inte en omtvistad sådan — det finns ännu ingen tredjepartsutvärdering av {{2}}Flint{{/2}}, och de enda siffror som cirkulerar är leverantörens, framtagna med leverantörens val av testramverk och leverantörens justering för webbinhämtning. Metodiken är redovisad tillräckligt väl för att kunna granskas, vilket är det mesta man kan begära den första dagen, men att den är redovisad innebär inte att den är verifierad.

Det andra är huruvida en modell med 2,5 miljarder aktiva parametrar håller för det långsiktiga arbete som kodagenter faktiskt är till för. Benchmarkprotokollet tillåter fem försök och tidsgränser på fem timmar, vilket är ett generöst spelrum; en modell som behöver flera försök och långt koppel kan uppnå en bra pass@1 men ändå kännas opålitlig i en editor. Recursives egen reservation om att den behöver mer vägledning än större slutna modeller pekar på samma sak.

Den tredje är själva arkitektursökningen. En konfiguration som förutses bli bäst bland dem som ett automatiserat system testade är en hypotes om en träningskörning, inte ett resultat om en färdig modell. Om Eureka Machines prognos var rätt är detta en mall som andra små team kommer att kopiera. Om den var ungefär rätt flyttar nästa checkpoint sig och kvoten ändras.

Var passar det här in om din agentstack bara är halvt lokal

Anledningen till att en modell som Flint spelar roll är att den tar bort en rad från en räkning, inte alla. Lokal inferens hanterar det arbete du kan köra på din egen maskin och gör ingenting för det arbete du inte kan — långkontextjobbet som inte får plats, belastningstoppen som överstiger kapaciteten hos en bärbar dator, uppgiften där en större modell helt enkelt är bättre. Det lämnar de flesta team med två system.

OrcaRouter är den hostade halvan av det upplägget, och för att vara tydlig med gränsen: vi tillhandahåller inte Flint, och ingenting i den här texten är ett säljargument för en checkpoint som vi hostar. Flint är en nedladdning från Recursive, inte en slutpunkt hos oss. Det vi gör är att sätta ett enda API framför över 200 hostade modeller till leverantörens eget listpris med inget påslag, routa mellan dem med en konfigurationsbaserad reservkedja, och växla över automatiskt när en leverantör börjar strula mitt i en begäran. Om du vill jämföra vad en lokal Flint-körning är värd mot en hostad mixture-of-experts-modell av liknande storlek – Qwen3.6-35B-A3B och Gemma 4 26B-A4B kan båda anropas via den där enda nyckeln – kostar jämförelsen en begäran i stället för en driftsättning.

Den rimliga läsningen

Flint är en riktig lansering med en specifik och ovanlig tyngdpunkt. Recursive släppte inte den starkaste kodningsmodell den hade kunnat göra; den släppte den snabbaste den kunde bygga i en storlek som ryms på en laptop och publicerade sedan en kvantiserings- och kernelstack som är utformad för att få den fördelen att överleva kontakten med 4-bitarsvikter. De 54,9 % på Terminal-Bench 2.1 och 89,7 % på SWE-bench Pro v2 är starka siffror för en gles modell med 40 miljarder parametrar, och de är tills vidare enbart leverantörens egna siffror.

Det som gör den värd att titta på i stället för att bara ladda ner är metoden bakom. Ett team som säger att en automatiserad forskningsloop valde arkitekturen, kvantiseringsreceptet och kernelerna gör ett påstående om en process, inte om en modell, och processer går att testa på ett sätt som lanseringsbenchmark inte gör: nästa version kommer antingen snabbare och bättre, eller så gör den inte det. Flint är den första datapunkten i det argumentet, släppt under en licens som är tillräckligt tillåtande för att vem som helst ska kunna kontrollera vikterna själv.

Om du har 48 GB enhetligt minne och en Apple Silicon-dator är kostnaden för att ta reda på det en nedladdning på 22,86 GB och en eftermiddag. Om du inte har det är den ärliga hållningen att vänta på den första oberoende utvärderingen, eftersom en dag gammal benchmark-tabell är ett löfte och inte en mätning.