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

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

Abbiamo analizzato il throughput e l'efficienza di scaling per illustrare come ciascuna architettura GPU gestisce 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, rendendola l'indicatore più importante delle prestazioni massime in 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 scaling del 99,8% con configurazioni a doppia GPU, indicando un utilizzo delle risorse quasi ottimale.

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

Latenza media di inference vs. numero di GPU

• Latenza media di inference (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ù rapida e reattiva per gli utenti finali.

Approfondimenti chiave sulle prestazioni:

Analisi delle prestazioni di latenza: La NVIDIA B200 presenta 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 i sistemi interattivi in tempo reale in cui una latenza sub-3ms è un requisito di progettazione.

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

Analisi comparativa tra H200 e H100: La H200 dimostra una latenza inferiore del 5-8% rispetto alla H100 su tutte le scale, con la differenza assoluta che diminuisce a conteggi di GPU più elevati (2.81ms contro 2.86ms a otto GPU, una differenza di 0.05ms). Questo differenziale prestazionale marginale, se confrontato con la differenza di prezzo del 41%, suggerisce che la H100 possa offrire caratteristiche di costo-prestazioni più favorevoli per implementazioni sensibili alla latenza.

Caratteristiche di latenza della AMD MI300X: La MI300X presenta valori di latenza superiori del 37-75% rispetto alla H200 in tutte le 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 prestazionale rispetto alle piattaforme NVIDIA.

Prestazioni vs. prezzo: un'analisi costo-efficienza

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) di ciascuna piattaforma, abbiamo confrontato i nostri risultati di throughput con i prezzi orari on-demand di RunPod al momento dei 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 archiviazione o di rete.

Come abbiamo calcolato il throughput per dollaro

Per generare questo grafico, abbiamo elaborato i nostri dati prestazionali grezzi 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 esempio, 4x H100 costa $10,76).
• Calcolo: Abbiamo quindi applicato la formula per calcolare il valore throughput_per_dollar. Ad esempio, la H100 con 1x GPU ha fornito 23.243 token/s a un costo di $2,69/ora, ottenendo 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 grande compito su più GPU. Per l'inference di LLM, ciò può essere ottenuto tramite il parallelismo dei dati, in cui copie indipendenti del model 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 miglioramenti prestazionali sono limitati dai colli di bottiglia della CPU e del sistema, dal tempo che il sistema host dedica alla gestione di più processi concorrenti, dai vincoli di larghezza di banda della memoria e dalla contesa delle risorse. Il nostro benchmark misura con quale efficienza ciascuna piattaforma gestisce questi vincoli a livello di sistema, un fattore critico per costruire server di inference IA efficienti in termini di costi e ad alte prestazioni per models di piccole e medie dimensioni.

Quali sono le sfide dei 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 model viene suddiviso tra 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 inter-GPU influisce direttamente sullo scaling. Se il tempo trascorso in attesa dei dati da un'altra GPU supera il tempo risparmiato parallelizzando il calcolo, i miglioramenti prestazionali diminuiranno. Questo effetto è particolarmente pronunciato nei model che non sono abbastanza grandi da saturare completamente la capacità di calcolo di ciascuna GPU.

Maturità dell'ecosistema software

Le prestazioni non sono solo una funzione dell'hardware. Lo stack software, inclusi driver, librerie di comunicazione (come NCCL per NVIDIA e RCCL per AMD) e il motore di inference (vLLM), svolge un ruolo fondamentale. Abbiamo scoperto che le prestazioni di una piattaforma sono profondamente legate alla maturità del suo supporto software. Un ecosistema consolidato come NVIDIA con la sua CUDA beneficia spesso di anni di fine-tuning e ottimizzazione, il che può portare a un'efficienza di scaling superiore rispetto a integrazioni più recenti come AMD con la sua ROCm, anche su hardware potente.

Ottimizzazioni specifiche per piattaforma

Come hanno rivelato i nostri test, ottenere prestazioni ottimali richiede spesso configurazioni specifiche per piattaforma. Un approccio generico e “valido per tutti” può portare a prestazioni ingannevolmente basse. L'immagine Docker corretta, le variabili d'ambiente (ad esempio, l'abilitazione di AMD kernel personalizzati) e persino i tipi di dati del model (ad esempio, bfloat16 per Blackwell) sono essenziali per sbloccare il vero potenziale dell'hardware. Ciò rende i confronti equi “mela a mela” una sfida tecnica significativa.

Metodologia del benchmark multi-GPU

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

Ambiente e processo di test

• Piattaforma: Tutti i benchmark sono stati eseguiti su RunPod Cloud per garantire un accesso coerente all'hardware.
• Motore di inference: vLLM (strumento vllm bench throughput) è stato utilizzato come motore standardizzato.
• Model: 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 inter-GPU (NVLink/PCIe) come collo di bottiglia, spostando i limiti prestazionali sul sistema host (CPU, RAM).
• Automazione: Script Bash personalizzati sono stati utilizzati per automatizzare la configurazione dell'ambiente, l'esecuzione dei test, il monitoraggio delle risorse (nvidia-smi, rocm-smi) e l'aggregazione dei risultati.

Configurazioni specifiche per piattaforma

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

NVIDIA piattaforme (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:

AMD piattaforma (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'ampia 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: ROCR_VISIBLE_DEVICES è stato utilizzato al posto dell'equivalente 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 model, inizializzazione della cache KV e compilazione dei kernel CUDA/ROCm
• Output: Scartato (non incluso nelle misurazioni)
• Comportamento specifico per piattaforma:
  • NVIDIA (CUDA): Compilazione dei kernel e ottimizzazione dei grafi CUDA (~30-60 secondi)
  • AMD (ROCm): Compilazione dei kernel e messa a punto opzionale TunableOp (varia in base all'impostazione PYTORCH_TUNABLEOP_ENABLED)

Fase 2: inizializzazione del monitoraggio della GPU

Contemporaneamente all'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 la post-analisi

Fase 3: esecuzione parallela del benchmark

Al termine del riscaldamento, tutte le istanze GPU sono state avviate simultaneamente:

• Ciascuna GPU ha elaborato una quota uguale dei 25.000 prompt totali
• Tutte le istanze sono state avviate nello stesso secondo per simulare il bilanciamento del carico di produzione
• Il throughput totale viene misurato come somma di tutti gli output delle GPU
• Il tempo di esecuzione viene 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 reale dei test

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

Ulteriori letture

Esplora altre ricerche sull'hardware IA, come:

• I migliori 30 provider di GPU cloud 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  = sep,
  howpublished    = {\url{https://aimultiple.com/multi-gpu}},
  note   = {AIMultiple. Consultato il 21 settembre 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