Ottieni prestazioni elevate su larga scala per il servizio di modelli utilizzando gli endpoint multi-modello di Amazon SageMaker con GPU

Amazon Sage Maker endpoint multi-modello (MME) forniscono un modo scalabile ed economico per implementare un gran numero di modelli di machine learning (ML). Ti dà la possibilità di distribuire più modelli ML in un unico contenitore di servizio dietro un singolo endpoint. Da lì, SageMaker gestisce il caricamento e lo scaricamento dei modelli e il ridimensionamento delle risorse per tuo conto in base ai tuoi modelli di traffico. Beneficerai della condivisione e del riutilizzo delle risorse di hosting e di un onere operativo ridotto per la gestione di una grande quantità di modelli.

Nel mese di novembre 2022, MME ha aggiunto il supporto per GPUs, che consente di eseguire più modelli su un singolo dispositivo GPU e ridimensionare le istanze GPU dietro un singolo endpoint. Ciò soddisfa la forte domanda MME di modelli di reti neurali profonde (DNN) che traggono vantaggio dal calcolo accelerato con GPU. Questi includono visione artificiale (CV), elaborazione del linguaggio naturale (PNL) e modelli di intelligenza artificiale generativa. Tra i motivi della richiesta si annoverano i seguenti:

• I modelli DNN sono in genere di grandi dimensioni e complessità e continuano a crescere a un ritmo rapido. Prendendo come esempio i modelli NLP, molti di essi superano miliardi di parametri, il che richiede che le GPU soddisfino i requisiti di bassa latenza e throughput elevato.
• Abbiamo osservato una maggiore necessità di personalizzare questi modelli per offrire esperienze iper-personalizzate ai singoli utenti. Con l'aumentare della quantità di questi modelli, è necessaria una soluzione più semplice per distribuire e rendere operativi molti modelli su larga scala.
• Le istanze GPU sono costose e si desidera riutilizzarle il più possibile per massimizzare l'utilizzo della GPU e ridurre i costi operativi.

Sebbene tutti questi motivi indichino MME con GPU come un'opzione ideale per i modelli DNN, si consiglia di eseguire test di carico per trovare la giusta configurazione dell'endpoint che soddisfi i requisiti del caso d'uso. Molti fattori possono influenzare i risultati del test di carico, come il tipo di istanza, il numero di istanze, la dimensione del modello e l'architettura del modello. Inoltre, i test di carico possono aiutare a guidare le strategie di ridimensionamento automatico utilizzando le metriche giuste anziché metodi iterativi per tentativi ed errori.

Per questi motivi, abbiamo messo insieme questo post per aiutarti a eseguire test di carico adeguati su MME con GPU e trovare la migliore configurazione per il tuo caso d'uso ML. Condividiamo i risultati dei nostri test di carico per alcuni dei modelli DNN più popolari in NLP e CV ospitati utilizzando MME su diversi tipi di istanza. Riassumiamo gli approfondimenti e le conclusioni dei risultati dei nostri test per aiutarti a prendere una decisione informata sulla configurazione delle tue distribuzioni. Lungo il percorso, condividiamo anche il nostro approccio consigliato per l'esecuzione di test di carico per MME su GPU. Gli strumenti e la tecnica consigliati determinano il numero ottimale di modelli che possono essere caricati per tipo di istanza e ti aiutano a ottenere il miglior rapporto prezzo-prestazioni.

Panoramica della soluzione

Per un'introduzione a MME e MME con GPU, fare riferimento a Creare un endpoint multimodello ed Esegui più modelli di deep learning su GPU con gli endpoint multimodello Amazon SageMaker. Per il contesto del test di carico in questo post, puoi scaricare il nostro codice di esempio dal file Repository GitHub per riprodurre i risultati o utilizzarlo come modello per confrontare i propri modelli. Ci sono due notebook forniti nel repository: uno per i modelli CV di test di carico e un altro per la PNL. Diversi modelli di varie dimensioni e architetture sono stati sottoposti a benchmark su diversi tipi di istanze GPU: ml.g4dn.2xlarge, ml.g5.2xlarge e ml.p3.2xlarge. Ciò dovrebbe fornire una ragionevole sezione trasversale delle prestazioni attraverso le seguenti metriche per ogni tipo di istanza e modello:

