Obțineți găzduire cu latență scăzută pentru modelele ML bazate pe arborele de decizie pe NVIDIA Triton Inference Server pe Amazon SageMaker

Implementările modelelor de învățare automată (ML) pot avea cerințe foarte solicitante de performanță și latență pentru companiile de astăzi. Cazurile de utilizare precum detectarea fraudelor și plasarea anunțurilor sunt exemple în care milisecundele contează și sunt esențiale pentru succesul afacerii. Trebuie îndeplinite acorduri stricte de nivel de serviciu (SLA), iar o cerere tipică poate necesita mai mulți pași, cum ar fi preprocesarea, transformarea datelor, logica de selecție a modelului, agregarea modelului și postprocesarea. La scară, acest lucru înseamnă adesea menținerea unui volum mare de trafic, menținând în același timp o latență scăzută. Modelele obișnuite de proiectare includ conducte de inferență în serie, ansambluri (scatter-gather) și fluxuri de lucru logice de afaceri, care au ca rezultat realizarea întregului flux de lucru al cererii ca un grafic aciclic direcționat (DAG). Cu toate acestea, pe măsură ce fluxurile de lucru devin mai complexe, acest lucru poate duce la o creștere a timpului general de răspuns, care, la rândul său, poate avea un impact negativ asupra experienței utilizatorului final și poate pune în pericol obiectivele de afaceri. Triton poate aborda aceste cazuri de utilizare în care mai multe modele sunt compuse într-o conductă cu tensori de intrare și de ieșire conectați între ei, ajutându-vă să abordați aceste sarcini de lucru.

Pe măsură ce îți evaluezi obiectivele în raport cu inferența modelului ML, pot fi luate în considerare multe opțiuni, dar puține sunt la fel de capabile și dovedite ca Amazon SageMaker cu Triton Inference Server. SageMaker cu Triton Inference Server a fost o alegere populară pentru mulți clienți, deoarece este conceput special pentru a maximiza debitul și utilizarea hardware-ului cu o latență de inferență ultra-scăzută (milisecunde cu o singură cifră). Are o gamă largă de cadre ML acceptate (inclusiv TensorFlow, PyTorch, ONNX, XGBoost și NVIDIA TensorRT) și backend-uri de infrastructură, inclusiv GPU-uri, procesoare și procesoare NVIDIA Inferentia AWS. În plus, Triton Inference Server este integrat cu SageMaker, un serviciu ML complet gestionat end-to-end, care oferă opțiuni de inferență în timp real pentru găzduirea modelelor.

În această postare, vom parcurge implementarea unui ansamblu de detectare a fraudei la SageMaker cu Triton Inference Server.

Prezentare generală a soluțiilor

Este esențial ca orice proiect să aibă o listă de cerințe și o estimare a efortului, pentru a aproxima costul total al proiectului. Este important să estimați rentabilitatea investiției (ROI) care sprijină decizia unei organizații. Câteva considerații de care trebuie să țineți cont atunci când mutați un volum de lucru în Triton includ:

Estimarea efortului este cheia în dezvoltarea software-ului, iar măsurarea acestuia se bazează adesea pe intrări incomplete, incerte și zgomotoase. Sarcinile de lucru ML nu sunt diferite. Factori multipli vor afecta o arhitectură pentru inferența ML, dintre care unele includ:

• Bugetul de latență al clientului – Specifică timpul de așteptare maxim acceptabil pentru un răspuns de inferență, exprimat în mod obișnuit în percentile. Pentru sarcinile de lucru care necesită un buget de latență aproape de zeci de milisecunde, transferurile de rețea ar putea deveni costisitoare, așa că utilizarea modelelor la margine ar fi o potrivire mai bună.
• Dimensiunea distribuției încărcăturii de date – Sarcina utilă, adesea denumită Conținutul mesajului, sunt datele de solicitare transmise de la client către model, precum și datele de răspuns transmise de la model către client. Dimensiunea sarcinii utile are adesea un impact major asupra latenței și ar trebui luată în considerare.
• Format date – Acesta specifică modul în care sarcina utilă este trimisă la modelul ML. Formatul poate fi citit de om, cum ar fi JSON și CSV, dar există și formate binare, care sunt adesea comprimate și de dimensiuni mai mici. Acesta este un compromis între suprasarcina de compresie și dimensiunea transferului, ceea ce înseamnă că ciclurile CPU și latența sunt adăugate pentru a comprima sau decomprima, pentru a salva octeții transferați în rețea. Această postare arată cum să utilizați atât formatele JSON, cât și formatele binar.
• Stiva software și componente necesare – O stivă este o colecție de componente care funcționează împreună pentru a susține o aplicație ML, inclusiv sistemul de operare, runtime și straturi software. Triton vine cu cadre ML populare încorporate, numite backend-uri, cum ar fi ONNX, TensorFlow, FIL, OpenVINO, Python nativ și altele. De asemenea, puteți crea un backend personalizat pentru propriile componente de casă. Această postare prezintă un model XGBoost și o preprocesare a datelor, pe care le migrăm către backend-urile FIL furnizate de NVIDIA și, respectiv, Python Triton.

Toți acești factori ar trebui să joace un rol vital în evaluarea modului în care performanța sarcinilor dvs. de lucru, dar în acest caz de utilizare ne concentrăm pe munca necesară pentru a muta modelele dvs. ML pentru a fi găzduite în SageMaker cu Triton Inference Server. Mai exact, folosim un exemplu de ansamblu de detectare a fraudei compus dintr-un model XGBoost cu logica de preprocesare scrisa in Python.

NVIDIA Triton Inference Server

Triton Inference Server a fost proiectat de la zero pentru a permite echipelor să implementeze, să ruleze și să scaleze modele AI instruite din orice cadru pe infrastructura bazată pe GPU sau CPU. În plus, a fost optimizat pentru a oferi inferențe de înaltă performanță la scară, cu caracteristici precum loturi dinamice, rulări concurente, configurație optimă a modelului, ansamblu de model și suport pentru intrări în flux.

Următoarea diagramă prezintă un exemplu de conductă de ansamblu NVIDIA Triton.

Volumul de lucru ar trebui să țină cont de capacitățile pe care Triton le oferă împreună cu găzduirea SageMaker pentru a maximiza beneficiile oferite. De exemplu, Triton acceptă HTTP, precum și a C API, care permit flexibilitate, precum și optimizarea sarcinii utile atunci când este necesar. După cum sa menționat anterior, Triton acceptă mai multe framework-uri populare, inclusiv TensorFlow, PyTorch, ONNX, XGBoost și NVIDIA TensorRT. Aceste cadre sunt acceptate prin backend-uri Triton și, în cazul rar în care un backend nu acceptă cazul dvs. de utilizare, Triton vă permite să implementați propriul dvs. și să îl integrați cu ușurință.

Următoarea diagramă prezintă un exemplu de arhitectură NVIDIA Triton.

NVIDIA Triton pe SageMaker

Gazduire SageMaker serviciile sunt setul de caracteristici SageMaker menite să faciliteze implementarea modelului și servirea. Oferă o varietate de opțiuni pentru implementarea, scalarea automată, monitorizarea și optimizarea cu ușurință a modelelor ML adaptate pentru diferite cazuri de utilizare. Aceasta înseamnă că vă puteți optimiza implementările pentru toate tipurile de modele de utilizare, de la persistente și întotdeauna disponibile cu opțiuni fără server, până la nevoi tranzitorii, de lungă durată sau de inferență în lot.

Sub umbrela de găzduire SageMaker se află, de asemenea, setul de containere de învățare profundă (DLC-uri) SageMaker, care vin pre-ambalate cu software-ul de server model adecvat pentru cadrul ML suportat corespunzător. Acest lucru vă permite să obțineți performanțe de inferență ridicate fără configurarea serverului de model, care este adesea cel mai complex aspect tehnic al implementării modelului și, în general, nu face parte din setul de abilități ale unui cercetător de date. Serverul de inferență Triton este acum disponibil pe DLC-urile SageMaker.

Această gamă largă de opțiuni, modularitatea și ușurința de utilizare a diferitelor cadre de servire fac din SageMaker și Triton o potrivire puternică.

Suport pentru backend NVIDIA FIL

