Guide pratiche

Gestione dell’infrastruttura GPU per i team di machine learning

Come pianificare, predisporre e gestire le risorse di calcolo GPU per il machine learning: suddivisione dei carichi di lavoro tra Hopper, Blackwell e Rubin, Slurm rispetto a Kubernetes, MIG, costi delle istanze spot e monitoraggio con DCGM.

AI.info Team · 2026-08-12

Dimensionare la flotta prima di acquistare o noleggiare alcunché

L’errore di pianificazione più costoso nell’infrastruttura GPU è scegliere l’hardware in base a ciò di cui si parla di più, anziché alle esigenze del carico di lavoro. Cominciate dividendo i carichi in tre categorie — pretraining su larga scala, fine-tuning e inferenza — perché ciascuna presenta un diverso collo di bottiglia.

Il pretraining e l’addestramento distribuito su larga scala sono vincolati dalla larghezza di banda e dalle interconnessioni. Attivazioni e gradienti si spostano tra centinaia di GPU, quindi le dimensioni del dominio NVLink e la larghezza di banda della HBM contano più dei FLOPs grezzi. È qui che trovano posto i modelli NVIDIA nel formato SXM: H100 SXM5 (80GB di HBM3, larghezza di banda di ~3,35 TB/s), H200 (141GB di HBM3e, ~4,8 TB/s — il 76% di memoria e il 43% di larghezza di banda in più rispetto a H100) e B200 della generazione Blackwell (192GB di HBM3e, ~8 TB/s, circa 2,3 volte la capacità di calcolo e 1,7 volte la larghezza di banda di H200).

A livello di rack, GB200 NVL72 abbina CPU Grace e GPU Blackwell in un dominio NVLink da 72 GPU, mentre GB300 (Blackwell Ultra) usa la stessa interconnessione con più memoria per GPU. Secondo NVIDIA, un rack GB300 NVL72 offre 20TB di memoria GPU e fino a 576 TB/s di larghezza di banda tra le sue 72 GPU Blackwell Ultra e 36 CPU Grace. Entrambi compaiono ormai nei listini pubblici, anziché soltanto nelle roadmap: CoreWeave elenca GB200 NVL72, GB300 NVL72 e HGX B300 accanto a H100 e A100.

Vera Rubin è arrivato nei tempi previsti. Ogni package Rubin dispone di 288GB di HBM4 con una larghezza di banda fino a 22 TB/s, è realizzato con il processo a 3nm di TSMC e ha una capacità dichiarata di circa 50 petaflops nell’inferenza NVFP4; Rubin Ultra, con due die Rubin in un unico package, è previsto per il 2027. I primi risultati di benchmark sono arrivati il 16 settembre 2026, quando MLPerf Inference v6.1 ha pubblicato una submission preliminare di Vera Rubin NVL72: NVIDIA ha riferito un throughput fino a 3,7 volte quello di GB300 NVL72 su Qwen3-VL e fino a 2,5 volte su DeepSeek-R1. Una submission preliminare non rientra nella categoria dei prodotti verificati e disponibili, e il riferimento è fornito dalla stessa NVIDIA: quelle proporzioni vanno quindi lette come valori massimi. Per la pianificazione, la conseguenza è comunque più netta dei numeri: una prenotazione pluriennale di H100 sottoscritta oggi trascorrerà la sua seconda metà a competere con chip più recenti di due generazioni.

La riga relativa a B300 è ricavata dai dati di NVIDIA a livello di rack — 20TB e 576 TB/s ripartiti tra 72 GPU — perché NVIDIA pubblica le specifiche di GB300 per rack NVL72, non per singola GPU.

Il fine-tuning (LoRA, QLoRA, fine-tuning completo di modelli con meno di ~70 miliardi di parametri) richiede raramente il modello di fascia più alta. Una singola A100 80GB o H100 PCIe offre spesso memoria sufficiente, evitando di pagare il sovrapprezzo per NVLink quando si lavora con una o due GPU e non lo si sfrutterebbe.