• Numero massimo di modelli che possono essere caricati nella memoria della GPU
• Latenza di risposta end-to-end osservata sul lato client per ogni query di inferenza
• Velocità effettiva massima di query al secondo che l'endpoint può elaborare senza errori
• Numero massimo di utenti correnti per istanza prima che venga osservata una richiesta non riuscita

La tabella seguente elenca i modelli testati.

La tabella seguente elenca le istanze GPU testate.

Come accennato in precedenza, il esempio di codice può essere adottato per altri modelli e tipi di istanza.

Tieni presente che gli MME attualmente supportano solo singole istanze GPU. Per l'elenco dei tipi di istanza supportati, fare riferimento a Algoritmi, framework e istanze supportati.

La procedura di benchmarking comprende le seguenti fasi:

1. Recupera un modello pre-addestrato da un hub modello.
2. Preparare l'artefatto del modello per la pubblicazione su SageMaker MME (vedere Esegui più modelli di deep learning su GPU con gli endpoint multimodello Amazon SageMaker per ulteriori dettagli).
3. Distribuisci un MME SageMaker su un'istanza GPU.
4. Determina il numero massimo di modelli che possono essere caricati nella memoria della GPU entro una soglia specificata.
5. Utilizza il Locust Load Testing Framework per simulare il traffico che richiama in modo casuale i modelli caricati sull'istanza.
6. Raccogli dati e analizza i risultati.
7. Facoltativamente, ripetere i passaggi da 2 a 6 dopo aver compilato il modello in TensorRT.

I passaggi 4 e 5 richiedono uno sguardo più approfondito. I modelli all'interno di un MME per GPU SageMaker vengono caricati in memoria in modo dinamico. Pertanto, nel passaggio 4, carichiamo un artefatto del modello iniziale in Servizio di archiviazione semplice Amazon (Amazon S3) e richiamare il modello per caricarlo in memoria. Dopo l'invocazione iniziale, misuriamo la quantità di memoria GPU consumata, creiamo una copia del modello iniziale, invochiamo la copia del modello per caricarla in memoria e misuriamo nuovamente la quantità totale di memoria GPU consumata. Questo processo viene ripetuto finché non viene raggiunta una soglia percentuale specificata di utilizzo della memoria della GPU. Per il benchmark, abbiamo impostato la soglia al 90% per fornire un buffer di memoria ragionevole per l'inferenza su batch più grandi o per lasciare un po' di spazio per caricare altri modelli usati meno di frequente.

Simula il traffico degli utenti

Dopo aver determinato il numero di modelli, possiamo eseguire un test di carico utilizzando il Framework di test di carico di locuste. Il test di carico simula le richieste degli utenti a modelli casuali e misura automaticamente metriche come latenza di risposta e velocità effettiva.

Locust supporta forme di test di carico personalizzate che consentono di definire modelli di traffico personalizzati. La forma utilizzata in questo benchmark è mostrata nella tabella seguente. Nei primi 30 secondi, l'endpoint viene riscaldato con 10 utenti simultanei. Dopo 30 secondi, i nuovi utenti vengono generati a una velocità di due al secondo, raggiungendo 20 utenti simultanei al segno dei 40 secondi. L'endpoint viene quindi confrontato costantemente con 20 utenti simultanei fino al segno dei 60 secondi, a quel punto Locust ricomincia a incrementare gli utenti a due al secondo fino a 40 utenti simultanei. Questo schema di accelerazione e test costanti viene ripetuto fino a quando l'endpoint non viene portato a 200 utenti simultanei. A seconda del tuo caso d'uso, potresti voler regolare la forma del test di carico in locust_benchmark_sm.py per riflettere più accuratamente i modelli di traffico previsti. Ad esempio, se intendi ospitare modelli di linguaggio più grandi, un test di carico con 200 utenti simultanei potrebbe non essere fattibile per un modello ospitato su una singola istanza e potresti quindi voler ridurre il numero di utenti o aumentare il numero di istanze. Potresti anche voler estendere la durata del test di carico per misurare con maggiore precisione la stabilità dell'endpoint per un periodo di tempo più lungo.

