DeepSeek rilascia DeepInfer, il motore di inferenza open source

DeepSeek ha reso open source DeepInfer, il framework di inferenza che dichiara di usare per alimentare i propri servizi in produzione. Il codice è pubblicato su GitHub con licenza Apache 2.0, quindi puoi scaricarlo, studiarlo, modificarlo e usarlo anche in ambito commerciale. Il rilascio riguarda l’inferenza offline e le funzioni essenziali per servire modelli su larga scala.

Per chi lavora con modelli aperti, non è un dettaglio: finora a fare la differenza tra un modello scaricabile e un servizio davvero veloce è stato spesso il software che lo esegue, più dei pesi stessi.

Che cos’è DeepInfer e perché DeepSeek lo pubblica ora

Nel README il progetto viene descritto come un framework di inferenza ad alte prestazioni e su larga scala per i modelli DeepSeek. Il modello supportato in questa prima versione è DeepSeek V4.1 Flash, e il checkpoint predefinito è quello che il sito aveva già raccontato nell’articolo dedicato a DeepSeek V4.1 Flash e alle sue API con ricerca e fetch. Al primo avvio il sistema scarica i pesi da Hugging Face, ma puoi indicare una copia locale impostando la variabile d’ambiente DEEPINFER_HF_MODEL_DIR.

Il repository chiarisce anche da dove nasce il lavoro. DeepInfer è stato costruito inizialmente soprattutto sopra vLLM, con ispirazioni prese da SGLang e TensorRT-LLM. In altre parole, DeepSeek non presenta un motore nato dal nulla, ma un’evoluzione di strumenti già noti alla comunità, riadattata alle esigenze dei propri modelli.

Il momento è interessante perché la corsa ai modelli si sta spostando sempre più sul costo e sulla velocità di servizio. Aprire il motore di inferenza significa mettere sul tavolo la parte di ingegneria che di solito resta nascosta dietro un’API.

Le funzioni principali del framework

Kernel ottimizzati e parallelismo

DeepInfer include kernel, modello e runtime di campionamento ottimizzati. I kernel arrivano da componenti già pubblicati da DeepSeek, come FlashMLA, DeepGEMM e DeepEP, più TileKernels, DeepSelect e kernel TileLang personalizzati. Sul fronte del parallelismo il framework supporta il data parallelism sull’attenzione, il context parallelism bilanciato e il parallelismo degli esperti per i modelli Mixture of Experts, con bilanciamento del carico tramite EPLB.

Sono scelte pensate per modelli molto grandi, in cui il collo di bottiglia non è solo il calcolo, ma anche il modo in cui lavoro e memoria vengono distribuiti tra tante GPU.

Decodifica speculativa e riduzione del prefill

Tra le novità tecniche c’è DSpark con la verifica schedulata in base alla confidenza, una forma di decodifica speculativa che propone più token alla volta e li controlla subito dopo. Si attiva con la variabile DEEPINFER_ENABLE_MTP_VARLEN=1, mentre DEEPINFER_USE_NEXTN_DECODE fissa la lunghezza massima della bozza, che di default è 5 token.

C’è poi il cosiddetto SWA bounded replay, che riduce il lavoro di prefill rielaborando solo un suffisso limitato del contesto. Per DeepSeek V4.1 il README suggerisce la modalità di troncamento compact con 140 token conservati, a patto che il suffisso mantenuto copra la finestra di attenzione a scorrimento più la massima distanza di backtracking.

In sintesi, meno calcolo ripetuto sul contesto e più token generati per ogni passaggio.

Scheduling asincrono, output deterministici e strutturati

Lo scheduling asincrono, attivo di default, sovrappone la preparazione dei batch sulla CPU all’esecuzione sul dispositivo, così l’acceleratore resta meno tempo in attesa. Esiste anche una modalità di inferenza invariante rispetto al batch, abilitata con DEEPINFER_BATCH_INVARIANT=1 e disponibile solo su hardware NVIDIA, che serve a ottenere risultati riproducibili.

Per il campionamento deterministico servono la modalità batch invariant, la disattivazione di DEEPINFER_ENABLE_MTP_VARLEN e un seme fisso (seq_seed) nei parametri di campionamento. Utile per test, valutazioni e debug, dove due esecuzioni identiche devono dare lo stesso risultato.