L’inferenza pone un problema di ottimizzazione del tutto diverso: contano il costo per token e il throughput per dollaro, non i FLOPs massimi. La L40S di NVIDIA (Ada Lovelace, 48GB GDDR6) è progettata appositamente per questa fascia: gestisce chatbot, pipeline RAG e la distribuzione di modelli di medie dimensioni su server PCIe standard a una frazione del prezzo di H100. La variante H100 NVL (due GPU collegate tramite NVLink, 94GB di HBM3 per GPU, 188GB complessivi) esiste proprio per offrire ai carichi di inferenza un’ampia dotazione di memoria senza richiedere un’infrastruttura SXM completa.

Una regola pratica per la fase di pianificazione: non acquistate né prenotate hardware di classe SXM per carichi che funzionano senza difficoltà su una singola GPU. Il sovrapprezzo per NVLink e HBM3e è giustificato solo quando il lavoro si estende effettivamente su più GPU.

Pianificazione dei carichi: Kubernetes, Slurm o entrambi

La maggior parte dei team che gestiscono piattaforme di ML finisce per usare entrambi, perché risolvono problemi diversi.

Kubernetes e il device plugin di NVIDIA

Il device plugin di NVIDIA per Kubernetes espone le GPU di ogni nodo come risorsa pianificabile nvidia.com/gpu, consentendo allo scheduler standard di Kubernetes di assegnare i pod ai nodi con capacità GPU disponibile. Da solo, il device plugin tratta una GPU come un’unità indivisibile: un pod, una GPU intera. Va bene per i lavori di addestramento, ma è uno spreco per i servizi di inferenza che richiedono solo una parte della capacità di calcolo o della memoria di una GPU.

NVIDIA GPU Operator aggiunge due meccanismi di condivisione, configurati tramite la ConfigMap del device plugin:

version: v1
sharing:
  timeSlicing:
    resources:
    - name: nvidia.com/gpu
      replicas: 4

Il time-slicing permette a più pod di alternarsi sulla stessa GPU fisica, presentandola come più repliche pianificabili. Tra le repliche, però, non c’è isolamento né della memoria né dei guasti: un container fuori controllo può esaurire la memoria anche per quelli vicini. Usatelo per carichi di inferenza intermittenti e tolleranti alla latenza, quando non è necessario un isolamento rigoroso.

Kubernetes è la scelta adatta per i servizi di inferenza, gli ambienti notebook e qualsiasi carico che tragga vantaggio da autoscaling, aggiornamenti graduali e individuazione dei servizi: funzionalità che Slurm non offre nativamente.

Slurm per l’addestramento batch

Slurm rimane la scelta predefinita per i lavori di addestramento grandi e di lunga durata, soprattutto nei cluster GPU dedicati e negli ambienti simili a quelli HPC. L’allocazione delle GPU avviene tramite GRES (Generic Resources): le risorse vengono definite esplicitamente in slurm.conf e gres.conf, usando nomi che specificano il tipo anziché un’etichetta GPU generica:

# slurm.conf
NodeName=gpu-node[01-08] Gres=gpu:h100:8 CPUs=96 RealMemory=1000000

# gres.conf
Name=gpu Type=h100 File=/dev/nvidia[0-7]

Un job richiede poi le GPU con --gres=gpu:h100:8 (oppure, in un cluster con GPU di tipi diversi, si potrebbe usare --gres=gpu:a100:4). Slurm supporta anche le GPU partizionate con MIG come tipi GRES schedulabili: una possibilità importante in un cluster di ricerca condiviso, dove alcuni job richiedono un’intera H100 e ad altri basta una partizione 1g.10gb.

I punti di forza di Slurm — l’assegnazione delle risorse che tiene conto della topologia, la schedulazione backfill, le quote fair-share tra gruppi di ricerca e la gestione di checkpoint e reinserimento dei job in coda — sono proprio ciò che serve per il preaddestramento che dura settimane. Il suo limite è che si presta poco ai servizi sempre attivi: per questo la maggior parte delle organizzazioni usa Slurm per l’addestramento e Kubernetes per il serving, talvolta suddividendo un pool di nodi condiviso tra i due sistemi.

