Obțineți performanță hiperscale pentru difuzarea modelelor folosind NVIDIA Triton Inference Server pe Amazon SageMaker

Aplicațiile de învățare automată (ML) sunt complexe de implementat și necesită adesea mai multe modele ML pentru a servi o singură cerere de inferență. O solicitare tipică poate curge pe mai multe modele cu pași precum preprocesarea, transformările datelor, logica de selecție a modelului, agregarea modelului și postprocesarea. Acest lucru a condus la evoluția modelelor comune de proiectare, cum ar fi conductele de inferență seriale, ansambluri (adunare dispersare) și fluxuri de lucru logice de afaceri, rezultând în 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 duce la o creștere a timpilor de răspuns generali, sau a latenței, a acestor aplicații, care, la rândul său, afectează experiența generală a utilizatorului. În plus, dacă aceste componente sunt găzduite pe instanțe diferite, latența suplimentară a rețelei dintre aceste instanțe crește latența generală. Luați în considerare un exemplu de caz popular de utilizare ML pentru un asistent virtual în asistența pentru clienți. O solicitare tipică ar putea trebui să treacă prin mai mulți pași care implică recunoașterea vorbirii, procesarea limbajului natural (NLP), urmărirea stării dialogului, politica de dialog, generarea textului și, în final, text to speech. În plus, pentru a face interacțiunea utilizatorului mai personalizată, ați putea folosi, de asemenea, modele NLP de ultimă generație, bazate pe transformatoare, cum ar fi diferite versiuni de OARET, BART, și GPT. Rezultatul final sunt timpi lungi de răspuns pentru aceste ansambluri de modele și o experiență slabă pentru clienți.

Un model obișnuit pentru a genera timpi de răspuns mai mici fără a compromite debitul general este găzduirea acestor modele pe aceeași instanță, împreună cu logica de afaceri ușoară încorporată în acesta. Aceste modele pot fi încapsulate în continuare în containere unice sau multiple pe aceeași instanță, pentru a asigura izolarea proceselor care rulează și pentru a menține latența scăzută. În plus, latența generală depinde, de asemenea, de logica aplicației de inferență, de optimizările modelului, de infrastructura de bază (inclusiv de calcul, de stocare și de rețea) și de serverul web de bază care preia cereri de inferență. NVIDIA Triton Inference Server este un software open-source care servește inferențe cu funcții pentru a maximiza debitul și utilizarea hardware-ului cu o latență de inferență ultra-scăzută (milisecunde cu o singură cifră). Are suport larg pentru cadre ML (inclusiv TensorFlow, PyTorch, ONNX, XGBoost și NVIDIA TensorRT) și backend-uri de infrastructură, inclusiv GPU-uri, procesoare și Inferentia AWS. În plus, Triton Inference Server este integrat cu Amazon SageMaker, un serviciu ML complet gestionat de la capăt la capăt, care oferă opțiuni de inferență în timp real, inclusiv singur și multi-model gazduire. Aceste opțiuni de inferență includ găzduirea mai multor modele în același container în spatele unui punct final unic, și găzduire modele multiple cu containere multiple în spatele unui singur punct final.

În noiembrie 2021, am anunțat integrarea Triton Inference Server pe SageMaker. AWS a colaborat îndeaproape cu NVIDIA pentru a vă permite să obțineți tot ce este mai bun din ambele lumi și pentru a facilita implementarea modelului cu Triton pe AWS.

În această postare, analizăm cele mai bune practici pentru implementarea modelelor de transformatoare la scară pe GPU-uri folosind Triton Inference Server pe SageMaker. În primul rând, începem cu un rezumat al conceptelor cheie despre latența în SageMaker și o prezentare generală a liniilor directoare de reglare a performanței. În continuare, oferim o prezentare generală a Triton și a caracteristicilor sale, precum și un exemplu de cod pentru implementarea pe SageMaker. În cele din urmă, efectuăm teste de sarcină folosind Recomandator SageMaker Inference și rezumați perspectivele și concluziile din testarea la sarcină a unui model popular de transformator oferit de Hugging Face.

