Ottieni hosting a bassa latenza per modelli ML basati su alberi decisionali su NVIDIA Triton Inference Server su Amazon SageMaker

Ripubblicato da Platone

Seguaci: 0

Le implementazioni del modello di machine learning (ML) possono avere requisiti di latenza e prestazioni molto impegnativi per le aziende di oggi. Casi d'uso come il rilevamento di frodi e il posizionamento di annunci sono esempi in cui i millisecondi contano e sono fondamentali per il successo aziendale. È necessario soddisfare rigorosi accordi sul livello di servizio (SLA) e una richiesta tipica può richiedere più passaggi come preelaborazione, trasformazione dei dati, logica di selezione del modello, aggregazione del modello e postelaborazione. Su larga scala, questo spesso significa mantenere un enorme volume di traffico mantenendo una bassa latenza. I modelli di progettazione comuni includono pipeline di inferenza seriale, insiemi (scatter-gather) e flussi di lavoro di logica aziendale, che si traducono nella realizzazione dell'intero flusso di lavoro della richiesta come un grafico aciclico diretto (DAG). Tuttavia, poiché i flussi di lavoro diventano più complessi, ciò può portare a un aumento dei tempi di risposta complessivi, che a loro volta possono avere un impatto negativo sull'esperienza dell'utente finale e compromettere gli obiettivi aziendali. Triton può affrontare questi casi d'uso in cui più modelli sono composti in una pipeline con tensori di input e output collegati tra loro, aiutandoti a gestire questi carichi di lavoro.

