Ottieni un throughput di inferenza ML quattro volte superiore a un costo per inferenza tre volte inferiore con le istanze G2 di Amazon EC5 per i modelli NLP e CV PyTorch

Cloud di calcolo elastico di Amazon (Amazon EC2) Istanze G5 sono le prime e uniche istanze nel cloud a presentare GPU NVIDIA A10G Tensor Core, che puoi utilizzare per un'ampia gamma di casi d'uso ad alta intensità grafica e di apprendimento automatico (ML). Con le istanze G5, i clienti ML ottengono prestazioni elevate e un'infrastruttura conveniente per addestrare e distribuire modelli più grandi e sofisticati per l'elaborazione del linguaggio naturale (NLP), la visione artificiale (CV) e i casi d'uso del motore di raccomandazione.

Lo scopo di questo post è mostrare i vantaggi in termini di prestazioni delle istanze G5 per carichi di lavoro di inferenza ML su larga scala. Lo facciamo confrontando il rapporto prezzo-prestazioni (misurato come $ per milione di inferenze) per i modelli NLP e CV con le istanze G4dn. Iniziamo descrivendo il nostro approccio di benchmarking e quindi presentiamo le curve di velocità effettiva rispetto alla latenza per le dimensioni dei batch e la precisione del tipo di dati. Rispetto alle istanze G4dn, troviamo che le istanze G5 offrono costi per milione di inferenze costantemente inferiori sia per le modalità di precisione completa che mista per i modelli NLP e CV, ottenendo al contempo un throughput più elevato e una latenza inferiore.

Approccio di benchmarking

Per sviluppare uno studio rapporto prezzo-prestazioni tra G5 e G4dn, dobbiamo misurare il throughput, la latenza e il costo per milione di inferenze in funzione della dimensione del batch. Studiamo anche l'impatto della precisione totale rispetto alla precisione mista. Sia il grafico del modello che gli input vengono caricati in CUDA prima dell'inferenza.

Come mostrato nel diagramma dell'architettura seguente, creiamo prima le rispettive immagini del contenitore di base con CUDA per l'istanza EC2 sottostante (G4dn, G5). Per costruire le immagini del contenitore di base, iniziamo con Contenitori per l'apprendimento profondo AWS, che utilizzano immagini Docker preconfezionate per distribuire ambienti di deep learning in pochi minuti. Le immagini contengono le librerie e gli strumenti PyTorch di deep learning richiesti. Puoi aggiungere le tue librerie e strumenti su queste immagini per un maggiore livello di controllo su monitoraggio, conformità ed elaborazione dei dati.

Quindi creiamo un'immagine del contenitore specifica del modello che incapsula la configurazione del modello, la traccia del modello e il codice correlato per eseguire i passaggi in avanti. Tutte le immagini del contenitore vengono caricate in Amazon ECR per consentire il ridimensionamento orizzontale di questi modelli per varie configurazioni di modelli. Noi usiamo Servizio di archiviazione semplice Amazon (Amazon S3) come archivio dati comune per scaricare la configurazione e caricare i risultati del benchmark per il riepilogo. Puoi utilizzare questa architettura per ricreare e riprodurre i risultati del benchmark e riproporli per eseguire il benchmark di vari tipi di modelli (come modelli Hugging Face, modelli PyTorch e altri modelli personalizzati) su tipi di istanze EC2 (CPU, GPU, Inf1).

Con questo esperimento impostato, il nostro obiettivo è studiare la latenza in funzione del throughput. Questa curva è importante affinché la progettazione dell'applicazione raggiunga un'infrastruttura economicamente ottimale per l'applicazione di destinazione. Per ottenere ciò, simuliamo carichi diversi mettendo in coda le query da più thread e quindi misurando il tempo di andata e ritorno per ogni richiesta completata. Il throughput viene misurato in base al numero di richieste completate per unità di tempo. Inoltre, puoi variare le dimensioni del lotto e altre variabili come la lunghezza della sequenza e la precisione completa rispetto alla precisione dimezzata per spazzare in modo completo lo spazio di progettazione per arrivare a metriche di prestazione indicative. Nel nostro studio, attraverso un'analisi parametrica della dimensione del batch e delle query da client multi-thread, viene determinata la curva di velocità effettiva rispetto alla latenza. Ogni richiesta può essere suddivisa in batch per garantire il pieno utilizzo dell'acceleratore, in particolare per richieste di piccole dimensioni che potrebbero non utilizzare completamente il nodo di calcolo. È inoltre possibile adottare questa configurazione per identificare la dimensione del batch lato client per prestazioni ottimali.