Puteți revizui caiet obișnuiam să implementăm modele și să efectuăm teste de încărcare pe cont propriu folosind codul activat GitHub.

Reglarea și optimizarea performanței pentru difuzarea modelelor pe SageMaker

Reglarea și optimizarea performanței este un proces empiric care implică adesea mai multe iterații. Numărul de parametri de reglat este combinatoriu, iar setul de valori ale parametrilor de configurare nu este independent unul de celălalt. Diferiți factori afectează reglarea optimă a parametrilor, inclusiv dimensiunea sarcinii utile, tipul și numărul de modele ML din graficul fluxului cererii de inferență, tipul de stocare, tipul instanței de calcul, infrastructura de rețea, codul aplicației, durata și configurația software-ului care servește inferențe și multe altele.

Dacă utilizați SageMaker pentru implementarea modelelor ML, trebuie să selectați o instanță de calcul cu cel mai bun preț-performanță, care este un proces complicat și iterativ care poate dura săptămâni de experimentare. În primul rând, trebuie să alegeți tipul potrivit de instanță ML dintre cele peste 70 de opțiuni, în funcție de cerințele de resurse ale modelelor dvs. și de dimensiunea datelor de intrare. Apoi, trebuie să optimizați modelul pentru tipul de instanță selectat. În cele din urmă, trebuie să furnizați și să gestionați infrastructura pentru a rula teste de încărcare și pentru a regla configurația cloud pentru performanțe și costuri optime. Toate acestea pot întârzia implementarea modelului și timpul de lansare pe piață. În plus, trebuie să evaluați compromisurile dintre latență, debit și cost pentru a selecta configurația optimă de implementare. Recomandator SageMaker Inference selectează automat tipul de instanță de calcul potrivit, numărul de instanțe, parametrii containerului și optimizările modelului pentru a deduce deducerea pentru a maximiza debitul, a reduce latența și a minimiza costurile.

Inferență și latență în timp real în SageMaker

SageMaker inferență în timp real este ideal pentru sarcinile de lucru de inferență în care aveți cerințe în timp real, interactive și cu latență scăzută. Există patru valori cel mai frecvent utilizate pentru monitorizarea latenței solicitărilor de inferență pentru punctele finale de inferență SageMaker

• Latența containerului – Timpul necesar pentru trimiterea cererii, preluarea răspunsului din containerul modelului și inferența completă în container. Această măsurătoare este disponibilă în Amazon CloudWatch ca parte a Valori de invocare publicat de SageMaker.
• Latența modelului – Timpul total luat de toate containerele SageMaker într-un conductă de inferență. Această măsurătoare este disponibilă în Amazon CloudWatch ca parte a Valori de invocare publicat de SageMaker.
• Latență generală – Măsurat din momentul în care SageMaker primește cererea și până când returnează un răspuns clientului, minus latența modelului. Această măsurătoare este disponibilă în Amazon CloudWatch ca parte a Valori de invocare publicat de SageMaker.
• Latență de la capăt la capăt – Măsurat din momentul în care clientul trimite cererea de inferență până când primește un răspuns înapoi. Clienții pot publica acest lucru ca măsură personalizată în Amazon CloudWatch.

Următoarea diagramă ilustrează aceste componente.

Latența containerului depinde de mai mulți factori; următoarele sunt printre cele mai importante:

• Protocolul de bază (HTTP(e)/gRPC) utilizat pentru a comunica cu serverul de inferență
• Suplimentar legat de crearea de noi conexiuni TLS
• Timpul de deserializare al sarcinii utile de cerere/răspuns
• Solicitați funcțiile de așteptare și de grupare furnizate de serverul de inferență de bază
• Solicitați capabilități de programare furnizate de serverul de inferență de bază
• Performanța de bază a serverului de inferență
• Performanța bibliotecilor de preprocesare și postprocesare înainte de apelarea funcției de predicție a modelului
• Performanța backend-ului cadrului ML subiacent
• Optimizări specifice modelului și hardware-ului

