DeepInfer: il motore di inferenza di DeepSeek ora è open source

Quando si parla di intelligenza artificiale si guarda quasi sempre il modello: quanti parametri ha, quanto è bravo, quanto costa. Dietro ogni risposta che arriva da un’API c’è però un altro pezzo di software, molto meno visibile e altrettanto decisivo: il motore di inferenza. È quello che prende il modello e lo fa girare su centinaia di schede senza bruciare tempo e denaro.

Il 20 ottobre 2026 DeepSeek ha reso pubblico su GitHub il suo: si chiama DeepInfer, licenza Apache 2.0. In poche ore ha superato le 9.800 stelle e le 860 fork. Non è il solito annuncio di un modello nuovo. È l’apertura del pezzo che trasforma un modello in un servizio vero, quello che serve 155 trilioni di token al giorno secondo i numeri dichiarati dall’azienda.

Vale la pena capire cosa c’è dentro, perché il modo in cui un modello viene servito conta quanto il modello stesso.

Che cos’è un motore di inferenza

Un modello di linguaggio è un insieme di pesi, cioè numeri. Da solo non fa nulla: qualcuno deve caricarlo in memoria, leggere il prompt, far girare i calcoli e restituire i token uno dopo l’altro. Questo lavoro lo fa il framework di inferenza.

La distanza tra un modello “che funziona” e un servizio che risponde in un secondo a milioni di persone è tutta lì. Il modello può essere ottimo, ma se il motore non sa organizzare la coda delle richieste, non riusa i calcoli già fatti e non distribuisce il carico sulle GPU, il servizio costa troppo o va troppo lento.

Nel ciclo di una richiesta ci sono due fasi diverse, che spesso vengono confusate.

• Prefill: il motore legge tutto il prompt e costruisce lo stato interno della conversazione. È un lavoro di calcolo puro, molto parallelo, che determina il tempo prima del primo token, il TTFT.
• Decode: il modello genera la risposta un token alla volta. Ogni passo dipende dal precedente, quindi qui il collo di bottiglia non è il calcolo ma la memoria: bisogna leggere i pesi e la cache a ogni token. Questa fase determina la velocità percepita, cioè il tempo tra un token e l’altro, il TBT.

Un buon framework deve ottimizzare entrambe, con strategie diverse. Ed è esattamente quello che si vede leggendo il repository.

Cosa c’è dentro DeepInfer

La release è pensata per l’inferenza offline, cioè per far girare il modello su hardware tuo, con le funzioni necessarie a un servizio su larga scala. Il modello supportato in questa versione è uno solo: DeepSeek-V4.1-Flash. Sul sito di DeepSeek è il modello leggero e veloce della famiglia, quello pensato per il traffico di massa.

Le funzioni dichiarate nel README sono queste:

• kernel ottimizzati, runtime del modello e del campionatore;
• parallelismo con Attention DP e balanced CP, più MoE EP con EPLB;
• DSpark e verifica programmata in base alla confidenza;
• SWA bounded replay, cioè la ricostruzione limitata della cache SWA;
• scheduling asincrono, con un batch scheduler a overhead dichiarato nullo;
• inferenza batch-invariant;
• campionamento deterministico;
• output strutturati.

Dietro ci sono i kernel che DeepSeek aveva già aperto negli anni: FlashMLA, DeepGEMM, DeepEP, TileKernels, DeepSelect e kernel scritti in TileLang. DeepInfer non è un progetto nato dal nulla: è il punto in cui quei pezzi vengono messi insieme in un motore completo. Il README lo dice esplicitamente, il progetto è nato sulle fondamenta di vLLM, con ispirazione da SGLang e TensorRT-LLM.

Prefill e decode, due mestieri diversi

La parte più interessante è come DeepInfer distribuisce il lavoro. La risposta breve: non lo distribuisce allo stesso modo nelle due fasi.

Nel prefill il calcolo è denso e regolare, quindi conviene usare parallelismi piccoli e macchine normali. DeepSeek parla di EP2-8 e DP2-8, cioè da 2 a 8 GPU per gruppo, con la raccomandazione di usare il valore più basso che la memoria HBM consente.

