Ottieni prestazioni iperscalabili per il servizio di modelli utilizzando NVIDIA Triton Inference Server su Amazon SageMaker

Le applicazioni di machine learning (ML) sono complesse da distribuire e spesso richiedono più modelli ML per soddisfare una singola richiesta di inferenza. Una richiesta tipica può fluire su più modelli con passaggi come la preelaborazione, le trasformazioni dei dati, la logica di selezione del modello, l'aggregazione del modello e la postelaborazione. Ciò ha portato all'evoluzione di modelli di progettazione comuni come pipeline di inferenza seriale, insiemi (scatter raccogliere) e flussi di lavoro di logica aziendale, con il risultato di realizzare l'intero flusso di lavoro della richiesta come un grafico aciclico diretto (DAG). Tuttavia, man mano che i flussi di lavoro diventano più complessi, ciò porta a un aumento dei tempi di risposta complessivi, o latenza, di queste applicazioni, che a sua volta influisce sull'esperienza utente complessiva. Inoltre, se questi componenti sono ospitati su istanze diverse, la latenza di rete aggiuntiva tra queste istanze aumenta la latenza complessiva. Considera un esempio di un popolare caso d'uso di ML per un assistente virtuale nell'assistenza clienti. Una richiesta tipica potrebbe dover passare attraverso diversi passaggi che coinvolgono il riconoscimento vocale, l'elaborazione del linguaggio naturale (NLP), il monitoraggio dello stato del dialogo, la politica del dialogo, la generazione di testo e infine la sintesi vocale. Inoltre, per rendere l'interazione dell'utente più personalizzata, potresti anche utilizzare modelli NLP all'avanguardia basati su trasformatori come diverse versioni di BERTA, BARTe GPT. Il risultato finale sono lunghi tempi di risposta per questi insiemi di modelli e una scarsa esperienza del cliente.

Un modello comune per ridurre i tempi di risposta senza compromettere il throughput complessivo consiste nell'ospitare questi modelli sulla stessa istanza insieme alla logica di business leggera incorporata in essa. Questi modelli possono essere ulteriormente incapsulati all'interno di contenitori singoli o multipli nella stessa istanza per fornire isolamento per i processi in esecuzione e mantenere bassa la latenza. Inoltre, la latenza complessiva dipende anche dalla logica dell'applicazione di inferenza, dalle ottimizzazioni del modello, dall'infrastruttura sottostante (inclusi elaborazione, archiviazione e rete) e dal server Web sottostante che accetta le richieste di inferenza. Server di inferenza NVIDIA Triton è un software di servizio di inferenza open source con funzionalità per massimizzare il throughput e l'utilizzo dell'hardware con una latenza di inferenza estremamente bassa (millisecondi a una cifra). Ha un ampio supporto di framework ML (tra cui TensorFlow, PyTorch, ONNX, XGBoost e NVIDIA TensorRT) e back-end di infrastruttura, tra cui GPU, CPU e AWS Inferenza. Inoltre, Triton Inference Server è integrato con Amazon Sage Maker, un servizio ML end-to-end completamente gestito, che fornisce opzioni di inferenza in tempo reale, tra cui singolo ed multimodello ospitando. Queste opzioni di inferenza includono l'hosting di più modelli all'interno dello stesso contenitore dietro a singolo punto finalee hosting più modelli con più contenitori dietro un unico punto finale.

Nel novembre 2021 abbiamo annunciato l'integrazione di Triton Inference Server su SageMaker. AWS ha lavorato a stretto contatto con NVIDIA per consentirti di ottenere il meglio da entrambi i mondi e semplificare la distribuzione del modello con Triton su AWS.

In questo post, esamineremo le migliori pratiche per la distribuzione di modelli di trasformatori su larga scala su GPU utilizzando Triton Inference Server su SageMaker. Innanzitutto, iniziamo con un riepilogo dei concetti chiave sulla latenza in SageMaker e una panoramica delle linee guida per l'ottimizzazione delle prestazioni. Successivamente, forniamo una panoramica di Triton e delle sue funzionalità, nonché un codice di esempio per la distribuzione su SageMaker. Infine, eseguiamo test di carico utilizzando Raccomandatore di inferenza di SageMaker e riassumere le intuizioni e le conclusioni dei test di carico di un popolare modello di trasformatore fornito da Hugging Face.