stages = [
{"duration": 30, "users": 10, "spawn_rate": 5},
{"duration": 60, "users": 20, "spawn_rate": 1},
{"duration": 90, "users": 40, "spawn_rate": 2},
…
]

Tieni presente che abbiamo eseguito il benchmark dell'endpoint solo con modelli omogenei, tutti in esecuzione su basi di servizio coerenti utilizzando PyTorch o TensorRT. Questo perché gli MME sono più adatti per ospitare molti modelli con caratteristiche simili, come il consumo di memoria e il tempo di risposta. I modelli di benchmarking forniti nel Repository GitHub può ancora essere utilizzato per determinare se servire modelli eterogenei su MME produrrebbe le prestazioni e la stabilità desiderate.

Risultati di benchmark per i modelli CV

Utilizza il notebook cv-benchmark.ipynb per eseguire il test di carico per i modelli di visione artificiale. Puoi adattare il nome del modello pre-addestrato e i parametri del tipo di istanza al test di carico delle prestazioni su diverse combinazioni di modello e tipo di istanza. Abbiamo appositamente testato tre modelli CV in diverse gamme di dimensioni dal più piccolo al più grande: resnet50 (25 milioni), convnext_base (88M), e vit_large_patch16_224 (304M). Potrebbe essere necessario adeguarsi al codice se si sceglie un modello al di fuori di questo elenco. inoltre, il notebook imposta per impostazione predefinita la forma dell'immagine in ingresso su un tensore dell'immagine 224x224x3. Ricordarsi di regolare la forma di input di conseguenza se è necessario eseguire il benchmark di modelli che acquisiscono un'immagine di dimensioni diverse.

Dopo aver esaminato l'intero notebook, otterrai diverse visualizzazioni di analisi delle prestazioni. I primi due descrivono in dettaglio le prestazioni del modello rispetto all'aumento degli utenti simultanei. Le seguenti figure sono le visualizzazioni di esempio generate per il ResNet50 modello in esecuzione su ml.g4dn.2xlarge, confrontando PyTorch (a sinistra) e TensorRT (a destra). I grafici della riga superiore mostrano la latenza e la velocità effettiva del modello sull'asse y con un numero crescente di lavoratori client simultanei riflessi sull'asse x. I grafici a barre in basso mostrano il conteggio delle richieste riuscite e non riuscite.

Esaminando tutti i modelli di visione artificiale che abbiamo testato, abbiamo osservato quanto segue:

• La latenza (in millisecondi) è maggiore e il throughput (richieste al secondo) è inferiore per i modelli più grandi (resnet50 > convnext_base > vit_large_patch16_224).
• L'aumento della latenza è proporzionale al numero di utenti man mano che più richieste vengono accodate sul server di inferenza.
• I modelli di grandi dimensioni consumano più risorse di calcolo e possono raggiungere i limiti massimi di velocità effettiva con un numero inferiore di utenti rispetto a un modello più piccolo. Questo è osservato con il vit_large_patch16_224 modello, che ha registrato la prima richiesta fallita a 140 utenti simultanei. Essendo significativamente più grande degli altri due modelli testati, presentava anche la maggior parte delle richieste non riuscite complessive a una maggiore concorrenza. Questo è un chiaro segnale che l'endpoint dovrebbe scalare oltre una singola istanza se l'intento è supportare più di 140 utenti simultanei.