Nel decode il problema è opposto: ogni token è un passo breve e la memoria la fa da padrona. Qui DeepSeek usa il Wide-EP, con EP64-128 e DP64-128. In pratica: un supernodo da 64 o 128 GPU per il decode, contro 8 per il prefill. Più esperti del modello vengono distribuiti su più schede, meno dati devono viaggiare a ogni passo, più token al secondo si generano.

Questa asimmetria spiega perché il deployment minimo efficiente non è una macchina sola. Nel documento tecnico DeepSeek scrive che in produzione il rapporto tra GPU di prefill e GPU di decode è circa 1:1: siccome il decode raccomandato parte da EP64, l’unità minima sensata è 64 GPU per il prefill più 64 per il decode. Il benchmark pubblico del repository misura invece le due fasi separatamente, con 4 GPU SM100 per il prefill e 64 per il decode, proprio per mostrare quanto poco hardware serva al prefill rispetto al decode.

Il problema del Wide-EP è che tanti esperti su tante schede si sbilanciano facilmente: una GPU finisce con gli esperti più richiesti e diventa il collo di bottiglia. DeepInfer risolve con EPLB, un load balancer degli esperti che tiene alcune copie ridondanti degli esperti “caldi” e le sposta ogni tot passi in base alle statistiche di utilizzo. Nel documento si legge che il rapporto tra il rank più lento e la media resta intorno a 1,07-1,09, cioè il sistema è sbilanciato di meno del 10%.

La cache KV diventa un’infrastruttura

Se c’è un dettaglio che distingue un servizio grande da un esperimento, è la gestione della cache KV. È la memoria dei calcoli già fatti sui token precedenti, quella che permette di non rileggere tutto il contesto a ogni nuovo token.

DeepSeek non tiene quella cache solo nella memoria delle GPU. Ha costruito un cluster di storage dedicato con 3FS, il file system distribuito interno, per circa 100 PiB di SSD. Ogni server di storage ha 20 dischi da 30,73 TB, con 10+2 erasure coding, cioè tollera il guasto simultaneo di due nodi. La cache resta viva 3 giorni per il traffico degli agenti e 7 giorni per il traffico chat. Il motivo è che le conversazioni hanno code lunghe di riletture: perdere quella cache costa più di quanto costi tenerla.

Il dato che rende l’idea: circa 14,4 TB di cache per GPU, misurati come dimensione logica. Non è un dettaglio da ingegneri: è la ragione per cui una risposta su un contesto lungo può costare poco anche se il modello è enorme.

Sul lato calcolo c’è il SWA bounded replay. In un’architettura con attention a finestra scorrevole, ricostruire la cache SWA in modo esatto richiederebbe di ricalcolare gli ultimi 2.560 token attraverso 20 layer del decoder. DeepInfer ricalcola solo gli ultimi 128 e usa il risultato per il decode, senza rimetterlo nella cache dei prefissi. Il documento parla di un risparmio vicino alla metà del calcolo di prefill. Un trucco che sacrifica un po’ di precisione nella cache per guadagnare un’enormità in velocità.

DSpark e la verifica a confidenza

La decodifica speculativa è la tecnica che fa indovinare al modello più token in anticipo, per poi verificarli tutti insieme. DeepSeek la usa nella variante DSpark, che ho raccontato in un articolo dedicato: invece di verificare sempre 5 token bozza, il sistema stima la probabilità che ciascuno venga accettato e verifica solo il prefisso che conviene.

I numeri nel documento sono concreti: la lunghezza media verificata scende da 5,00 a 3,2-4,4 token, mentre quella accettata resta praticamente uguale, 3,29 contro 3,20. Il guadagno di throughput va dal +4% al +7% nel punto di funzionamento di produzione, con circa 60 sequenze per rank e sale fino a +11% a 96 sequenze. Non è il +400% dei titoli, è il tipo di guadagno noioso e solido che paga le bollette.

Per chi vuole il ripasso: DSpark, come DeepSeek fa parlare i modelli AI il doppio più velocemente.