Puoi rivedere il taccuino eravamo abituati a distribuire modelli ed eseguire test di carico da soli utilizzando il codice su GitHub.

Ottimizzazione e ottimizzazione delle prestazioni per la pubblicazione di modelli su SageMaker

L'ottimizzazione e l'ottimizzazione delle prestazioni è un processo empirico che spesso coinvolge più iterazioni. Il numero di parametri da regolare è combinatorio e l'insieme dei valori dei parametri di configurazione non è indipendente l'uno dall'altro. Vari fattori influiscono sull'ottimizzazione ottimale dei parametri, tra cui la dimensione del carico utile, il tipo e il numero di modelli ML nel grafico del flusso della richiesta di inferenza, il tipo di archiviazione, il tipo di istanza di calcolo, l'infrastruttura di rete, il codice dell'applicazione, il runtime e la configurazione del software di inferenza e altro ancora.

Se utilizzi SageMaker per la distribuzione di modelli ML, devi selezionare un'istanza di calcolo con il miglior rapporto qualità-prezzo, che è un processo complicato e iterativo che può richiedere settimane di sperimentazione. Innanzitutto, devi scegliere il tipo di istanza ML corretto tra oltre 70 opzioni in base ai requisiti di risorse dei tuoi modelli e alle dimensioni dei dati di input. Successivamente, è necessario ottimizzare il modello per il tipo di istanza selezionato. Infine, è necessario eseguire il provisioning e gestire l'infrastruttura per eseguire test di carico e ottimizzare la configurazione del cloud per prestazioni e costi ottimali. Tutto ciò può ritardare l'implementazione del modello e il time-to-market. Inoltre, è necessario valutare i compromessi tra latenza, velocità effettiva e costo per selezionare la configurazione di distribuzione ottimale. Raccomandatore di inferenza di SageMaker seleziona automaticamente il tipo di istanza di calcolo, il conteggio delle istanze, i parametri del contenitore e le ottimizzazioni del modello corretti per l'inferenza per massimizzare il throughput, ridurre la latenza e ridurre al minimo i costi.

Inferenza e latenza in tempo reale in SageMaker

SageMaker inferenza in tempo reale è l'ideale per carichi di lavoro di inferenza in cui sono richiesti requisiti in tempo reale, interattivi e a bassa latenza. Esistono quattro metriche più comunemente utilizzate per il monitoraggio della latenza delle richieste di inferenza per gli endpoint di inferenza di SageMaker

• Latenza del contenitore – Il tempo necessario per inviare la richiesta, recuperare la risposta dal contenitore del modello e completare l'inferenza nel contenitore. Questo parametro è disponibile in Amazon CloudWatch come parte del Metriche di invocazione pubblicato da SageMaker.
• Latenza del modello – Il tempo totale impiegato da tutti i contenitori SageMaker in un pipeline di inferenza. Questo parametro è disponibile in Amazon CloudWatch come parte del Metriche di invocazione pubblicato da SageMaker.
• Latenza ambientale – Misurato dal momento in cui SageMaker riceve la richiesta fino a quando non restituisce una risposta al client, meno la latenza del modello. Questo parametro è disponibile in Amazon CloudWatch come parte del Metriche di invocazione pubblicato da SageMaker.
• Latenza end-to-end – Misurato dal momento in cui il client invia la richiesta di inferenza fino a quando non riceve una risposta. I clienti possono pubblicarlo come parametro personalizzato in Amazon CloudWatch.

Il diagramma seguente illustra questi componenti.

La latenza del contenitore dipende da diversi fattori; i seguenti sono tra i più importanti:

• Protocollo sottostante (HTTP(s)/gRPC) utilizzato per comunicare con il server di inferenza
• Spese generali relative alla creazione di nuove connessioni TLS
• Tempo di deserializzazione del payload di richiesta/risposta
• Richiedi le funzionalità di accodamento e batch fornite dal server di inferenza sottostante
• Richiedi le funzionalità di pianificazione fornite dal server di inferenza sottostante
• Prestazioni di runtime alla base del server di inferenza
• Prestazioni delle librerie di preelaborazione e postelaborazione prima di chiamare la funzione di previsione del modello
• Prestazioni del back-end del framework ML alla base
• Ottimizzazioni specifiche del modello e dell'hardware

