DGX Spark, i cluster arrivano a otto nodi con 1 TB di memoria
Il GLM 5.3 di Z.ai nella versione completa, 753 miliardi di parametri, pesa circa 470 GB nel formato NVFP4 e ora, secondo Nvidia, gira su otto DGX Spark collegati in cluster. Il supporto ufficiale ai cluster a otto nodi, annunciato al GTC Berlin, è nel post del blog per sviluppatori di Nvidia del 22 ottobre 2026. Per chi fa IA in locale cambia il tetto di memoria: con quattro nodi si arrivava a 512 GB, con otto si sale a 1 TB.
Cosa entra in 1 TB di memoria unificata
I benchmark riguardano DGX Spark da 128 GB di memoria unificata: quattro nodi ne sommano 512, otto arrivano a 1 TB. Dal 23 ottobre è disponibile presso i partner anche una configurazione da 64 GB, da distinguere quando si calcola la memoria del cluster. Nvidia spiega che con questa capacità si aprono modelli che su quattro nodi non partivano, tra cui il GLM 5.3 completo, che definisce uno dei più grandi modelli aperti servibili in locale.
Nvidia riporta anche le prestazioni. Sul GLM 5.3 completo (nvidia/GLM-5.3-NVFP4) su otto nodi, misurato con MTP3 e prefill a 8K token di input per richiesta, la generazione cambia così con il numero di richieste in parallelo:
- 1 richiesta: 31 token al secondo in totale e 31 per utente;
- 4 richieste: 51 token al secondo in totale, 21 per utente;
- 8 richieste: 67 token al secondo in totale, 18 per utente.
Il prefill (la lettura del prompt) resta a 1.600 token al secondo in totale; per utente scende da 1.600 a 750 e poi a 473. Nvidia dichiara circa 80 token al secondo in generazione con GLM 5.3 Flash su otto nodi, valore che giudica adatto allo sviluppo interattivo in locale.
Come scala la velocità: due, quattro, otto nodi
Per isolare l’effetto del cluster, Nvidia ha misurato un modello denso, Qwen3.8-27B in NVFP4, senza speculative decoding né MTP, con una richiesta alla volta, 8.192 token in ingresso e 256 in uscita (strumento llama-benchy). Lo scaling è calcolato rispetto a un singolo Spark.
| Nodi | Topologia | Prefill (token/s) | Decode (token/s) | Scaling decode |
|---|---|---|---|---|
| 1 | — | 2.635 | 11,86 | 1,00x |
| 2 | Connessione diretta | 3.285 | 21,71 | 1,838x |
| 4 | Anello fisico | 4.446 | 32,82 | 2,77x |
| 4 | Switch (RoCEnante) | 4.556 | 36,34 | 3,06x |
| 8 | Anello fisico | 4.962 | 40,11 | 3,38x |
| 8 | Switch (RoCEnante) | 5.105 | 52,58 | 4,43x |
La generazione cresce da circa 12 a 52 token al secondo; il prefill, a otto nodi, non arriva a due volte il valore di partenza.
A far la differenza sullo switch è RoCEnante, un backend di comunicazione collettiva pensato per Spark. Riduce la latenza dell’all-reduce, l’operazione con cui i nodi si scambiano i risultati parziali nel decode tensor-parallel. A otto nodi porta lo scaling del decode a 4,43x contro 3,05x senza, un miglioramento del 45% in efficienza di scaling. A quattro nodi Nvidia indica circa il 21% di decode in più (NVFP4). Il backend è integrato in FlashInfer e, se il test di avvio fallisce, ripiega in automatico su NCCL, la libreria di comunicazione di Nvidia.
Anello senza switch o switch: cosa serve in ciascun caso
Per scalare un modello sui nodi servono le schede di rete NVIDIA ConnectX-7 e la comunicazione RoCE (RDMA su Ethernet). I nodi possono anche essere cablati direttamente fra loro ad anello, senza switch: costa meno e si configura più facilmente. Nvidia lo indica come la soluzione più semplice ed economica per un’inferenza a quattro nodi, dove NCCL usa già algoritmi ad anello.
Per otto nodi Nvidia consiglia uno switch, ma riporta anche benchmark con otto nodi ad anello fisico. Lo switch serve in questi casi, elencati da Nvidia:
- cluster da dividere in gruppi indipendenti, per esempio due da quattro;
- carichi con comunicazione any-to-any o basati su MPI;
- uso di RoCEnante, che richiede lo scambio diretto fra ogni coppia di nodi.
RoCEnante ha anche un limite dichiarato: con molti utenti in parallelo, cluster più grandi o anelli, secondo Nvidia rende meglio NCCL, che resta il default supportato. Nel post l’azienda dice di stare ancora valutando il backend.
Più modelli sullo stesso cluster con Switchyard
NeMo Switchyard smista le richieste fra pool di modelli su un cluster a otto nodi con switch. Un classificatore leggero esamina ogni richiesta o sessione e la manda al pool adatto, mentre un load balancer distribuisce il traffico sulle repliche. Nel prototipo, su un benchmark di tool use, l’agente con routing ha eguagliato la qualità della configurazione con solo Qwen, liberando capacità sul cluster.
Con tre repliche Qwen da due nodi ciascuna e due repliche MiniCPM da un nodo ciascuna, Nvidia riporta circa 1,5x di throughput aggregato rispetto al solo Qwen quando metà delle richieste va a Qwen, e circa 3,0x quando ne va a Qwen un quarto. La politica di routing è un file YAML e Nvidia ne fornisce uno di esempio da adattare al proprio carico.
Training di piccoli modelli: scaling quasi lineare
Per l’addestramento Nvidia ha fatto un pre-training da zero di un modello nanochat da circa 896,5 milioni di parametri. Ogni nodo tiene una copia completa del modello e l’unica comunicazione tra nodi è la sincronizzazione dei gradienti a ogni passo, quindi lo scaling resta vicino al lineare.
| Nodi | Token/s | Speedup | Efficienza di scaling |
|---|---|---|---|
| 1 | 8.741 | 1,00x | 100,0% |
| 2 | 17.202 | 1,97x | 98,4% |
| 4 | 33.640 | 3,85x | 96,2% |
| 8 | 68.079 | 7,79x | 97,4% |
Nvidia presenta quindi il cluster a otto nodi come una piattaforma credibile per addestrare piccoli modelli da zero, non solo per servire modelli grandi.
Tempi, prezzi e come provarlo
Il supporto ai cluster a otto nodi in NVIDIA Sync, dove il Cluster Assistant gestisce setup e dispositivi, arriverà entro fine anno. Il post non indica prezzi di DGX Spark o dello switch, né disponibilità in Italia.
Per partire, Nvidia rimanda a quattro risorse:
- la guida di rete per collegare più DGX Spark, che parte da due nodi e sale;
- la guida per servire LLM con vLLM su DGX Spark;
- la guida di compatibilità dei modelli;
- le risorse su Switchyard per il routing fra più modelli.
Il codice dell’esperimento nanochat è pubblicato su GitHub, per riprodurlo o adattarlo al proprio modello.