Le altre carte: scheduling, determinismo, output strutturati

Tre funzioni sembrano dettagli e invece fanno la differenza in produzione.

La prima è lo scheduling asincrono. Nel ciclo di decode il framework deve fare tre cose: programmare il batch, far girare il modello, campionare il token. Programmazione e post-processing sono logica CPU e nella versione classica la GPU resta ferma mentre la CPU lavora. DeepInfer sovrappone le due cose: mentre la GPU calcola il passo N, la CPU prepara il passo N+1. Il risultato è che la GPU non ha più tempi morti tra un token e l’altro.

La seconda è l’inferenza batch-invariant. Di solito il risultato di un modello può cambiare leggermente se la richiesta viaggia in un batch diverso, per via di come vengono sommati i numeri in virgola mobile. Con DEEPINFER_BATCH_INVARIANT=1 questo non succede: lo stesso input dà lo stesso output indipendentemente da chi viaggia insieme a lui. Serve per i test, per la riproducibilità e per chiunque abbia provato a spiegare a un cliente perché due risposte identiche avevano punteggi diversi. Funziona solo su NVIDIA, per ora.

La terza sono gli output strutturati. Si può vincolare la generazione a una regex, a uno schema JSON o a una grammatica EBNF. Il formato viene compilato in un automa e a ogni passo il motore maschera i token non ammessi. È il modo pulito per far restituire a un modello JSON valido senza pregarlo nel prompt e senza sperare che non aggiunga una frase di cortesia prima della graffa.

Il campionamento deterministico completa il quadro: con batch-invariant attivo, verifica speculativa disattivata e un seed fisso, lo stesso input produce esattamente lo stesso output. Anche qui, solo NVIDIA.

NVIDIA e Huawei Ascend, il dettaglio che conta

DeepInfer gira su due famiglie di acceleratori: le GPU NVIDIA SM100, cioè la generazione Blackwell per il calcolo AI e le NPU Huawei Ascend 950. Non è una nota a piè di pagina. È la parte più politica del progetto.

Quasi tutti i framework di inferenza open source nascono su CUDA e trattano gli acceleratori alternativi come cittadini di serie B, quando va bene. DeepSeek ha costruito il suo motore con due backend di prima classe, con build separate e due toolchain diverse: CUDA 13 per NVIDIA, CANN 9.2 per Ascend. Nella pratica significa che un operatore cinese può servire DeepSeek-V4.1 Flash su hardware Huawei senza riscrivere il motore.

È anche una mossa commerciale intelligente. DeepSeek non vende GPU, quindi non ha interesse a legare il proprio software a un solo fornitore. Più hardware può far girare il modello, più il modello si diffonde. E se il modello si diffonde, cresce l’ecosistema che ci costruisce sopra.

Va detto che l’Ascend 950 è hardware recente e non esattamente alla portata di un appassionato. Il supporto nel repository è un segnale industriale, non un’opzione per il computer di casa.

Cosa non c’è e cosa serve per provarlo

DeepInfer non è un pacchetto pronto da installare e usare in cinque minuti. Il README è onesto: la release contiene l’inferenza offline e le funzioni di base, non un servizio completo. Mancano tre pezzi, dichiarati esplicitamente.

• un sistema di KV cache pronto all’uso, quello che DeepSeek usa internamente e che resta legato alla sua infrastruttura;
• la disaggregazione VE/Prefill/Decode completa, anche se la maggior parte della logica è già implementata;
• il load balancing tra repliche data-parallel per prefill e decode.

I requisiti tecnici sono severi: Linux, GCC 13 o superiore, Python 3.12, CUDA 13 per NVIDIA o CANN 9.2 per Ascend. Si compila con ./build.sh, dopo aver creato un ambiente Python vuoto. Al primo avvio scarica dal catalogo Hugging Face il checkpoint deepseek-ai/DeepSeek-V4.1-Flash-1017, a meno che non gli si punti una copia locale con DEEPINFER_HF_MODEL_DIR.