Cu Versiunea 22.05 Triton, NVIDIA acceptă acum modele forestiere antrenate de mai multe cadre populare ML, inclusiv XGBoost, LightGBM, Scikit-learn și cuML. Când utilizați backend-ul FIL pentru Triton, ar trebui să vă asigurați că artefactele de model pe care le furnizați sunt acceptate. De exemplu, FIL acceptă model_type xgboost, xgboost_json, lightgbm, Sau treelite_checkpoint, indicând dacă modelul furnizat este în format binar XGBoost, format JSON XGBoost, format text LightGBM sau, respectiv, format binar Treelite.

Acest suport backend este esențial pentru ca noi să îl folosim în exemplul nostru, deoarece FIL acceptă modelele XGBoost. Singura considerație de verificat este să ne asigurăm că modelul pe care îl implementăm acceptă formatele binare sau JSON.

Pe lângă faptul că vă asigurați că aveți formatul de model adecvat, ar trebui luate și alte considerații. Backend-ul FIL pentru Triton oferă opțiuni configurabile pentru dezvoltatori pentru a-și ajusta sarcinile de lucru și pentru a optimiza performanța rulării modelului. Configurația dynamic_batching permite Triton să rețină cereri de la parte client și să le grupeze pe partea de server, pentru a utiliza eficient calculul paralel al FIL pentru a deduce întregul lot împreună. Optiunea max_queue_delay_microseconds oferă un control sigur asupra cât timp așteaptă Triton pentru a forma un lot. FIL vine cu explicatorul Shapley, care poate fi activat prin configurare treeshap_output; totuși, ar trebui să țineți cont de faptul că ieșirile Shapley afectează performanța datorită dimensiunii sale de ieșire. Un alt aspect important este storage_type pentru a face un compromis între amprenta memoriei și timpul de rulare. De exemplu, utilizarea stocării ca SPARSE poate reduce consumul de memorie, în timp ce DENSE poate reduce performanța de rulare a modelului în detrimentul utilizării mai mari a memoriei. Decizia celei mai bune alegeri pentru fiecare dintre acestea depinde de volumul de lucru și de bugetul de latență, așa că vă recomandăm o privire mai aprofundată asupra tuturor opțiunilor din Întrebări frecvente ale backend-ului FIL si lista de configurații disponibile în FIL.

Pași pentru a găzdui un model pe triton

Să ne uităm la cazul nostru de utilizare pentru detectarea fraudei ca un exemplu de ceea ce trebuie luat în considerare atunci când mutați o sarcină de lucru în Triton.

Identificați-vă volumul de muncă

În acest caz de utilizare, avem un model de detectare a fraudei utilizat în timpul procesului de finalizare a comenzii unui client cu amănuntul. Conducta de inferență folosește un algoritm XGBoost cu logica de preprocesare care include pregătirea datelor pentru preprocesare.

Identificați valorile actuale și vizate de performanță și alte obiective care se pot aplica

Este posibil să descoperiți că timpul de inferență de la capăt la capăt durează prea mult pentru a fi acceptabil. Scopul dvs. ar putea fi să treceți de la zeci de milisecunde de latență la o latență de o singură cifră pentru același volum de cereri și debitul respectiv. Stabiliți că cea mai mare parte a timpului este consumată de preprocesarea datelor și de modelul XGBoost. Alți factori, cum ar fi dimensiunea rețelei și a sarcinii utile, joacă un rol minim în suprasarcina asociată cu timpul de inferență de la capăt la capăt.

Lucrați înapoi pentru a determina dacă Triton vă poate găzdui volumul de lucru în funcție de cerințele dvs

Pentru a determina dacă Triton vă poate îndeplini cerințele, doriți să acordați atenție două domenii principale de îngrijorare. Primul este să vă asigurați că Triton poate servi cu o opțiune acceptabilă de front-end, cum ar fi HTTP sau C API.