Quando valuti i tuoi obiettivi in relazione all'inferenza del modello ML, puoi prendere in considerazione molte opzioni, ma poche sono capaci e comprovate come Amazon Sage Maker con Server di inferenza Triton. SageMaker con Triton Inference Server è stata una scelta popolare per molti clienti perché è progettato appositamente per massimizzare il throughput e l'utilizzo dell'hardware con una latenza di inferenza estremamente bassa (millisecondi a una cifra). Dispone di un'ampia gamma di framework ML supportati (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 SageMaker, un servizio ML end-to-end completamente gestito, che fornisce opzioni di inferenza in tempo reale per l'hosting del modello.

In questo post, illustreremo l'implementazione di un carico di lavoro dell'insieme di rilevamento delle frodi su SageMaker con Triton Inference Server.

Panoramica della soluzione

È essenziale per qualsiasi progetto avere un elenco di requisiti e una stima dello sforzo, al fine di approssimare il costo totale del progetto. È importante stimare il ritorno sull'investimento (ROI) che supporta la decisione di un'organizzazione. Alcune considerazioni da tenere in considerazione quando si sposta un carico di lavoro su Triton includono:

La stima dello sforzo è fondamentale nello sviluppo del software e la sua misurazione è spesso basata su input incompleti, incerti e rumorosi. I carichi di lavoro ML non sono diversi. Più fattori influenzeranno un'architettura per l'inferenza ML, alcuni dei quali includono:

Budget di latenza lato client – Specifica il tempo di attesa massimo accettabile di andata e ritorno lato client per una risposta di inferenza, comunemente espresso in percentili. Per i carichi di lavoro che richiedono un budget di latenza vicino alle decine di millisecondi, i trasferimenti di rete potrebbero diventare costosi, quindi l'utilizzo di modelli all'edge sarebbe più adatto.
Dimensione della distribuzione del carico utile dei dati – Carico utile, spesso indicato come corpo del messaggio, sono i dati della richiesta trasmessi dal cliente al modello, nonché i dati di risposta trasmessi dal modello al cliente. La dimensione del carico utile ha spesso un forte impatto sulla latenza e dovrebbe essere presa in considerazione.
Formato dei dati – Specifica come viene inviato il carico utile al modello ML. Il formato può essere leggibile dall'uomo, come JSON e CSV, tuttavia esistono anche formati binari, che sono spesso compressi e di dimensioni inferiori. Questo è un compromesso tra sovraccarico di compressione e dimensione del trasferimento, il che significa che i cicli della CPU e la latenza vengono aggiunti per comprimere o decomprimere, al fine di salvare i byte trasferiti sulla rete. Questo post mostra come utilizzare i formati JSON e binari.
Stack software e componenti richiesti – Uno stack è una raccolta di componenti che operano insieme per supportare un'applicazione ML, inclusi sistema operativo, runtime e livelli software. Triton viene fornito con i popolari framework ML integrati, chiamati backend, come ONNX, TensorFlow, FIL, OpenVINO, Python nativo e altri. Puoi anche creare un back-end personalizzato per i tuoi componenti nostrani. Questo post esamina un modello XGBoost e la preelaborazione dei dati, che migriamo rispettivamente ai backend FIL e Python Triton forniti da NVIDIA.

Tutti questi fattori dovrebbero svolgere un ruolo fondamentale nella valutazione delle prestazioni dei carichi di lavoro, ma in questo caso d'uso ci concentriamo sul lavoro necessario per spostare i modelli ML in modo che siano ospitati in SageMaker con Triton Inference Server. Nello specifico, utilizziamo un esempio di un insieme di rilevamento delle frodi composto da un modello XGBoost con logica di preelaborazione scritta in Python.

Server di inferenza NVIDIA Triton

Triton Inference Server è stato progettato da zero per consentire ai team di distribuire, eseguire e ridimensionare modelli di IA addestrati da qualsiasi framework su GPU o infrastruttura basata su CPU. Inoltre, è stato ottimizzato per offrire un'inferenza ad alte prestazioni su larga scala con funzionalità come batch dinamico, esecuzioni simultanee, configurazione ottimale del modello, insieme di modelli e supporto per gli input di streaming.

Il diagramma seguente mostra un esempio di pipeline di ensemble NVIDIA Triton.

I carichi di lavoro dovrebbero tenere conto delle funzionalità fornite da Triton insieme all'hosting SageMaker per massimizzare i vantaggi offerti. Ad esempio, Triton supporta HTTP e a API C, che consentono flessibilità e ottimizzazione del carico utile quando necessario. Come accennato in precedenza, Triton supporta immediatamente diversi framework popolari, inclusi TensorFlow, PyTorch, ONNX, XGBoost e NVIDIA TensorRT. Questi framework sono supportati tramite i backend Triton e, nel raro caso in cui un backend non supporti il tuo caso d'uso, Triton ti consente di implementare il tuo e integrarlo facilmente.

Il diagramma seguente mostra un esempio dell'architettura NVIDIA Triton.

NVIDIA Triton su 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 forniti 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 DLC di SageMaker.

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

Supporto per il back-end NVIDIA FIL

Grazie alla Versione 22.05 di Triton, NVIDIA ora supporta i modelli foresta addestrati da diversi framework ML popolari, inclusi XGBoost, LightGBM, Scikit-learn e cuML. Quando si utilizza il back-end FIL per Triton, è necessario assicurarsi che gli artefatti del modello forniti siano supportati. Ad esempio, FIL supporta model_type xgboost, xgboost_json, lightgbm, o treelite_checkpoint, indicando se il modello fornito è rispettivamente in formato binario XGBoost, formato JSON XGBoost, formato testo LightGBM o formato binario Treelite.

Questo supporto di back-end è essenziale per noi da utilizzare nel nostro esempio perché FIL supporta i modelli XGBoost. L'unica considerazione da verificare è assicurarsi che il modello che distribuiamo supporti i formati binari o JSON.

Oltre a garantire di avere il formato del modello corretto, dovrebbero essere prese altre considerazioni. Il backend FIL per Triton offre agli sviluppatori opzioni configurabili per ottimizzare i propri carichi di lavoro e ottimizzare le prestazioni di esecuzione del modello. La configurazione dynamic_batching consente a Triton di conservare le richieste lato client e inviarle in batch sul lato server, al fine di utilizzare in modo efficiente il calcolo parallelo di FIL per dedurre l'intero batch insieme. L'opzione max_queue_delay_microseconds offre un controllo a prova di errore di quanto tempo Triton attende per formare un batch. FIL viene fornito con la spiegazione Shapley, che può essere attivata dalla configurazione treeshap_output; tuttavia, dovresti tenere a mente che le uscite di Shapley danneggiano le prestazioni a causa delle sue dimensioni di uscita. Un altro aspetto importante è storage_type al fine di compensare tra footprint di memoria e runtime. Ad esempio, l'utilizzo dello storage come SPARSE può ridurre il consumo di memoria, mentre DENSE può ridurre le prestazioni di esecuzione del modello a scapito di un maggiore utilizzo della memoria. La decisione della scelta migliore per ciascuno di questi dipende dal tuo carico di lavoro e dal tuo budget di latenza, quindi ti consigliamo di esaminare più a fondo tutte le opzioni nel Domande frequenti sul back-end FIL e la elenco delle configurazioni disponibili in FIL.

Passaggi per ospitare un modello su triton

Diamo un'occhiata al nostro caso d'uso del rilevamento delle frodi come esempio di cosa considerare quando si sposta un carico di lavoro su Triton.

Identifica il tuo carico di lavoro

In questo caso d'uso, abbiamo un modello di rilevamento delle frodi utilizzato durante il processo di pagamento di un cliente al dettaglio. La pipeline di inferenza utilizza un algoritmo XGBoost con logica di preelaborazione che include la preparazione dei dati per la preelaborazione.

Identificare le metriche di performance attuali e di destinazione e altri obiettivi che potrebbero essere applicati

Potresti scoprire che il tuo tempo di inferenza end-to-end sta impiegando troppo tempo per essere accettabile. Il tuo obiettivo potrebbe essere quello di passare da decine di millisecondi di latenza a una latenza a una cifra per lo stesso volume di richieste e il rispettivo throughput. Si determina che la maggior parte del tempo viene utilizzata dalla preelaborazione dei dati e dal modello XGBoost. Altri fattori come le dimensioni della rete e del carico utile svolgono un ruolo minimo nell'overhead associato al tempo di inferenza end-to-end.

Lavora a ritroso per determinare se Triton può ospitare il tuo carico di lavoro in base alle tue esigenze

Per determinare se Triton può soddisfare le tue esigenze, devi prestare attenzione a due aree principali di interesse. Il primo è garantire che Triton possa servire con un'opzione front-end accettabile come HTTP o C API.

Come accennato in precedenza, è anche fondamentale determinare se Triton supporta un back-end in grado di servire i tuoi artefatti. Triton supporta un certo numero di backend che sono fatti su misura per supportare vari framework come PyTorch e TensorFlow. Verifica che i tuoi modelli siano supportati e di avere il formato del modello corretto che Triton si aspetta. Per fare ciò, prima controlla quali formati di modello supporta il backend Triton. In molti casi, ciò non richiede modifiche al modello. In altri casi, il modello potrebbe richiedere la trasformazione in un formato diverso. A seconda del formato di origine e di destinazione, esistono varie opzioni, come la trasformazione di a File pickle Python per utilizzare il formato di checkpoint binario di Treelite.

Per questo caso d'uso, determiniamo il back-end FIL può supportare il modello XGBoost senza modifiche necessarie e che possiamo utilizzare il Backend Python per la preelaborazione. Con la funzione ensemble di Triton, puoi ottimizzare ulteriormente il tuo carico di lavoro evitando costose chiamate di rete tra istanze di hosting.

Crea un piano e stima lo sforzo richiesto per utilizzare Triton per l'hosting

Parliamo del piano per spostare i tuoi modelli su Triton. Ogni distribuzione Triton richiede quanto segue:

Artefatti del modello richiesti dai backend Triton
File di configurazione di Triton
Una cartella del repository del modello con la struttura corretta

Mostriamo un esempio di come creare queste dipendenze di distribuzione più avanti in questo post.

Esegui il piano e convalida i risultati

Dopo aver creato i file e gli artefatti richiesti nel repository del modello strutturato correttamente, è necessario ottimizzare la distribuzione e testarla per verificare di aver raggiunto le metriche di destinazione.

A questo punto puoi usare Raccomandatore di inferenza di SageMaker per determinare quale tipo di istanza dell'endpoint è più adatto a te in base ai tuoi requisiti. Inoltre, Triton fornisce strumenti per apportare ottimizzazioni di build per ottenere prestazioni migliori.

Implementazione

Ora diamo un'occhiata ai dettagli di implementazione. Per questo abbiamo preparato due quaderni che forniscono un esempio di cosa ci si può aspettare. Il primo taccuino mostra l'addestramento del modello XGBoost specificato, nonché la logica di preelaborazione utilizzata sia per l'addestramento che per il tempo di inferenza. Il secondo taccuino mostra come prepariamo gli artefatti necessari per il dispiegamento su Triton.

Il primo taccuino mostra un taccuino esistente della tua organizzazione che utilizza il RAPIDE suite di librerie e il kernel RAPIDS Conda. Questa istanza viene eseguita su un tipo di istanza G4DN fornito da AWS, che è accelerato dalla GPU utilizzando i processori NVIDIA T4.

Le attività di preelaborazione in questo esempio traggono vantaggio dall'accelerazione GPU e utilizzano pesantemente le librerie cuML e cuDF. Un esempio di ciò è nel codice seguente, dove mostriamo la codifica dell'etichetta categoriale usando cuML. Generiamo anche a label_encoders.pkl file che possiamo utilizzare per serializzare i codificatori e utilizzarli per la preelaborazione durante il tempo di inferenza.

Il primo notebook si conclude addestrando il nostro modello XGBoost e salvando gli artefatti di conseguenza.

In questo scenario, il codice di addestramento esisteva già e non sono necessarie modifiche per il modello in fase di addestramento. Inoltre, sebbene abbiamo utilizzato l'accelerazione GPU per la preelaborazione durante l'addestramento, prevediamo di utilizzare le CPU per la preelaborazione al momento dell'inferenza. Spieghiamo meglio più avanti nel post.

Passiamo ora al secondo taccuino e ricordiamo ciò di cui abbiamo bisogno per un'implementazione di successo di Triton.

Innanzitutto, abbiamo bisogno degli artefatti del modello richiesti dai backend. I file che dobbiamo creare per questo insieme includono:

Artefatti di preelaborazione (model.py, label_encoders.pkl)
Artefatti del modello XGBoost (xgboost.json)

Il backend Python in Triton ci richiede di utilizzare un ambiente Conda come dipendenza. In questo caso, utilizziamo il backend Python per preelaborare i dati grezzi prima di inserirli nel modello XGBoost in esecuzione nel backend FIL. Anche se originariamente abbiamo utilizzato le librerie cuDF e cuML RAPIDS per eseguire la preelaborazione dei dati (come indicato in precedenza utilizzando la nostra GPU), qui utilizziamo Pandas e Scikit-learn come dipendenze di preelaborazione per il tempo di inferenza (usando la nostra CPU). Lo facciamo per tre motivi:

Per mostrare come creare un ambiente Conda per le tue dipendenze e come impacchettarlo nel file formato previsto dal backend Python di Triton.
Mostrando il modello di pre-elaborazione in esecuzione nel backend Python sulla CPU mentre il modello XGBoost viene eseguito sulla GPU nel backend FIL, illustriamo come ciascun modello nella pipeline dell'ensemble di Triton può essere eseguito su un backend framework diverso ed eseguito su hardware diverso con differenti configurazioni.
Evidenzia come le librerie RAPIDS (cuDF, cuML) siano compatibili con le loro controparti CPU (Pandas, Scikit-learn). In questo modo, possiamo mostrare come LabelEncoders creato in cuML può essere utilizzato in Scikit-learn e viceversa. Nota che se prevedi di preelaborare grandi quantità di dati tabulari durante il tempo di inferenza, puoi comunque utilizzare RAPIDS per accelerarlo tramite GPU.

Ricordiamo che abbiamo creato il label_encoders.pkl file nel primo taccuino. Non c'è altro da fare per la codifica delle categorie se non includerla nel nostro model.py file per la preelaborazione.

Per creare il file model.py richiesto dal backend di Triton Python, aderiamo al formattazione richiesta dal back-end e includi la nostra logica Python per elaborare il tensore in ingresso e utilizzare il codificatore di etichette a cui si fa riferimento in precedenza. Puoi rivedere il filetto utilizzato per la preelaborazione.

Per il modello XGBoost, non è necessario fare altro. Abbiamo addestrato il modello nel primo notebook e il backend FIL di Triton non richiede sforzi aggiuntivi per i modelli XGBoost.

Successivamente, abbiamo bisogno dei file di configurazione di Triton. Ogni modello dell'ensemble Triton richiede a config.pbtxt file. Inoltre, creiamo anche un config.pbtxt file per l'insieme nel suo insieme. Questi file consentono a Triton di conoscere i metadati sull'ensemble con informazioni come gli input e gli output che ci aspettiamo, oltre ad aiutare a definire il DAG associato all'ensemble.

Infine, per distribuire un modello su Triton, abbiamo bisogno della nostra cartella del repository del modello per avere la struttura di cartelle corretta. Triton ha requisiti specifici per il layout del repository del modello. All'interno della directory del repository di modelli di livello superiore, ogni modello ha la propria sottodirectory contenente le informazioni per il modello corrispondente. Ciascuna directory del modello in Triton deve avere almeno una sottodirectory numerica che rappresenta una versione del modello. Per il nostro caso d'uso, la struttura risultante dovrebbe essere simile alla seguente.

Dopo aver ottenuto questi tre prerequisiti, creiamo un file compresso come pacchetto per la distribuzione e lo carichiamo in Servizio di archiviazione semplice Amazon (Amazon S3).

Ora possiamo creare un modello SageMaker dal repository di modelli che abbiamo caricato su Amazon S3 nel passaggio precedente.

In questo passaggio, forniamo anche la variabile di ambiente aggiuntiva SAGEMAKER_TRITON_DEFAULT_MODEL_NAME, che specifica il nome del modello che deve essere caricato da Triton. Il valore di questa chiave deve corrispondere al nome della cartella nel pacchetto del modello caricato su Amazon S3. Questa variabile è facoltativa nel caso di un singolo modello. Nel caso di modelli ensemble, questa chiave deve essere specificata per l'avvio di Triton in SageMaker.

Inoltre, puoi impostare SAGEMAKER_TRITON_BUFFER_MANAGER_THREAD_COUNT e SAGEMAKER_TRITON_THREAD_COUNT per ottimizzare il conteggio dei thread. Entrambi i valori di configurazione aiutano a ottimizzare il numero di thread in esecuzione sulle CPU, quindi è possibile ottenere un migliore utilizzo aumentando questi valori per le CPU con un numero maggiore di core. Nella maggior parte dei casi, i valori predefiniti spesso funzionano bene, ma potrebbe valere la pena sperimentare per vedere se è possibile ottenere ulteriore efficienza per i carichi di lavoro.

Con il modello precedente, creiamo una configurazione dell'endpoint in cui possiamo specificare il tipo e il numero di istanze che desideriamo nell'endpoint.

Infine, utilizziamo la configurazione dell'endpoint precedente per creare un nuovo endpoint SageMaker e attendiamo il completamento della distribuzione. Lo stato cambia in InService dopo che la distribuzione è andata a buon fine.

Questo è tutto! Il tuo endpoint è ora pronto per il test e la convalida. A questo punto, potresti voler utilizzare vari strumenti per ottimizzare i tipi di istanza e la configurazione per ottenere le migliori prestazioni possibili. La figura seguente fornisce un esempio dei guadagni che è possibile ottenere utilizzando il backend FIL per un modello XGBoost su Triton.

Sommario

In questo post, ti abbiamo guidato attraverso la distribuzione di un carico di lavoro dell'ensemble XGBoost su SageMaker con Triton Inference Server. Spostare i carichi di lavoro su Triton su SageMaker può essere un utile ritorno sull'investimento. Come per qualsiasi adozione della tecnologia, un processo di verifica e un piano sono fondamentali e abbiamo dettagliato un processo in cinque fasi per guidarti attraverso cosa considerare quando sposti i tuoi carichi di lavoro. Inoltre, abbiamo approfondito i passaggi necessari per distribuire un insieme che utilizza l'utilizzo della preelaborazione Python e un modello XGBoost su Triton su SageMaker.

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. Il supporto dell'hosting SageMaker per Triton Inference Server consente carichi di lavoro TPS (transazioni al secondo) a bassa latenza.

Puoi trovare i taccuini usati per questo esempio su GitHub.

Circa l'autore

James Park è un Solutions Architect presso Amazon Web Services. Collabora con Amazon.com per progettare, creare e distribuire soluzioni tecnologiche su AWS e ha un interesse particolare per l'intelligenza artificiale e l'apprendimento automatico. Nel tempo libero gli piace cercare nuove culture, nuove esperienze e tenersi aggiornato sulle ultime tendenze tecnologiche.

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.

Kshitiz Gupta è un architetto di soluzioni presso NVIDIA. Gli piace educare i clienti del cloud sulle tecnologie di intelligenza artificiale GPU che NVIDIA ha da offrire e assisterli nell'accelerazione delle loro applicazioni di machine learning e deep learning. Al di fuori del lavoro, gli piace correre, fare escursioni e osservare la fauna selvatica.

Bruno Aguiar de Melo è un ingegnere di sviluppo software presso Amazon.com, dove aiuta i team scientifici a creare, distribuire e rilasciare carichi di lavoro ML. È interessato alla strumentazione e agli aspetti controllabili all'interno della fase di modellazione/progettazione ML che devono essere considerati e misurati con l'intuizione che le prestazioni di esecuzione del modello sono importanti tanto quanto le prestazioni di qualità del modello, in particolare nei casi d'uso con vincoli di latenza. Nel tempo libero ama il vino, i giochi da tavolo e la cucina.

Eliuth Triana è un Developer Relations Manager presso NVIDIA. Collega i leader di prodotto, gli sviluppatori e gli scienziati di Amazon e AWS con i tecnologi e i leader di prodotto di NVIDIA per accelerare i carichi di lavoro Amazon ML/DL, i prodotti EC2 e i servizi di intelligenza artificiale di AWS. Inoltre, Eliuth è un appassionato di mountain bike, sciatore e giocatore di poker.