Infine gli output strutturati: puoi vincolare la generazione a un’espressione regolare, a uno schema JSON o a una grammatica EBNF tramite il parametro so_args. È una funzione molto richiesta da chi costruisce agenti e pipeline che devono produrre dati validi.

Hardware supportato e come provarlo

Il supporto dichiarato riguarda le GPU NVIDIA SM100 e le NPU Huawei Ascend 950. Per costruire il progetto servono Linux, GCC 13 o successivo, Python 3.12 e, a seconda dell’acceleratore, CUDA 13 per NVIDIA oppure CANN 9.2 per Ascend. Non è quindi un software pensato per il portatile di casa.

La procedura descritta è breve: crei un ambiente Python 3.12 vuoto, imposti DEEPINFER_ACCELERATOR su nvidia o ascend, lanci lo script build.sh e poi esegui l’esempio examples/offline_inference.py. Nella cartella degli esempi trovi i dettagli per il resto.

Sul fronte delle prestazioni il README non riporta numeri puntuali di throughput o latenza, ma mostra grafici di Pareto per prefill e decode. Le misure indicate sono state ottenute con 4 GPU SM100 per il prefill e 64 per il decode, ciascuna configurazione all’interno di un singolo dominio di scale-up. Lo script run_sweep.sh permette di riprodurle, e questo è un punto a favore della trasparenza.

Cosa manca e quali sono i limiti

DeepSeek è esplicita su ciò che questa release non contiene. Per costruire uno stack di servizio completo servono ancora un sistema di cache KV, la disaggregazione tra prefill e decode e il bilanciamento del carico tra repliche in data parallelism. Il README precisa che gran parte delle funzioni di motore necessarie alla disaggregazione è già implementata, ma il pacchetto non è un prodotto chiavi in mano.

Per ora il modello supportato è uno solo, DeepSeek V4.1 Flash. Chi sperava di usare il motore con altri modelli dovrà aspettare eventuali aggiornamenti o contribuire direttamente al repository.

Un limite da tenere presente anche per la sicurezza: i motori di inferenza sono software critico. Come abbiamo visto con la vulnerabilità critica di LMCache legata a vLLM, un componente dello stack di serving può diventare una superficie di attacco, e un progetto giovane con pochi commit richiede revisione attenta prima di finire in produzione.

Perché conta per chi sviluppa e per il mercato

Il primo effetto è pratico. Un motore di inferenza open source e pensato per un modello Mixture of Experts di grandi dimensioni abbassa la barriera per chi vuole ospitare in proprio un modello aperto, invece di dipendere da un fornitore. Per aziende con vincoli di privacy o di costo è un’opzione concreta da valutare.

Il secondo effetto è competitivo. La velocità di generazione è ormai un terreno di scontro, come mostra anche Mercury 3 di Inception, un modello a diffusione che punta a oltre mille token al secondo. DeepSeek risponde su un altro piano, quello del software di esecuzione, dimostrando che l’efficienza si conquista tanto con l’architettura del modello quanto con l’ingegneria che lo fa girare.

Il terzo effetto riguarda la geopolitica del calcolo. Il supporto esplicito alle NPU Huawei Ascend 950 accanto alle GPU NVIDIA indica un ecosistema che non vuole dipendere da un solo fornitore di hardware, un tema sempre più centrale nel settore.

Resta da vedere quanto la community adotterà il progetto. Il repository mostra già un forte interesse, con oltre 12mila stelle e più di mille fork secondo la pagina GitHub al momento della consultazione.

Conclusioni: cosa fare adesso

DeepInfer non è un prodotto per tutti, ma è un segnale chiaro: DeepSeek condivide ciò che usa davvero in produzione e lo fa con una licenza permissiva. Se gestisci infrastrutture AI o sviluppi servizi basati su modelli aperti, leggi il README, prova l’esempio di inferenza offline e confronta i risultati con il tuo stack attuale.

Se invece usi i modelli solo tramite API, tieni d’occhio l’evoluzione del progetto: i miglioramenti di efficienza scoperti in questo tipo di software tendono, prima o poi, a tradursi in prezzi più bassi e risposte più rapide. Seguici per gli aggiornamenti su DeepSeek e sull’infrastruttura AI.