In questo post, ci concentriamo principalmente sull'ottimizzazione della latenza del contenitore insieme al throughput e ai costi complessivi. In particolare, esploriamo l'ottimizzazione delle prestazioni di Triton Inference Server in esecuzione all'interno di un contenitore SageMaker.

Panoramica dei casi d'uso

La distribuzione e il ridimensionamento dei modelli NLP in un'impostazione di produzione può essere piuttosto impegnativo. I modelli NLP sono spesso di dimensioni molto grandi e contengono milioni di parametri del modello. Sono necessarie configurazioni di modello ottimali per soddisfare i severi requisiti di prestazioni e scalabilità delle applicazioni NLP di livello produttivo.

In questo post, eseguiamo il benchmark di un caso d'uso NLP utilizzando un endpoint in tempo reale SageMaker basato su un contenitore Triton Inference Server e consigliamo l'ottimizzazione delle prestazioni per il nostro caso d'uso ML. Usiamo un grande Hugging Face basato su trasformatore pre-addestrato BERT grande senza custodia modello, che ha circa 336 milioni di parametri del modello. La frase di input utilizzata per il modello di classificazione binaria viene riempita e troncata a una lunghezza massima della sequenza di input di 512 token. Il test del carico di inferenza simula 500 chiamate al secondo (30,000 chiamate massime al minuto) e ModelLatency inferiore a 0.5 secondi (500 millisecondi).

La tabella seguente riassume la nostra configurazione del benchmark.

Server di inferenza NVIDIA Triton

Triton Inference Server è specificamente progettato per consentire un'implementazione scalabile, rapida e semplice dei modelli in produzione. Triton supporta una varietà dei principali framework di intelligenza artificiale, inclusi TensorFlow, TensorRT, PyTorch, XGBoost e ONNX. Con il backend personalizzato Python e C++, puoi anche implementare il tuo carico di lavoro di inferenza per casi d'uso più personalizzati.

Ancora più importante, Triton fornisce una semplice configurazione basata sulla configurazione per ospitare i tuoi modelli, che espone un ricco set di funzionalità di ottimizzazione delle prestazioni che puoi utilizzare con un minimo sforzo di codifica.

Triton aumenta le prestazioni di inferenza massimizzando l'utilizzo dell'hardware con diverse tecniche di ottimizzazione (le esecuzioni simultanee del modello e il batch dinamico sono le più utilizzate). Trovare le configurazioni del modello ottimali da varie combinazioni di dimensioni batch dinamiche e il numero di istanze del modello simultanee è la chiave per ottenere l'inferenza in tempo reale all'interno di servizi a basso costo utilizzando Triton.

Dosaggio dinamico

Molti professionisti tendono a eseguire l'inferenza in sequenza quando il server viene invocato con più richieste indipendenti. Sebbene sia più facile da configurare, di solito non è la migliore pratica utilizzare la potenza di calcolo della GPU. Per risolvere questo problema, Triton offre le ottimizzazioni integrate di dosaggio dinamico per combinare queste richieste di inferenza indipendenti sul lato server per formare un batch più grande in modo dinamico per aumentare la velocità effettiva. Il diagramma seguente illustra l'architettura di runtime di Triton.

Nell'architettura precedente, tutte le richieste raggiungono il batcher dinamico prima di entrare nelle code effettive dello scheduler del modello per attendere l'inferenza. È possibile impostare le dimensioni batch preferite per il batch dinamico utilizzando il file dimensione_batch_preferita impostazioni nella configurazione del modello. (Si noti che la dimensione del lotto formato deve essere inferiore a dimensione_batch_massima il modello supporta.) È anche possibile configurare max_queue_delay_microsecondi per specificare il tempo di ritardo massimo nel batcher per attendere che altre richieste si uniscano al batch in base ai requisiti di latenza.

Il frammento di codice seguente mostra come aggiungere questa funzionalità con i file di configurazione del modello per impostare il batch dinamico con una dimensione batch preferita di 16 per l'inferenza effettiva. Con le impostazioni correnti, l'istanza del modello viene richiamata istantaneamente quando viene soddisfatta la dimensione batch preferita di 16 o è trascorso il tempo di ritardo di 100 microsecondi da quando la prima richiesta ha raggiunto il batcher dinamico.

