Benchmark multi-GPU: B200 vs H200 vs H100 vs MI300X

Da oltre due decenni, l'ottimizzazione delle prestazioni di calcolo è stata una pietra angolare del mio lavoro. Abbiamo confrontato NVIDIA B200, H200, H100 e AMD MI300X per valutare quanto scalano bene per l'inferenza di Large Language Model (LLM). Utilizzando il framework vLLM con il modello meta-llama/Llama-3.1-8B-Instruct, abbiamo eseguito test su 1, 2, 4 e 8 GPU.

Abbiamo analizzato il throughput e l'efficienza di scalabilità per illustrare come ciascuna architettura GPU gestisca carichi di lavoro parallelizzati e ad alta intensità di calcolo.

Risultati del benchmark multi-GPU

Throughput totale vs. numero di GPU

• Throughput totale (token/secondo): Questa metrica rappresenta la potenza di elaborazione grezza dell'intero sistema multi-GPU. Misura il numero totale di token di input e output elaborati al secondo, rendendolo l'indicatore più importante delle prestazioni massime sotto un carico di lavoro offline saturo.

Per capire come abbiamo calcolato il punteggio, consulta la nostra metodologia del benchmark multi-GPU.

Approfondimenti chiave sulle prestazioni:

Analisi delle prestazioni: La NVIDIA H200 offre il throughput più elevato in tutte le configurazioni testate, con miglioramenti prestazionali del 9-10% rispetto alla H100. Il sistema raggiunge un'efficienza di scalabilità del 99,8% con configurazioni a doppia GPU, indicando un utilizzo delle risorse quasi ottimale.

AMD MI300X: caratteristiche prestazionali: La AMD MI300X raggiunge un throughput su singola GPU di 18.752 token al secondo, pari a circa il 74% delle prestazioni della H200. Il sistema mantiene efficienze di scalabilità del 95% e dell'81% rispettivamente per configurazioni a due e quattro GPU.

Latenza media di inferenza vs. numero di GPU

• Latenza media di inferenza (millisecondi): Questa metrica misura il tempo medio necessario per elaborare una singola richiesta dall'inizio alla fine. Una latenza inferiore si traduce in un'esperienza più veloce e reattiva per gli utenti finali.

Approfondimenti chiave sulle prestazioni:

Analisi delle prestazioni di latenza: La NVIDIA B200 mostra le latenze più basse in tutte le configurazioni valutate, raggiungendo 2.40ms con implementazioni a otto GPU. Queste caratteristiche prestazionali la rendono adatta ad applicazioni che richiedono tempi di risposta minimi, come sistemi interattivi in tempo reale in cui una latenza sotto i 3ms è un requisito di progettazione.

Osservazioni sull'efficienza di scalabilità: L'analisi rivela rendimenti decrescenti nella riduzione della latenza all'aumentare del numero di GPU su tutte le piattaforme. La maggiore riduzione di latenza si verifica nel passaggio dalle configurazioni a singola GPU a quelle a doppia GPU (circa il 50% su tutte le piattaforme). Le configurazioni con più di 4 GPU mostrano miglioramenti di latenza progressivamente inferiori.

Analisi comparativa H200 e H100: L'H200 mostra una latenza inferiore del 5-8% rispetto all'H100 su tutte le scale, con una differenza assoluta che diminuisce all'aumentare del numero di GPU (2.81ms contro 2.86ms a otto GPU, una differenza di 0.05ms). Questo differenziale di prestazioni marginale, confrontato con la differenza di prezzo del 41%, suggerisce che l'H100 può offrire caratteristiche costo-prestazioni più favorevoli per implementazioni sensibili alla latenza.

AMD MI300X: caratteristiche di latenza: La MI300X mostra valori di latenza superiori dal 37 al 75% rispetto all'H200 nelle configurazioni testate, il che può essere attribuito alle attuali differenze di maturità dello stack software tra le implementazioni vLLM ROCm e CUDA. Su scala a otto GPU, la MI300X raggiunge una latenza di 4.20ms, che rimane entro parametri accettabili per numerose applicazioni di produzione nonostante il differenziale di prestazioni rispetto alle piattaforme NVIDIA.

Prestazioni vs. prezzo: un'analisi di efficienza dei costi