După cum am menționat anterior, este, de asemenea, esențial să determinați dacă Triton acceptă un backend care vă poate servi artefactele. Triton acceptă un număr de backend-uri care sunt personalizate pentru a suporta diverse cadre precum PyTorch și TensorFlow. Verificați pentru a vă asigura că modelele dvs. sunt acceptate și că aveți formatul de model adecvat, la care se așteaptă Triton. Pentru a face acest lucru, verificați mai întâi pentru a vedea ce formate de model acceptă backend-ul Triton. În multe cazuri, acest lucru nu necesită nicio modificare pentru model. În alte cazuri, modelul dvs. poate necesita transformarea într-un format diferit. În funcție de formatul sursă și țintă, există diverse opțiuni, cum ar fi transformarea unui Fișierul Python pickle pentru a utiliza formatul binar al punctului de control al Treelite.

Pentru acest caz de utilizare, determinăm Backend FIL poate suporta modelul XGBoost fără modificări necesare și pe care îl putem folosi Backend-ul Python pentru preprocesare. Cu funcția de ansamblu Triton, vă puteți optimiza și mai mult volumul de lucru, evitând apelurile costisitoare de rețea între instanțe de găzduire.

Creați un plan și estimați efortul necesar pentru a utiliza Triton pentru găzduire

Să vorbim despre planul de a vă muta modelele în Triton. Fiecare implementare Triton necesită următoarele:

• Model de artefacte cerute de backend-urile Triton
• Fișierele de configurare Triton
• Un folder de depozit de modele cu structura adecvată

Vă prezentăm un exemplu despre cum să creați aceste dependențe de implementare mai târziu în această postare.

Rulați planul și validați rezultatele

După ce creați fișierele și artefactele necesare în depozitul de modele structurat corespunzător, trebuie să vă reglați implementarea și să o testați pentru a valida că ați atins acum valorile țintă.

În acest moment, puteți utiliza Recomandator SageMaker Inference pentru a determina ce tip de instanță de punct final este cel mai potrivit pentru dvs., în funcție de cerințele dvs. În plus, Triton oferă instrumente pentru a face optimizări de construcție pentru a obține performanțe mai bune.

Punerea în aplicare

Acum să ne uităm la detaliile implementării. Pentru aceasta am pregătit două caiete care oferă un exemplu de ceea ce se poate aștepta. The primul caiet arată antrenamentul modelului XGBoost dat, precum și logica de preprocesare care este utilizată atât pentru antrenament, cât și pentru timpul de inferență. The al doilea caiet arată cum pregătim artefactele necesare pentru desfășurare pe Triton.

Primul blocnotes arată un blocnotes existent pe care îl are organizația dvs. care utilizează PRAGURI suită de biblioteci și nucleul RAPIDS Conda. Această instanță rulează pe un tip de instanță G4DN furnizat de AWS, care este accelerat GPU prin utilizarea procesoarelor NVIDIA T4.

Sarcinile de preprocesare din acest exemplu beneficiază de accelerarea GPU și folosesc în mare măsură bibliotecile cuML și cuDF. Un exemplu în acest sens este în codul următor, unde arătăm codificarea etichetelor categoriale folosind cuML. De asemenea, generăm un label_encoders.pkl fișier pe care îl putem utiliza pentru a serializa codificatoarele și pentru a le folosi pentru preprocesare în timpul deducerii.

Primul notebook se încheie prin antrenarea modelului nostru XGBoost și salvarea artefactelor în consecință.

În acest scenariu, codul de antrenament exista deja și nu sunt necesare modificări pentru model la momentul antrenamentului. În plus, deși am folosit accelerarea GPU pentru preprocesare în timpul antrenamentului, intenționăm să folosim procesoarele pentru preprocesare la momentul deducerii. Mai multe explicăm mai târziu în postare.

Să trecem acum la al doilea notebook și să ne amintim de ce avem nevoie pentru o implementare de succes a Triton.

În primul rând, avem nevoie de artefactele de model necesare backend-urilor. Fișierele pe care trebuie să le creăm pentru acest ansamblu includ:

• Artefacte de preprocesare (model.py, label_encoders.pkl)
• Artefacte model XGBoost (xgboost.json)