dynamic_batching { preferred_batch_size: 16 max_queue_delay_microseconds: 100 }

Esecuzione di modelli contemporaneamente

Un'altra ottimizzazione essenziale offerta in Triton per massimizzare l'utilizzo dell'hardware senza ulteriore sovraccarico di latenza è esecuzione simultanea del modello, che consente l'esecuzione in parallelo di più modelli o più copie dello stesso modello. Questa funzione consente a Triton di gestire più richieste di inferenza contemporaneamente, aumentando il throughput dell'inferenza utilizzando la potenza di calcolo altrimenti inattiva sull'hardware.

La figura seguente mostra come configurare facilmente criteri di distribuzione di modelli diversi con solo poche righe di modifiche al codice. Ad esempio, la configurazione A (a sinistra) mostra che puoi trasmettere la stessa configurazione di due istanze del modello di bert-large-uncased a tutte le GPU disponibili. Al contrario, la configurazione B (al centro) mostra una configurazione diversa solo per la GPU 0, senza modificare i criteri sulle altre GPU. Puoi anche distribuire istanze di modelli diversi su una singola GPU, come mostrato nella configurazione C (a destra).

Nella configurazione C, l'istanza di calcolo può gestire due richieste simultanee per il modello DistilGPT-2 e sette richieste simultanee per il bert-large-uncased modello in parallelo. Con queste ottimizzazioni, le risorse hardware possono essere utilizzate meglio per il processo di elaborazione, migliorando così il throughput e fornendo una migliore efficienza in termini di costi per il carico di lavoro.

TensorRT

NVIDIA TensorRT è un SDK per l'inferenza di deep learning ad alte prestazioni che funziona perfettamente con Triton. TensorRT, che supporta tutti i principali framework di deep learning, include un ottimizzatore di inferenza e un runtime che offre bassa latenza e throughput elevato per eseguire inferenze con enormi volumi di dati tramite potenti ottimizzazioni.

TensorRT ottimizza il grafico per ridurre al minimo l'ingombro di memoria liberando memoria non necessaria e riutilizzandola in modo efficiente. Inoltre, la compilazione TensorRT fonde le operazioni sparse all'interno del grafico del modello per formare un kernel più grande per evitare il sovraccarico di più lanci di kernel piccoli. L'autotuning del kernel ti aiuta a utilizzare completamente l'hardware selezionando il miglior algoritmo sulla tua GPU di destinazione. I flussi CUDA consentono ai modelli di essere eseguiti in parallelo per massimizzare l'utilizzo della GPU e ottenere le migliori prestazioni. Ultimo ma non meno importante, la tecnica di quantizzazione può utilizzare completamente l'accelerazione di precisione mista dei core Tensor per eseguire il modello in FP32, TF32, FP16 e INT8 per ottenere le migliori prestazioni di inferenza.

Triton sull'hosting di SageMaker

Hosting di SageMaker i servizi sono l'insieme di funzionalità di SageMaker volte a semplificare l'implementazione e l'elaborazione del modello. Fornisce una varietà di opzioni per distribuire facilmente, ridimensionare automaticamente, monitorare e ottimizzare modelli ML su misura per diversi casi d'uso. Ciò significa che puoi ottimizzare le tue distribuzioni per tutti i tipi di modelli di utilizzo, da quelli persistenti e sempre disponibili con opzioni serverless, a quelli transitori, a esecuzione prolungata o per esigenze di inferenza batch.

Sotto l'ombrello di hosting SageMaker c'è anche il set di SageMaker inference Deep Learning Containers (DLC), che vengono preconfezionati con il software server modello appropriato per il loro framework ML supportato corrispondente. Ciò consente di ottenere prestazioni di inferenza elevate senza la configurazione del server modello, che è spesso l'aspetto tecnico più complesso della distribuzione del modello e, in generale, non fa parte delle competenze di un data scientist. Il server di inferenza Triton è ora disponibile sui contenitori di deep learning di SageMaker (DLC).

