Che cos'è DeepInfer? Il motore di inferenza di DeepSeek e le parti che non ha rilasciato

DeepInfer è il framework di inferenza che DeepSeek ha pubblicato il 16 ottobre 2026 con licenza Apache-2.0, e serve esattamente un modello: DeepSeek-V4.1-Flash, con DeepSeek-V4.1-Flash-1017 come checkpoint predefinito. Questa portata limitata a un singolo modello è la prima cosa da capire, perché spiega quasi tutto il resto del repository. Non è un framework di serving generico che include per caso una configurazione DeepSeek. È il percorso di codice che DeepSeek esegue in produzione, ridotto alle parti generalizzabili, ed è trasparente riguardo a questo taglio: l'elenco presente nel README di ciò che serve a un servizio di inferenza completo, e di ciò che questa release non include, menziona un sistema di cache KV, la disaggregazione VE/Prefill/Decode e il bilanciamento del carico tra repliche data-parallel. Quello che ottieni è il percorso di calcolo — kernel, parallelismo, decodifica speculativa, scheduling, output strutturato. Quello che non ottieni è il livello di archiviazione e routing che rende economico da gestire su larga scala il percorso di calcolo. DeepSeek ne spiega il motivo: quei componenti sono strettamente accoppiati all'infrastruttura interna, quindi il design è descritto in un articolo pubblicato mentre il codice resta interno.

Cosa c'è effettivamente nel repository

L'elenco delle funzionalità pubblicato si legge come un tour dei colli di bottiglia nel servire un grande modello mixture-of-experts. Ci sono le librerie di kernel che DeepSeek ha rilasciato in precedenza — FlashMLA per l'attenzione, DeepGEMM per le moltiplicazioni matriciali, DeepEP per la comunicazione expert-parallel, più TileKernels e DeepSelect. C'è lo schema di parallelismo: l'attenzione viene eseguita come parallelismo dei dati con parallelismo del contesto bilanciato, la metà MoE viene eseguita come parallelismo degli esperti con un bilanciatore di carico expert-parallel. C'è DSpark, lo stack di decodifica speculativa, con lunghezze di verifica pianificate anziché fisse. C'è SWA bounded replay, il meccanismo che impedisce a una cache di attenzione a finestra scorrevole di forzare una ricomputazione completa a ogni cache miss. Ci sono la pianificazione asincrona dei batch, l'inferenza invariante rispetto al batch con campionamento deterministico e l'output strutturato vincolato da regex, schema JSON o EBNF.

Il punto di ingresso è deliberatamente piccolo. Dopo aver impostato DEEPINFER_ACCELERATOR su nvidia o sull'equivalente Ascend ed eseguito build.sh, il repository include examples/offline_inference.py, che esegue il checkpoint predefinito dall'inizio alla fine. DEEPINFER_HF_MODEL_DIR lo punta a una directory di pesi diversa. I benchmark pubblicati sono stati misurati su quattro GPU SM100 per il prefill e 64 GPU SM100 per il decode, che è la configurazione del deployment per cui il motore è stato scritto e non una demo da laptop.

Il README indica anche da dove proviene il codice, cosa che vale la pena sapere prima di leggerlo. Il motore è stato originariamente costruito principalmente su vLLM, con ispirazione progettuale tratta da SGLang e TensorRT-LLM. Questa discendenza si vede nella struttura — lo scheduler, l'interfaccia di paged attention e il percorso di campionamento appariranno familiari a chiunque abbia letto quei progetti — e spiega perché il rilascio sia un fork di uno stack di serving anziché un'architettura scritta da zero. Ciò che DeepSeek ha aggiunto è la parte specifica del proprio modello: il deployment disaggregato, il wide expert parallelism con il suo balancer, il replay a finestra scorrevole e DSpark.

Ciò che non contiene, e perché questo conta di più

I tre pezzi mancanti non sono piccole omissioni. Ciascuno è un sistema che deve esistere prima che il motore gestisca traffico di produzione, e ciascuno è costoso in modo diverso.

• Il sistema di cache KV.Il riutilizzo dei prefissi è dove si concentra la maggior parte del guadagno in un carico di lavoro di chat, perché un hit della cache sostituisce un prefill. Senza un archivio cache, ogni richiesta ricalcola il proprio prompt. La stessa documentazione di DeepSeek descrive l'archivio che utilizza: un cluster 3FS dedicato anziché la memoria locale dell'host, proprio affinché qualsiasi macchina di prefill possa accedere a qualsiasi prefisso e la capacità della cache possa essere scalata indipendentemente dalla potenza di calcolo.

