Supporto H100 in DeepInfer: cosa significa l’elenco ufficiale

La risposta breve per i team H100 e RTX

Il supporto DeepInfer per H100 non è stato annunciato né documentato ufficialmente. Anche il supporto RTX non risulta documentato. La release attuale è destinata a DeepSeek-V4.1-Flash e indica hardware NVIDIA SM100 con CUDA 13 oppure Ascend 950 con CANN 9.2. Il repository richiede inoltre Linux, GCC 13 o versioni successive e Python 3.12 (repository ufficiale di DeepInfer).

“Non indicato” è un verdetto di supporto da tenere in considerazione per acquisti e pianificazione della produzione, non la prova che una patch sperimentale non possa mai essere compilata.

Cosa supporta ufficialmente DeepInfer oggi

Il perimetro del supporto è più preciso di un generico “GPU NVIDIA” o “modello DeepSeek”: comprende una specifica generazione di acceleratori, uno stack software definito e un determinato percorso per il modello.

La documentazione Q&A sul deployment di DeepSeek riporta topologie di benchmark con 4 GPU SM100 per il prefill e 64 GPU SM100 per il decode in un dominio scale-up. Si tratta di misurazioni su SM100, non di stime della capacità di H100.

Perché SM100 non significa automaticamente H100 o RTX

L’elenco ufficiale di DeepInfer non cita H100, SM90 né alcun modello RTX. La sola compatibilità con CUDA non basta a dimostrare la compatibilità con DeepInfer.

Il repository integra componenti sensibili all’architettura, tra cui FlashMLA, DeepGEMM, DeepEP e operazioni TileLang (documentazione del progetto). Anche quando una GPU viene riconosciuta, l’esecuzione può comunque fallire, produrre risultati errati o perdere proprio quel vantaggio prestazionale che aveva motivato la migrazione.

Per questo è importante distinguere tre affermazioni:

1. Il codice viene compilato per una determinata architettura.
2. Il modello produce risultati corretti e mantiene stabile il comportamento distribuito.
3. Il deployment raggiunge latenza e throughput utili.

Una compilazione completata dimostra soltanto la prima. I materiali pubblici di DeepInfer non forniscono benchmark su H100 o RTX, una procedura ufficiale di build per SM90 né una configurazione RTX consumer validata.

Percorsi di migrazione per l’infrastruttura esistente

Se il cluster usa H100 o un altro sistema Hopper

Non sostituire uno stack di serving H100 funzionante solo per provare DeepInfer. Considera l’eventuale porting un progetto sperimentale, non un deployment supportato.

Un piano di migrazione sensato prevede di:

1. Lasciare invariato il model server in produzione.
2. Creare un branch isolato con versioni fissate di DeepInfer, CUDA, driver, compilatore e modello.
3. Fare l’inventario delle dipendenze specifiche dell’architettura prima della compilazione.
4. Eseguire test di confronto numerico rispetto a un runtime noto e affidabile.
5. Misurare la latenza di prefill, la latenza di decode, la concorrenza, l’uso della memoria e il recupero dagli errori.
6. Promuovere il porting solo se migliora il carico di lavoro che conta davvero per il team.

L’alternativa pratica consiste nel valutare un runtime di serving che documenti esplicitamente la configurazione H100, come vLLM, SGLang o TensorRT-LLM. La scelta va fatta in base al checkpoint DeepSeek esatto, alla quantizzazione, alle funzionalità API e alla topologia distribuita necessarie, non sulla base dei numeri di DeepInfer ottenuti su SM100.

Se il team usa workstation o server RTX

L’elenco ufficiale di DeepInfer non cita alcun modello RTX. Inoltre, la topologia di benchmark documentata è pensata per l’inferenza su larga scala: una singola scheda RTX o un piccolo pool RTX non va considerato un sostituto economico delle configurazioni da 4 GPU per il prefill o 64 GPU per il decode.

Se l’obiettivo è lo sviluppo, la valutazione o un endpoint self-hosted di dimensioni ridotte, usa un runtime generale per l’inferenza locale. Tieni DeepInfer sotto osservazione in vista di un futuro porting specifico per architettura, ma non pianificare il budget sulla base di un issue non integrato o di una voce comparsa su un forum.

Se hai accesso a SM100 o Ascend 950

È l’unico percorso che corrisponde alla matrice ufficiale attuale. Anche in questo caso, però, DeepInfer non è un servizio API online completo: le note ufficiali sul deployment indicano l’assenza di componenti di produzione come la cache KV persistente, l’orchestrazione tra prefill e decode e il bilanciamento del carico tra repliche.

DeepInfer è quindi più adatto ai team che vogliono studiare o sottoporre a benchmark il motore, dispongono della topologia di acceleratori richiesta e sono pronti a costruire la piattaforma circostante. Non è automaticamente la scelta migliore per un gateway API multi-modello.

Vincoli del deployment oltre la GPU

Il supporto hardware è solo uno dei requisiti da verificare durante una migrazione. La release pubblica viene descritta come una soluzione per l’inferenza offline, non come un server OpenAI-compatible completo. Le funzionalità mancanti hanno conseguenze dirette sulle scelte architetturali:

Il progetto separato deepseek-recipe converte i formati Messages, Chat Completions e Responses, ma non esegue l’inferenza e non fornisce da solo il servizio completo per la produzione.

Checklist da verificare prima di cambiare hardware

Prima di approvare una migrazione a DeepInfer, chiedi evidenze per ciascuno di questi punti:

1. Supporto ufficiale dell’architettura e della build: la GPU esatta è indicata e una macchina pulita riesce a riprodurre l’ambiente con versioni fissate?
2. Copertura di kernel e correttezza: i kernel per attention, GEMM e parallelismo degli esperti producono output coerenti, risposte strutturate e un comportamento corretto su contesti lunghi?
3. Prestazioni distribuite: il numero di GPU e la topologia di interconnessione previsti restano stabili con i livelli di concorrenza e gli obiettivi di memoria richiesti?
4. da dove arrivano cache KV, routing, autenticazione, trasporto HTTP e bilanciamento delle repliche?