Recursive Flint 40B-A2.5B: un modello di coding pensato per essere veloce prima di tutto

Il numero che decide se Recursive Flint 40B-A2.5B meriti il vostro spazio su disco non è 54,9%. È 2,5. Il primo modello di coding open-weight di Recursive porta 39,8 miliardi di parametri e ne risveglia circa 2,5 miliardi per ogni token che scrive, e quasi ogni altra decisione del rilascio — il layout dell'attenzione, la ricetta di quantizzazione, il kernel Metal personalizzato, il motore di inferenza — è a valle di quel singolo rapporto. Flint è stato rilasciato il 21 ottobre 2026 con licenza Apache 2.0, il che lo rende vecchio di un giorno al momento della scrittura e dentro la finestra in cui un lancio è ancora notizia anziché storia. Poiché una tabella di benchmark vecchia di un giorno è una promessa più che una misurazione, teniamo separato il record di produzione: l'AI Incident Archive registra come le dichiarazioni di modelli e fornitori hanno tenuto una volta che servono traffico reale.

La versione breve per chi deve decidere proprio ora: è un modello sparse mixture-of-experts pensato per essere la cosa più veloce nella sua classe di peso su un laptop, pubblica tre punteggi di coding agentico tutti dichiarati dal fornitore e non riprodotti, ed è il primo modello di un'azienda il cui scopo dichiarato è automatizzare la ricerca che costruisce i modelli. Tutti e tre questi fatti contano, e il terzo è quello che sarà ancora interessante tra un anno.

Cosa è stato effettivamente spedito

Quattro repository, non uno. Il repository principale RecursiveSI/flint contiene il checkpoint BF16, la configurazione, il tokenizer, il template di chat e un kit di serving SGLang, ed è stato creato il 21 ottobre 2026 alle 14:20 UTC. Tre varianti quantizzate gli stanno accanto, tutte datate lo stesso pomeriggio: una build int4 safetensors, un GGUF int4 e un GGUF NVFP4. Ogni dimensione riportata di seguito è stata misurata dagli elenchi dei file dei repository stessi anziché citata dall'annuncio.

• Riferimento BF16 — 79,59 GB su 37 file, in 15 shard safetensors da circa 5,37 GB ciascuno. Questo è l'artefatto di fine-tuning, e quello che non vuoi scaricare per l'inferenza.

• NVFP4 GGUF — 22.86GB in un singolo file, la più piccola build di inferenza completa pubblicata.

• Int4 GGUF — 25,99 GB, una quantizzazione q4_1 più grande del file NVFP4, cioè l'opposto dell'ordine di denominazione e una cosa da sapere prima di scegliere in base al nome del file.

• Safetensors Int4 — 22,58 GB, per runtime che preferiscono pesi sharded rispetto a un singolo GGUF.

La licenza è Apache 2.0, con la model card che aggiunge la distinzione secondo cui i termini dell'API ospitata e le pratiche sui dati sono separati dalla licenza sui pesi — la consueta separazione, dichiarata apertamente anziché sotterrata.

L'architettura è un argomento relativo alla larghezza di banda della memoria

Su un laptop, decodificare un token non è soprattutto un problema di calcolo. È un problema di spostare i pesi dalla memoria alle unità aritmetiche abbastanza velocemente, ed è per questo che un modello denso da 40 miliardi di parametri è lento, per quanto sia buono il chip: ogni token legge ogni peso. La risposta di Flint è leggerne quasi nessuno.

• Sparsità — 256 esperti instradati per layer MoE con 6 selezionati per token, più un esperto condiviso sempre attivo. Su 49 layer, 2 sono densi e 47 sono MoE, quindi tutti tranne i primi due svolgono lavoro condizionale.

• Parametri attivi — 39,8B in totale, circa 2,5B attivi per token includendo l'output head, da cui deriva la designazione "40B-A2.5B". Il solo corpo attivo è di circa 2,2B.

• Attenzione — 35 livelli a finestra scorrevole con una finestra di 513 token (il token corrente più i 512 precedenti), intervallati a 14 livelli di attenzione completa. Solo 32 teste di query e 4 teste chiave-valore, con dimensione della testa pari a 128, così la cache KV resta sufficientemente piccola da rendere praticabili le lunghe sessioni degli agenti.

• Codifica posizionale — rotary embeddings sugli strati a finestra scorrevole e nessuna affatto sugli strati a full attention, una scelta che la model card riporta senza spiegarla. QK RMSNorm per testa e attention sink appresi per testa svolgono il lavoro di stabilità che normalmente la codifica posizionale condivide.