Alla fine dell'esecuzione del notebook, ottieni anche un confronto riepilogativo dei modelli PyTorch e TensorRT per ciascuna delle quattro metriche chiave. Dai nostri test di benchmark, tutti i modelli CV hanno visto un aumento delle prestazioni del modello dopo la compilazione di TensorRT. Prendendo il nostro ResNet50 modello come esempio, la latenza è diminuita del 32% mentre il throughput è aumentato del 18%. Sebbene il numero massimo di utenti simultanei sia rimasto lo stesso per ResNet50, gli altri due modelli hanno entrambi registrato un miglioramento del 14% nel numero di utenti simultanei che possono supportare. Il miglioramento delle prestazioni di TensorRT, tuttavia, è avvenuto a scapito di un maggiore utilizzo della memoria, con il risultato di un minor numero di modelli caricati dagli MME. L'impatto è maggiore per i modelli che utilizzano una rete neurale convoluzionale (CNN). Infatti, il nostro modello ResNet50 ha consumato circa il doppio della memoria della GPU passando da PyTorch a TensorRT, con il risultato di caricare il 50% in meno di modelli (46 contro 23). Diagnostichiamo ulteriormente questo comportamento nella sezione seguente.

Risultati di benchmark per i modelli di PNL

Per i modelli NLP, usa il notebook nlp-benchmark.ipynb per eseguire il test di carico. La configurazione del notebook dovrebbe essere molto simile. Abbiamo testato due modelli di PNL: bert-base-uncased (109M) e roberta-large (335M). Il modello pre-addestrato e il tokenizer vengono entrambi scaricati dall'hub Hugging Face e il payload di test viene generato dal tokenizer utilizzando una stringa di esempio. La lunghezza massima della sequenza è predefinita a 128. Se è necessario testare stringhe più lunghe, ricordarsi di regolare quel parametro. L'esecuzione del notebook NLP genera lo stesso set di visualizzazioni: Pytorch (a sinistra) vs TensorRT (a destra).

Da questi, abbiamo osservato un vantaggio ancora maggiore in termini di prestazioni di TensorRT per i modelli NLP. Prendendo il roberta-large modello su un'istanza ml.g4dn.2xlarge, ad esempio, la latenza di inferenza è diminuita drasticamente da 180 millisecondi a 56 millisecondi (un miglioramento del 70%), mentre la velocità effettiva è migliorata del 406% da 33 richieste al secondo a 167. Inoltre, il numero massimo di richieste simultanee gli utenti sono aumentati del 50%; le richieste fallite non sono state osservate fino a quando non abbiamo raggiunto 180 utenti simultanei, rispetto ai 120 del modello PyTorch originale. In termini di utilizzo della memoria, abbiamo visto un modello in meno caricato per TensorRT (da nove modelli a otto). Tuttavia, l'impatto negativo è molto minore rispetto a quanto osservato con i modelli basati sulla CNN.

Analisi sull'utilizzo della memoria

La tabella seguente mostra l'analisi completa dell'impatto sull'utilizzo della memoria passando da PyTorch a TensorRT. Abbiamo accennato in precedenza che i modelli basati sulla CNN hanno un impatto più negativo. IL ResNet50 model ha registrato una riduzione di oltre il 50% nel numero di modelli caricati su tutti e tre i tipi di istanza GPU. Convnext_base ha avuto una riduzione ancora maggiore a circa il 70% su tutta la linea. D'altra parte, l'impatto sui modelli di trasformatore è piccolo o misto. vit_large_patch16_224 ed roberta-large hanno avuto una riduzione media di circa il 20% e il 3%, rispettivamente, mentre bert-base-uncased ha avuto un miglioramento di circa il 40%.

Considerando tutti i punti dati nel loro insieme per quanto riguarda le prestazioni superiori in termini di latenza, throughput e affidabilità e l'impatto minore sul numero massimo di modelli caricati, consigliamo il modello TensorRT per le architetture del modello basate su trasformatore. Per le CNN, riteniamo che sia necessaria un'ulteriore analisi delle prestazioni in termini di costi per assicurarsi che il vantaggio in termini di prestazioni superi il costo dell'infrastruttura di hosting aggiuntiva.

Le seguenti tabelle elencano i nostri risultati di benchmark completi per tutti i parametri in tutti e tre i tipi di istanze GPU.