Sebbene le metriche di prestazioni grezze siano cruciali, la decisione finale per qualsiasi organizzazione dipende dall'efficienza dei costi. Per analizzare il ritorno sull'investimento (ROI) per ciascuna piattaforma, abbiamo confrontato i nostri risultati di throughput con i prezzi orari on-demand di RunPod al momento del test. Questo ci consente di calcolare un punteggio di “prestazioni per dollaro”, rivelando quale configurazione offre la maggiore potenza di calcolo al costo più basso.

Nota: tutte le informazioni sui prezzi riflettono le tariffe on-demand disponibili sulla piattaforma RunPod Cloud al momento del benchmark (settembre 2025) e sono soggette a modifiche. I costi sono presentati a scopo di analisi comparativa e non includono costi di storage o di rete.

Come abbiamo calcolato il throughput per dollaro

Per generare questo grafico, abbiamo elaborato i nostri dati grezzi di prestazioni confrontandoli con i costi orari. La formula di calcolo è:

• Preparazione dei dati: Per ogni punto dati nella nostra tabella dei risultati, abbiamo recuperato il costo orario corrispondente per la specifica configurazione GPU (ad es., 4x H100 costa $10,76).
• Calcolo: Abbiamo quindi applicato la formula per calcolare il valore throughput_per_dollar. Ad esempio, la H100 a 1x GPU ha fornito 23.243 token/s a un costo di $2,69/ora, risultando in un punteggio di 8.642 token/s per dollaro.

Questo punteggio di efficienza fornisce uno strumento decisionale, spostando la discussione da “qual è il più veloce?” a “qual è l'investimento più intelligente per il nostro carico di lavoro?”

Che cos'è lo scaling multi-GPU?

Lo scaling multi-GPU si riferisce alla capacità di un sistema di aumentare le proprie prestazioni distribuendo un singolo compito di grandi dimensioni su più GPU. Per l'inferenza di LLM, questo può essere ottenuto tramite parallelismo dei dati, in cui copie indipendenti del modello vengono eseguite su ciascuna GPU, con un bilanciatore di carico che distribuisce le richieste in arrivo su tutte le istanze.

Idealmente, l'uso di due GPU fornirebbe il doppio delle prestazioni di una singola GPU (accelerazione 2x). Tuttavia, in realtà, i guadagni prestazionali sono limitati da CPU e colli di bottiglia di sistema, dal tempo che il sistema host impiega a gestire più processi concorrenti, dai vincoli di larghezza di banda della memoria e dalla contesa delle risorse. Il nostro benchmark misura quanto efficientemente ciascuna piattaforma gestisce questi vincoli a livello di sistema, un fattore critico per costruire server di inferenza IA economici e ad alte prestazioni per modelli di piccole e medie dimensioni.

Quali sono le sfide nei test di scaling multi-GPU?

Il benchmarking di sistemi multi-GPU pone sfide uniche che possono influenzare significativamente le prestazioni.

Overhead di comunicazione e colli di bottiglia dell'interconnessione

Quando un modello viene suddiviso su più GPU, l'interconnessione, come NVLink di NVIDIA o Infinity Fabric di AMD, diventa un collo di bottiglia critico per le prestazioni. L'efficienza della comunicazione tra GPU influisce direttamente sullo scaling. Se il tempo speso in attesa dei dati da un'altra GPU supera il tempo risparmiato parallelizzando il calcolo, i guadagni prestazionali diminuiranno. Questo effetto è particolarmente pronunciato nei modelli che non sono abbastanza grandi da saturare completamente la capacità di calcolo di ciascuna GPU.

Maturità dell'ecosistema software

Le prestazioni non sono esclusivamente una funzione dell'hardware. Lo stack software, inclusi driver, librerie di comunicazione (come NCCL per NVIDIA e RCCL per AMD) e il motore di inferenza (vLLM), gioca un ruolo monumentale. Abbiamo scoperto che le prestazioni di una piattaforma sono profondamente legate alla maturità del suo supporto software. Un ecosistema consolidato come CUDA di NVIDIA beneficia spesso di anni di messa a punto e ottimizzazione, il che può portare a un'efficienza di scalabilità superiore rispetto a integrazioni più recenti come ROCm di AMD, anche su hardware potente.

Ottimizzazioni specifiche della piattaforma