În această postare, ne concentrăm în primul rând pe optimizarea latenței containerului, împreună cu debitul și costul general. Mai exact, explorăm reglarea performanței Triton Inference Server care rulează într-un container SageMaker.

Prezentare generală a cazului de utilizare

Implementarea și scalarea modelelor NLP într-o configurație de producție poate fi destul de dificilă. Modelele NLP sunt adesea foarte mari ca dimensiuni, conținând milioane de parametri de model. Sunt necesare configurații optime de model pentru a satisface cerințele stricte de performanță și scalabilitate ale aplicațiilor NLP de nivel de producție.

În această postare, analizăm un caz de utilizare NLP utilizând un punct final în timp real SageMaker bazat pe un container Triton Inference Server și recomandăm optimizări de reglare a performanței pentru cazul nostru de utilizare ML. Folosim un Hugging Face mare, pre-antrenat, bazat pe transformator BERT mare fără carcasă model, care are aproximativ 336 de milioane de parametri de model. Propoziția de intrare utilizată pentru modelul de clasificare binar este completată și trunchiată la o lungime maximă a secvenței de intrare de 512 jetoane. Testul de încărcare a inferenței simulează 500 de invocări pe secundă (30,000 de invocări maxime pe minut) și ModelLatency mai puțin de 0.5 secunde (500 milisecunde).

Următorul tabel rezumă configurația noastră de referință.

NVIDIA Triton Inference Server

Triton Inference Server este proiectat special pentru a permite implementarea scalabilă, rapidă și ușoară a modelelor în producție. Triton acceptă o varietate de cadre AI majore, inclusiv TensorFlow, TensorRT, PyTorch, XGBoost și ONNX. Cu backend-ul personalizat Python și C++, puteți implementa, de asemenea, volumul de lucru de inferență pentru cazuri de utilizare mai personalizate.

Cel mai important, Triton oferă o configurație simplă bazată pe configurație pentru a găzdui modelele dvs., care expune un set bogat de caracteristici de optimizare a performanței pe care le puteți utiliza cu puțin efort de codare.

Triton crește performanța de inferență prin maximizarea utilizării hardware cu diferite tehnici de optimizare (execuțiile simultane ale modelului și loturile dinamice sunt cele mai frecvent utilizate). Găsirea configurațiilor optime de model din diferite combinații de dimensiuni dinamice ale loturilor și numărul de instanțe de model concurente este esențială pentru a obține inferențe în timp real în servirea cu costuri reduse folosind Triton.

Loturi dinamice

Mulți practicieni tind să execute inferențe secvenţial atunci când serverul este invocat cu mai multe cereri independente. Deși mai ușor de configurat, de obicei nu este cea mai bună practică să utilizați puterea de calcul a GPU-ului. Pentru a rezolva acest lucru, Triton oferă optimizările încorporate ale loturi dinamice pentru a combina aceste cereri de inferență independente pe partea de server pentru a forma un lot mai mare în mod dinamic pentru a crește debitul. Următoarea diagramă ilustrează arhitectura de rulare Triton.

În arhitectura anterioară, toate cererile ajung mai întâi la dozatorul dinamic înainte de a intra în cozile de planificare a modelului real pentru a aștepta inferența. Puteți seta dimensiunile de lot preferate pentru loturi dinamice folosind dimensiunea_lotului_preferată setările din configurația modelului. (Rețineți că dimensiunea lotului format trebuie să fie mai mică decât max_batch_size modelul suportă.) De asemenea, puteți configura max_queue_delay_microsecunde pentru a specifica timpul maxim de întârziere în lot pentru a aștepta ca alte solicitări să se alăture lotului, pe baza cerințelor dvs. de latență.