La tabella seguente riepiloga i risultati di tutti i tipi di istanza. L'istanza ml.g5.2xlarge offre le migliori prestazioni, mentre l'istanza ml.p3.2xlarge generalmente ha prestazioni inferiori nonostante sia la più costosa delle tre. Le istanze g5 e g4dn dimostrano il valore migliore per i carichi di lavoro di inferenza.

ripulire

Dopo aver completato il test di carico, pulisci le risorse generate per evitare di incorrere in costi aggiuntivi. Le risorse principali sono gli endpoint SageMaker e i file degli artefatti del modello in Amazon S3. Per semplificarti le cose, i file del notebook hanno il seguente codice di pulizia per aiutarti a eliminarli:

delete_endpoint(sm_client, sm_model_name, endpoint_config_name, endpoint_name) ! aws s3 rm --recursive {trt_mme_path}

Conclusione

In questo post, abbiamo condiviso i risultati dei test e l'analisi per vari modelli di reti neurali profonde in esecuzione su endpoint multi-modello SageMaker con GPU. I risultati e gli approfondimenti che abbiamo condiviso dovrebbero fornire una ragionevole sezione trasversale delle prestazioni tra diverse metriche e tipi di istanza. Nel processo, abbiamo anche introdotto il nostro approccio consigliato per eseguire test di benchmark per SageMaker MME con GPU. Gli strumenti e il codice di esempio che abbiamo fornito possono aiutarti ad avviare rapidamente i test di benchmark e prendere una decisione più informata su come ospitare a costi contenuti centinaia di modelli DNN su hardware di calcolo accelerato. Per iniziare con il benchmarking dei tuoi modelli con il supporto MME per GPU, fai riferimento a Algoritmi, framework e istanze supportati e la Repository GitHub per ulteriori esempi e documentazione.

Circa gli autori

Giacomo Wu è un Senior AI/ML Specialist Solution Architect presso AWS. aiutare i clienti a progettare e realizzare soluzioni AI/ML. Il lavoro di James copre un'ampia gamma di casi d'uso di ML, con un interesse primario per la visione artificiale, il deep learning e la scalabilità del ML in tutta l'azienda. Prima di entrare in AWS, James è stato architetto, sviluppatore e leader tecnologico per oltre 10 anni, di cui 6 in ingegneria e 4 anni nei settori del marketing e della pubblicità.

Vikram Elango è un AI/ML Specialist Solutions Architect presso Amazon Web Services, con sede in Virginia, USA. Vikram aiuta i clienti del settore finanziario e assicurativo con la progettazione e la leadership di pensiero a creare e distribuire applicazioni di machine learning su larga scala. Attualmente è concentrato sull'elaborazione del linguaggio naturale, sull'IA responsabile, sull'ottimizzazione dell'inferenza e sul ridimensionamento del ML in tutta l'azienda. Nel tempo libero ama viaggiare, fare escursioni, cucinare e fare campeggio con la sua famiglia.

Simone Zamarin è un architetto di soluzioni AI / ML il cui obiettivo principale è aiutare i clienti a estrarre valore dalle loro risorse di dati. Nel tempo libero, Simon ama passare il tempo con la famiglia, leggere fantascienza e lavorare a vari progetti di case fai da te.

Saurabh Trikande è un Senior Product Manager per Amazon SageMaker Inference. È appassionato di lavorare con i clienti ed è motivato dall'obiettivo di democratizzare l'apprendimento automatico. Si concentra sulle sfide principali relative all'implementazione di applicazioni ML complesse, modelli ML multi-tenant, ottimizzazioni dei costi e rendere più accessibile l'implementazione di modelli di deep learning. Nel tempo libero, Saurabh ama fare escursioni, conoscere tecnologie innovative, seguire TechCrunch e trascorrere del tempo con la sua famiglia.

• Distribuzione di contenuti basati su SEO e PR. Ricevi amplificazione oggi.
• Platoblockchain. Web3 Metaverse Intelligence. Conoscenza amplificata. Accedi qui.
• Fonte: https://aws.amazon.com/blogs/machine-learning/achieve-high-performance-at-scale-for-model-serving-using-amazon-sagemaker-multi-model-endpoints-with-gpu/