• Disaggregazione di VE/Prefill/Decode. Il README nota che la maggior parte della funzionalità lato engine esiste già nella release; ciò che manca è il deployment. Disaggregare il vision encoder, il prefill e il decode consente di dimensionare ogni fase in base al proprio collo di bottiglia e di controllare il time-to-first-token separatamente dal time-between-tokens. Questa è una decisione infrastrutturale, non un flag.

• Bilanciamento del carico tra repliche data-parallel. DeepSeek utilizza quattro bilanciatori — prefill, decode, vision encoder ed expert-parallel — e li descrive tutti e quattro nel documento. Nessuna delle logiche di routing viene distribuita. Senza di essa, una flotta di repliche vale solo quanto il router che le si mette davanti, e un router round-robin ingenuo distruggerà il tasso di successo della cache che lo store è stato progettato per proteggere.

Letti insieme, l'omissione ti dice che tipo di artefatto sia questo. DeepInfer è un'implementazione di riferimento del percorso di calcolo, pubblicata affinché il lavoro sul kernel e sulla schedulazione possa essere ispezionato e riutilizzato, non una distribuzione da installare e a cui indirizzare il traffico.

Il gate hardware è il vero filtro

DeepInfer è pensato per NVIDIA SM100 e Huawei Ascend 950. Non esiste un percorso Ampere né un percorso Hopper, il che esclude la maggior parte delle GPU presenti oggi nella maggior parte dei cluster. Il resto della toolchain è altrettanto specifico: solo Linux, GCC 13 o superiore, Python 3.12, CUDA 13 per NVIDIA o CANN 9.2 per Ascend. E non ci sono affatto release: il repository non aveva alcuna release pubblicata quando è stato consultato il 21 ottobre 2026, quindi non c'è nulla da scaricare e nulla su cui fissare una versione. Lo cloni e lo compili con la tua toolchain.

Quella combinazione è insolita per una release open source con così tanta attenzione, ed è meglio leggerla come un’accurata dichiarazione dell’ambito piuttosto che come una svista. I kernel nel repository sono scritti per un set di istruzioni specifico e un’interconnessione specifica; i numeri nel README provengono da quell’hardware. Portare il percorso di calcolo a una generazione precedente è esattamente il tipo di lavoro che una community svolge rapidamente e che un’organizzazione di ingegneria non può promettere. Nel giro di pochi giorni dalla release è apparso su GitHub un porting di terze parti rivolto a componenti NVIDIA più vecchi, il che è un segnale utile sulla domanda e nessun segnale circa se i valori di throughput pubblicati sopravvivano al porting.

La configurazione di deployment che DeepSeek esegue realmente

La documentazione sull'architettura è il punto in cui le ipotesi del repository diventano comprensibili. Il sistema è disaggregato in un encoder visivo, prefill e decode, più nodi di archiviazione dedicati. Il prefill utilizza un parallelismo degli esperti da 2 a 8 con un corrispondente parallelismo dei dati, scegliendo la configurazione più piccola consentita dalla HBM. Il decode va nella direzione opposta: parallelismo degli esperti e parallelismo dei dati da 64 a 128, che DeepSeek chiama Wide-EP, usando la configurazione più grande consentita dalle GPU disponibili. Il parallelismo tensoriale e il parallelismo del contesto non vengono affatto utilizzati. L'encoder visivo esegue una GPU per istanza, con GPU più economiche consigliate, perché l'encoder non è dove vanno i soldi.

La più piccola implementazione che abbia senso deriva da quei numeri. Verranno eseguite una GPU prefill e una GPU decode e, in pratica, il rapporto tra i due pool è all'incirca uno a uno. Ma poiché decode richiede 64 GPU o più per ottenere il vantaggio del parallelismo degli esperti, la più piccola unità efficiente è 64 GPU prefill più 64 GPU decode. Questo è il numero da tenere a mente quando si legge qualsiasi affermazione sull'efficienza di DeepInfer: le cifre descrivono un'implementazione da 128 GPU, e metà di essa è una fase.