NVIDIA Run:ai come terza opzione

Dopo l’acquisizione da parte di NVIDIA nel 2024, Run:ai opera sopra Kubernetes e aggiunge funzionalità che né K8s senza estensioni né Slurm offrono di serie: frazioni dinamiche di GPU (assegnando quantità inferiori a una GPU intera, come 0,5, e adeguandole alla domanda in tempo reale anziché usare intervalli di tempo fissi), gestione gerarchica delle quote tra team e progetti e bin-packing che tiene conto dei carichi di lavoro.

I benchmark di NVIDIA e Nebius hanno rilevato una capacità disponibile per gli utenti fino a 2 volte maggiore sullo stesso hardware nei periodi di picco rispetto all’allocazione statica. Nell’aprile 2025, NVIDIA ha reso open source, con licenza Apache 2.0 e con il nome KAI Scheduler, il nucleo dello scheduler nato all’interno di Run:ai: vale la pena valutarlo se si vuole schedulare frazioni di GPU senza una licenza commerciale. Il prezzo di listino pubblicato da NVIDIA per AI Enterprise sui sistemi gestiti in proprio è di 4.500 dollari per GPU per un anno, 18.000 dollari per GPU per cinque anni, oppure 1 dollaro per ora-GPU tramite i marketplace cloud, in aggiunta al costo dell’istanza.

Sfruttare meglio GPU costose

Nella maggior parte delle organizzazioni che si occupano di machine learning, l’utilizzo delle GPU è ben al di sotto delle capacità dell’hardware, soprattutto perché i job vengono dimensionati per «una GPU» anziché in base alle effettive esigenze di memoria e calcolo. Due meccanismi affrontano il problema a livello hardware.

MIG (Multi-Instance GPU)

MIG suddivide fisicamente una GPU supportata (A100, H100 e modelli successivi) in un massimo di sette istanze isolate, ciascuna con memoria, cache L2 e core di calcolo dedicati: è un vero isolamento a livello hardware, non una semplice condivisione gestita dallo scheduler. Su una A100 o H100 da 80 GB, le configurazioni comuni vanno da 1g.10gb (una partizione di calcolo, 10 GB di memoria) a 7g.80gb (l’intera GPU).

Una configurazione frequente in produzione consiste nel suddividere una singola H100 in sette istanze 1g.10gb per l’inferenza multi-tenant con modelli piccoli, oppure in due istanze 3g.40gb per eseguire due server indipendenti con modelli della classe 13B su una sola GPU fisica. MIG è integrato con il device plugin di Kubernetes dal 2020, quindi le istanze partizionate compaiono come risorse schedulabili distinte.

Rispetto al time-slicing, il compromesso è tra flessibilità e isolamento: MIG offre prestazioni prevedibili e garantite per ciascun tenant, ma la configurazione delle partizioni resta fissa finché non si riconfigura la GPU (operazione che richiede di liberarla dai job in esecuzione). Il time-slicing permette una condivisione dinamica e più granulare, ma non garantisce l’isolamento. Per l’inferenza multi-tenant sensibile alla latenza, dove le interferenze tra tenant sono inaccettabili, MIG è la scelta predefinita più sicura; per i carichi interni di sviluppo e test, dove una contesa occasionale è tollerabile, il time-slicing è più semplice da gestire.

Dimensionare in base al carico di lavoro, non alla GPU

Prima di ricorrere a MIG o alla schedulazione di frazioni di GPU, verificate se il job ha davvero bisogno di tutta la memoria di una GPU. Un modello da 7 miliardi di parametri in fp16 richiede circa 14 GB per i pesi, più la memoria per le attivazioni: non gli serve un’intera H100 da 80 GB. Dimensionare correttamente le risorse nella definizione del job (abbinando le dimensioni del modello alla configurazione MIG o alla fascia di GPU) produce in genere incrementi di utilizzo maggiori di qualsiasi ottimizzazione dello scheduler.