In sintesi, possiamo rappresentare matematicamente questo problema come: (Throughput, Latency) = funzione di (Batch Size, Number of threads, Precision).

Ciò significa che, dato lo spazio esauriente, il numero di esperimenti può essere elevato. Fortunatamente, ogni esperimento può essere eseguito in modo indipendente. Si consiglia di utilizzare Batch AWS per eseguire questo benchmarking su scala orizzontale in un tempo compresso senza un aumento dei costi di benchmarking rispetto a un approccio lineare al test. Il codice per replicare i risultati è presente nel file Repository GitHub preparato per AWS Re:Invent 2021. Il repository è completo per eseguire benchmark su diversi acceleratori. Puoi fare riferimento all'aspetto GPU del codice per creare il contenitore (Dockerfile-gpu) e quindi fare riferimento al codice all'interno Container-Root per esempi specifici per BERT e ResNet50.

Abbiamo utilizzato l'approccio precedente per sviluppare studi sulle prestazioni su due tipi di modello: Bert-base-uncased (110 milioni di parametri, NLP) e ResNet50 (25.6 milioni di parametri, CV). La tabella seguente riassume i dettagli del modello.

Tipo di modello	Modello	Dettagli
NLP	twmkn9/bert-base-uncased-squad2	110 milioni di parametri Lunghezza sequenza = 128
CV	ResNet50	25.6 milioni di parametri

Inoltre, per confrontare i tipi di dati (precisione completa, dimezzata), utilizziamo torch.cuda.amp, che fornisce metodi convenienti per gestire la precisione mista in cui alcune operazioni utilizzano il torch.float32 tipo di dati (flottante) e utilizzo di altre operazioni torch.float16 (metà). Ad esempio, operatori come i livelli lineari e le convoluzioni sono molto più veloci con float16, mentre altri come le riduzioni spesso richiedono la gamma dinamica di float32. La precisione mista automatica cerca di abbinare ciascun operatore al tipo di dati appropriato per ottimizzare il runtime e l'ingombro di memoria della rete.

Risultati comparativi

Per un confronto equo, abbiamo selezionato G4dn.4xgrande ed G5.4xgrande istanze con attributi simili, come elencato nella tabella seguente.

Instance	GPU	Memoria GPU (GiB)	CPU virtuali	Memoria (GiB)	Memoria istanza (GB)	Prestazioni di rete (Gbps)	Larghezza di banda EBS (Gbps)	Prezzi Linux On-Demand (us-east-1)
G5.4xgrande	1	24	16	64	1x SSD da 600 NVMe	fino a 25	8	$ 1.204 / ora
G4dn.4xgrande	1	16	16	64	1x SSD da 225 NVMe	fino a 25	4.75	$ 1.624 / ora

Nelle sezioni seguenti, confrontiamo le prestazioni di inferenza ML dei modelli BERT e RESNET50 con un approccio grid sweep per dimensioni batch specifiche (32, 16, 8, 4, 1) e precisione del tipo di dati (precisione completa e semi-precisione) per arrivare al throughput vs. curva di latenza. Inoltre, esaminiamo l'effetto della velocità effettiva rispetto alla dimensione del batch per la precisione sia completa che dimezzata. Infine, misuriamo il costo per milione di inferenze in funzione della dimensione del batch. I risultati consolidati di questi esperimenti sono riassunti più avanti in questo post.

Throughput vs. latenza

Le figure seguenti confrontano le istanze G4dn e G5 per carichi di lavoro NLP e CV con precisione sia completa che parziale. Rispetto alle istanze G4dn, l'istanza G5 offre un throughput di circa cinque volte superiore (precisione completa) e circa 2.5 volte superiore (mezza precisione) per un modello base BERT e circa 2-2.5 volte superiore per un modello ResNet50. Nel complesso, G5 è la scelta preferita, con dimensioni dei lotti crescenti per entrambi i modelli per la precisione sia completa che mista dal punto di vista delle prestazioni.

I grafici seguenti confrontano il throughput e la latenza P95 a piena e mezza precisione per BERT.