Dividere prefill e decode tra data center è tecnicamente possibile perché DeepSeek-V4.1-Flash comprime sostanzialmente la sua cache KV, e la distribuzione di DeepSeek stessa colloca effettivamente i nodi di inferenza in data center diversi ma adiacenti. Il budget è di circa 400 Gbps di interconnessione ogni otto GPU, e il documento è schietto sul costo in termini di affidabilità — la fibra tra edifici è facile da tagliare.

Perché la decodifica è così diffusa

Un ampio parallelismo degli esperti è la scelta più importante in assoluto nel design, ed è facile interpretarlo erroneamente come un trucco di scalabilità. In un layer mixture-of-experts, ogni token entra in contatto con un piccolo numero di esperti, quindi il costo di un passo di decodifica è dominato dallo spostamento dei pesi e delle attivazioni degli esperti più che dall'intensità aritmetica. Distribuire gli esperti su 64 o 128 GPU riduce il traffico di memoria per passo contribuito da ciascuna GPU, il che aumenta i token al secondo se — e questa è la condizione — il carico tra gli esperti rimane uniforme. È a questo che serve il bilanciatore di carico per il parallelismo degli esperti.

Le impostazioni di DeepSeek sono abbastanza specifiche da poter essere copiate. Per il prefill, ogni GPU mantiene quattro esperti ridondanti oltre a quelli che possiede, le statistiche vengono raccolte su una finestra di 100 passi e gli esperti vengono riassegnati ogni 1.000 passi, con i pesi rimescolati all'interno del gruppo tramite la memoria condivisa NVLink. Lo squilibrio misurato — il rank più lento diviso per la media — è risultato pari a 1,074 per una configurazione EP4/DP4 e a 1,045 per EP2/DP2. Per il decode le impostazioni si dilatano: un esperto ridondante per GPU, una finestra delle statistiche di 1.000 passi, riassegnazione ogni 10.000 passi e uno squilibrio misurato di 1,090. La differenza tra i due è il punto centrale. Il prefill vede un lavoro a raffiche ed eterogeneo e richiede un ribilanciamento rapido; il decode vede un flusso costante e può permettersi una finestra lunga, quindi ribilancia di rado e non paga quasi nulla per questo privilegio.

Il lato del routing ha la stessa impostazione. Le richieste di prefill vengono raggruppate per lunghezza totale del contesto in quattro livelli — sotto 16K, da 16 a 64K, da 64 a 256K e 256K e oltre — e i motori vengono assegnati ai livelli in base alla quota di domanda computazionale di ciascun livello nel round precedente. All'interno di una GPU, la dimensione del chunk per ogni passo di prefill non è fissa: un modello di costo quadratico calibrato prevede quanto tempo richiederà un passo in base al numero di token della sequenza e al prefisso già calcolato, e lo scheduler calcola il chunk più grande che rientra in un budget di 32.768 token entro il tempo rimanente. Il bilanciatore di decode bilancia due dimensioni contemporaneamente, il numero di richieste e la lunghezza totale della cache KV, inviando le richieste brevi alle GPU con bassa concorrenza e cache lunga, e le richieste lunghe alle GPU con cache piccola. La sintesi di DeepSeek su quanto tutto questo renda: circa l'80% di un benchmark offline perfettamente bilanciato.

La cache e la questione dei tre giorni

La cache KV risiede su un cluster 3FS dedicato, non nella memoria locale dell'host, e questa decisione guida il resto della progettazione dello storage. I dati sono archiviati con codifica erasure 10+2, quindi ogni gruppo di codifica sopravvive a due guasti simultanei di nodo; una lettura invia richieste a tutti gli 11 nodi del gruppo e qualsiasi 10 risposte sono sufficienti per decodificare. Un worker di garbage collection viene eseguito su ogni nodo di storage ed elimina secondo LRU oltre una watermark. Il server consigliato dispone di 20 unità a stato solido da 30,73 TB ciascuna e sostiene almeno 40 GB/s in lettura e 5 GB/s in scrittura, dimensionato per conservare circa 24 ore di dati per server. In pratica il cluster funziona a circa 14,4 TB di cache logica per GPU online, con capacità fisica maggiore di quella.

