Le workstation per intelligenza artificiale non si giocano solo su CPU e GPU. A fare la differenza sono VRAMRAM banda e latenza tra i sottosistemi, oltre a storage NVMe dimensionato e configurato con criterio. Una scelta sbilanciata brucia budget senza rendimenti; un equilibrio accurato sblocca throughput e stabilità nei carichi reali, dall’inference ai fine-tuning leggeri.
Questa guida entra nel merito dei colli di bottiglia più comuni: quando serve più VRAM e quando basta RAM, quanto pesa la bandwidth su training e generazione, perché la cache CPU cambia la vita ai data loader, e come strutturare gli NVMe per dataset, checkpoint e scratch. Con metriche operative e benchmark di riferimento, l’obiettivo è evitare spese superflue e massimizzare i risultati.
VRAM vs RAM: quando conta davvero la memoria della GPU
La VRAM determina la dimensione effettiva dei modelli che possono risiedere su GPU senza offloading. Per inference di LLM, un 7B a 4 bit richiede tipicamente 6–8 GB di VRAM e produce 20–40 token/s su GPU di fascia media; un 13B a 4 bit richiede 12–16 GB con 10–25 token/s. Oltre i 20B servono 24–48 GB per evitare swapping su PCIe. In generazione d’immagini, Stable Diffusion a 512×512 con 30 step consuma 6–10 GB e scala quasi linearmente con la banda della VRAM. Se la VRAM non basta, il passaggio via PCIe riduce il throughput anche del 30–70% rispetto al tutto-in-GPU.
La RAM di sistema resta cruciale per preprocessing caching dei batch e modelli in sharded loading. Un budget sensato: 2–3× la VRAM totale. Con 24 GB di VRAM, puntare a 64–96 GB di RAM evita pressione sullo swap. Per pipeline complesse (visione + LLM) o training con batch ampi, 128 GB danno margine. La regola pratica: se l’utilizzo RAM supera stabilmente l’80% durante i job, il data loader diventerà il collo di bottiglia prima ancora della GPU.
Bandwidth e cache: il collo di bottiglia nascosto
Molti carichi IA sono memory bound. La banda della VRAM (ad esempio 600–1.000 GB/s su GPU recenti) impatta più dei TFLOPS su modelli con pesi sparsi, attention o quantizzazioni aggressive. Incrementi del 20% di bandwidth producono spesso guadagni del 10–15% nel throughput d’inference su LLM 7B–13B. Lato CPU, la RAM DDR5 a 2 canali offre 60–80 GB/s reali, 4 canali 110–150 GB/s: per data augmentation e decompressione, passare da 2 a 4 canali riduce i tempi di preparazione batch del 25–40%.
La cache L3 incide sui data loader: un’L3 più ampia (es. 64–96 MB per socket) riduce i stall su dataset con molte piccole letture random. In workload ibridi (feature extraction CPU + inference GPU), una cache maggiore abbatte la latenza p95 dei batch di 5–15%. Inoltre, la topologia PCIe conta: uno slot x16 Gen4 offre ~32 GB/s nominali (28–30 reali), Gen5 raddoppia. Se più GPU condividono linee con NVMe o NIC, la contesa può costare un 5–20% nei picchi; mappare le periferiche su radici PCIe distinte mitiga il problema.
Storage NVMe: dataset e checkpoint senza attese
Con dataset di decine di GB, lo storage NVMe incide sulla fase di I/O e sul shuffle continuo. Un singolo SSD PCIe 4.0 x4 offre 5–7 GB/s sequenziale e 600k–1M IOPS; per carichi misti conviene puntare a SSD con DRAM e buone prestazioni in random read 4k. Strutturare tre aree distinte aiuta: dataset (NVMe 1: capienza), checkpoint (NVMe 2: affidabile, magari in RAID1), scratch/temp (NVMe 3: veloce, anche in RAID0 se si dispone di backup).
Per pipeline veloci, il pre-fetch su NVMe riduce il tempo tra batch: con pre-caricamento di 2–3 GB e page cache attiva, la latenza p95 dei batch si riduce del 20–35%. In training, uno stripe RAID0 su due SSD Gen4 può sostenere 10–12 GB/s e tenere la GPU alimentata durante grandi shuffle. Quando lo spazio è il limite, un volume ZFS con compressione lz4 su dataset testuali offre risparmi del 30–50% con CPU moderna, spesso senza penalità percepibile sul throughput.
Benchmark di riferimento: carichi reali e metriche chiave
Per misurare in modo significativo servono metriche legate al caso d’uso. Suggerimenti: per LLM, tokens/s a batch 1 e batch 4, latenza p50/p95 su prompt di 512–2.048 token, verifica di OOM per vari livelli di quantizzazione (4/8 bit). Per visione, immagini/min a 512×512 e 1024×1024 con 20/30 step e sampler coerenti. Per data loader, tempo medio per epoch su dataset predefinito con caching caldo e freddo.
Valori indicativi utili per orientarsi: su una GPU di fascia media con 16 GB di VRAM e 700 GB/s di banda, LLM 7B a 4 bit produce 30–35 tokens/s (batch 1) e 60–70 tokens/s (batch 4) con latenza p95 sotto i 120 ms; Stable Diffusion 1.5 a 512×512 con 30 step genera 22–28 immagini/min. Se l’NVMe scende sotto 2 GB/s in random read effettivo, l’epoch time su dataset di immagini tende a peggiorare del 10–25%. Questi numeri non sostituiscono test locali ma forniscono un baseline per il dimensionamento.
Bilanciare il budget: tre profili di configurazione
Profilo inference compatta (LLM 7B/13B, SD 512): GPU con 16–24 GB VRAM ad alta banda; 64–96 GB di RAM; 1× NVMe Gen4 2 TB per dataset e 1× 1 TB per checkpoint. Obiettivo: 25–40 tokens/s e 20–30 img/min. Profilo sviluppo/fine-tuning leggero GPU 24–48 GB VRAM, RAM 128 GB, 2× NVMe (scratch in RAID0) da 2 TB. Obiettivo: evitare offloading, ridurre p95. Profilo multimodale/spazio abbondante due GPU 24 GB o una GPU 48–80 GB, RAM 128–192 GB, 3× NVMe (dataset/ckpt/scratch separati) con backup.
Criteri decisivi: 1) dimensionare la VRAM sul modello target e quantizzazione; 2) garantire bandwidth adeguata (VRAM e canali RAM); 3) mappare PCIe per ridurre contese; 4) scegliere NVMe con IOPS e DRAM per carichi random; 5) misurare tokens/s, img/min e p95 ad ogni modifica. Un budget ben speso è quello che inchioda i colli di bottiglia prima su calcolo e non su I/O o memoria.