• Contesto — 262.144 token documentati, e la scheda del modello è esplicita sul fatto che questo comprende insieme prompt e output generato. L'annuncio pubblicizza «fino a 512k» e poi consiglia di restare entro 256k per la programmazione. Entrambe le affermazioni provengono dallo stesso fornitore, a un paragrafo di distanza.

Il dettaglio interessante è come è stata scelta la forma. Recursive afferma che la sua Eureka Machine — un ciclo di ricerca automatizzato che propone idee, le implementa, le testa e combina ciò che funziona — è partita da una baseline da 35 miliardi di parametri con 3 miliardi attivi e ha esplorato configurazioni e larghezze degli esperti. La configurazione 40B/2.5B risultante era, secondo la formulazione stessa dell'annuncio, "prevista come la migliore combinazione di velocità e prestazioni di codifica tra le configurazioni testate dalla nostra Eureka Machine". Prevista, non dimostrata da un confronto tra modelli finiti. È un modo normale di scegliere un'architettura quando le esecuzioni di addestramento sono costose, ed è anche un'affermazione che un checkpoint successivo potrebbe silenziosamente smentire.

I tre punteggi e le note a piè di pagina che li accompagnano.

Flint ottiene il 54,9% su Terminal-Bench 2.1, l'89,7% su SWE-bench Pro v2 e il 74,2% su SWE-bench Verified. Questi numeri compaiono nella scheda del modello come valutazioni di rilascio, e nessuna terza parte ha pubblicato una misurazione di questo modello: l'indice dei modelli di Artificial Analysis, il consueto arbitro indipendente per un lancio del genere, non ha alcuna voce relativa a Flint alla data del 22 ottobre. Quindi tutto quanto segue è Recursive che misura Recursive.

Ciò che il fornitore rivela sulla propria metodologia è più di quanto la maggior parte dei post di lancio offra spontaneamente, e cambia il modo in cui dovrebbero essere letti i numeri:

• Terminal-Bench 2.1 — eseguito con l'harness Terminus 2, con accesso a Internet abilitato, e le soluzioni ottenute tramite recupero dal web conteggiate come fallimenti. Quest'ultima modifica è un handicap deliberato, e la model card osserva che i punteggi pubblicati da altri sviluppatori potrebbero non applicarla, il che rende più difficile, anziché più facile, un confronto omogeneo con i numeri di terze parti.

• SWE-bench Pro v2 e SWE-bench Verified — eseguiti con mini-swe-agent e senza alcun accesso a Internet, un'impostazione più difficile rispetto ad agenti che possono cercare la documentazione durante il task.

• Tentativi e timeout — pass@1 medio su almeno cinque tentativi, con timeout dell'agente fino a cinque ore. La media su cinque tentativi è un protocollo ragionevole; timeout di cinque ore significano che questi sono punteggi per un agente che sei disposto a lasciare in esecuzione, non per un autocompletamento.

• Campionamento — temperature 1.0, top-p 0.95, top-k 20 in ogni valutazione, e il serving kit applica tali valori predefiniti quando una richiesta li omette.

La tabella di benchmark di un fornitore è anche una dichiarazione su quali concorrenti ha scelto. Il grafico di Recursive stesso confronta Flint con Qwen 3.5, Qwen 3.6, Qwen 3.8, Laguna XS 21, Muse Glimmer e Gemma 4 — modelli locali che si adattano a hardware simili, che è il gruppo di pari onesto per un modello da laptop e anche un gruppo selezionato per far sembrare buono l'argomento sulla sparsità. L'affermazione fatta è ristretta e difendibile: Flint guida i modelli MoE sotto i 50 miliardi di parametri totali nel coding agentico e rivaleggia con modelli densi da 25 a 40 miliardi pur funzionando molto più velocemente. Non è un'affermazione sui modelli di coding di frontiera, e Recursive non ne fa una — l'annuncio dice apertamente che Flint "potrebbe aver bisogno di più guida rispetto ai modelli di coding closed-source più grandi a cui sei abituato."

Velocità: rispetto a cosa viene effettivamente misurato il 2×

Recursive riporta più di 125 token al secondo su un MacBook Pro M4 Pro e più di 150 token al secondo su una NVIDIA RTX Spark da 64 GB in contesti brevi, descrivendo ciò come fino a due volte più veloce rispetto a modelli comparabili e più di cinque volte più veloce rispetto a modelli densi da 25 a 40 miliardi di parametri con punteggi di coding simili. La nota metodologica nel grafico della velocità è la parte che vale la pena leggere: media di token al secondo per l'intera durata di una sessione da 128.000 token, prefill escluso, con un concorrente misurato a 124k anziché alla lunghezza completa.