Următorul fragment de cod arată cum puteți adăuga această caracteristică cu fișierele de configurare a modelului pentru a seta lotul dinamic cu o dimensiune preferată a lotului de 16 pentru deducerea reală. Cu setările curente, instanța modelului este invocată instantaneu atunci când dimensiunea preferată a lotului de 16 este îndeplinită sau timpul de întârziere de 100 de microsecunde a trecut de când prima solicitare a ajuns la lotul dinamic.

dynamic_batching { preferred_batch_size: 16 max_queue_delay_microseconds: 100 }

Rularea modelelor concomitent

O altă optimizare esențială oferită în Triton pentru a maximiza utilizarea hardware-ului fără latență suplimentară este execuție concomitentă a modelului, care permite rularea în paralel a mai multor modele sau a mai multor copii ale aceluiași model. Această caracteristică îi permite lui Triton să gestioneze simultan mai multe solicitări de inferență, ceea ce crește debitul de inferență prin utilizarea puterii de calcul, altfel inactiv, pe hardware.

Următoarea figură arată cum puteți configura cu ușurință diferite politici de implementare a modelului cu doar câteva rânduri de modificări de cod. De exemplu, configurația A (stânga) arată că puteți difuza aceeași configurație a două instanțe de model ale bert-large-uncased la toate GPU-urile disponibile. În schimb, configurația B (din mijloc) arată o configurație diferită numai pentru GPU 0, fără a modifica politicile celorlalte GPU. De asemenea, puteți implementa instanțe ale diferitelor modele pe un singur GPU, așa cum se arată în configurația C (dreapta).

În configurația C, instanța de calcul poate gestiona două solicitări simultane pentru modelul DistilGPT-2 și șapte solicitări simultane pentru bert-large-uncased model în paralel. Cu aceste optimizări, resursele hardware pot fi utilizate mai bine pentru procesul de servire, îmbunătățind astfel debitul și oferind o mai bună eficiență a costurilor pentru volumul de lucru.

TensorRT

NVIDIA TensorRT este un SDK pentru inferență de învățare profundă de înaltă performanță care funcționează perfect cu Triton. TensorRT, care acceptă fiecare cadru major de învățare profundă, include un optimizator de inferență și un timp de rulare care oferă o latență scăzută și un randament ridicat pentru a rula inferențe cu volume masive de date prin optimizări puternice.

TensorRT optimizează graficul pentru a minimiza amprenta memoriei prin eliberarea memoriei inutile și reutilizarea eficientă a acesteia. În plus, compilarea TensorRT îmbină operațiunile rare din graficul modelului pentru a forma un nucleu mai mare pentru a evita supraîncărcarea mai multor lansări mici de kernel. Reglarea automată a kernelului vă ajută să utilizați pe deplin hardware-ul selectând cel mai bun algoritm pe GPU-ul dvs. țintă. Fluxurile CUDA permit modelelor să ruleze în paralel pentru a maximiza utilizarea GPU-ului pentru performanță optimă. Nu în ultimul rând, tehnica de cuantizare poate folosi pe deplin accelerația de precizie mixtă a nucleelor ​​Tensor pentru a rula modelul în FP32, TF32, FP16 și INT8 pentru a obține cea mai bună performanță de inferență.

Triton pe găzduire 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 sunt pre-ambalate cu software-ul de server model adecvat pentru cadrul ML acceptat 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 SageMaker Deep Learning Containers (DLC).

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ă.

Recomandare SageMaker Inference pentru compararea rezultatelor testelor

Folosim SageMaker Inference Recommender pentru a rula experimentele noastre. SageMaker Inference Recommender oferă două tipuri de lucrări: implicite și avansate, așa cum este ilustrat în diagrama următoare.