Come hanno rivelato i nostri test, il raggiungimento di prestazioni ottimali richiede spesso configurazioni specifiche della piattaforma. L'uso di un approccio generico “one-size-fits-all” può portare a prestazioni ingannevolmente basse. L'immagine Docker corretta, le variabili d'ambiente (ad es., l'abilitazione di kernel AMD personalizzati) e persino i tipi di dati del modello (ad es., bfloat16 per Blackwell) sono essenziali per sbloccare il vero potenziale dell'hardware. Ciò rende i confronti equi “apple-to-apple” una sfida tecnica significativa.

Metodologia del benchmark multi-GPU

Abbiamo testato le più recenti architetture GPU ad alte prestazioni sia di NVIDIA che di AMD per valutare le loro capacità di scalabilità. Il nostro benchmark ha misurato le prestazioni di configurazioni a singola e multi-GPU (1x, 2x, 4x, 8x) utilizzando il modello standard meta-llama/Llama-3.1-8B-Instruct¹ modello e il vLLM² motore di inferenza.

Ambiente di test e processo

• Piattaforma: Tutti i benchmark sono stati eseguiti su RunPod Cloud per garantire un accesso hardware coerente.
• Motore di inferenza: è stato utilizzato vLLM (strumento vllm bench throughput) come motore standardizzato.
• Modello: meta-llama/Llama-3.1-8B-Instruct.
• Dataset: dataset ShareGPT Vicuna (25.000 prompt) per simulare un carico di lavoro conversazionale.
• Strategia: parallelismo dei dati; ogni test multi-GPU ha eseguito un'istanza vLLM indipendente su ciascuna GPU. Il carico totale di prompt è stato distribuito uniformemente tra le istanze, eseguite simultaneamente per simulare un ambiente di produzione bilanciato. Questo approccio elimina la comunicazione tra GPU (NVLink/PCIe) come collo di bottiglia, spostando i limiti prestazionali sul sistema host (CPU, RAM).
• Automazione: sono stati utilizzati script Bash personalizzati per automatizzare l'installazione dell'ambiente, l'esecuzione dei test, il monitoraggio delle risorse (nvidia-smi, rocm-smi) e l'aggregazione dei risultati.

Configurazioni specifiche della piattaforma

Il raggiungimento di prestazioni ottimali ha richiesto configurazioni su misura per ciascuna architettura.

Piattaforme NVIDIA (H100, H200, B200)

• Immagine di base: runpod/pytorch:2.8.0-py3.11-cuda12.8.1.
• Installazione di vLLM:
  • H100/H200 (Hopper): installazione standard tramite pip install vllm.
  • B200 (Blackwell): vLLM è stato compilato dai sorgenti (pip install -e .) per abilitare il supporto nativo alla nuova architettura, risolvendo gli errori “no kernel image”.
• Parametri chiave:

• Variabile d'ambiente critica:

Piattaforma AMD (MI300X)

• Immagine di base: rocm/vllm:rocm6.4.1_vllm_0.10.1_20250909
• Installazione di vLLM: non è stata necessaria alcuna installazione, poiché la versione ottimizzata era inclusa nell'immagine.
• Parametri chiave e ottimizzazioni: un'approfondita messa a punto ha identificato le seguenti impostazioni non predefinite come critiche per ottenere il massimo throughput:

• Variabili d'ambiente specifiche per AMD:

• Visibilità dei dispositivi: è stato utilizzato ROCR_VISIBLE_DEVICES invece dell'equivalente di CUDA per assegnare le istanze a specifiche GPU.

Fasi di esecuzione del benchmark

Ogni esecuzione del benchmark ha seguito un protocollo di esecuzione in tre fasi per garantire risultati accurati e riproducibili:

Fase 1: Riscaldamento

Prima di ogni test di configurazione multi-GPU, abbiamo eseguito una fase di riscaldamento dedicata per eliminare gli effetti di avvio a freddo:

• Durata: 100 prompt elaborati sulla GPU 0
• Scopo: caricamento del modello, inizializzazione della cache KV e compilazione dei kernel CUDA/ROCm
• Output: scartato (non incluso nelle misurazioni)
• Comportamento specifico della piattaforma:
  • NVIDIA (CUDA): compilazione del kernel e ottimizzazione del grafo CUDA (~30-60 secondi)
  • AMD (ROCm): compilazione del kernel e messa a punto opzionale di TunableOp (varia in base all'impostazione PYTORCH_TUNABLEOP_ENABLED)

Fase 2: inizializzazione del monitoraggio della GPU

In concomitanza con l'esecuzione del benchmark, abbiamo avviato processi di monitoraggio dedicati per ciascuna GPU:

• Frequenza di campionamento: intervalli di 1 secondo
• Metriche raccolte: utilizzo della GPU, utilizzo della memoria, temperatura, consumo energetico
• Strumenti: nvidia-smi (NVIDIA) o rocm-smi (AMD)
• Output: log CSV per l'analisi successiva

Fase 3: esecuzione parallela del benchmark

Dopo il completamento del riscaldamento, tutte le istanze GPU sono state avviate simultaneamente:

• Ogni GPU ha elaborato una quota uguale dei 25.000 prompt totali
• Tutte le istanze sono state avviate entro lo stesso secondo per simulare il bilanciamento del carico di produzione
• Il throughput totale è misurato come somma di tutti gli output delle GPU
• Il tempo di esecuzione è stato misurato dall'avvio della prima istanza al completamento dell'ultima

Non perderti i nostri benchmark e approfondimenti basati sui dati. Il pulsante apre Google; selezionare AIMultiple conferma che desideri vedere AIMultiple più spesso nei risultati di ricerca di Google.

Aggiungi come fonte preferita

Impatto prestazionale nel mondo reale derivante dai test

I nostri test hanno rivelato che errori di configurazione minori possono portare a risultati prestazionali significativi e fuorvianti. La tabella seguente illustra l'impatto delle configurazioni errate specifiche della piattaforma:

Ulteriori letture

Esplora altre ricerche sull'hardware IA, come:

• I migliori 30 fornitori cloud di GPU e le loro GPU
• GPU Benchmark di concorrenza
• I migliori 25+ produttori di chip IA: NVIDIA e i suoi concorrenti

Cita questo benchmark

Scegli il formato adatto a dove pubblicherai. Incollare la versione con link nel tuo CMS preserva il backlink.

@misc{dogan2026,
  author = {Dogan, Sedat and Sarı, Ekrem},
  title  = {{Benchmark multi-GPU: B200 vs H200 vs H100 vs MI300X}},
  year   = {2026},
  month  = jun,
  howpublished    = {\url{https://aimultiple.com/multi-gpu}},
  note   = {AIMultiple. Consultato il 30 giugno 2026}
}

Registro delle modifiche

2 aggiornamenti

2025

1. 8 ott

   Aggiornato il Dataset nella sezione dei risultati del benchmark multi-GPU.

2. 6 ott

   Rimossa la metrica 'Richieste al secondo' dalla sezione 'Throughput totale vs. conteggio GPU'.

Collegamenti di riferimento

1.

meta-llama/Llama-3.1-8B-Instruct · Hugging Face

2.

vLLM easy, fast, and cheap LLM serving for everyone

Sedat Dogan

CTO

Segui

Sedat è un leader tecnologico e della sicurezza informatica con 20 anni di esperienza nello sviluppo software, nelle infrastrutture di rete e nella cybersecurity. Sedat:
- Ha 20 anni di esperienza come hacker white-hat e guru dello sviluppo, con una vasta competenza nei linguaggi di programmazione e nelle architetture dei server.
- È consulente del consiglio di amministrazione presso una società di venture capital che investe in aziende tecnologiche in fase iniziale e presso Ödeal, una piattaforma di pagamento digitale regionale che serve 125.000 commercianti.
- Ha guidato l'infrastruttura tecnologica e la cybersecurity di sette elezioni nazionali ed è stato riconosciuto nella Hall of Fame della cybersecurity da leader tecnologici globali tra cui Twitter.

Visualizza il profilo completo

Ricercato da

Ekrem Sarı

Ricercatore IA

Segui

Ekrem è un Ricercatore IA e Data Scientist presso AIMultiple. Progetta ed esegue benchmark pratici per sistemi di IA e LLM.

Visualizza il profilo completo

Sii il primo a commentare

Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori. I commenti vengono lasciati nella loro lingua originale.

Nome

Indirizzo e-mail

Commento

0/450

Pubblica un commento