Questa ampiezza di opzioni, modularità e facilità d'uso di diversi framework di servizio rende SageMaker e Triton una combinazione potente.

SageMaker Inference Recommender per il benchmarking dei risultati dei test

Usiamo SageMaker Inference Recommender per eseguire i nostri esperimenti. SageMaker Inference Recommender offre due tipi di lavori: predefinito e avanzato, come illustrato nel diagramma seguente.

Il lavoro predefinito fornisce consigli sui tipi di istanza con solo il modello e un payload di esempio da confrontare. Oltre ai consigli sulle istanze, il servizio offre anche parametri di runtime che migliorano le prestazioni. I consigli del lavoro predefinito hanno lo scopo di restringere la ricerca di istanze. In alcuni casi, potrebbe essere la famiglia di istanze e in altri potrebbero essere i tipi di istanze specifici. I risultati del lavoro predefinito vengono quindi inseriti nel lavoro avanzato.

Il lavoro avanzato offre più controlli per ottimizzare ulteriormente le prestazioni. Questi controlli simulano l'ambiente reale ei requisiti di produzione. Tra questi controlli c'è il modello di traffico, che mira a mettere in scena il modello di richiesta per i benchmark. È possibile impostare rampe o traffico costante utilizzando le fasi multiple del modello di traffico. Ad esempio, un Numero iniziale di utenti di 1, Tasso di spawn di 1, e DurataInSecondi di 600 può comportare un traffico di rampa di 10 minuti con 1 utente simultaneo all'inizio e 10 alla fine. Inoltre, sui controlli, MaxInvocazioni ed Soglie di latenza del modello impostare la soglia di produzione, così quando una delle soglie viene superata, il benchmarking si interrompe.

Infine, metriche di raccomandazione includono velocità effettiva, latenza alla velocità effettiva massima e costo per inferenza, quindi è facile confrontarli.

Utilizziamo il tipo di lavoro avanzato di SageMaker Inference Recommender per eseguire i nostri esperimenti per ottenere un controllo aggiuntivo sui modelli di traffico e ottimizzare la configurazione del contenitore di servizio.

Configurazione dell'esperimento

Utilizziamo la funzione di test di carico personalizzato di SageMaker Inference Recommender per confrontare il profilo NLP delineato nel nostro caso d'uso. Per prima cosa definiamo i seguenti prerequisiti relativi al modello NLP e all'attività ML. SageMaker Inference Recommender utilizza queste informazioni per estrarre un'immagine Docker di inferenza da Registro dei contenitori Amazon Elastic (Amazon ECR) e registrare il modello nel registro modelli SageMaker.

Le configurazioni del modello di traffico in SageMaker Inference Recommender ci consentono di definire diverse fasi per il test di carico personalizzato. Il test di carico inizia con due utenti iniziali e genera due nuovi utenti ogni minuto, per una durata totale di 25 minuti (1500 secondi), come mostrato nel codice seguente:

"TrafficPattern": { "TrafficType": "PHASES", "Phases": [ { "InitialNumberOfUsers": 2, "SpawnRate": 2, "DurationInSeconds": 1500 }, ],
}

Sperimentiamo il test di carico dello stesso modello in due stati diversi. Gli esperimenti basati su PyTorch utilizzano il modello PyTorch standard e inalterato. Per gli esperimenti basati su TensorRT, convertiamo in anticipo il modello PyTorch in un motore TensorRT.

Applichiamo diverse combinazioni delle funzionalità di ottimizzazione delle prestazioni su questi due modelli, riepilogate nella tabella seguente.

Risultati dei test e osservazioni

Abbiamo condotto test di carico per tre tipi di istanza all'interno della stessa famiglia g4dn: ml.g4dn.xlarge, ml.g4dn.2xlarge e ml.g4dn.12xlarge. Tutti i tipi di istanza g4dn hanno accesso alle GPU NVIDIA T4 Tensor Core e ai processori Intel Cascade Lake di seconda generazione. La logica alla base della scelta dei tipi di istanza era quella di avere sia un'istanza con una sola GPU disponibile, sia un'istanza con accesso a più GPU, quattro nel caso di ml.g2dn.4xlarge. Inoltre, volevamo verificare se l'aumento della capacità della vCPU sull'istanza con una sola GPU disponibile avrebbe prodotto un miglioramento del rapporto costi-prestazioni.