Lucrarea implicită oferă recomandări cu privire la tipurile de instanțe doar cu modelul și un eșantion de sarcină utilă de comparat. Pe lângă recomandările de instanță, serviciul oferă și parametri de rulare care îmbunătățesc performanța. Recomandările implicite ale jobului sunt menite să restrângă căutarea instanței. În unele cazuri, ar putea fi familia de instanțe, iar în altele, ar putea fi tipurile de instanțe specifice. Rezultatele jobului implicit sunt apoi introduse în jobul avansat.

Lucrarea avansată oferă mai multe controale pentru a regla în continuare performanța. Aceste controale simulează mediul real și cerințele de producție. Printre aceste controale se numără modelul de trafic, care urmărește să pună în scenă modelul de solicitare pentru benchmark-uri. Puteți seta rampe sau trafic constant utilizând fazele multiple ale modelului de trafic. De exemplu, un InitialNumberOfUsers din 1, SpawnRate din 1 și DurationInSeconds de 600 poate duce la un trafic pe rampă de 10 minute cu 1 utilizator simultan la început și 10 la sfârșit. În plus, pe comenzi, MaxInvocations și ModelLatency Thresholds setați pragul de producție, astfel încât atunci când unul dintre praguri este depășit, benchmarking-ul se oprește.

În cele din urmă, metrici de recomandare includeți debitul, latența la debitul maxim și costul pe inferență, astfel încât este ușor să le comparați.

Folosim tipul avansat de muncă SageMaker Inference Recommender pentru a rula experimentele noastre pentru a obține un control suplimentar asupra tiparelor de trafic și pentru a ajusta configurația containerului de servire.

Configurarea experimentului

Folosim caracteristica personalizată de testare a sarcinii a SageMaker Inference Recommender pentru a evalua profilul NLP prezentat în cazul nostru de utilizare. Mai întâi definim următoarele cerințe preliminare legate de modelul NLP și sarcina ML. SageMaker Inference Recommender folosește aceste informații pentru a extrage o imagine Docker de inferență din Registrul Amazon de containere elastice (Amazon ECR) și înregistrați modelul în registrul de modele SageMaker.

Configurațiile modelului de trafic din SageMaker Inference Recommender ne permit să definim diferite faze pentru testul de încărcare personalizat. Testul de încărcare începe cu doi utilizatori inițiali și generează doi utilizatori noi în fiecare minut, pentru o durată totală de 25 de minute (1500 de secunde), așa cum se arată în următorul cod:

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

Experimentăm testarea la sarcină a aceluiași model în două stări diferite. Experimentele bazate pe PyTorch folosesc modelul standard, nealterat, PyTorch. Pentru experimentele bazate pe TensorRT, transformăm în prealabil modelul PyTorch într-un motor TensorRT.

Aplicăm diferite combinații ale caracteristicilor de optimizare a performanței pe aceste două modele, rezumate în tabelul următor.

Rezultatele testelor și observațiile

Am efectuat teste de încărcare pentru trei tipuri de instanțe din aceeași familie g4dn: ml.g4dn.xlarge, ml.g4dn.2xlarge și ml.g4dn.12xlarge. Toate tipurile de instanțe g4dn au acces la GPU-uri NVIDIA T4 Tensor Core și procesoare Intel Cascade Lake de a doua generație. Logica din spatele alegerii tipurilor de instanță a fost aceea de a avea atât o instanță cu un singur GPU disponibil, cât și o instanță cu acces la mai multe GPU-uri – patru în cazul ml.g2dn.4xlarge. În plus, am vrut să testăm dacă creșterea capacității vCPU pe instanță cu un singur GPU disponibil ar duce la o îmbunătățire a raportului cost-performanță.