Poi c’è l’hardware. Il benchmark di riferimento gira su 4 GPU SM100 per il prefill e 64 per il decode. Non è un progetto per una singola scheda da gaming, nemmeno una molto costosa. È pensato per chi gestisce cluster, per i provider cloud e per i gruppi di ricerca che vogliono studiare come si serve un modello di questa classe.

I numeri del servizio

Nel documento di accompagnamento DeepSeek dichiara alcuni numeri sulla propria infrastruttura. Vanno presi come dati dell’azienda, non come misure indipendenti, ma danno la scala del problema.

• 155 trilioni di token al giorno serviti da un singolo cluster;
• 38 dollari di ricavo per GPU-ora ai prezzi di fascia bassa;
• KV cache conservata per più di 72 ore;
• circa l’80% delle prestazioni di un benchmark offline perfettamente bilanciato, nonostante il carico reale sia molto più disordinato.

L’ultimo numero è forse il più onesto. Un sistema di produzione non è mai perfettamente bilanciato: ci sono richieste corte e richieste lunghissime, picchi, code, code in testa. Arrivare all’80% del teorico significa che il lavoro di scheduling e di load balancing recupera gran parte del divario tra la teoria e la realtà.

Perché è una notizia

DeepSeek aveva già aperto i pesi dei suoi modelli. Il motore di inferenza era il pezzo che restava dentro casa, ed era probabilmente il vero fossato: chiunque può scaricare i pesi, ma servirli in modo economico è un altro mestiere.

Aprire DeepInfer sposta il terreno. Un provider cloud può partire da un motore già ottimizzato per V4.1 Flash invece di adattare vLLM per mesi. Un’azienda con hardware Huawei può valutare il modello senza dipendere da CUDA. Un ricercatore può guardare dentro le scelte di scheduling di un servizio che macina 155 trilioni di token al giorno.

E c’è una promessa per il futuro: DeepSeek ha scritto che il codice di inferenza dei prossimi modelli, insieme alle ottimizzazioni successive, continuerà a essere pubblicato in DeepInfer. Se la promessa viene mantenuta, il repository diventa il posto dove seguire l’evoluzione del serving di DeepSeek, non un rilascio isolato.

Nel frattempo, per chi lavora con l’AI, il messaggio è semplice: il modello è solo metà della storia. L’altra metà è il modo in cui lo fai parlare.

FAQ

DeepInfer è un modello di intelligenza artificiale?

No. È un framework di inferenza, cioè il software che fa girare un modello su hardware reale. Il modello è DeepSeek-V4.1-Flash, un file di pesi separato che DeepInfer scarica o carica da disco.

Posso usarlo con altri modelli, tipo Llama o Qwen?

In questa release il modello supportato è solo DeepSeek-V4.1-Flash. Il codice nasce da vLLM, quindi adattarlo ad altri modelli è tecnicamente possibile, ma non è una strada supportata e richiede lavoro sul runtime, sui kernel e sulla cache.

Serve una GPU particolare?

Sì. Servono GPU NVIDIA SM100 oppure NPU Huawei Ascend 950. Non è supportato su GPU consumer e i requisiti di compilazione, CUDA 13 o CANN 9.2, escludono la maggior parte delle macchine domestiche.

È gratis?

Il codice sì: licenza Apache 2.0, quindi puoi usarlo, modificarlo e ridistribuirlo anche in prodotti commerciali. L’hardware e l’energia non sono gratis e per un deployment efficiente servono decine di acceleratori.

Che differenza c’è con vLLM o SGLang?

vLLM e SGLang sono framework generalisti, pensati per far girare tanti modelli diversi. DeepInfer è specializzato: un modello, due famiglie di hardware, ottimizzazioni spinte su misura. Il prezzo della specializzazione è la flessibilità, il guadagno è la prestazione. Il progetto stesso dichiara di essere nato sulle fondamenta di vLLM.

I 155 trilioni di token al giorno sono un dato verificabile?

No, è un numero dichiarato da DeepSeek nel documento di accompagnamento al rilascio. Non esiste un ente indipendente che possa misurarlo. È utile per capire la scala del sistema, non come benchmark confrontabile.

✅ Verificato il 20 ottobre 2026.