I grafici seguenti confrontano il throughput e la latenza P95 a piena e mezza precisione per ResNet50.

Throughput e latenza rispetto alle dimensioni del batch

I grafici seguenti mostrano il throughput in funzione della dimensione del batch. Con dimensioni batch ridotte, l'acceleratore non funziona alla massima capacità e all'aumentare delle dimensioni del batch, il throughput aumenta a scapito della latenza. La curva di throughput asintota a un valore massimo che è una funzione delle prestazioni dell'acceleratore. La curva ha due caratteristiche distinte: una sezione ascendente e una sezione asintotica piatta. Per un dato modello, un acceleratore performante (G5) è in grado di allungare la sezione ascendente a lotti di dimensioni maggiori rispetto a G4dn e asintoto a un throughput più elevato. Inoltre, esiste un compromesso lineare tra latenza e dimensione del batch. Pertanto, se l'applicazione è vincolata alla latenza, è possibile utilizzare la latenza P95 rispetto alla dimensione del batch per determinare la dimensione ottimale del batch. Tuttavia, se l'obiettivo è massimizzare il throughput alla latenza più bassa, è meglio selezionare la dimensione del batch corrispondente al "ginocchio" tra la sezione ascendente e quella asintotica, poiché qualsiasi ulteriore aumento della dimensione del batch comporterebbe lo stesso throughput a un latenza peggiore. Per ottenere il miglior rapporto qualità-prezzo, puntando a un throughput più elevato alla latenza più bassa, è meglio scalare orizzontalmente questo valore ottimale attraverso più server di inferenza piuttosto che aumentare semplicemente le dimensioni del batch.

Costo rispetto alla dimensione del lotto

In questa sezione, presentiamo i risultati comparativi dei costi di inferenza ($ per milione di inferenze) rispetto alla dimensione del batch. Dalla figura seguente, possiamo osservare chiaramente che il costo (misurato come $ per milione di inferenze) è costantemente inferiore con G5 rispetto a G4dn entrambi (precisione completa e metà).

La tabella seguente riassume i confronti di throughput, latenza e costi ($ per milione di inferenze) per i modelli BERT e RESNET50 in entrambe le modalità di precisione per lotti di dimensioni specifiche. Nonostante un costo per istanza più elevato, G5 supera costantemente G4dn in tutti gli aspetti di latenza di inferenza, velocità effettiva e costo ($ per milione di inferenza), per tutte le dimensioni dei batch. Combinando le diverse metriche in un costo ($ per milione di inferenze), il modello BERT (32 dimensioni batch, precisione completa) con G5 è 3.7 volte più vantaggioso di G4dn e con il modello ResNet50 (32 dimensioni batch, precisione completa), è 1.6 volte più favorevole di G4dn.

Modello	Dimensione del lotto	Precisione	Throughput (Lotto dimensione X Richieste/sec)		Latenza (ms)		$/milione Inferenze (su richiesta)		Costi-benefici (G5 su G4dn)
.	.	.	G5	G4DN	G5	G4DN	G5	G4DN
Bert-base-senza custodia	32	Lunga	723	154	44	208	$0.6	$2.2	3.7X
		Misto	870	410	37	79	$0.5	$0.8	1.6X
	16	Lunga	651	158	25	102	$0.7	$2.1	3.0X
		Misto	762	376	21	43	$0.6	$0.9	1.5X
	8	Lunga	642	142	13	57	$0.7	$2.3	3.3X
		Misto	681	350	12	23	$0.7	$1.0	1.4X
.	1	Lunga	160	116	6	9	$2.8	$2.9	1.0X
		Misto	137	102	7	10	$3.3	$3.3	1.0X
ResNet50	32	Lunga	941	397	34	82	$0.5	$0.8	1.6X
		Misto	1533	851	21	38	$0.3	$0.4	1.3X
	16	Lunga	888	384	18	42	$0.5	$0.9	1.8X
		Misto	1474	819	11	20	$0.3	$0.4	1.3X
	8	Lunga	805	340	10	24	$0.6	$1.0	1.7X
		Misto	1419	772	6	10	$0.3	$0.4	1.3X
.	1	Lunga	202	164	5	6	$2.2	$2	0.9X
		Misto	196	180	5	6	$2.3	$1.9	0.8X

Ulteriori benchmark di inferenza