Să trecem mai întâi peste accelerarea optimizării individuale. Următorul grafic arată că optimizarea TensorRT oferă o reducere cu 50% a latenței modelului în comparație cu cea nativă din PyTorch pe instanța ml.g4dn.xlarge. Această reducere a latenței crește de peste trei ori pe instanțele multi-GPU ale ml.g4dn.12xlarge. Între timp, îmbunătățirea cu 30% a debitului este consecventă în ambele instanțe, rezultând o eficiență mai bună a costurilor după aplicarea optimizărilor TensorRT.

Cu loturi dinamice, ne putem apropia de o îmbunătățire de 2 ori a debitului folosind aceeași arhitectură hardware pentru toate exemplele experimentelor ml.g4dn.xlarge, ml.g4dn.2xlarge și ml.g4dn.12xlarge, fără o creștere vizibilă a latenței.

În mod similar, execuția simultană a modelului ne permite să obținem o îmbunătățire de aproximativ 3-4x a debitului prin maximizarea utilizării GPU pe instanța ml.g4dn.xlarge și o îmbunătățire de aproximativ 2x atât pe instanța ml.g4dn.2xlarge, cât și pe instanța multi-GPU de ml. g4dn.12xlarge.. Această creștere a debitului vine fără nicio suprasarcină în latență.

Mai bine, putem integra toate aceste optimizări pentru a oferi cea mai bună performanță utilizând resursele hardware la maximum. Următorul tabel și graficele rezumă rezultatele pe care le-am obținut în experimentele noastre.

[1] Numărul inițial de instanțe din tabelul de mai sus este numărul recomandat de instanțe de utilizat cu o politică de autoscaling pentru a menține cerințele de debit și latență pentru volumul de lucru.

[2] Costul pe oră din tabelul de mai sus este calculat pe baza numărului de instanțe inițiale și a prețului pentru tipul de instanță.

Rezultatele validează în mare parte impactul așteptat al diferitelor funcții de optimizare a performanței:

• Compilarea TensorRT are cel mai fiabil impact pentru toate tipurile de instanțe. Tranzacțiile pe minut per instanță au crescut cu 30–35%, cu o reducere constantă a costurilor de aproximativ 25% în comparație cu performanța motorului TensorRT față de PyTorch BERT implicit (pt-base). Performanța crescută a motorului TensorRT se adaugă și este exploatată de celelalte funcții de reglare a performanței testate.
• Încărcarea a două modele pe fiecare GPU (grup de instanțe) a dublat aproape strict toate valorile măsurate. Invocările pe minut per instanță au crescut cu aproximativ 80–90%, producând o reducere a costurilor în intervalul de 50%, aproape ca și cum am folosi două GPU-uri. De fapt, Amazon CloudWatch valorile pentru experimentele noastre pe g4dn.2xlarge (de exemplu) confirmă faptul că atât utilizarea CPU, cât și a GPU-ului se dublează atunci când configurăm un grup de instanțe de două modele.

Alte sfaturi de performanță și optimizare a costurilor

Benchmark-ul prezentat în această postare doar a zgâriat suprafața posibilelor caracteristici și tehnici pe care le puteți utiliza cu Triton pentru a îmbunătăți performanța de inferență. Acestea variază de la tehnici de preprocesare a datelor, cum ar fi trimiterea de încărcături binare la serverul model sau încărcări utile cu loturi mai mari, până la caracteristici native Triton, cum ar fi următoarele:

• Încălzire model, care previne cererile inițiale de inferență lente prin inițializarea completă a modelului înainte ca prima cerere de inferență să fie primită.
• Cache de răspuns, care memorează în cache solicitările repetate.
• Asamblare model, care vă permite să creați o conductă de unul sau mai multe modele și conectarea tensorilor de intrare și de ieșire între acele modele. Acest lucru deschide posibilitatea de a adăuga pași de preprocesare și postprocesare, sau chiar de inferență cu alte modele, la fluxul de procesare pentru fiecare cerere.

Ne așteptăm să testăm și să comparam aceste tehnici și funcții într-o postare viitoare, așa că rămâneți pe fază!