Esaminiamo prima la velocità dell'ottimizzazione individuale. Il grafico seguente mostra che l'ottimizzazione TensorRT fornisce una riduzione del 50% della latenza del modello rispetto a quella nativa in PyTorch sull'istanza ml.g4dn.xlarge. Questa riduzione della latenza aumenta di oltre tre volte sulle istanze multi-GPU di ml.g4dn.12xlarge. Nel frattempo, il miglioramento della velocità effettiva del 30% è coerente su entrambe le istanze, con conseguente migliore rapporto costo-efficacia dopo l'applicazione delle ottimizzazioni TensorRT.

Con il batch dinamico, possiamo ottenere un miglioramento vicino al doppio della velocità effettiva utilizzando la stessa architettura hardware su tutte le istanze degli esperimenti di ml.g2dn.xlarge, ml.g4dn.4xlarge e ml.g2dn.4xlarge senza un notevole aumento della latenza.

Allo stesso modo, l'esecuzione del modello simultaneo ci consente di ottenere un miglioramento di circa 3-4 volte nel throughput massimizzando l'utilizzo della GPU sull'istanza ml.g4dn.xlarge e un miglioramento di circa 2 volte sia sull'istanza ml.g4dn.2xlarge che sull'istanza multi-GPU di ml. g4dn.12xlarge.. Questo aumento del throughput avviene senza alcun sovraccarico nella latenza.

Meglio ancora, possiamo integrare tutte queste ottimizzazioni per fornire le migliori prestazioni utilizzando al meglio le risorse hardware. La tabella e i grafici seguenti riassumono i risultati che abbiamo ottenuto nei nostri esperimenti.

[1] Il conteggio iniziale delle istanze nella tabella precedente è il numero consigliato di istanze da utilizzare con una policy di scalabilità automatica per mantenere i requisiti di velocità effettiva e latenza per il carico di lavoro.

[2] Il costo orario nella tabella precedente viene calcolato in base al conteggio e al prezzo dell'istanza iniziale per il tipo di istanza.

I risultati per lo più convalidano l'impatto che ci si aspettava dalle diverse funzioni di ottimizzazione delle prestazioni:

• La compilazione di TensorRT ha l'impatto più affidabile su tutti i tipi di istanza. Le transazioni al minuto per istanza sono aumentate del 30–35%, con una riduzione costante dei costi di circa il 25% rispetto alle prestazioni del motore TensorRT rispetto al PyTorch BERT predefinito (pt-base). Le prestazioni migliorate del motore TensorRT sono integrate e sfruttate dalle altre funzionalità di ottimizzazione delle prestazioni testate.
• Il caricamento di due modelli su ciascuna GPU (gruppo di istanze) ha quasi rigorosamente raddoppiato tutte le metriche misurate. Le chiamate al minuto per istanza sono aumentate di circa l'80–90%, ottenendo una riduzione dei costi nell'intervallo del 50%, quasi come se stessimo utilizzando due GPU. Di fatto, Amazon Cloud Watch le metriche per i nostri esperimenti su g4dn.2xlarge (ad esempio) confermano che l'utilizzo di CPU e GPU raddoppia quando configuriamo un gruppo di istanze di due modelli.

Ulteriori suggerimenti sulle prestazioni e sull'ottimizzazione dei costi

Il benchmark presentato in questo post ha appena scalfito la superficie delle possibili funzionalità e tecniche che puoi utilizzare con Triton per migliorare le prestazioni di inferenza. Questi vanno dalle tecniche di preelaborazione dei dati, come l'invio di payload binari al server modello o payload con batch più grandi, a funzionalità Triton native, come le seguenti:

• Riscaldamento del modello, che impedisce richieste di inferenza iniziali e lente inizializzando completamente il modello prima che venga ricevuta la prima richiesta di inferenza.
• Cache di risposta, che memorizza nella cache le richieste ripetute.
• Assieme del modello, che consente di creare una pipeline di uno o più modelli e la connessione di tensori di input e output tra tali modelli. Ciò apre la possibilità di aggiungere fasi di preelaborazione e postelaborazione, o anche inferenza con altri modelli, al flusso di elaborazione per ogni richiesta.

