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 eseguito benchmark sui modelli B200, H200 e H100 di NVIDIA e sul MI300X di AMD per valutare la loro scalabilità nell'inferenza di modelli linguistici di grandi dimensioni (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 la velocità di elaborazione e l'efficienza di scalabilità per illustrare come ciascuna architettura GPU gestisce i carichi di lavoro paralleli e ad alta intensità di calcolo.

Risultati del benchmark multi-GPU

Throughput totale rispetto al 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, risultando l'indicatore più importante delle massime prestazioni in condizioni di carico di lavoro offline saturo.

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

Principali informazioni sulle prestazioni:

Analisi delle prestazioni : l'H200 (991259-1763) offre la massima velocità di elaborazione in tutte le configurazioni testate, con miglioramenti delle prestazioni del 9-10% rispetto all'H100. Il sistema raggiunge un'efficienza di scalabilità del 99,8% con configurazioni a doppia GPU, indicando un utilizzo delle risorse pressoché ottimale.

Caratteristiche prestazionali del AMD MI300X : Il AMD MI300X raggiunge una velocità di elaborazione a singola GPU di 18.752 token al secondo, pari a circa il 74% delle prestazioni dell'H200. Il sistema mantiene un'efficienza di scalabilità del 95% e dell'81% rispettivamente per le configurazioni a due e quattro GPU.

Latenza media di inferenza rispetto al 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ù rapida e reattiva per gli utenti finali.

Principali informazioni sulle prestazioni:

Analisi delle prestazioni di latenza : il NVIDIA B200 presenta le misurazioni di latenza più basse in tutte le configurazioni valutate, raggiungendo 2,40 ms con implementazioni a otto GPU. Queste caratteristiche prestazionali lo rendono adatto ad applicazioni che richiedono tempi di risposta minimi, come i sistemi interattivi in tempo reale in cui una latenza inferiore a 3 ms è 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 della latenza si verifica durante il passaggio da configurazioni a singola GPU a configurazioni a doppia GPU (circa il 50% su tutte le piattaforme). Le configurazioni con più di 4 GPU mostrano miglioramenti della latenza progressivamente inferiori.

Analisi comparativa H200 e H100 : l'H200 dimostra 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,81 ms contro 2,86 ms con otto GPU, una differenza di 0,05 ms). Questa differenza di prestazioni marginale, se confrontata con la differenza di prezzo del 41%, suggerisce che l'H100 potrebbe offrire caratteristiche di costo-prestazioni più favorevoli per implementazioni sensibili alla latenza.

AMD Caratteristiche di latenza MI300X : MI300X dimostra valori di latenza superiori del 37-75% rispetto a H200 nelle configurazioni testate, il che può essere attribuito alle attuali differenze nella maturità dello stack software tra le implementazioni vLLM ROCm e CUDA. Su una scala a otto GPU, MI300X raggiunge una latenza di 4,20 ms, che rimane entro parametri accettabili per numerose applicazioni di produzione nonostante la differenza di prestazioni rispetto alle piattaforme NVIDIA.

Prestazioni vs. prezzo: un'analisi di costo-efficacia

Sebbene le metriche di performance 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 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 le tariffe di archiviazione o di rete.

Come abbiamo calcolato il throughput per dollaro

Per generare questo grafico, abbiamo elaborato i nostri dati grezzi sulle 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 esempio, 4x H100 costano $10,76).
• Calcolo: Abbiamo quindi applicato la formula per calcolare il valore throughput_per_dollar. Ad esempio, l'H100 con 1 GPU ha erogato 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 è la soluzione 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 LLM, ciò può essere ottenuto tramite il 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 tra tutte le istanze.

Idealmente, l'utilizzo di due GPU offrirebbe prestazioni doppie rispetto a una singola GPU (accelerazione 2x). Tuttavia, nella realtà, i miglioramenti prestazionali sono limitati dai colli di bottiglia della CPU e del sistema, dal tempo che il sistema host impiega per gestire più processi simultanei, dai vincoli di larghezza di banda della memoria e dalla contesa delle risorse. Il nostro benchmark misura l'efficienza con cui ciascuna piattaforma gestisce questi vincoli a livello di sistema, un fattore critico per la creazione di server di inferenza AI economici e ad alte prestazioni per modelli di piccole e medie dimensioni.

Quali sono le sfide nei test di scalabilità multi-GPU?

Il benchmarking dei sistemi multi-GPU presenta sfide uniche che possono influire significativamente sulle prestazioni.

Sovraccarico di comunicazione e colli di bottiglia di interconnessione

Quando un modello viene suddiviso tra più GPU, l'interconnessione, come ad esempio NVLink di NVIDIA o Infinity Fabric di AMD, diventa un collo di bottiglia critico per le prestazioni. L'efficienza della comunicazione tra GPU ha un impatto diretto sulla scalabilità. Se il tempo impiegato per attendere i dati da un'altra GPU supera il tempo risparmiato grazie alla parallelizzazione del calcolo, i vantaggi in termini di prestazioni diminuiranno. Questo effetto è particolarmente pronunciato nei modelli che non sono sufficientemente grandi da saturare completamente la capacità di calcolo di ciascuna GPU.

Maturità dell'ecosistema software