Escludere la prefill è prassi standard per il benchmarking della fase di decode e qui conta ancora, perché è proprio nella prefill che un agente di coding passa il suo tempo quando scarica un repository nella finestra di contesto. Un numero che misura solo la metà di decode di una sessione da 128k farà apparire migliore qualsiasi modello con attivazione sparsa, e l'intero design di Flint si basa sull'attivazione sparsa. Niente di tutto ciò rende il dato errato. Lo rende un dato di decode, e dovrebbe essere confrontato con altri dati di decode plutôt che con quanto tempo impiega il tuo agente a completare un'attività.

La ricetta di quantizzazione è la parte più trasferibile

La maggior parte degli articoli sulla quantizzazione riguarda quanta accuratezza è stata persa. Questo, invece, riguarda una decisione che si è mossa in direzione opposta rispetto alla convenzione.

Recursive ha quantizzato lo strato di output — lm_head — a 4 bit. Ciò va contro la prassi comune, e la ragione è specifica ai modelli sparsi: con solo 2,5 miliardi di parametri attivi, lo strato di output rappresenta una quota consistente dei pesi letti per ogni singolo token, quindi lasciarlo a 16 bit limita la velocità massima possibile del modello. Recuperare l'accuratezza ha richiesto una fase di distillazione offline in cui il modello quantizzato si addestra sulle proprie risposte pre-campionate da un coreset che ha scoperto da sé, con il modello a 16 bit nel ruolo di teacher — una configurazione che, secondo Recursive, ha quasi dimezzato i passi di addestramento rispetto alla sua baseline di quantisation-aware training.

Il risultato pubblicato è che il modello finale NVFP4 ottiene un punteggio entro 0,7 punti dal modello a 16 bit su tutta la suite di benchmark. Questa è un'affermazione del fornitore, ed è il tipo di affermazione che è facile verificare in seguito e costosa da falsificare, il che la rende utile per chiedergliene conto. La conseguenza pratica sono le dimensioni dei file indicate sopra: un download da 22,86GB che esegue un modello da 39,8 miliardi di parametri su una macchina con 48GB di memoria unificata.

Su Apple Silicon c’è un secondo livello. La Eureka Machine di Recursive ha prodotto kernel specializzati per proiezioni a basso numero di bit, operazioni MoE, attenzione ed elaborazione dei prompt, incluso un megakernel Metal che fonde l’intero forward pass di decodifica in un’unica dispatch sui chip M4 e M5. Fondere il passaggio di decodifica è il tipo di ottimizzazione che ripaga solo quando si controllano insieme l’architettura del modello, il formato di quantizzazione e il kernel — che è la vera tesi di questo rilascio, più di qualsiasi singolo numero di benchmark.

Come lo esegui e quanto ti costa ciascun percorso

Ci sono due storie di deployment distinte e non sono intercambiabili.

• GPU server — il checkpoint BF16 viene fornito con un kit di serving SGLang pensato per una B300 o una H200 per replica, espone un endpoint compatibile con OpenAI sulla porta 30000 con il nome del modello flint, e include un client di esempio per il ragionamento e le chiamate agli strumenti. Questo è l'unico percorso supportato per i pesi a piena precisione; la model card afferma chiaramente che il codice di modellazione Transformers non è ancora incluso.

• Macchine locali — llama.cpp, Ollama, Unsloth, LM Studio, vLLM e SGLang sono tutti indicati come supportati, il che è insolitamente ampio per un modello nel giorno del lancio ed è la differenza tra un checkpoint e un artefatto utilizzabile.

• Il motore rec — il motore di inferenza di Recursive, installato in ~/.local/bin, richiede un M4 Pro, M5 Pro o M5 Max con almeno 48 GB di memoria unificata e circa 30 GB di disco libero, ed espone localmente un'API compatibile con OpenAI. Il suo README dichiara un throughput in token da 1,4× a 2,6× rispetto a quello di llama.cpp su un M4 Pro con pesi a 4 bit, su prompt da 1.000 a 252.000 token con 1.024 token di output, cinque esecuzioni per lunghezza del contesto, prefill escluso. È esplicitamente ottimizzato per l'uso a sessione singola — esegui più agenti contemporaneamente e la documentazione ti indirizza altrove.

Note pratiche che determinano se una sessione va bene: la finestra di contesto è condivisa tra prompt e output, i problemi difficili richiedono un budget di output di almeno 32.768 token, incluso il ragionamento, e il reasoning_content restituito deve essere conservato nella cronologia della conversazione, altrimenti l'uso degli strumenti multi-turno peggiora. La guida di Recursive stesso per i compiti complessi è suddividere il lavoro in sottocompiti più piccoli con istruzioni esplicite, un consiglio onesto che si legge anche come una descrizione del limite massimo del modello.