Oltre alla base BERT e ai risultati ResNet50 nelle sezioni precedenti, presentiamo ulteriori risultati di benchmarking per altri modelli NLP e CV di grandi dimensioni comunemente usati in PyTorch. Il vantaggio in termini di prestazioni di G5 rispetto a G4dn è stato presentato per i modelli BERT Large con varia precisione e per i modelli Yolo-v5 per varie dimensioni. Per il codice per la replica del benchmark, fare riferimento a Esempi di Deep Learning NVIDIA per Tensor Core. Questi risultati mostrano il vantaggio dell'utilizzo di G5 su G4dn per un'ampia gamma di attività di inferenza che coprono diversi tipi di modello.

Modello	Precisione	Dimensione del lotto	Lunghezza della sequenza	Throughput (inviato/sec)	Produttività: G4dn	Accelerazione su G4dn
BERT-grande	FP16	1	128	93.5	40.31	2.3
BERT-grande	FP16	4	128	264.2	87.4	3.0
BERT-grande	FP16	8	128	392.1	107.5	3.6
BERT-grande	FP32	1	128	68.4	22.67	3.0
BERT-grande		4	128	118.5	32.21	3.7
BERT-grande		8	128	132.4	34.67	3.8

Modello	GFLOPS	Numero di parametri	Preelaborazione (ms)	Inferenza (ms)	Inferenza (soppressione non max) (NMS/immagine)
YOLOv5s	16.5	7.2M	0.2	3.6	4.5
YOLOv5m	49.1	21M	0.2	6.5	4.5
YOLOv5l	109.3	46M	0.2	9.1	3.5
YOLOv5x	205.9	86M	0.2	14.4	1.3

Conclusione

In questo post, abbiamo dimostrato che per l'inferenza con modelli NLP e CV PyTorch di grandi dimensioni, le istanze EC2 G5 sono una scelta migliore rispetto alle istanze G4dn. Sebbene il costo orario on-demand per le istanze G5 sia superiore a quello delle istanze G4dn, le sue prestazioni più elevate possono raggiungere 2-5 volte il throughput con qualsiasi precisione per i modelli NLP e CV, il che rende il costo per milione di inferenze 1.5-3.5 volte più favorevole di istanze G4dn. Anche per le applicazioni legate alla latenza, G5 è 2.5–5 volte migliore di G4dn per i modelli NLP e CV.

In sintesi, le istanze AWS G5 sono una scelta eccellente per le tue esigenze di inferenza sia dal punto di vista delle prestazioni che del costo per inferenza. L'universalità del framework CUDA e la scala e la profondità del pool di istanze G5 su AWS ti offrono una capacità unica di eseguire inferenze su larga scala.

---

Circa gli autori

Ankur Srivastava è Sr. Solutions Architect nel team di ML Frameworks. Si concentra sull'assistenza ai clienti con formazione distribuita autogestita e inferenza su larga scala su AWS. La sua esperienza comprende la manutenzione predittiva industriale, i gemelli digitali, l'ottimizzazione del design probabilistico e ha completato i suoi studi di dottorato presso l'ingegneria meccanica presso la Rice University e la ricerca post-dottorato presso il Massachusetts Institute of Technology.

Sundar Ranganathan è Head of Business Development, ML Frameworks nel team Amazon EC2. Si concentra su carichi di lavoro ML su larga scala attraverso servizi AWS come Amazon EKS, Amazon ECS, Elastic Fabric Adapter, AWS Batch e Amazon SageMaker. La sua esperienza include ruoli di leadership nella gestione e nello sviluppo dei prodotti presso NetApp, Micron Technology, Qualcomm e Mentor Graphics.

Mahadevan Balasubramaniam è un Principal Solutions Architect per l'Autonomous Computing con quasi 20 anni di esperienza nell'area dell'apprendimento profondo infuso di fisica, costruzione e implementazione di gemelli digitali per sistemi industriali su larga scala. Mahadevan ha conseguito il dottorato di ricerca in Ingegneria Meccanica presso il Massachusetts Institute of Technology e ha al suo attivo oltre 25 brevetti e pubblicazioni.

Amr Ragab è un Principal Solutions Architect per EC2 Accelerated Platforms for AWS, dedicato ad aiutare i clienti a eseguire carichi di lavoro computazionali su larga scala. Nel tempo libero ama viaggiare e trovare nuovi modi per integrare la tecnologia nella vita quotidiana.