Spot, Reserved e On-Demand

La capacità GPU nel cloud è disponibile in tre modalità, con prezzi e profili di rischio sensibilmente diversi. La pianificazione deve associare ciascun carico di lavoro alla modalità più adatta in base alla sua tolleranza alle interruzioni.

• On-demand è il prezzo massimo di riferimento e la soluzione di riserva: AWS P5 (H100) on-demand costa circa 6,88 dollari per GPU-ora (55,04 dollari l’ora per una p5.48xlarge con 8 H100). Usala per i lavori che non puoi permetterti di interrompere durante l’esecuzione.
• Reserved / Capacity Blocks (AWS EC2 Capacity Blocks for ML e soluzioni analoghe altrove) richiedono un acquisto anticipato per una durata fissa e garantiscono disponibilità senza interruzioni: sono utili per un ciclo di pre-addestramento pianificato di cui conosci data di inizio e durata, ma per il quale vuoi avere certezza del prezzo.
• Spot riduce i costi di circa il 60–70% rispetto all’on-demand su AWS P5, ma comporta un rischio di interruzione che varia sensibilmente a seconda del tipo di GPU: il tasso di interruzione delle istanze spot H100 su AWS è inferiore al 5%, mentre quello delle A100 spot è nettamente più alto, al 15–20%, per effetto di un diverso equilibrio tra domanda e offerta.

I provider neocloud aggiungono una quarta dimensione al confronto con i prezzi degli hyperscaler. Il prezzo di listino di CoreWeave in Nord America per un nodo HGX H100 con 8 GPU è di 49,24 dollari l’ora, circa 6,16 dollari per GPU-ora. Un nodo HGX H200 costa 50,44 dollari e un nodo A100 con 8 GPU 21,60 dollari, circa 2,70 dollari per GPU-ora. Anche i prezzi dei modelli Blackwell sono espressi nello stesso modo: 68,80 dollari per un nodo HGX B200, circa 8,60 dollari per GPU-ora, 42,00 dollari per un’istanza GB200 NVL72 con 4 GPU, mentre i prezzi di GB300 NVL72 e HGX B300 sono disponibili su richiesta. Le tariffe dei neocloud sono spesso sensibilmente inferiori a quelle on-demand degli hyperscaler per gli stessi chip, a fronte di un ecosistema di servizi gestiti meno maturo.

Far funzionare lo spot nella pratica è soprattutto una questione di disciplina nel checkpointing: salva lo stato del modello ogni 15–30 minuti, così un’interruzione non comporterà mai la perdita di più di una piccola parte del lavoro di calcolo. Configura inoltre il ciclo di addestramento in modo che rilevi l’avviso di interruzione e forzi un checkpoint d’emergenza prima che l’istanza venga revocata. Il tempo di preavviso varia da un cloud all’altro: AWS concede circa due minuti, GCP circa 30 secondi. La procedura che crea un checkpoint al ricevimento del segnale deve quindi essere rapida e già collaudata, non qualcosa da costruire mentre è in corso un’interruzione.

Il checkpointing suddiviso in shard, che scrive lo stato di ciascun rank in modo indipendente anziché raccoglierlo su un unico nodo, mantiene rapida questa operazione anche per i modelli di grandi dimensioni. Con questo sistema, i team eseguono comunemente su spot il 40–70% del calcolo complessivo per l’addestramento, riservando la capacità on-demand o Reserved alla fase finale del ciclo, in cui rispettare i tempi è cruciale.

Multi-tenancy e gestione delle quote

Quando un cluster GPU serve più di un team, la contesa per la capacità diventa un problema di governance, non soltanto di schedulazione. L’approccio che consente di crescere è questo:

• Quote a livello di namespace o progetto, applicate dallo scheduler (Kubernetes ResourceQuota su nvidia.com/gpu, limiti QOS/association di Slurm o la struttura gerarchica delle quote di Run:ai), impediscono che un team privi gli altri delle risorse necessarie quando la capacità scarseggia.
• Ripartizione equa con possibilità di usare la capacità inutilizzata: assegna ai team una quota di base garantita, ma consenti loro di utilizzare la capacità che gli altri team non stanno impiegando, con regole di preemption per recuperarla.
• Livelli di priorità che distinguono i carichi interattivi e di sviluppo (piccoli job che richiedono risposte rapide) dall’addestramento batch (di lunga durata e interrompibile) impediscono che un unico grande job blocchi tutti i piccoli esperimenti sul cluster.
• Visibilità dell’attribuzione dei costi: anche in un cluster interno, rendere disponibili i dati sulle GPU-ora per team cambia i comportamenti. Quando l’utilizzo è visibile e attribuito, i team richiedono risorse in eccesso molto meno spesso.

Monitoraggio: DCGM come base

Qualunque sia lo stack di schedulazione utilizzato, l’osservabilità a livello di GPU dovrebbe passare da Data Center GPU Manager (DCGM) di NVIDIA. dcgm-exporter è il collegamento standard con Prometheus: è un binario Go basato sull’API DCGM che espone la telemetria delle GPU tramite un endpoint HTTP /metrics. Può essere distribuito come container autonomo o, più comunemente, come DaemonSet installato automaticamente da GPU Operator.

Le metriche per cui vale la pena configurare avvisi, non soltanto raccogliere dati, sono:

• Utilizzo della GPU (attività degli SM): un utilizzo costantemente basso nell’intero parco GPU è il segnale più chiaro di una capacità sovradimensionata o di una schedulazione insufficiente; un utilizzo stabilmente vicino al 100%, accompagnato da una coda in crescita, indica che serve più capacità o un dimensionamento migliore dei job.
• Utilizzo del controller di memoria e memoria libera: permettono di individuare i job limitati dalla memoria anziché dalla capacità di calcolo, un motivo comune per ricorrere a MIG invece che a una GPU più grande.
• Conteggio degli errori ECC: un aumento degli errori ECC correggibili o non correggibili su una determinata GPU è un segnale precoce di guasto hardware. Vale la pena predisporre un isolamento e uno svuotamento automatici del nodo prima che il problema provochi il blocco di un job di addestramento durante l’esecuzione.
• Consumo energetico e temperatura: utili per rilevare il throttling prima che riduca silenziosamente la velocità dell’addestramento.
• Traffico NVLink e PCIe: nell’addestramento multi-GPU, un traffico NVLink inaspettatamente basso su una GPU rispetto alle altre indica spesso una configurazione errata della topologia o del posizionamento, non un guasto hardware.

Le dashboard Grafana basate sul template ufficiale DCGM-Exporter offrono un rapido punto di partenza. Il valore sta nel collegare i segnali relativi agli errori ECC e ai valori anomali di utilizzo al sistema di avvisi già in uso, anziché trattare DCGM come una dashboard passiva.

Lista di controllo per la pianificazione

Prima di impegnare il budget o firmare una prenotazione, verifica che il tipo di carico di lavoro (pre-addestramento/fine-tuning/inferenza) sia associato alla generazione di GPU e alla quantità di memoria appropriate; che lo scheduler scelto sia adatto al tipo di job (Slurm per l’addestramento batch, Kubernetes per i servizi, Run:ai/KAI se servono frazioni di GPU e quote per più team); che la scelta tra MIG e time-slicing sia fatta per ciascun carico di lavoro, anziché per l’intero cluster; che l’idoneità allo spot sia decisa per ogni job in base alla maturità del sistema di checkpointing, non secondo una regola generale; e che il monitoraggio basato su DCGM sia attivo prima dell’esecuzione del primo job di produzione, non aggiunto dopo il primo rallentamento inspiegabile.