Che cosa è realmente indimostrato?

Tre cose, in ordine decrescente rispetto a quanto dovrebbero influenzare una decisione.

Il primo è la misurazione indipendente. Non esiste. Non un punteggio basso in una classifica, non uno contestato — non esiste ancora alcuna valutazione di terze parti di Flint, e gli unici numeri in circolazione sono quelli del fornitore, prodotti con le scelte di harness del fornitore e l'adeguamento del fornitore per il recupero web. La metodologia è divulgata abbastanza bene da poter essere verificata, che è il massimo che si possa chiedere al primo giorno, ma divulgato non significa verificato.

Il secondo è se un modello con 2,5 miliardi di parametri attivi regge sul lavoro a lungo orizzonte per cui gli agenti di programmazione sono effettivamente pensati. Il protocollo di benchmark consente cinque tentativi e timeout di cinque ore, un margine generoso; un modello che richiede diversi tentativi e un lungo guinzaglio può ottenere un buon pass@1 pur risultando inaffidabile in un editor. L'avvertenza di Recursive stessa sulla necessità di maggiore guida rispetto a modelli chiusi più grandi indica la stessa cosa.

Il terzo è la ricerca dell’architettura stessa. Una configurazione che si prevede sarà la migliore tra quelle testate da un sistema automatizzato è un’ipotesi su una sessione di addestramento, non un risultato su un modello finito. Se la previsione della Eureka Machine era corretta, questo è un modello che altri piccoli team copieranno. Se era approssimativamente corretta, il prossimo checkpoint si sposta e il rapporto cambia.

Dove si inserisce questo se il tuo stack di agenti è solo in parte locale

Il motivo per cui un modello come Flint è importante è che rimuove una riga da una fattura, non tutte. L'inferenza locale gestisce il lavoro che puoi eseguire sulla tua macchina e non fa nulla per il lavoro che non puoi: il lavoro a contesto lungo che non entra, il picco di carico che supera le capacità di un singolo laptop, l'attività in cui un modello più grande è semplicemente migliore. Questo lascia la maggior parte dei team a gestire due sistemi.

OrcaRouter è la metà ospitata di questa soluzione e, per essere chiari sul confine: non serviamo Flint, e nulla in questo articolo è una promozione per un checkpoint che ospitiamo. Flint è un download da Recursive, non un nostro endpoint. Quello che facciamo è mettere un'unica API davanti a oltre 200 modelli ospitati al prezzo di listino del provider stesso con nessun ricarico aggiunto, instradare tra di essi con una catena di fallback basata sulla configurazione, e passare automaticamente al failover quando un provider si guasta durante una richiesta. Se vuoi confrontare quanto vale un'esecuzione locale di Flint rispetto a un modello mixture-of-experts ospitato di dimensioni simili — Qwen3.6-35B-A3B e Gemma 4 26B-A4B sono entrambi richiamabili tramite quell'unica chiave — il confronto costa una richiesta anziché un deployment.

La lettura ragionevole

Flint è un rilascio concreto con un baricentro specifico e insolito. Recursive non ha distribuito il modello di coding più forte che avrebbe potuto realizzare; ha distribuito quello più veloce che è riuscita a costruire a una dimensione che entra in un laptop, per poi pubblicare uno stack di quantizzazione e kernel progettato per far sopravvivere quel vantaggio al contatto con pesi a 4 bit. Il 54,9% su Terminal-Bench 2.1 e l'89,7% su SWE-bench Pro v2 sono numeri solidi per un modello sparso da 40 miliardi di parametri e, per ora, sono soltanto i numeri del fornitore.

Ciò che lo rende degno di essere seguito anziché semplicemente scaricato è il metodo che vi sta dietro. Un team che afferma che un ciclo di ricerca automatizzato ha scelto l'architettura, la ricetta di quantizzazione e i kernel sta facendo un'affermazione su un processo, non su un modello, e i processi sono verificabili in un modo in cui i benchmark di lancio non lo sono: la versione successiva o arriva più veloce e migliore, oppure no. Flint è il primo dato a sostegno di questa tesi, rilasciato con una licenza sufficientemente permissiva da consentire a chiunque di verificare i pesi autonomamente.

Se disponi di 48 GB di memoria unificata e di una macchina Apple Silicon, il costo per scoprirlo è un download da 22,86 GB e un pomeriggio. Se non è così, la posizione onesta è attendere la prima valutazione indipendente, perché una tabella di benchmark vecchia di un giorno è una promessa e non una misurazione.