La residenza è il punto in cui il compromesso diventa visibile. Non esiste una logica di scadenza lato cache; il TTL è impostato lato storage a tre giorni per il traffico degli agenti e a sette giorni per il traffico dei chatbot, su un cluster che contiene circa 100 petabyte di storage a stato solido. La suddivisione esiste perché il traffico dei chatbot ha una coda lunga di hit molto più pesante — una piccola quantità di cache viene letta molte volte, quindi perderla costa, in termini di hit rate complessivo, più di quanto il volume suggerisca. Il costo misurato da DeepSeek per ridurre la conservazione dei chatbot a tre giorni è dello 0,5-1 percento dell'hit rate della cache. È un numero piccolo che finisce per rappresentare una grande quantità di prefill ricalcolato.

L'attenzione a finestra scorrevole riceve una cache separata con regole diverse. La cache SWA non entra nei blocchi paginati; ogni sequenza occupa uno slot di dimensione fissa nella memoria host e, per DeepSeek-V4.1-Flash, i layer memorizzati sono i primi 20. Persiste solo quella regione: 20 layer per 134 token per 528 byte, ovvero 1,415,040 byte per sequenza in formato MXFP8. Nulla va al cluster di storage; rimane nella memoria della macchina che l'ha prodotto, con una directory in memoria che registra quale macchina conserva cosa, e un hit cross-machine lo recupera attraverso una VLAN a 400 Gbps.

I due meccanismi che producono le cifre principali

Il replay limitato è il più interessante dei due perché prende un costo illimitato e lo rende costante. Normalmente, una mancata corrispondenza nella cache a finestra scorrevole implica il ricalcolo della finestra dall'inizio, e il costo cresce con la lunghezza del contesto e il numero di livelli. DeepSeek, invece, ricalcola solo i 128 token più recenti e tronca la finestra di attenzione a quel segmento, producendo una cache SWA approssimativa a un prezzo fisso. Sul lato encoder, questo disaccoppia completamente la lunghezza del prefisso in cache hit dalla cache SWA: se la cache SWA manca, vengono riprodotti gli ultimi 128 token del prefisso in cache hit mentre la cache dei blocchi viene riutilizzata intatta.

Il lato decoder è quello in cui il risparmio è maggiore. In questa architettura la block cache dei layer del decoder viene proiettata dallo hidden state dell'ultimo layer dell'encoder, quindi solo la SWA cache del decoder deve essere calcolata per layer — e ricostruirla esattamente significherebbe far passare gli ultimi 2.560 token attraverso 20 layer del decoder a ogni prefill. Riproducendo invece 128 token e usando il risultato solo per il decode, senza lasciarlo entrare nella prefix cache, si quasi dimezza il calcolo totale del prefill. Quel singolo cambiamento vale più della maggior parte delle ottimizzazioni dei kernel, ed è il tipo di cosa che solo un team che possiede l'architettura del modello può fare.

Il contributo di DSpark è più modesto e più convenzionale. I token bozza hanno probabilità di accettazione diverse a seconda della richiesta e della posizione, quindi verificare cinque bozze fisse per passo spreca calcolo su token che verranno rifiutati. Una testa di confidenza prevede il tasso di accettazione di ciascun token bozza, e lo scheduler ordina le bozze in base al rendimento atteso e verifica solo il prefisso che massimizza il throughput. In produzione il modello bozza genera comunque cinque token per passo; il numero verificato scende da 5,00 a un valore compreso tra 3,2 e 4,4, un taglio di circa il 30 percento, mentre la lunghezza accettata si muove appena: 3,29 contro 3,20. A giudicare dai dati di benchmark EP64/DP64, ciò equivale a un throughput superiore del 4-7 percento con circa 60 sequenze concorrenti per rank. A esattamente 60, il throughput per rank passa da 13.730 a 14.466 token al secondo. Sotto circa 16 sequenze concorrenti la tecnica comporta una piccola perdita netta, cosa che vale la pena sapere prima di adottarla per un deployment a basso traffico.

Che cosa significa la cifra di 155 trilioni

