A dire il vero, sono rimasto sorpreso. Quando ho collegato due unità DGX Spark in cluster e ho eseguito DeepSeek-V4-Flash, il risultato è stato 1,78x più veloce nel tempo di generazione totale (tempo reale a parete) rispetto al Mac Studio M3 Ultra, il che significa che ha completato l'attività in circa la metà del tempo. E questo con la DGX Spark che eseguiva il modello FP8 ufficiale senza alcuna quantizzazione aggiuntiva.
Mentre eseguivo questi benchmark, ho avuto la sensazione che il punto che ho sostenuto più volte fosse stato nuovamente confermato dai numeri. Ovvero:
Le prestazioni di un LLM non possono essere misurate solo dalla velocità di decodifica (token al secondo, TPS) basata sulla larghezza di banda della memoria.
Potenza di elaborazione della GPU, comunicazione tra nodi, gerarchia di memoria, qualità della quantizzazione, lunghezza del contesto, elaborazione parallela e così via: è l'"equilibrio" di tutti questi fattori a determinare l'esperienza utente reale. E la DGX Spark aveva semplicemente un equilibrio migliore.
Il Benchmark Utilizzato: Il Coding Benchmark di shi3z
Per la misurazione, ho utilizzato il benchmark di coding del Japanese LLM Benchmark di shi3z. Il compito è "completare una chat app che gira su React in una singola generazione." Il codice generato viene effettivamente avviato in Docker e testato automaticamente utilizzando Playwright per login, amici, DM e aggiornamenti in tempo reale, con un punteggio funzionale su 80 punti.
I risultati dell'esecuzione di DeepSeek-V4-Flash Q4 (quantizzazione a 4 bit) su un Mac Studio M3 Ultra tramite il motore di inferenza ds4 di antirez sono elencati nel repository di shi3z. La tabella seguente confronta quei risultati con quelli di questa volta con il cluster di 2 unità DGX Spark + FP8 ufficiale.
Risultati del Benchmark
Perché "Perde in tok/s ma Vince in Tempo Reale a Parete"
Se guardi la tabella e pensi: "Aspetta, il Mac è più veloce in tok/s," hai ragione. Osservando solo la velocità istantanea di generazione di un token (decodifica TPS), il Mac Studio M3 Ultra è 1,58x più veloce. Ciò è dovuto all'enorme larghezza di banda della memoria di Apple Silicon.
Tuttavia, c'è un trabocchetto. Per completare la stessa chat app con "punteggio perfetto 80/80", il Mac ha scritto 8.036 token, mentre la DGX Spark ne ha scritti 2.866. C'è una differenza di circa 2,8x.
Entrambi hanno utilizzato DeepSeek-V4-Flash senza degradazione ufficiale della qualità, ma è naturale interpretare che il lato Mac, quantizzato a Q4, sia diventato ridondante, mentre il lato Spark, eseguendo in FP8 a piena qualità, sia rimasto conciso. È un fenomeno comune in cui l'impatto della quantizzazione sulla distribuzione dell'output non si manifesta nella velocità di decodifica ma influenza silenziosamente la strategia di generazione.
Di conseguenza, il calcolo è il seguente:
Tempo Reale a Parete = (Token di Output) ÷ (tok/s)
Mac: 8.036 ÷ 26,2 = 307 secondi Noi: 2.866 ÷ 16,6 = 172 secondi
Perdere in tok/s ma vincere in tempo reale a parete significa "raggiungere la stessa risposta corretta in meno passaggi." Nell'uso pratico, ciò che gli umani sperimentano è il "tempo fino al completamento dell'attività," non il tok/s istantaneo.
Configurazione Utilizzata
- Hardware: DGX Spark × 2 (NVIDIA GB10, basato su Blackwell, 128 GB di memoria unificata ciascuno)
- Interconnessione Nodi: Connessione diretta tramite ConnectX-7 200 Gbps RoCE (Tensor Parallel = 2, backend distribuito PyTorch)
- Motore di Inferenza: La ricetta di Aiden, che integra b12x (un set di kernel CuTe DSL specifici per GB10) in vLLM 0.21.1dev
- Modello: DeepSeek-V4-Flash FP8 ufficiale (154 GB, attenzione FP8, MoE MXFP4—questo è il formato ufficiale rilasciato da DeepSeek)
- Contesto: 524.288 token (512K), util 0,82, cache KV 19,85 GiB, concorrenza 3,89×
- Predizione Multi-Token (MTP): Decodifica speculativa con un tasso di accettazione di circa il 62% (guadagnando velocità senza sacrificare la qualità dell'output)
Uno Sguardo Più Approfondito alle Prestazioni
Oltre ai numeri di questo benchmark, ho misurato separatamente le velocità di decodifica pura e prefill:
- Velocità di Decodifica Pura (Testo breve, escluso TTFT): Stabile a circa 39 tok/s
- Velocità di Prefill (Contesto ampio): 1.277 tok/s (Questo è circa 6,5x più veloce dei 196 tok/s della vecchia configurazione senza kernel b12x)
- Decodifica con Contesto Lungo: Anche aumentando da 8K → 64K → 128K → 256K → 512K → 768K, la velocità di decodifica non è diminuita drasticamente; anzi, è accelerata (106 tok/s a 768K). Questo perché l'Attenzione Sparsa (DSA) di DeepSeek è implementata nativamente nei kernel b12x, rendendo i calcoli di attenzione quasi indipendenti dalla lunghezza del contesto.
Questo è un Risultato con "Nessuna Quantizzazione, Piena Qualità"
Un altro punto che voglio sottolineare è che il lato DGX Spark non ha utilizzato alcuna quantizzazione aggiuntiva sul modello. Abbiamo caricato i 154 GB ufficiali distribuiti su HuggingFace così come sono e li abbiamo eseguiti nel formato di quantizzazione ufficiale progettato da DeepSeek: attenzione FP8 + MoE MXFP4.
Nel mondo degli LLM locali, è diventato senso comune comprimere modelli enormi a IQ2 (2 bit) o Q4 per farli funzionare, ma questi riducono sicuramente la qualità. In effetti, in precedenza ho provato la versione IQ2XXS (2 bit) di DeepSeek-V4-Flash e ho visto un risultato di 55/80 + collasso del comportamento dell'agente sullo stesso benchmark. La quantizzazione non è un pranzo gratis.
Una configurazione che può garantire 256 GB di memoria unificata con due DGX Spark rende l'opzione di "eseguire modelli enormi a piena qualità" una realtà per la prima volta. Penso che questo sia un avanzamento più significativo di quanto i numeri suggeriscano.
Perché l'"Equilibrio" di Spark ha Funzionato
Analizzando gli elementi tecnici che hanno supportato questo risultato:
- Suite di Kernel b12x: Quattro tipi di kernel (NVFP4 fused MoE GEMM, NVFP4 dense GEMM, FP8 paged attention e sparse MLA attention) scritti specificamente per GB10 / SM12.x utilizzando CuTe DSL. A differenza del percorso MARLIN in vLLM generale, questi calcolano direttamente in modalità fusa senza dequantizzare.
- Connessione Diretta RoCE 200 Gbps: Sebbene l'all-reduce TP=2 da nodo a nodo avvenga due volte per layer, la connessione diretta a 200 Gbps mantiene una latenza effettiva ridotta, quindi non diventa un collo di bottiglia per la decodifica.
- 128 GB di Memoria Unificata × 2: Un vantaggio di Grace Blackwell, che non separa HBM e DDR. Consente di suddividere il modello FP8 ufficiale da 154 GB tra due unità così com'è, con spazio sufficiente per una cache KV da 19,85 GiB per un contesto di 512K.
- Implementazione Nativa dell'Attenzione Sparsa di DeepSeek (DSA): I kernel b12x gestiscono correttamente il design in cui la complessità dell'attenzione non dipende dalla lunghezza del contesto utilizzando le operazioni sparse native di GB10. Questo ha portato al risultato in cui la velocità di decodifica non crolla con la lunghezza del contesto.
In altre parole, se solo uno di questi elementi—larghezza di banda della memoria, potenza di calcolo, comunicazione tra nodi, ottimizzazione del contesto lungo o qualità della quantizzazione—fosse eccezionale, questo risultato non si sarebbe verificato. Spark fornisce tutti questi elementi a un livello superiore rispetto a qualsiasi configurazione a macchina singola nella stessa fascia di prezzo. Questa è la vera natura del suo "equilibrio."
Cosa Cambia nell'Uso Pratico?
Per andare oltre la teoria astratta, ecco alcuni vantaggi concreti:
- Il riassunto e l'analisi del codice di documenti enormi diventano realistici: Con un contesto di 512K e una velocità di prefill di 1.277 tok/s, puoi caricare e riassumere un intero libro (~300.000 token) in circa 4 minuti.
- I loop degli agenti non si bloccano: Con una concorrenza di 3,89×, puoi eseguire chat e riassunti di testi lunghi simultaneamente (ad esempio, con Hermes Agent) senza che la decodifica collassi.
- Niente problemi di "Agente tutto fumo" a causa di un fallimento della quantizzazione: Questa è una trappola in cui sono caduto molte volte con i modelli della serie IQ2; a piena qualità, semplicemente non accade.
- Competitivo con Mac in termini di consumo energetico: Il consumo energetico totale di due GB10 durante l'inferenza è di circa 100W–140W, che è vicino al Mac Studio M3 Ultra a pieno regime. Considerando le prestazioni 1,78x, l'efficienza energetica non è male.
Conclusione: L'Era di Giudicare le Prestazioni degli LLM Solo dal TPS è Finita
La velocità istantanea di generazione di un token—il decode TPS—è certamente una metrica importante. Tuttavia, è come la "velocità massima di una corsa sui 100 metri." Ciò che serve nella pratica è il "tempo per raggiungere la stessa risposta corretta," la "qualità della risposta," "quanti possono essere eseguiti simultaneamente," "quanto contesto può essere gestito" e "se i loop degli agenti funzionano." Questi sono i punteggi totali.
Ciò che questo risultato ha mostrato è che la DGX Spark sta iniziando a prendere il comando in questo punteggio totale. Siamo entrati in un'era in cui puoi eseguire un modello enorme a qualità ufficiale, con contesto lungo, mantenendo la compatibilità con gli agenti, a 1,78x la velocità a parete di un Mac Studio, semplicemente collegando due unità in un cluster.
Negli ultimi anni, la gente ha detto "gli LLM sono solo larghezza di banda della memoria" e "il decode TPS è tutto," ma dopo aver effettivamente eseguito Spark, sento che la mia affermazione "l'equilibrio è la prestazione pratica" è stata finalmente provata dai numeri.
È stata annunciata anche la RTX Spark, e c'è la sensazione che le cose si stiano scaldando più del previsto (anche se l'atmosfera potrebbe raffreddarsi una volta che il prezzo sarà fuori...). Ho grandi aspettative che la comunità cresca e che si accumulino più ottimizzazioni e know-how!
Jensen è davvero incredibile... Il suo regno continuerà a lungo?
**
**
**
**
**
Bonus
I lettori più attenti potrebbero avere questa critica:
"Allora non sarebbe un confronto equo se avessi eseguito il FP8 ufficiale originale anche sul Mac Studio?"
"Non è un confronto sleale? Il Mac Studio è diventato ridondante solo perché è stato quantizzato a Q4. Se avessi eseguito il FP8 ufficiale originale sul Mac Studio, non sarebbe sullo stesso piano in termini di qualità?" Questa è una domanda ragionevole.
Per andare dritti al punto: Attualmente, non c'è modo di eseguire il 'FP8 ufficiale originale + MXFP4 MoE' su un Mac Studio a velocità praticabili.
- Prima di tutto, non esiste un motore di inferenza compatibile.
Non sembra esserci un motore che supporti completamente il formato ufficiale di DeepSeek-V4-Flash (attenzione FP8 + MoE MXFP4 + Lightning Indexer + Attenzione Sparsa DSA) su Apple Silicon (secondo una ricerca di Claude Code).
- MLX (Il framework LLM ufficiale di Apple per Apple Silicon): Nessuna implementazione nativa di MXFP4 fused MoE GEMM, nessuna attenzione paginata FP8 e nessuna implementazione MLX dell'Attenzione Sparsa DSA di DeepSeek. Se provassi a eseguirlo, probabilmente saresti costretto a fare upcast a bf16.
- llama.cpp: Non può caricare MXFP4 direttamente, quindi richiede una ri-quantizzazione in GGUF = si finisce per convertirlo in Q4 / Q5 / IQ2, ecc., e non è più la versione "originale ufficiale".
- vLLM: Il supporto per Apple Silicon è limitato in partenza, e kernel specifici per GB10 come b12x non funzioneranno su un Mac.
- antirez/ds4: Questo è un motore specializzato scritto basato su MLX specificamente per DeepSeek V4 Flash con il presupposto di Q4. È la soluzione ottimale attuale per eseguirlo su Mac Studio, ma non è costruito per gestire "FP8 originale."
Il fatto che antirez abbia scritto un motore dedicato per DeepSeek V4 Flash specificamente per Q4 testimonia la realtà che attualmente non esiste un percorso praticabile per eseguire la qualità ufficiale così com'è su Apple Silicon.
- Anche se fosse eseguito con upcast bf16, la larghezza di banda sarebbe quasi interamente consumata.
Per amor di discussione, supponiamo che qualcuno crei un'implementazione MLX che faccia l'upcast dei pesi ufficiali in bf16. Puoi stimare cosa accadrebbe con un calcolo approssimativo della larghezza di banda:
- DeepSeek-V4-Flash ha una configurazione MoE con circa 30B parametri attivi.
- A Q4 (4 bit), i parametri attivi occupano circa 15 GB, e ds4 raggiunge 26,2 tok/s (misurato).
- Se lo stesso modello è mantenuto in FP8 (8 bit), i parametri attivi occupano circa 30 GB = 2x il requisito di larghezza di banda = teoricamente ~13 tok/s sullo stesso motore.
- Inoltre, fare upcast a bf16 in MLX richiede circa 60 GB per i parametri attivi = 4x il requisito di larghezza di banda = teoricamente ~6,5 tok/s.
- Poiché la larghezza di banda effettiva della memoria del Mac Studio M3 Ultra è di circa 800 GB/s, leggere 60 GB per ogni token colpirebbe il limite di larghezza di banda.
In altre parole, la scelta di "avere la qualità originale" su Apple Silicon attualmente ha il costo di "sacrificare più del doppio della velocità." Eseguire a 26,2 tok/s con ds4 + Q4 è stata una scelta più pratica che ottenere solo 6 tok/s con bf16 a piena qualità.
- È qui che entra in gioco il vantaggio strutturale di Spark.
D'altra parte, questa configurazione DGX Spark esegue il "FP8 ufficiale originale + MXFP4 MoE nativamente." Questo è supportato da:
- La suite b12x di kernel specifici per GB10, che ha implementazioni per eseguire NVFP4 fused MoE GEMM e attenzione paginata FP8 "senza dequantizzazione."
- Questo non è stato ancora scritto per Apple Silicon.
- Di conseguenza, Spark è attualmente l'unica soluzione realistica per eseguire "qualità ufficiale così com'è" e "a velocità praticabili."
Per riassumere, se guardi solo alla larghezza di banda hardware, il valore assoluto del Mac Studio per una singola unità è a un livello simile, ma la presenza o assenza di "implementazioni di kernel che eseguono nativamente i formati di quantizzazione ufficiali" crea una differenza decisiva. Il vantaggio di Spark non deriva solo dal chip, ma dall'intera combinazione con lo stack software specializzato per GB10 come b12x.
Se qualcuno scrivesse in futuro MXFP4 fused MoE GEMM, attenzione paginata FP8 e Attenzione Sparsa DSA per Apple Silicon in MLX, questa premessa crollerebbe. Il panorama cambierà a seconda delle implementazioni della comunità. Per ora, il fatto è che Spark è un passo avanti nel raggiungere la combinazione di "qualità ufficiale × velocità praticabile."
Questi sono i risultati dell'analisi fornita da Claude Code.