Backend-ul Python din Triton ne cere să folosim un mediu Conda ca dependență. În acest caz, folosim backend-ul Python pentru a preprocesa datele brute înainte de a le introduce în modelul XGBoost rulat în backend-ul FIL. Chiar dacă inițial am folosit bibliotecile RAPIDS cuDF și cuML pentru a face preprocesarea datelor (așa cum sa menționat mai devreme folosind GPU-ul nostru), aici folosim Pandas și Scikit-learn ca dependențe de preprocesare pentru timpul de inferență (folosind procesorul nostru). Facem acest lucru din trei motive:

• Pentru a arăta cum să creați un mediu Conda pentru dependențele dvs. și cum să-l împachetați în format așteptat de backend-ul Python al lui Triton.
• Arătând modelul de preprocesare care rulează în backend-ul Python pe CPU, în timp ce modelul XGBoost rulează pe GPU în backend-ul FIL, ilustrăm modul în care fiecare model din conducta de ansamblu Triton poate rula pe un backend cadru diferit și poate rula pe hardware diferit cu diferite configuratii.
• Acesta evidențiază modul în care bibliotecile RAPIDS (cuDF, cuML) sunt compatibile cu omologii lor CPU (Pandas, Scikit-learn). În acest fel, putem arăta cum LabelEncoders creat în cuML poate fi folosit în Scikit-learn și invers. Rețineți că, dacă vă așteptați să preprocesați cantități mari de date tabelare în timpul deducerii, puteți utiliza în continuare RAPIDS pentru a le accelera prin GPU.

Amintiți-vă că am creat label_encoders.pkl dosar în primul caiet. Nu există nimic altceva de făcut pentru codificarea categoriei, în afară de a o include în documentul nostru model.py fișier pentru preprocesare.

Pentru a crea fișierul model.py cerut de backend-ul Triton Python, aderăm la formatarea cerută de backend și includeți logica noastră Python pentru a procesa tensorul de intrare și pentru a utiliza codificatorul de etichetă menționat mai devreme. Puteți revizui fişier folosit pentru preprocesare.

Pentru modelul XGBoost nu mai trebuie făcut nimic. Am antrenat modelul în primul notebook, iar backend-ul FIL al lui Triton nu necesită efort suplimentar pentru modelele XGBoost.

În continuare, avem nevoie de fișierele de configurare Triton. Fiecare model din ansamblul Triton necesită a config.pbtxt fişier. În plus, creăm și un config.pbtxt dosar pentru ansamblu. Aceste fișiere îi permit lui Triton să cunoască metadate despre ansamblu cu informații precum intrările și ieșirile pe care le așteptăm, precum și să ajute la definirea DAG-ului asociat ansamblului.

În cele din urmă, pentru a implementa un model pe Triton, avem nevoie de folderul de depozit de modele pentru a avea structura de foldere adecvată. Triton are cerințe specifice pentru aspectul depozitului de modele. În directorul de depozit de modele de nivel superior, fiecare model are propriul său subdirector care conține informațiile pentru modelul corespunzător. Fiecare director de model din Triton trebuie să aibă cel puțin un subdirector numeric reprezentând o versiune a modelului. Pentru cazul nostru de utilizare, structura rezultată ar trebui să arate ca următorul.

După ce avem aceste trei cerințe preliminare, creăm un fișier comprimat ca ambalaj pentru implementare și îl încărcăm în Serviciul Amazon de stocare simplă (Amazon S3).

Acum putem crea un model SageMaker din depozitul de modele pe care l-am încărcat pe Amazon S3 la pasul anterior.

În acest pas, oferim și variabila de mediu suplimentară SAGEMAKER_TRITON_DEFAULT_MODEL_NAME, care specifică numele modelului care urmează să fie încărcat de Triton. Valoarea acestei chei ar trebui să se potrivească cu numele folderului din pachetul model încărcat pe Amazon S3. Această variabilă este opțională în cazul unui singur model. În cazul modelelor de ansamblu, această cheie trebuie specificată pentru ca Triton să pornească în SageMaker.

În plus, puteți seta SAGEMAKER_TRITON_BUFFER_MANAGER_THREAD_COUNT și SAGEMAKER_TRITON_THREAD_COUNT pentru optimizarea numărului de fire. Ambele valori de configurare ajută la reglarea numărului de fire care rulează pe procesoarele dvs., astfel încât să puteți obține o utilizare mai bună prin creșterea acestor valori pentru procesoarele cu un număr mai mare de nuclee. În majoritatea cazurilor, valorile implicite funcționează adesea bine, dar poate merita să experimentați pentru a vedea dacă se poate obține o eficiență suplimentară pentru sarcinile dvs. de lucru.

