DeepSeek V4.1 Flash: +60% throughput sulle stesse GPU
DeepSeek V4.1 Flash aumenta il throughput su un sistema NVIDIA GB300 NVL72 invariato dopo circa un mese di ottimizzazione dello stack di serving. Secondo i risultati di Artificial Analysis riportati nel resoconto sulle ottimizzazioni software, la generazione per un singolo agente passa da 596 a 848 token al secondo, un incremento del 42%. Il guadagno del 60% riguarda invece il throughput per GPU ad alta concorrenza, mantenendo ciascun agente vicino a 80 token al secondo.
La distinzione è decisiva: non si tratta di un’accelerazione uniforme di ogni richiesta, né di un miglioramento equivalente dell’intero ciclo operativo di un agente. Il risultato mostra quanto margine possa restare nell’hardware già installato, ma non dimostra ancora risparmi energetici o una riduzione proporzionale del costo totale. Il punto è capire quali condizioni dello stack rendano riproducibile quel margine.
DeepSeek V4.1 Flash: due guadagni, due condizioni di servizio
Il confronto riguarda lo stesso sistema GB300 NVL72, senza sostituzione dell’hardware. Cambiano software e configurazione: il risultato va quindi interpretato come progresso nell’esecuzione del modello, non come prova di maggiori capacità di ragionamento o migliore qualità del codice prodotto.
La misura sul singolo agente descrive la velocità di generazione in quel regime; quella ad alta concorrenza misura quanta attività complessiva viene sostenuta per GPU conservando una determinata velocità per agente. Sono obiettivi diversi. Un servizio interattivo può privilegiare la risposta della singola sessione, mentre un’infrastruttura condivisa deve anche sostenere più sessioni simultanee senza degradare il servizio.
Il +60% non significa dunque che ogni agente completi il proprio lavoro nel 60% di tempo in meno. Anche considerando soltanto il serving, throughput aggregato, velocità individuale e latenza della richiesta non sono metriche intercambiabili.
vLLM, FlashInfer e Dynamo: i cinque interventi sul serving
Il resoconto attribuisce il miglioramento a cinque cambiamenti: kernel vLLM più recenti e specifici per il modello, autotuning FlashInfer per attenzione e moltiplicazioni di matrici, maggiore copertura dei CUDA graph, migliore configurazione dello speculative decoding e colocazione di prefill e decode tramite NVIDIA Dynamo con vLLM. Non è riportato quanto contribuisca ciascun intervento separatamente.
I meccanismi agiscono su costi diversi. Kernel specializzati e autotuning cercano implementazioni adatte alle operazioni e alle forme dei tensori del workload; i CUDA graph riducono l’overhead di lancio delle sequenze di operazioni coperte. Lo speculative decoding tenta invece di accelerare la generazione proponendo token da verificare: il beneficio dipende anche dall’accettazione delle proposte e dal costo della verifica.
Il cambiamento architetturale più rilevante riguarda prefill, ossia l’elaborazione del contesto in ingresso, e decode, la generazione successiva. La configurazione precedente impiegava pool GPU separati; quella nuova esegue entrambe le fasi sulle stesse GPU, riutilizzando sul posto la cache KV, che conserva chiavi e valori dell’attenzione.
Nei dialoghi lunghi questo può evitare il trasferimento della cache tra i due pool. Il vantaggio è coerente con un workload che riusa molto contesto, ma non rende la colocazione universalmente superiore: concentrare le due fasi sulle stesse risorse modifica anche la contesa tra elaborazione dei prompt e generazione. La scelta dipende dal traffico effettivo.
AA-AgentPerf e Rubin: cosa dimostrano i confronti
AA-AgentPerf riproduce traiettorie registrate di agenti di programmazione su più turni. Gli input vanno da circa 1.000 a 131.000 token, con una media intorno a 27.000; gli output hanno una mediana di circa 150 token e un 95° percentile vicino a 2.000. Il benchmark riutilizza i turni precedenti attraverso la cache KV: misura quindi un comportamento più specifico della semplice generazione da prompt indipendenti.
Resta però un test del model serving. La latenza end-to-end comprende anche chiamate agli strumenti, avvio delle sandbox, esecuzione del codice, accesso allo storage e rete. Non sono riportate misure sufficienti della latenza al primo token o della sua distribuzione per tradurre il throughput in un livello di servizio completo. La distinzione tra prestazioni misurate e capacità operative vale anche rispetto ai benchmark di cybersecurity di DeepSeek: cambia il test, non la necessità di delimitarne le conclusioni.
I risultati Vera Rubin NVL72 presentati da NVIDIA aggiungono un confronto hardware: 1.249 token al secondo nel test sul singolo agente, contro 848 su GB300, ossia 1,47 volte. A una velocità richiesta di 260 token al secondo per agente, il throughput per GPU raggiunge invece 5 volte il riferimento GB300; a 80 token al secondo, il vantaggio scende a 1,7 volte. Per questi ultimi confronti mancano i valori assoluti: GB300 è normalizzato a 1. Il vantaggio relativo dipende dunque dal servizio richiesto, non soltanto dal nome dell’acceleratore.
A100: compatibilità possibile, ma con dipendenze diverse
Un distinto resoconto di self-hosting su otto A100 descrive DeepSeek-V4.1-Flash-1017 con GPUStack e una singola istanza vLLM in tensor parallelism a otto GPU. Riporta circa 129 token al secondo per un singolo flusso e 1.537 token di output al secondo con input da 1.000 token e output da 2.000. Condizioni diverse impediscono un confronto diretto con AA-AgentPerf.
A100 non dispone di Tensor Core FP8 e FP4 nativi: la configurazione utilizza kernel Marlin, fallback Triton, offload su CPU ed emulazione per gestire i formati descritti nel checkpoint. GPUStack segnala 78,47 GiB allocati sugli 80 disponibili per ciascuna GPU. La compatibilità esiste, ma con margini di memoria ridotti e uno stack specifico; inoltre il test non verifica un prompt completo da un milione di token. Una finestra di contesto dichiarata non equivale alla sua sostenibilità operativa su qualsiasi configurazione.
Il risparmio dipende dall’utilizzo, non dal solo benchmark
Per riprodurre il risultato GB300 occorre trattare lo stack come una dipendenza versionata: kernel vLLM, impostazioni FlashInfer, copertura CUDA graph, speculative decoding e politica di collocazione Dynamo. Le tracce di validazione devono riflettere lunghezze dei prompt, output, concorrenza e riuso della cache reali. Altrimenti si rischia di replicare la configurazione senza replicarne il beneficio.
Più throughput sullo stesso hardware può ridurre il costo per token quando la capacità aggiuntiva viene utilizzata. Non prova però una riduzione dei consumi: mancano misure energetiche comparabili e dati sui joule per token. Restano inoltre manutenzione, collaudo e gestione delle regressioni.
Il beneficio immediato riguarda chi esegue workload agentici simili su GB300 e può aggiornare e validare lo stack. Prima di acquistare nuova capacità, questi risultati giustificano una verifica del margine software. Il vincolo successivo resta la latenza dell’intero workflow: accelerare il modello serve meno se strumenti, sandbox o storage continuano a determinare il tempo di completamento.