Le prestazioni non dipendono esclusivamente dall'hardware. Lo stack software, inclusi i driver, le librerie di comunicazione (come NCCL per NVIDIA e RCCL per AMD) e il motore di inferenza (vLLM), gioca un ruolo fondamentale. Abbiamo scoperto che le prestazioni di una piattaforma sono profondamente legate alla maturità del suo supporto software. Un ecosistema consolidato come CUDA di NVIDIA spesso beneficia di anni di messa a punto e ottimizzazione, che possono portare a una maggiore efficienza di scalabilità 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 spesso richiede configurazioni specifiche per la piattaforma. L'utilizzo di un approccio generico, "valido per tutti", può portare a risultati ingannevolmente bassi. L'immagine Docker corretta, le variabili d'ambiente (ad esempio, l'abilitazione di kernel personalizzati AMD) e persino i tipi di dati del modello (ad esempio, bfloat16 per Blackwell) sono essenziali per sbloccare il vero potenziale dell'hardware. Questo rende i confronti equi "a parità di condizioni" una sfida tecnica significativa.

Metodologia di benchmark multi-GPU

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

Ambiente e processo di prova

• Piattaforma : Tutti i benchmark sono stati eseguiti su RunPod Cloud per garantire un accesso hardware coerente.
• Motore di inferenza : vLLM (vllm bench throughput tool) è stato utilizzato come motore standardizzato.
• Modello : meta-llama/Llama-3.1-8B-Instruct.
• Set di dati : set di dati ShareGPT Vicuña (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 dei prompt è stato distribuito uniformemente tra le istanze, che sono state eseguite simultaneamente per simulare un ambiente di produzione con bilanciamento del carico. Questo approccio elimina la comunicazione tra le GPU (NVLink/PCIe) come collo di bottiglia, spostando i fattori limitanti delle prestazioni sul sistema host (CPU, RAM).
• Automazione : sono stati utilizzati script Bash personalizzati 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 della piattaforma

Per ottenere prestazioni ottimali erano necessarie configurazioni personalizzate per ciascuna architettura.

Piattaforme NVIDIA (H100, H200, B200)

• Immagine di base : runpod/pytorch:2.8.0-py3.11-cuda12.8.1.
• Installazione 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 per la nuova architettura, risolvendo gli errori "nessuna immagine del kernel".
• Parametri chiave :

• Variabile ambientale 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 fase di messa a punto ha identificato le seguenti impostazioni non predefinite come cruciali per ottenere la massima produttività:

• AMD-variabili d'ambiente specifiche :

• Visibilità del dispositivo : ROCR_VISIBLE_DEVICES è stato utilizzato al posto dell'equivalente CUDA per assegnare le istanze a specifiche GPU.

Fasi di esecuzione di riferimento

Ogni test di 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 richieste elaborate sulla GPU 0
• Scopo: Caricamento del modello, inizializzazione della cache KV e compilazione del kernel CUDA/ROCm
• Uscita: Scartata (non inclusa nelle misurazioni)
• Comportamento specifico della piattaforma:
  • NVIDIA (CUDA): Compilazione del kernel e ottimizzazione del grafico CUDA (~30-60 secondi)
  • AMD (ROCm): Compilazione del kernel e ottimizzazione opzionale di TunableOp (varia in base all'impostazione PYTORCH_TUNABLEOP_ENABLED)

Fase 2: Inizializzazione del monitoraggio GPU

Contemporaneamente all'esecuzione dei benchmark, abbiamo avviato processi di monitoraggio dedicati per ciascuna GPU:

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

Fase 3: Esecuzione parallela del benchmark

Al termine della fase di 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.
• La velocità di trasmissione totale viene misurata come la somma di tutti gli output della GPU
• Tempo di esecuzione misurato dall'avvio della prima istanza al completamento dell'ultima istanza.

Impatto reale delle prestazioni derivanti dai test

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

Per approfondire

Esplora altre ricerche sull'hardware basato sull'intelligenza artificiale, come ad esempio:

• I 20 principali produttori di chip per l'intelligenza artificiale: NVIDIA e i suoi concorrenti
• GPU cloud per il deep learning: disponibilità e prezzo/prestazioni
• Le 10 migliori piattaforme cloud GPU serverless e 14 GPU economiche
• Benchmark di concorrenza GPU

Collegamenti di riferimento

1.

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

2.

https://docs.vllm.ai/en/latest/

Sedat Dogan

CTO

Segui

Sedat è un leader nel settore della tecnologia e della sicurezza informatica, con esperienza nello sviluppo software, nella raccolta di dati web e nella sicurezza informatica. Sedat: - Ha 20 anni di esperienza come hacker etico e guru dello sviluppo, con una vasta competenza nei linguaggi di programmazione e nelle architetture server. - È consulente di dirigenti di alto livello e membri del consiglio di amministrazione di aziende con operazioni tecnologiche ad alto traffico e di importanza critica, come le infrastrutture di pagamento. - Possiede una solida competenza commerciale oltre alla sua competenza tecnica.

Visualizza il profilo completo

Ricercato da

Ekrem Sarı

Ricercatore di intelligenza artificiale

Segui

Ekrem è un ricercatore di intelligenza artificiale presso AIMultiple, specializzato in automazione intelligente, GPU, agenti di intelligenza artificiale e framework RAG.

Visualizza il profilo completo

Sii il primo a commentare

Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori.

Nome

Indirizzo e-mail

Commento

0/450

Pubblica un commento