Cu modelul precedent, creăm o configurație a punctului final în care putem specifica tipul și numărul de instanțe pe care le dorim în punctul final.

În cele din urmă, folosim configurația anterioară a punctului final pentru a crea un nou punct final SageMaker și așteptăm finalizarea implementării. Starea se schimbă în InService după implementarea cu succes.

Asta este! Punctul final este acum gata pentru testare și validare. În acest moment, este posibil să doriți să utilizați diverse instrumente pentru a vă optimiza tipurile de instanțe și configurația pentru a obține cea mai bună performanță posibilă. Următoarea figură oferă un exemplu de câștiguri care pot fi obținute prin utilizarea backend-ului FIL pentru un model XGBoost pe Triton.

Rezumat

În această postare, v-am prezentat prin implementarea unui volum de lucru de ansamblu XGBoost la SageMaker cu Triton Inference Server. Mutarea sarcinilor de lucru la Triton pe SageMaker poate fi o rentabilitate benefică a investiției. Ca și în cazul oricărei adoptări de tehnologie, un proces și un plan de verificare sunt esențiale și am detaliat un proces în cinci pași pentru a vă ghida prin ceea ce trebuie să luați în considerare atunci când vă mutați sarcinile de lucru. În plus, ne-am aprofundat în pașii necesari pentru a implementa un ansamblu care utilizează preprocesarea Python și un model XGBoost pe Triton pe SageMaker.

SageMaker oferă instrumentele pentru a elimina sarcinile grele nediferențiate din fiecare etapă a ciclului de viață ML, facilitând astfel experimentarea și explorarea rapidă necesare pentru a optimiza pe deplin implementările modelului dumneavoastră. Suportul de găzduire SageMaker pentru Triton Inference Server permite încărcături de lucru cu latență scăzută și tranzacții pe secundă (TPS).

Puteți găsi caietele folosite pentru acest exemplu pe GitHub.

---

Despre autor

James Park este arhitect de soluții la Amazon Web Services. El lucrează cu Amazon.com pentru a proiecta, construi și implementa soluții tehnologice pe AWS și are un interes deosebit pentru AI și învățarea automată. În timpul liber, îi place să caute noi culturi, noi experiențe și să fie la curent cu cele mai recente tendințe tehnologice.

Jiahong Liu este arhitect de soluții în echipa de furnizori de servicii cloud de la NVIDIA. El ajută clienții să adopte soluții de învățare automată și inteligență artificială care folosesc calcularea accelerată NVIDIA pentru a-și aborda provocările de formare și inferență. În timpul liber, îi place origami, proiecte de bricolaj și joacă baschet.

Kshitiz Gupta este arhitect de soluții la NVIDIA. Îi face plăcere să educe clienții din cloud despre tehnologiile GPU AI pe care le oferă NVIDIA și să-i ajute să-și accelereze învățarea automată și aplicațiile de deep learning. În afara serviciului, îi place să alerge, să facă drumeții și să urmărească fauna sălbatică.

Bruno Aguiar de Melo este inginer de dezvoltare software la Amazon.com, unde ajută echipele științifice să construiască, să implementeze și să elibereze sarcini de lucru ML. El este interesat de instrumentare și aspectele controlabile din cadrul fazei de modelare/proiectare ML, care trebuie luate în considerare și măsurate, având în vedere că performanța execuției modelului este la fel de importantă ca și performanța calității modelului, în special în cazurile de utilizare cu latență restrânsă. În timpul liber, îi place vinul, jocurile de societate și gătitul.

Eliuth Triana este manager de relații cu dezvoltatorii la NVIDIA. El pune în legătură liderii de produse Amazon și AWS, dezvoltatorii și oamenii de știință cu tehnologii și liderii de produse NVIDIA pentru a accelera încărcările de lucru Amazon ML/DL, produsele EC2 și serviciile AWS AI. În plus, Eliuth este un pasionat de ciclism montan, schior și jucător de poker.