Concluzie

În această postare, am explorat câțiva parametri pe care îi puteți folosi pentru a maximiza performanța punctului final în timp real SageMaker pentru a servi modelele PyTorch BERT cu Triton Inference Server. Am folosit SageMaker Inference Recommender pentru a efectua testele de benchmarking pentru a regla fin acești parametri. Acești parametri sunt în esență legați de optimizarea modelului bazat pe TensorRT, ceea ce duce la o îmbunătățire cu aproape 50% a timpilor de răspuns comparativ cu versiunea neoptimizată. În plus, rularea simultană a modelelor și utilizarea procesului de loturi dinamice de Triton a condus la o creștere cu aproape 70% a debitului. Reglarea fină a acestor parametri a condus și la o reducere generală a costurilor de inferență.

Cel mai bun mod de a obține valorile corecte este prin experimentare. Cu toate acestea, pentru a începe să construiți cunoștințe empirice despre reglarea și optimizarea performanței, puteți observa combinațiile diferiților parametri legați de Triton și efectul acestora asupra performanței în modelele ML și instanțele ML 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ă.

Puteți găsi notebook-ul folosit pentru testarea încărcării și implementare pe GitHub. Puteți actualiza configurațiile Triton și setările SageMaker Inference Recommender pentru a se potrivi cel mai bine în cazul dvs. de utilizare pentru a obține sarcini de lucru de inferență rentabile și cu cele mai bune performanțe.

Despre Autori

Vikram Elango este arhitect specializat în soluții AI/ML la Amazon Web Services, cu sediul în Virginia, SUA. Vikram ajută clienții din industria financiară și de asigurări cu design, lider de gândire pentru a construi și implementa aplicații de învățare automată la scară. În prezent, se concentrează pe procesarea limbajului natural, AI responsabil, optimizarea inferenței și scalarea ML în întreaga întreprindere. În timpul liber, îi place să călătorească, să facă drumeții, să gătească și să campeze împreună cu familia.

João Moura este arhitect specializat în soluții AI/ML la Amazon Web Services. El se concentrează în principal pe cazurile de utilizare a NLP și ajută clienții să optimizeze instruirea și implementarea modelului Deep Learning. El este, de asemenea, un susținător activ al soluțiilor ML low-code și al hardware-ului specializat în ML.

Mohan Gandhi este inginer software senior la AWS. El a fost la AWS în ultimii 9 ani și a lucrat la diverse servicii AWS precum EMR, EFA și RDS pe Outposts. În prezent, el se concentrează pe îmbunătățirea experienței SageMaker Inference. În timpul liber, îi place drumețiile și alergarea maratoanelor.

Dhawal Patel este arhitect principal de învățare automată la AWS. El a lucrat cu organizații, de la întreprinderi mari până la startup-uri mijlocii, pe probleme legate de calculul distribuit și inteligența artificială. El se concentrează pe învățarea profundă, inclusiv pe domeniile NLP și Computer Vision. El îi ajută pe clienți să obțină inferențe de model de înaltă performanță pe SageMaker.

Santosh Bhavani este Senior Technical Product Manager al echipei Amazon SageMaker Elastic Inference. El se concentrează pe a ajuta clienții SageMaker să accelereze deducerea și implementarea modelului. În timpul liber, îi place să călătorească, să joace tenis și să bea o mulțime de ceai Pu'er.

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.

• Coinsmart. Cel mai bun schimb de Bitcoin și Crypto din Europa.
• Platoblockchain. Web3 Metaverse Intelligence. Cunoștințe amplificate. ACCES LIBER.
• CryptoHawk. Radar Altcoin. Încercare gratuită.
• Sursa: https://aws.amazon.com/blogs/machine-learning/achieve-hyperscale-performance-for-model-serving-using-nvidia-triton-inference-server-on-amazon-sagemaker/