Il numero più citato associato a questo rilascio è un singolo cluster che serve 155 trilioni di token al giorno con un ricavo complessivo di 38 dollari USA per GPU-ora a prezzi valley. Entrambe le metà sono dichiarate dal fornitore e nessuna delle due è un benchmark riproducibile, il che non le rende prive di interesse — una cifra di ricavo per GPU-ora è un tipo di affermazione genuinamente diverso da un numero di throughput, perché racchiude utilizzo, prezzi e tasso di cache hit in un'unica riga. È anche la cifra che più probabilmente viene citata senza i suoi qualificatori, quindi i qualificatori meritano di essere messi per iscritto: un cluster, prezzi valley, ricavo anziché costo, e aggregato su prefill, decode e vision encoder.

Due comunicazioni più piccole sono più direttamente utili. Al kernel di decodifica FlashMLA nel repository pubblico manca un'ottimizzazione assembly messa a punto manualmente che la versione interna possiede, il che lo rende dal 5 al 10 percento più lento isolatamente; DeepSeek afferma che le prestazioni end-to-end differiscono al massimo del 5 percento. E il modello bozza interno per la decodifica speculativa è più recente di quello pubblicato, con una differenza di prestazioni descritta come piccola. Entrambe le affermazioni stabiliscono un'aspettativa su quanta parte delle prestazioni pubblicate una terza parte possa raggiungere copiando il codice, e la risposta è: la maggior parte, a condizione che l'hardware corrisponda.

Il repository, così com'è

L'istantanea sopra è stata realizzata il 21 ottobre 2026 e mostra la pagina che riporta 16,3k stelle. L'API di GitHub, interrogata lo stesso giorno, restituiva 16.590 stelle, 1.649 fork e 176 issue aperte, con le issue disabilitate e la discussione indirizzata a GitHub Discussions. Il numero di stelle ha continuato a salire da allora, quindi leggi ogni cifra qui come un'indicazione temporale anziché come una proprietà del codice. Un traffico di quella entità in meno di una settimana dice più dell'interesse per lo stack di serving di DeepSeek che della maturità del codice, e il conteggio di zero release dice il resto.

Se stai pensando di eseguirlo tu stesso

Il riassunto onesto è che DeepInfer vale la pena di essere letto con attenzione ed è difficile da gestire. Quattro domande ti diranno se è adatto.

• Hai SM100 o Ascend 950? Tutto il resto della toolchain dipende da questo. Senza l'acceleratore giusto i numeri pubblicati non sono trasferibili, e i port della community non sono validati su scala di produzione.

• Puoi eseguire 64 GPU di decode in un unico dominio di comunicazione? Il parallelismo esperto ampio non è un'ottimizzazione che puoi saltare; è la configurazione attorno a cui è stato progettato il percorso di decode. Al di sotto di quella scala, stai eseguendo un sistema diverso con lo stesso nome.

• Hai già una cache dei prefissi? In caso contrario, stai confrontando il percorso di calcolo di DeepInfer con uno stack concorrente che ne include una, e il confronto apparirà peggiore di quanto il design meriti.

• Puoi permetterti di scrivere il livello di routing? Il prefill bucketing, il bilanciamento del decode e la riassegnazione degli esperti sono descritti in modo sufficientemente dettagliato da poter essere reimplementati, e reimplementarli richiede settimane di lavoro che il repository non fa per te.

Se preferisci non possedere nessuno degli elementi sopra indicati

Per la maggior parte dei team la domanda pratica non è come distribuire DeepSeek-V4.1-Flash, ma dove chiamarlo. Il modello è disponibile tramite un'API compatibile senza dover costruire un cluster da 128 GPU o reimplementare un load balancer, ed è lo stesso modello di cui questo articolo ha descritto l'architettura — stessa gestione del contesto, stesso comportamento in output strutturato, senza il lavoro di disaggregazione.

Il confronto da fare non è quale motore sia più veloce in astratto, perché le cifre pubblicate sono misurazioni dichiarate dal fornitore su hardware che la maggior parte dei lettori non possiede. È se il carico di lavoro sia uno in cui un TTL della cache di 3 giorni e un pool di decodifica da 64 GPU cambiano il prezzo, oppure uno in cui una richiesta ogni pochi secondi tramite un'API è semplicemente più economica di qualsiasi operazione descritta sopra. Per il secondo caso — che è la maggioranza dei casi — la giusta quantità di DeepInfer da usare è nessuna, e la giusta quantità da leggere è tutta. Inizia da la pagina del modello DeepSeek V4.1 Flash se vuoi l'endpoint; inizia dal README del repository se vuoi sapere cosa sta facendo l'endpoint.