Ci aspettiamo di testare e confrontare queste tecniche e funzionalità in un post futuro, quindi rimanete sintonizzati!

Conclusione

In questo post, abbiamo esplorato alcuni parametri che puoi utilizzare per massimizzare le prestazioni del tuo endpoint in tempo reale SageMaker per servire i modelli PyTorch BERT con Triton Inference Server. Abbiamo utilizzato SageMaker Inference Recommender per eseguire i test di benchmarking per mettere a punto questi parametri. Questi parametri sono essenzialmente correlati all'ottimizzazione del modello basato su TensorRT, portando a un miglioramento di quasi il 50% dei tempi di risposta rispetto alla versione non ottimizzata. Inoltre, l'esecuzione simultanea dei modelli e l'utilizzo del batch dinamico di Triton ha portato a un aumento di quasi il 70% della produttività. La messa a punto di questi parametri ha portato anche a una riduzione complessiva dei costi di inferenza.

Il modo migliore per ricavare i valori corretti è attraverso la sperimentazione. Tuttavia, per iniziare a costruire conoscenze empiriche sull'ottimizzazione e l'ottimizzazione delle prestazioni, puoi osservare le combinazioni di diversi parametri relativi a Triton e il loro effetto sulle prestazioni nei modelli ML e nelle istanze SageMaker ML.

SageMaker fornisce gli strumenti per rimuovere il lavoro pesante indifferenziato da ogni fase del ciclo di vita del ML, facilitando così la rapida sperimentazione ed esplorazione necessaria per ottimizzare completamente le implementazioni del modello.

È possibile trovare il notebook utilizzato per il test di carico e la distribuzione GitHub. Puoi aggiornare le configurazioni di Triton e le impostazioni di SageMaker Inference Recommender per adattarle al meglio al tuo caso d'uso per ottenere carichi di lavoro di inferenza convenienti e con le migliori prestazioni.

Informazioni sugli autori

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.

João Moura è un architetto specializzato in soluzioni AI/ML presso Amazon Web Services. Si concentra principalmente sui casi d'uso della NLP e aiuta i clienti a ottimizzare la formazione e l'implementazione del modello di Deep Learning. È anche un attivo sostenitore di soluzioni ML a basso codice e hardware specializzato in ML.

Mohan Gandhi è un Senior Software Engineer presso AWS. È stato con AWS negli ultimi 9 anni e ha lavorato su vari servizi AWS come EMR, EFA e RDS su Outposts. Attualmente, è concentrato sul miglioramento dell'esperienza di inferenza di SageMaker. Nel tempo libero ama fare escursioni e correre maratone.

Dhawal Patel è un Principal Machine Learning Architect presso AWS. Ha lavorato con organizzazioni che vanno dalle grandi imprese alle startup di medie dimensioni su problemi legati all'informatica distribuita e all'intelligenza artificiale. Si concentra sull'apprendimento profondo, inclusi i domini della PNL e della visione artificiale. Aiuta i clienti a ottenere l'inferenza del modello ad alte prestazioni su SageMaker.

Santosh Bhavani è un Senior Technical Product Manager con il team di Amazon SageMaker Elastic Inference. Si concentra sull'aiutare i clienti di SageMaker ad accelerare l'inferenza e l'implementazione del modello. Nel tempo libero ama viaggiare, giocare a tennis e bere un sacco di tè Pu'er.

Jiahong Liu è un Solution Architect nel team di Cloud Service Provider di NVIDIA. Assiste i clienti nell'adozione di soluzioni di apprendimento automatico e intelligenza artificiale che sfruttano l'informatica accelerata NVIDIA per affrontare le loro sfide di formazione e inferenza. Nel tempo libero ama gli origami, i progetti fai-da-te e gioca a basket.

• Coinsmart. Il miglior scambio di bitcoin e criptovalute d'Europa.
• Platoblockchain. Web3 Metaverse Intelligence. Conoscenza amplificata. ACCESSO LIBERO.
• Criptofalco. Radar Altcoin. Prova gratuita.
• Fonte: https://aws.amazon.com/blogs/machine-learning/achieve-hyperscale-performance-for-model-serving-using-nvidia-triton-inference-server-on-amazon-sagemaker/