Workstation AI vs DGX Spark
02-10-2026
Memoria, VRAM, banda, modelli e prezzi in euro. Come scegliere l'hardware locale per 1-4 utenti
AI
02-10-2026
Memoria, VRAM, banda, modelli e prezzi in euro. Come scegliere l'hardware locale per 1-4 utenti
Per scegliere tra una workstation con RTX 5090 o RTX PRO, un NVIDIA DGX Spark, un Mac Studio o un sistema a memoria unificata non basta confrontare TOPS e teraflop. Prima bisogna capire quale risorsa limita davvero il carico: capacità di memoria, banda, latenza, contesto o richieste concorrenti.
Questa guida confronta le principali piattaforme per l'AI locale con dati verificati al 2 ottobre 2026, esempi su modelli open-weight, KV cache, RAG e due semplici calcoli in C#. L'obiettivo è pratico: capire quale hardware serve davvero a una persona o a un team di 2-4 utenti, evitando sia macchine sottodimensionate sia acquisti inutilmente costosi.
| Se il vincolo principale è... | Piattaforma da valutare | Perché |
|---|---|---|
| Modello che non entra in 32-96 GB ma serve CUDA | DGX Spark / più Spark | 128 GB unificati per nodo e stack NVIDIA |
| Modello entro 32 GB e priorità alla velocità | RTX 5090 | banda molto alta e ottime prestazioni per euro se il modello entra |
| 72-96 GB, affidabilità e uso professionale | RTX PRO 5000/6000 | più VRAM, ECC, MIG e opzioni multi-GPU |
| Modelli molto grandi senza requisito CUDA | Mac Studio M5 Ultra | fino a 512 GB e 1,2 TB/s di banda |
| 128 GB su x86 a costo più basso | Ryzen AI Max+ / Strix Halo | molta memoria condivisa, con ecosistema software diverso da CUDA |
È l'architettura che conosciamo tutti. La GPU ha la sua memoria (GDDR7 sulle schede attuali), separata dalla RAM di sistema gestita dalla CPU. Per ottenere le prestazioni migliori conviene che pesi, cache e tensori necessari all'inferenza restino nella VRAM; quando si ricorre a offload verso la RAM di sistema, il modello può continuare a funzionare ma il trasferimento attraverso PCIe diventa spesso un collo di bottiglia.
Esempio concreto: la RTX PRO 6000 Blackwell ha 96 GB di GDDR7 ECC con una banda di 1.792 GB/s [46]. Un modello che richiede più di 96 GB non entra interamente su una singola scheda: per usarlo bisogna quantizzarlo, fare offload oppure distribuirlo su più GPU.
Il DGX Spark fa l'opposto. Il chip GB10 mette CPU e GPU nello stesso sistema Grace Blackwell e le fa lavorare su un unico pool coerente da 128 GB di LPDDR5X. CPU e GPU non devono quindi essere dimensionate su due budget separati di RAM e VRAM, e molti flussi possono evitare le copie esplicite tipiche di una GPU discreta [5][10]. Questo non significa che ogni allocazione sia gratuita: runtime, cache e workspace continuano a consumare memoria dello stesso pool.
La differenza si vede subito con un esempio: un modello da 70 miliardi di parametri in FP16 richiede circa 140 GB per i soli pesi. Non entra in una scheda da 96 GB. A 8 bit il minimo teorico dei pesi scende a circa 70 GB e a 4 bit a circa 35 GB, lasciando sullo Spark spazio variabile per cache, runtime e contesto a seconda del formato e dell'architettura.
| Componente | Valore |
|---|---|
| Chip | NVIDIA GB10 Grace Blackwell |
| CPU | 20 core Arm (10 Cortex-X925 + 10 Cortex-A725) |
| Memoria | 128 GB LPDDR5X unificata, bus a 256 bit |
| Banda di memoria | 273 GB/s |
| Prestazioni AI | fino a 1 petaFLOP in FP4 |
| Storage | da 1 a 4 TB NVMe (autocrittografante nella Founders Edition) |
| Rete | ConnectX-7 a 200 Gb/s, 10 GbE, Wi-Fi 7 |
| Alimentazione | alimentatore da 240 W, TDP del chip 140 W |
| Sistema operativo | DGX OS (basato su Ubuntu 24.04) |
Fonti: [5][7][8].
NVIDIA supporta oggi lo scaling da uno a quattro Spark: due nodi portano la memoria fisica complessiva a 256 GB e sono indicati da NVIDIA per inferenza fino a modelli di circa 400B parametri; quattro nodi, collegati attraverso la rete RoCE/ConnectX-7, sono indicati fino alla classe 700B [54]. La memoria resta distribuita tra i nodi: non diventa un singolo banco locale con la latenza della LPDDR5X.
Questo è il punto centrale del confronto: capacità e velocità non sono la stessa cosa.
Nel decode single-stream di un modello denso, soprattutto a batch basso, la banda di memoria è spesso il principale collo di bottiglia. A ogni passo devono essere attraversati gran parte dei pesi del modello; una roofline molto semplice è quindi banda / byte dei pesi letti per token. Se un modello richiede idealmente 35 GB di letture e la memoria trasferisce 273 GB/s, il tetto puramente bandwidth-bound è nell'ordine di 7-8 token/s. È un limite teorico, non una previsione universale: kernel, quantizzazione, cache, attention, batching e speculative decoding possono spostare parecchio il risultato.
I numeri:
Risultato pratico: nei confronti citati, sui modelli che entrano in entrambe le macchine una workstation con GPU dedicata può risultare da circa 2 a 7 volte più veloce nel decode, a seconda di modello, quantizzazione, runtime e carico [6]. È un ordine di grandezza osservato, non un moltiplicatore universale: Spark privilegia cosa ci sta, la GPU discreta quanto rapidamente può correre quel workload.
C'è una sfumatura importante. L'inferenza di un LLM ha due fasi:
Il GB10 dispone di Tensor Core di quinta generazione e supporto FP4, ma la sua banda di 273 GB/s è molto inferiore a quella delle GPU discrete di fascia alta. Per questo può risultare relativamente competitivo nel prefill e molto meno nel decode di modelli densi. Un confronto pubblicato ad agosto 2026 lo mostra bene: contro un Mac Studio M3 Ultra, il DGX Spark elaborava il prompt circa 3,8 volte più velocemente, mentre il Mac generava token circa 3,4 volte più in fretta [11].
Tradotto: se il tuo lavoro consiste nel dare in pasto al modello documenti lunghi e ottenere risposte brevi (classificazione, estrazione, ricerca su archivi aziendali), il Spark può essere più competitivo di quanto suggeriscano i soli benchmark di decode. Se invece produci risposte molto lunghe con un modello denso e batch basso, la banda tende a pesare molto di più.
Per ragionare senza farsi guidare dal marketing basta un'aritmetica molto semplice. Ma bisogna distinguere due cose:
parametri × bit / 8;Il primo numero serve per capire gli ordini di grandezza; per decidere se un modello entra davvero in memoria va sempre controllata la dimensione del file o del checkpoint che si intende usare. Per esempio, 27,8 miliardi di parametri a 4 bit danno 13,9 GB ideali, ma un Qwen3.8-27B Q4_K_M reale occupa circa 17-19 GB a seconda della conversione [49].
Questo primo programma C# stima:
// Stime di ordine di grandezza, non benchmark.
// La dimensione reale di un file Q4 può essere superiore a params × 4 / 8.
// Anche la roofline del decode non è una previsione: runtime, kernel, batch,
// attention, quantizzazione e speculative decoding possono cambiare molto il risultato.
static double IdealWeightsGB(double paramsB, double bitsPerWeight)
=> paramsB * bitsPerWeight / 8.0;
// KV cache classica: 2 (K e V) × layer × kv_heads × head_dim × byte × token.
// Non è universale: MLA, sliding-window e architetture ibride possono comportarsi diversamente.
static double KvCacheGB(Model m, int contextTokens, double bytesPerElem = 2)
=> 2.0 * m.Layers * m.KvHeads * m.HeadDim * bytesPerElem * contextTokens / 1e9;
// Roofline bandwidth-bound: banda / dimensione ideale dei pesi attivi.
static double DecodeRooflineTokS(Machine hw, Model m, double bitsPerWeight)
=> hw.BandwidthGBs / IdealWeightsGB(m.ActiveParamsB, bitsPerWeight);
var dense70b = new Model("Denso 70B ipotetico", 70, 70, Layers: 80, KvHeads: 8, HeadDim: 128);
var machines = new[]
{
new Machine("DGX Spark", 128, 273),
new Machine("RTX PRO 6000", 96, 1792),
new Machine("Mac Studio M5 Ultra", 256, 1200),
};
double bits = 4;
int ctx = 128_000;
double idealWeights = IdealWeightsGB(dense70b.ParamsB, bits);
double kv = KvCacheGB(dense70b, ctx);
Console.WriteLine($"Pesi ideali: {idealWeights:F1} GB, KV @128k: {kv:F1} GB, " +
$"totale minimo: {idealWeights + kv:F1} GB\n");
foreach (var hw in machines)
{
bool fitsAsLowerBound = idealWeights + kv < hw.MemoryGB * 0.9;
Console.WriteLine($"{hw.Name,-22} stima minima ci sta: {(fitsAsLowerBound ? "sì" : "no"),-3} " +
$"roofline decode ≈ {DecodeRooflineTokS(hw, dense70b, bits):F0} token/s");
}
record Model(string Name, double ParamsB, double ActiveParamsB,
int Layers, int KvHeads, int HeadDim);
record Machine(string Name, double MemoryGB, double BandwidthGBs);
Output (arrotondato):
Pesi ideali: 35.0 GB, KV @128k: 41.9 GB, totale minimo: 76.9 GB
DGX Spark stima minima ci sta: sì roofline decode ≈ 8 token/s
RTX PRO 6000 stima minima ci sta: sì roofline decode ≈ 51 token/s
Mac Studio M5 Ultra stima minima ci sta: sì roofline decode ≈ 34 token/s
Quattro cose da notare:
4 bit non significa automaticamente 0,5 byte per parametro su disco o in memoria. Per il capacity planning bisogna usare l'artifact reale.parametri attivi × bit / 8 resta una stima ideale: shared expert, attention, router, batch e token instradati verso expert diversi aumentano il traffico effettivo.Per questo una macchina con molta memoria ma banda relativamente bassa, come Spark, può essere molto più interessante con alcuni MoE che con un denso di pari dimensione totale. I benchmark reali restano indispensabili: un utente che usa DGX Spark riporta circa 50,7 token/s su un modello da 27 miliardi servito con SGLang [8], un numero impossibile da ricavare correttamente dalla sola banda senza conoscere architettura e runtime.
Come slogan è utile, ma va interpretato bene: due GPU da 32 GB hanno davvero 64 GB di VRAM fisica complessiva, però non formano automaticamente un unico pool trasparente da 64 GB. Ogni scheda continua ad avere il proprio spazio di memoria.
Per far girare un modello più grande della VRAM di una singola scheda bisogna distribuirlo:
Una parte della VRAM viene inoltre usata da runtime, workspace e KV cache. La formulazione più precisa quindi è: due schede da 32 GB possono ospitare un modello shardato sfruttando quasi 64 GB aggregati, ma non equivalgono a una singola GPU da 64 GB e non garantiscono il doppio delle prestazioni. Vanno messi in conto software, topologia PCIe, alimentazione, raffreddamento e spazio nel case.
È la domanda a cui Syspack dedica un altro articolo [2]: per l'AI in locale serve davvero una scheda professionale, o basta la top di gamma consumer?
| Scheda | VRAM | Banda | Consumo | ECC | MIG (partizionamento) |
|---|---|---|---|---|---|
| GeForce RTX 5090 | 32 GB GDDR7 | 1.792 GB/s | fino a 575 W circa | no | no |
| RTX PRO 5000 Blackwell 48 GB | 48 GB GDDR7 | — | 300 W | sì | sì |
| RTX PRO 5000 Blackwell 72 GB | 72 GB GDDR7, bus 384 bit | 1.344 GB/s | 300 W | sì | sì |
| RTX PRO 6000 Max-Q | 96 GB GDDR7, bus 512 bit | 1.792 GB/s | 300 W | sì | fino a 4 istanze |
| RTX PRO 6000 Workstation | 96 GB GDDR7, bus 512 bit | 1.792 GB/s | 600 W | sì | fino a 4 istanze |
Fonti: [29][31][43][45][46][47].
Cosa ci dice la tabella:
In sintesi: la RTX 5090 può essere eccellente per una persona e anche per piccoli carichi condivisi se il modello, la KV cache e il runtime entrano nei 32 GB. Le RTX PRO diventano interessanti quando servono più capacità, isolamento, affidabilità o densità multi-GPU, non semplicemente perché la 5090 sarebbe troppo lenta.
Un aspetto che rende la scelta più difficile oggi rispetto a un anno fa è il prezzo. Il mercato DRAM del 2026 resta sotto forte pressione: a fine settembre TrendForce descriveva il mercato ancora sottocapacità e stimava ulteriori aumenti dei prezzi contrattuali nel quarto trimestre [56]. Le macchine “ricche di memoria” sono quindi particolarmente esposte alla volatilità dei componenti.
Per uniformare il confronto, in questa sezione tutti i prezzi sono espressi in euro. Quando la fonte riportava dollari USA ho applicato il cambio di riferimento BCE del 1° ottobre 2026: 1 € = 1,1298 $, cioè 1 $ ≈ 0,8851 €. Le conversioni sono arrotondate e servono a confrontare gli ordini di grandezza: non equivalgono a un prezzo retail europeo, che può includere IVA, dazi, margini e condizioni commerciali diverse [57].
DGX Spark. Il prezzo di lancio statunitense equivale a circa 3.540 € al cambio indicato. A febbraio 2026 NVIDIA ha aumentato quel listino di circa 620 € equivalenti, citando la scarsità di memoria [7][12]. A settembre 2026 il prezzo più basso osservato su Amazon USA corrispondeva a circa 4.430 € [7]. In Europa, però, un distributore tedesco riporta prezzi reali tra 5.038 e 8.096 € netti, a seconda di marca e storage, con la variante più economica (Lenovo ThinkStation PGX da 1 TB, senza sistema operativo) in consegna a metà ottobre [7]. La differenza fra conversione e prezzo europeo mostra perché i due valori non vanno confusi.
Tutti i modelli OEM (Lenovo, Dell, HP, ASUS, MSI, Acer, Gigabyte) usano lo stesso GB10 con 128 GB: cambiano storage, chassis, raffreddamento, sistema operativo preinstallato e disponibilità [7].
RTX PRO 6000 Blackwell. Il prezzo di lancio statunitense equivale a circa 7.580 €. Nel corso del 2026 il marketplace NVIDIA è salito a circa 11.730 € equivalenti [13], e ad agosto il listino statunitense ha raggiunto circa 14.160 € [14]. Sul mercato secondario USA, a settembre, la media dei prezzi più bassi corrispondeva a circa 13.100 € al cambio utilizzato [15].
RTX PRO 5000 Blackwell 72 GB. A fine settembre il prezzo più basso rilevato tra i rivenditori europei era di circa 11.200 euro [31].
RTX 5090. La scheda consumer con 32 GB di VRAM è stata travolta dalla stessa ondata: a metà settembre su Amazon USA si superavano circa 5.750 € equivalenti al cambio BCE utilizzato, con segnalazioni di acquisti in blocco da parte di aziende che la usano per costruire workstation AI [14]. Anche qui si tratta della conversione di un prezzo USA, non di un listino europeo.
Workstation complete. Per avere un'idea dei costi "chiavi in mano" in Italia, questi sono alcuni prezzi di listino Syspack (IVA esclusa) rilevati per questo articolo [33]:
| Configurazione | Prezzo (IVA esclusa) |
|---|---|
| Core Ultra 9 285K, 128 GB RAM, 1× RTX PRO 5000 72 GB | ~16.550 € |
| Threadripper 9970X, 256 GB RAM, 1× RTX PRO 6000 96 GB | ~34.990 € |
| Threadripper PRO 9985WX, 512 GB RAM, 2× RTX PRO 6000 96 GB | ~70.370 € |
| Threadripper PRO 9995WX, 512 GB RAM, 3× RTX PRO 6000 Max-Q | ~92.835 € |
C'è un modo utile di leggere tutti questi numeri, proposto da un rivenditore statunitense: il DGX Spark costa poco per gigabyte di memoria, ma tanto per gigabyte al secondo di banda [12]. Le due letture sono entrambe valide: quale conta dipende dal modello e dal carico che vuoi eseguire.
Il confronto non si ferma a Spark e workstation NVIDIA: nel 2026 sono emerse alternative con profili di memoria e software molto diversi.
Annunciato da Apple il 25 agosto 2026 e disponibile dal 22 settembre, Mac Studio con M5 Ultra arriva fino a 512 GB di memoria unificata con 1,2 TB/s di banda [48]. È quindi molto più vicino a una workstation ad altissima capacità che a un normale desktop consumer. Per dare un ordine di grandezza coerente con il resto dell'articolo, il listino USA citato nelle fonti equivaleva a circa 4.870 € per la configurazione di ingresso; l'upgrade fino a 256 GB aggiungeva circa 3.540 € equivalenti, portando quella configurazione a circa 8.410 € al cambio BCE usato qui [18]. Sono conversioni del listino USA, non prezzi Apple Italia.
Nella recensione citata in precedenza, il M5 Ultra ha generato token quasi quattro volte più velocemente del DGX Spark su uno specifico modello Qwen da 27 miliardi quantizzato a 4 bit [18][19]. È un benchmark utile, ma non va generalizzato a qualunque modello o runtime.
Il limite principale resta l'ecosistema: niente CUDA. Lo stack Apple ruota attorno a MLX, Core AI e runtime compatibili come LM Studio e llama.cpp. Per chi sviluppa codice destinato a infrastruttura NVIDIA, una macchina CUDA evita una classe di differenze fra ambiente locale e produzione.
D'altra parte il Mac non è più soltanto una macchina "da singolo utente": Apple supporta clustering di più Mac Studio attraverso Thunderbolt 5 e RDMA, con un pool di memoria distribuito e fino a 3× le prestazioni di inferenza rispetto a un singolo sistema nel test dichiarato da Apple [48]. Lo stack di serving multiutente più maturo resta comunque nel mondo CUDA, quindi va distinto ciò che l'hardware può fare da quanto è semplice gestirlo come server condiviso.
NVIDIA ha annunciato i sistemi RTX Spark con Windows 11 basati sul superchip N1X [44]. La configurazione superiore combina CPU Grace a 20 core e GPU Blackwell da 6.144 CUDA core con fino a 128 GB di LPDDR5X unificata; la variante inferiore usa 18 core CPU e 5.120 CUDA core con fino a 64 GB, non 24-32 GB [44].
Al 2 ottobre 2026 NVIDIA presenta ancora la piattaforma come disponibilità in arrivo, quindi è più prudente parlare di prime consegne annunciate/attese per ottobre invece che di consegne già iniziate. Tra i produttori annunciati figurano diversi grandi OEM [21][23].
È la stessa idea generale del GB10 portata più vicino al mercato PC Windows: memoria unificata capiente, GPU Blackwell e CUDA in un sistema compatto. Attenzione però al nome e alla configurazione: "RTX Spark" descrive una famiglia, non una quantità fissa di memoria. Prima di comprare bisogna controllare RAM installata, TDP, chassis e banda effettiva del modello specifico.
È l'alternativa x86 più economica per avere 128 GB di memoria unificata sulla scrivania: 16 core Zen 5, GPU integrata Radeon 8060S, LPDDR5X-8000 su bus a 256 bit. In pratica la GPU può indirizzarne circa 96 GB [25]. Gira Windows e Linux, ma l'ecosistema ROCm è meno maturo di CUDA. Lo stesso distributore europeo citato sopra la elenca tra le alternative dirette al Spark [7].
All'estremo opposto c'è la DGX Station con il superchip GB300: 748 GB di memoria coerente, di cui 252 GB di HBM3e a 7,1 TB/s e 496 GB di LPDDR5X a 396 GB/s, fino a 20 petaFLOP in FP4, rete ConnectX-8 fino a 800 Gb/s e alimentatore da 1.600 W [26]. Un integratore statunitense la lista a partire da circa 84.020 € equivalenti al cambio BCE utilizzato [27]; in Europa il prezzo indicativo rilevato è invece intorno ai 90.000 € netti [26].
È un esempio istruttivo: "coerente" non significa "uniforme". La DGX Station ha due tipi di memoria con bande molto diverse, e le prestazioni dipendono da dove finiscono i pesi del modello.
Prima di comprare hardware per un LLM locale conviene trasformare l'uso previsto in requisiti misurabili. Queste otto domande coprono i vincoli che cambiano davvero il dimensionamento.
Il panorama open-weight cambia abbastanza in fretta da rendere pericolose le tabelle troppo rigide. La memoria richiesta dipende non solo dai parametri totali, ma da formato reale dei pesi, architettura, precisione della KV cache, runtime e contesto. Questa tabella va quindi letta come fascia pratica, non come garanzia.
| Memoria disponibile | Macchine tipiche | Esempi e note pratiche |
|---|---|---|
| 8–16 GB | laptop, GPU da 12-16 GB | modelli piccoli e medi; alcuni MoE o 20-30B possono entrarci solo con quantizzazioni aggressive e poco margine per il contesto |
| 24–32 GB | RTX 5090, Mac o mini PC da 32 GB | Qwen3.8-27B Q4_K_M (~17-19 GB di artifact), Muse Glimmer 30B in quantizzazione ~4 bit; resta memoria per cache e runtime, ma non infinita [49][55] |
| 64–128 GB | RTX PRO, DGX Spark, Mac Studio, Strix Halo | modelli 30-100B con ampio contesto; Qwen3.8-Flash-Next; DeepSeek V4-Flash solo con quantizzazioni molto spinte come Q2/Q3, non con un normale Q4 [50][51][52] |
| 192 GB e oltre | multi-GPU, Mac Studio 256-512 GB, 2+ Spark | DeepSeek V4-Flash Q4 (~161 GB di soli pesi in una quantizzazione community), GLM-5.3/5.3-Flash e modelli ancora più grandi, con margine che dipende dal contesto [51] |
Un esempio chiarisce perché la parola “4 bit” da sola non basta. Qwen3.8-27B ha un minimo matematico di circa 13,5-13,9 GB a 4 bit, ma conversioni Q4_K_M reali disponibili su Hugging Face occupano circa 17-19 GB [49]. All'opposto, DeepSeek V4-Flash ha 284B parametri totali e 13B attivi per token [50]: il fatto che ne attivi pochi riduce il calcolo, non elimina la necessità di tenere residenti i pesi degli expert. Una quantizzazione Q4_K_M community è nell'ordine di 161 GB, mentre Q2 scende intorno a 96 GB [51].
Due osservazioni:
Qui la questione cambia natura. Quando un modello serve più persone, non conta solo “quanti token al secondo fa”, ma come si dividono memoria, banda e tempo GPU.
Se più richieste sono attive insieme, un buon motore di inferenza può raggrupparle in batch dinamici e riutilizzare in modo più efficiente il passaggio dei pesi. È il principio del continuous batching. In genere:
Due misure recenti mostrano l'ordine di grandezza, ma non vanno confrontate come se fossero benchmark identici: su RTX PRO 6000 un modello MoE di classe media (Laguna S 2.1) passa da circa 146 token/s su una richiesta a circa 383 token/s aggregati con otto richieste [37][38]. Su due DGX Spark, un test community di DeepSeek V4-Flash riporta circa 55 token/s su una singola richiesta e circa 269 token/s aggregati con 16 richieste [39].
Ollama e LM Studio sono comodi per l'uso personale; per un server che deve gestire richieste parallele, vLLM e SGLang offrono scheduler, continuous batching e gestione della KV cache più sofisticati [36]. In un caso di produzione citato nell'articolo, cambiare motore di inferenza a parità di GPU e modello ha prodotto una differenza di 7,8× nel throughput aggregato [40]. È un buon promemoria: comprare più hardware prima di ottimizzare il serving può essere la spesa sbagliata.
Per un team non basta una sola cifra “token/s”. Le metriche utili sono:
Una chat può sembrare fluida già a 15-20 token/s di decode, ma se il TTFT è di 10 secondi l'esperienza resta scadente. Gli agenti di coding sono ancora più esigenti: generano e consumano testo senza aspettare la lettura umana, quindi beneficiano molto di throughput e latenza bassi.
Per il capacity planning conviene usare la dimensione reale del modello quantizzato, non parametri × bit / 8. Il frammento seguente assume volutamente un modello denso da circa 28B con artifact quantizzato da 18 GB e una KV cache classica FP8 da 32k token per utente. È un modello didattico, non la descrizione di uno specifico LLM.
// Esempio di capacity planning per ~28B.
// modelFileGB va preso dal file/checkpoint reale, non calcolato solo dai bit nominali.
static double KvPerUserGB(int layers, int kvHeads, int headDim,
double bytesPerElem, int ctxTokens)
=> 2.0 * layers * kvHeads * headDim * bytesPerElem * ctxTokens / 1e9;
double modelFileGB = 18.0; // esempio realistico per una quantizzazione Q4 di classe ~27-30B
double kvPerUser = KvPerUserGB(
layers: 64,
kvHeads: 8,
headDim: 128,
bytesPerElem: 1, // FP8
ctxTokens: 32_768);
var machines = new (string Name, double MemGB, double BwGBs)[]
{
("RTX PRO 5000 72GB", 72, 1344),
("RTX PRO 6000 96GB", 96, 1792),
("DGX Spark 128GB", 128, 273),
("Mac Studio M5U 256GB", 256, 1200),
};
Console.WriteLine($"Pesi reali ipotizzati: {modelFileGB:F1} GB, " +
$"KV per utente @32k FP8: {kvPerUser:F2} GB\n");
foreach (var m in machines)
{
double usable = m.MemGB * 0.9; // riserva semplice per OS/runtime/workspace
int usersByMemory = Math.Max(0, (int)((usable - modelFileGB) / kvPerUser));
double rooflineSingle = m.BwGBs / modelFileGB;
Console.WriteLine($"{m.Name,-22} utenti per sola memoria: {usersByMemory,3} " +
$"roofline decode single ≈ {rooflineSingle:F0} token/s");
}
Output:
Pesi reali ipotizzati: 18.0 GB, KV per utente @32k FP8: 4.29 GB
RTX PRO 5000 72GB utenti per sola memoria: 10 roofline decode single ≈ 75 token/s
RTX PRO 6000 96GB utenti per sola memoria: 15 roofline decode single ≈ 100 token/s
DGX Spark 128GB utenti per sola memoria: 22 roofline decode single ≈ 15 token/s
Mac Studio M5U 256GB utenti per sola memoria: 49 roofline decode single ≈ 67 token/s
Questi numeri dicono soltanto quante sessioni potrebbero stare in memoria con quelle ipotesi. Non dicono che il server riesca a servirle tutte con latenza accettabile: il limite può diventare molto prima il throughput.
Per 1-4 persone su un modello 27-30B, quindi, la memoria spesso non è il primo collo di bottiglia su sistemi da 72-128 GB. Su una GPU da 32 GB il quadro è diverso: con 18 GB di pesi, una riserva del 10% e la KV ipotetica sopra rimangono circa 10,8 GB, cioè spazio per appena due contesti da 32k prima di considerare ulteriori workspace. Con context più corto può bastare ampiamente; con agenti o finestre lunghe può diventare il limite.
Uno degli usi più richiesti in azienda è far rispondere un modello su documenti interni: manuali, contratti, procedure e pratiche. Si può fare senza riaddestrare il modello sui documenti: la conoscenza resta aggiornabile separatamente dai pesi dell'LLM.
La tecnica si chiama RAG (Retrieval-Augmented Generation):
Cosa significa per l'hardware:
Per un piccolo studio o un ufficio con qualche migliaio di documenti, un sistema RAG con un modello da 20-30B può girare su una sola macchina. La qualità dipende spesso più dalla pipeline documentale che da qualche miliardo di parametri in più: OCR, chunking, metadati, hybrid retrieval, reranking e un evaluation set di domande reali possono fare più differenza di un semplice upgrade del modello.
Mettiamo tutto insieme. Questi scenari sono punti di partenza, non configurazioni garantite: vanno verificati con il modello, la quantizzazione, il context e il motore di serving che userai davvero. I prezzi restano quelli citati nelle sezioni precedenti e fotografano il mercato fra settembre e inizio ottobre 2026.
| Chi | Uso tipico | Classe di modello | Memoria pratica | Hardware indicativo | Nota |
|---|---|---|---|---|---|
| 1 persona | chat, scrittura, RAG, coding | 20-30B quantizzato | 24-32 GB | RTX 5090, Mac o mini PC da 32-64 GB, Strix Halo | ottimo rapporto velocità/capacità se il modello entra con il context desiderato |
| 1 persona | sviluppo AI su stack NVIDIA, modelli oltre la VRAM consumer | 70-125B, MoE o context ampio | ~128 GB | DGX Spark / OEM GB10 | ideale quando serve capacità CUDA; DeepSeek V4-Flash richiede quantizzazioni molto aggressive per stare su 128 GB [51] |
| 1 persona | modelli molto grandi senza requisito CUDA | 100B+ e grandi MoE | 256-512 GB | Mac Studio M5 Ultra | molta capacità e 1,2 TB/s; supporta anche clustering RDMA [48] |
| 2 persone | chat e RAG condivisi | 20-30B con context medio/lungo | 48-72 GB | RTX PRO 5000 72 GB, Spark o Mac | prima di salire di hardware, verificare TTFT/p95 e continuous batching |
| 3-4 persone | chat, RAG, assistenza al codice | 20-30B veloce o MoE medio | 72-128 GB | RTX PRO 5000/6000, DGX Spark, Mac Studio | la scelta è soprattutto banda vs capacità; MIG serve se occorre isolamento |
| 3-4 persone | agenti intensivi, modelli molto grandi | 100B+ / frontier open-weight | 192 GB e oltre | multi-GPU, 2-4 Spark, Mac Studio ad alta memoria/cluster | qui throughput, rete tra nodi e software diventano decisivi |
Un caso estremo citato nelle fonti è una build quantizzata di GLM-5.3 da circa 178 GiB eseguita su due DGX Spark [42]. Va letta come prova di fattibilità, non come indicazione che due Spark offrano la stessa latenza di quattro RTX PRO 6000: il modello entra, ma banda locale e comunicazione tra nodi restano molto diverse.
Un server AI condiviso in ufficio è un servizio di rete a tutti gli effetti. Servono autenticazione, logging controllato, backup di configurazione e indici, segmentazione di rete, aggiornamenti e controllo del traffico in uscita. Un endpoint LLM esposto indiscriminatamente sulla LAN non diventa sicuro solo perché il modello è on-premise.
Ci sono poi due costi che le tabelle GPU nascondono:
Dopo i numeri, la scelta si può ridurre a una matrice semplice. Non è una classifica: ogni piattaforma risolve un collo di bottiglia diverso.
| Piattaforma | Ha senso soprattutto quando... | Limite da ricordare |
|---|---|---|
| DGX Spark | serve più capacità della VRAM consumer, vuoi CUDA e modelli/contesti grandi | 273 GB/s sono pochi rispetto alle GPU discrete di fascia alta |
| RTX 5090 | il modello entra in 32 GB e vuoi il massimo decode per euro | 32 GB diventano stretti con modelli grandi, context lungo o più utenti |
| RTX PRO 5000/6000 | servono 72-96 GB, ECC, MIG, supporto professionale o multi-GPU | costo molto superiore alla 5090 |
| Mac Studio M5 Ultra | vuoi 256-512 GB e alta banda senza requisito CUDA | ecosistema e serving differiscono dal mondo NVIDIA |
| Strix Halo / Ryzen AI Max+ | vuoi molta memoria condivisa su x86 con budget più contenuto | ROCm e compatibilità AI vanno verificati sul workload reale |
| RTX Spark | vuoi Windows, CUDA e memoria unificata in formato compatto | al 2 ottobre 2026 servono ancora benchmark indipendenti dei sistemi in vendita |
La regola pratica resta questa: se il modello non entra, compra capacità; se entra ma è lento, compra banda; se gli utenti aumentano, misura il serving prima di comprare altra GPU.
Su questo blog parlo spesso di privacy, quindi vale la pena distinguere locale da isolato.
Eseguire un LLM on-premise permette di progettare un sistema in cui prompt, documenti, embedding e risposte restano nell'infrastruttura controllata dall'organizzazione. Non lo garantisce automaticamente: un'interfaccia locale può comunque usare telemetria, ricerca web, API esterne, modelli di embedding cloud, logging SaaS o tool remoti. La privacy dipende quindi dall'intera architettura, non dalla sola posizione dei pesi.
Per un'azienda europea, un'architettura interamente locale può ridurre trasferimenti verso fornitori terzi e semplificare alcuni aspetti di data governance, ma non elimina gli obblighi GDPR. Il tema si collega direttamente al problema più ampio della sovranità digitale europea e dell'AI Act, perché possedere l'hardware non significa automaticamente controllare ogni livello dello stack. Restano, a seconda dei dati e del trattamento, controllo degli accessi, minimizzazione, retention, sicurezza, basi giuridiche e gli altri adempimenti applicabili. Questo è particolarmente importante per categorie di dati sensibili come quelli sanitari.
Il RAG offre un vantaggio operativo: i documenti non devono essere incorporati nei pesi per essere interrogati. Restano file e indici aggiornabili separatamente. Ma anche qui vanno protetti archivio originale, chunk, embedding, log delle query e backup.
Da questo punto di vista DGX Spark, Mac Studio, Strix Halo e workstation classiche possono tutti essere parte di una soluzione privata: ciò che conta è come vengono configurati, collegati e amministrati. Per il lato complementare — quante informazioni possono essere inferite anche senza un ascolto diretto — rimando anche a I nostri dispositivi ci leggono nel pensiero?.
Per le aziende italiane c'è anche un aspetto pratico: alcuni rivenditori propongono questi sistemi in noleggio operativo e tramite canali per la pubblica amministrazione [28][33]. In un mercato molto volatile può essere utile confrontare acquisto, noleggio e cloud sul TCO reale, non soltanto sul prezzo della GPU.
Non in generale. Il DGX Spark offre 128 GB di memoria unificata, ma circa 273 GB/s di banda; la RTX 5090 ha soltanto 32 GB di VRAM ma circa 1.792 GB/s. Se il modello entra nei 32 GB della 5090, il decode può essere molto più veloce. Spark diventa interessante quando il problema principale è far entrare modelli o contesti che superano la VRAM della GPU consumer.
No. Sul DGX Spark CPU e GPU condividono un unico pool coerente da 128 GB, che deve ospitare anche runtime, cache e altre allocazioni. Il vantaggio è la capacità accessibile senza un budget RAM/VRAM separato; la differenza rispetto alla VRAM GDDR7 è soprattutto nella banda disponibile.
Per molti modelli quantizzati di classe 20-30B, sì. Il limite emerge quando aumentano la dimensione del modello, la finestra di contesto, la KV cache, la multimodalità o le richieste contemporanee. Per questo 32 GB possono essere abbondanti per un singolo utente e stretti per un server condiviso.
Possono sfruttare quasi 64 GB aggregati distribuendo il modello tra le due GPU, ma non creano una singola GPU virtuale da 64 GB. Servono sharding e comunicazione tra le schede; topologia PCIe, runtime e strategia di parallelismo influenzano prestazioni e memoria realmente utilizzabile.
Non esiste un numero unico. Con un modello quantizzato 20-30B, 72-128 GB offrono spesso ampio margine per 1-4 utenti, ma il collo di bottiglia può diventare prima la latenza o il throughput. Con 32 GB si può comunque lavorare, soprattutto con contesti più brevi e poche richieste concorrenti; la verifica corretta è misurare TTFT, ITL e p95 sul workload reale.
La domanda giusta non è “qual è la macchina più potente?”, ma “qual è il mio collo di bottiglia?”
Prima di comprare, scegli il modello e la quantizzazione che userai davvero, misura il file reale, stima il context medio e p95, definisci quante richieste saranno concorrenti e stabilisci un obiettivo di TTFT/ITL. Poi prova lo stesso workload sul runtime candidato. Cinque minuti di aritmetica restringono il campo; un benchmark rappresentativo decide l'acquisto.
Le specifiche, i prezzi e i benchmark citati sono stati verificati fino al 2 ottobre 2026. Dove possibile sono state privilegiate fonti primarie NVIDIA, Apple e model card ufficiali; benchmark community e listini sono usati per ordini di grandezza e disponibilità di mercato.
Tutte le fonti sono state consultate il 2 ottobre 2026. Dove indicata, la data è quella di pubblicazione o ultimo aggiornamento della pagina.
Articoli Syspack di partenza. Il sito blocca l'accesso automatico ai contenuti degli articoli del blog: i temi sono ricavati da titoli, sottotitoli e pagine prodotto accessibili.
Architettura, specifiche e prezzi DGX Spark
Prezzi GPU
Mac Studio M5
RTX Spark, Strix Halo, DGX Station
Schede RTX PRO, workstation e listini
Modelli, concorrenza e RAG
Aggiunta
Verifiche e fonti primarie aggiunte nella revisione del 2 ottobre 2026
Nota sui prezzi: nel corpo dell'articolo tutti i prezzi sono espressi in euro. I prezzi originariamente pubblicati in dollari USA sono convertiti al cambio di riferimento BCE del 1° ottobre 2026 (1 EUR = 1,1298 USD) e arrotondati; sono equivalenti valutari, non listini europei. I prezzi già rilevati in Europa restano quelli delle fonti e possono essere IVA esclusa. In un mercato molto volatile vanno verificati nuovamente prima dell'acquisto.
Nota sui benchmark: i numeri di velocità provengono da configurazioni diverse (modelli, quantizzazioni, motori di inferenza). Servono a capire gli ordini di grandezza, non a confrontare le macchine al decimale.