Obțineți performanță ridicată la scară pentru difuzarea modelelor folosind punctele finale multimodel Amazon SageMaker cu GPU

Amazon SageMaker puncte finale multi-model (MME) oferă o modalitate scalabilă și rentabilă de a implementa un număr mare de modele de învățare automată (ML). Vă oferă posibilitatea de a implementa mai multe modele ML într-un singur container de servire în spatele unui singur punct final. De acolo, SageMaker gestionează încărcarea și descărcarea modelelor și scalarea resurselor în numele dvs. în funcție de tiparele dvs. de trafic. Veți beneficia de partajarea și reutilizarea resurselor de găzduire și de o sarcină operațională redusă a gestionării unei cantități mari de modele.

În noiembrie 2022, MME-urile au adăugat suport pentru GPUs, care vă permite să rulați mai multe modele pe un singur dispozitiv GPU și să scalați instanțe GPU în spatele unui singur punct final. Acest lucru satisface cererea puternică MME pentru modele de rețea neuronală profundă (DNN) care beneficiază de calcul accelerat cu GPU. Acestea includ viziunea computerizată (CV), procesarea limbajului natural (NLP) și modelele AI generative. Motivele cererii includ următoarele:

• Modelele DNN sunt de obicei mari ca dimensiune și complexitate și continuă să crească într-un ritm rapid. Luând ca exemplu modelele NLP, multe dintre ele depășesc miliarde de parametri, ceea ce necesită ca GPU-urile să îndeplinească cerințe de latență scăzută și de debit ridicat.
• Am observat o nevoie crescută de personalizare a acestor modele pentru a oferi experiențe hiperpersonalizate utilizatorilor individuali. Pe măsură ce cantitatea acestor modele crește, este nevoie de o soluție mai ușoară pentru implementarea și operaționalizarea multor modele la scară.
• Instanțele GPU sunt scumpe și doriți să reutilizați aceste instanțe cât mai mult posibil pentru a maximiza utilizarea GPU și a reduce costurile de operare.

Deși toate aceste motive indică MME-urile cu GPU ca opțiune ideală pentru modelele DNN, se recomandă să efectuați testarea de încărcare pentru a găsi configurația corectă a punctului final care să satisfacă cerințele dvs. de utilizare. Mulți factori pot influența rezultatele testării de încărcare, cum ar fi tipul instanței, numărul de instanțe, dimensiunea modelului și arhitectura modelului. În plus, testarea încărcării poate ajuta la ghidarea strategiilor de scalare automată folosind valorile potrivite, mai degrabă decât metodele iterative de încercare și eroare.

Din aceste motive, am creat această postare pentru a vă ajuta să efectuați testarea corectă a încărcării pe MME-uri cu GPU și să găsiți cea mai bună configurație pentru cazul dvs. de utilizare ML. Împărtășim rezultatele testării de încărcare pentru unele dintre cele mai populare modele DNN în NLP și CV găzduite folosind MME-uri pe diferite tipuri de instanțe. Rezumăm perspectivele și concluziile din rezultatele testelor noastre pentru a vă ajuta să luați o decizie informată cu privire la configurarea propriilor implementări. Pe parcurs, împărtășim și abordarea noastră recomandată pentru efectuarea testării de încărcare pentru MME-uri pe GPU. Instrumentele și tehnica recomandate determină numărul optim de modele care pot fi încărcate pe tip de instanță și vă ajută să obțineți cel mai bun preț-performanță.

Prezentare generală a soluțiilor

Pentru o introducere în MME și MME cu GPU, consultați Creați un punct final cu mai multe modele și Rulați mai multe modele de deep learning pe GPU cu punctele finale cu mai multe modele Amazon SageMaker. Pentru contextul testării de încărcare din această postare, puteți descărca codul nostru exemplu de la GitHub repo pentru a reproduce rezultatele sau utilizați-l ca șablon pentru a vă compara propriile modele. Există două notebook-uri furnizate în repo: unul pentru testarea încărcării modelelor CV și altul pentru NLP. Mai multe modele de dimensiuni și arhitecturi diferite au fost evaluate pe diferite tipuri de instanțe GPU: ml.g4dn.2xlarge, ml.g5.2xlarge și ml.p3.2xlarge. Acest lucru ar trebui să ofere o secțiune transversală rezonabilă a performanței pentru următoarele valori pentru fiecare instanță și tip de model:

• Număr maxim de modele care pot fi încărcate în memoria GPU
• Latența de răspuns de la capăt la capăt observată pe partea clientului pentru fiecare interogare de inferență
• Debitul maxim de interogări pe secundă pe care punctul final le poate procesa fără erori
• Numărul maxim de utilizatori actuali pe instanțe înainte ca o solicitare eșuată să fie observată

Următorul tabel listează modelele testate.

Următorul tabel listează instanțele GPU testate.

După cum sa menționat anterior, exemplu de cod poate fi adoptat la alte modele și tipuri de instanțe.

Rețineți că MME-urile acceptă în prezent doar instanțele GPU unice. Pentru lista tipurilor de instanțe acceptate, consultați Algoritmi, cadre și instanțe acceptate.

Procedura de evaluare comparativă constă din următorii pași:

1. Preluați un model pre-antrenat de la un hub de model.
2. Pregătiți artefactul model pentru difuzare pe MME-uri SageMaker (vezi Rulați mai multe modele de deep learning pe GPU cu punctele finale cu mai multe modele Amazon SageMaker pentru mai multe detalii).
3. Implementați un MME SageMaker pe o instanță GPU.
4. Determinați numărul maxim de modele care pot fi încărcate în memoria GPU într-un prag specificat.
5. Utilizați Cadrul de testare a încărcării Locust pentru a simula traficul care invocă aleatoriu modele încărcate pe instanță.
6. Colectați date și analizați rezultatele.
7. Opțional, repetați pașii 2–6 după compilarea modelului în TensorRT.

Pașii 4 și 5 garantează o privire mai profundă. Modelele dintr-un GPU MME SageMaker sunt încărcate în memorie într-un mod dinamic. Prin urmare, în Pasul 4, încărcăm un artefact model inițial în Serviciul Amazon de stocare simplă (Amazon S3) și invocați modelul pentru a-l încărca în memorie. După invocarea inițială, măsuram cantitatea de memorie GPU consumată, facem o copie a modelului inițial, invocăm copia modelului pentru a o încărca în memorie și măsurăm din nou cantitatea totală de memorie GPU consumată. Acest proces se repetă până când este atins un anumit prag procentual de utilizare a memoriei GPU. Pentru benchmark, am stabilit pragul la 90% pentru a oferi un buffer de memorie rezonabil pentru deducerea unor loturi mai mari sau pentru a lăsa spațiu pentru a încărca alte modele utilizate mai puțin frecvent.

Simulați traficul utilizatorilor

După ce am determinat numărul de modele, putem rula un test de încărcare folosind Cadrul de testare a încărcăturii Locust. Testul de încărcare simulează solicitările utilizatorilor către modele aleatorii și măsoară automat valori precum latența de răspuns și debitul.

Locust acceptă forme personalizate de testare a încărcării care vă permit să definiți modele de trafic personalizate. Forma care a fost utilizată în acest benchmark este prezentată în următorul grafic. În primele 30 de secunde, punctul final este încălzit cu 10 utilizatori concurenți. După 30 de secunde, utilizatorii noi sunt generați cu o rată de doi pe secundă, ajungând la 20 de utilizatori concurenți la 40 de secunde. Punctul final este apoi evaluat în mod constant cu 20 de utilizatori concurenți până la marcajul de 60 de secunde, moment în care Locust începe din nou să crească utilizatorii cu doi pe secundă până la 40 de utilizatori concurenți. Acest model de accelerare și testare constantă se repetă până când punctul final ajunge la 200 de utilizatori concurenți. În funcție de cazul dvs. de utilizare, este posibil să doriți să ajustați forma testului de încărcare în locust_benchmark_sm.py pentru a reflecta mai precis modelele de trafic așteptate. De exemplu, dacă intenționați să găzduiți modele de limbă mai mari, este posibil ca un test de încărcare cu 200 de utilizatori concurenți să nu fie fezabil pentru un model găzduit pe o singură instanță și, prin urmare, este posibil să doriți să reduceți numărul de utilizatori sau să creșteți numărul de instanțe. De asemenea, poate doriți să extindeți durata testului de încărcare pentru a măsura mai precis stabilitatea punctului final pe o perioadă mai lungă de timp.

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

Rețineți că am evaluat punctul final doar cu modele omogene, toate rulând pe baze de servire consistente, folosind fie PyTorch, fie TensorRT. Acest lucru se datorează faptului că MME-urile sunt cele mai potrivite pentru găzduirea multor modele cu caracteristici similare, cum ar fi consumul de memorie și timpul de răspuns. Șabloanele de evaluare comparativă furnizate în GitHub repo poate fi încă folosit pentru a determina dacă deservirea de modele eterogene pe MME-uri ar produce performanța și stabilitatea dorite.

Rezultate de referință pentru modelele de CV

Utilizați notebook-ul cv-benchmark.ipynb pentru a efectua teste de încărcare pentru modelele de computer vision. Puteți ajusta numele modelului pre-antrenați și parametrii tipului de instanță la testarea sarcinii de performanță pe diferite combinații de model și tip de instanță. Am testat în mod intenționat trei modele CV în diferite game de dimensiuni, de la cel mai mic la cel mai mare: resnet50 (25 milioane), convnext_base (88M) și vit_large_patch16_224 (304M). Poate fi necesar să vă adaptați la cod dacă alegeți un model în afara acestei liste. în plus, notebook-ul setează implicit forma imaginii de intrare la un tensor de imagine de 224x224x3. Nu uitați să ajustați forma de intrare în consecință dacă trebuie să comparați modele care iau o imagine de dimensiuni diferite.

După ce parcurgeți întregul notebook, veți obține mai multe vizualizări ale analizei performanței. Primele două detaliază performanța modelului în ceea ce privește creșterea utilizatorilor concurenți. Următoarele figuri sunt exemple de vizualizări generate pentru ResNet50 model care rulează pe ml.g4dn.2xlarge, comparând PyTorch (stânga) cu TensorRT (dreapta). Graficele liniei de sus arată latența și debitul modelului pe axa y, cu un număr tot mai mare de lucrători clienți concurenți reflectând pe axa x. Diagramele cu bare de jos arată numărul de solicitări reușite și nereușite.

Analizând toate modelele de computer vision pe care le-am testat, am observat următoarele:

• Latența (în milisecunde) este mai mare, iar debitul (cereri pe secundă) este mai mic pentru modelele mai mari (resnet50 > convnext_base > vit_large_patch16_224).
• Creșterea latenței este proporțională cu numărul de utilizatori, deoarece mai multe cereri sunt puse în coadă pe serverul de inferență.
• Modelele mari consumă mai multe resurse de calcul și își pot atinge limitele maxime de debit cu mai puțini utilizatori decât un model mai mic. Acest lucru se observă cu vit_large_patch16_224 model, care a înregistrat prima solicitare eșuată la 140 de utilizatori concurenți. Fiind semnificativ mai mare decât celelalte două modele testate, a avut cele mai multe solicitări eșuate, de asemenea, la concurență mai mare. Acesta este un semnal clar că punctul final ar trebui să se extindă dincolo de o singură instanță dacă intenția este să accepte mai mult de 140 de utilizatori concurenți.

La sfârșitul rulării notebook-ului, obțineți și o comparație rezumată a modelelor PyTorch și TensorRT pentru fiecare dintre cele patru valori cheie. Din testele noastre de referință, toate modelele CV au înregistrat o creștere a performanței modelului după compilarea TensorRT. Luându-ne ResNet50 ca exemplu din nou, latența a scăzut cu 32%, în timp ce debitul a crescut cu 18%. Deși numărul maxim de utilizatori concurenți a rămas același pentru ResNet50, celelalte două modele au înregistrat o îmbunătățire cu 14% a numărului de utilizatori concurenți pe care îi pot suporta. Cu toate acestea, îmbunătățirea performanței TensorRT a venit în detrimentul unei utilizări mai mari a memoriei, rezultând mai puține modele încărcate de MME-uri. Impactul este mai mult pentru modelele care utilizează o rețea neuronală convoluțională (CNN). De fapt, modelul nostru ResNet50 a consumat aproximativ de două ori memoria GPU de la PyTorch la TensorRT, rezultând cu 50% mai puține modele încărcate (46 față de 23). Diagnosticam acest comportament în continuare în secțiunea următoare.

Rezultate de referință pentru modelele NLP

Pentru modelele NLP, utilizați notebook-ul nlp-benchmark.ipynb pentru a rula testul de încărcare. Configurația notebook-ului ar trebui să arate foarte asemănătoare. Am testat două modele NLP: bert-base-uncased (109M) și roberta-large (335M). Modelul pre-antrenat și tokenizer-ul sunt ambele descărcate din hub-ul Hugging Face, iar sarcina utilă de testare este generată de tokenizer folosind un șir de probă. Lungimea maximă a secvenței este implicită la 128. Dacă trebuie să testați șiruri mai lungi, nu uitați să ajustați acel parametru. Rularea prin notebook-ul NLP generează același set de vizualizări: Pytorch (stânga) vs TensorRT (dreapta).

Din acestea, am observat și mai multe beneficii de performanță ale TensorRT pentru modelele NLP. Luând roberta-large model pe o instanță ml.g4dn.2xlarge, de exemplu, latența de inferență a scăzut dramatic de la 180 milisecunde la 56 milisecunde (o îmbunătățire cu 70%), în timp ce debitul s-a îmbunătățit cu 406% de la 33 de solicitări pe secundă la 167. În plus, numărul maxim de solicitări simultane utilizatorii au crescut cu 50%; cererile eșuate nu au fost respectate până când am ajuns la 180 de utilizatori concurenți, față de 120 pentru modelul original PyTorch. În ceea ce privește utilizarea memoriei, am văzut încă un model mai puțin încărcat pentru TensorRT (de la nouă modele la opt). Cu toate acestea, impactul negativ este mult mai mic în comparație cu ceea ce am observat cu modelele bazate pe CNN.

Analiza utilizării memoriei

Următorul tabel arată analiza completă a impactului utilizării memoriei de la PyTorch la TensorRT. Am menționat mai devreme că modelele bazate pe CNN sunt afectate mai negativ. The ResNet50 modelul a avut o reducere de peste 50% a numărului de modele încărcate în toate cele trei tipuri de instanțe GPU. Convnext_base a avut o reducere și mai mare de aproximativ 70% la nivel general. Pe de altă parte, impactul asupra modelelor de transformatoare este mic sau mixt. vit_large_patch16_224 și roberta-large a avut o reducere medie de aproximativ 20%, respectiv 3%, în timp ce bert-base-uncased a avut o îmbunătățire de aproximativ 40%.

Privind toate punctele de date în ansamblu în ceea ce privește performanța superioară în latență, debit și fiabilitate și impactul minor asupra numărului maxim de modele încărcate, recomandăm modelul TensorRT pentru arhitecturile model bazate pe transformator. Pentru CNN, credem că este necesară o analiză suplimentară a performanței costurilor pentru a ne asigura că beneficiul performanței depășește costul infrastructurii suplimentare de găzduire.

Următoarele tabele listează rezultatele noastre de referință complete pentru toate valorile din toate cele trei tipuri de instanțe GPU.

Următorul tabel rezumă rezultatele pentru toate tipurile de instanțe. Instanța ml.g5.2xlarge oferă cea mai bună performanță, în timp ce instanța ml.p3.2xlarge are în general performanțe slabe, în ciuda faptului că este cea mai scumpă dintre cele trei. Instanțele g5 și g4dn demonstrează cea mai bună valoare pentru sarcinile de lucru de inferență.

A curăța

După ce finalizați testul de încărcare, curățați resursele generate pentru a evita costurile suplimentare. Principalele resurse sunt punctele finale SageMaker și fișierele artefacte model din Amazon S3. Pentru a vă ușura, fișierele blocnotesului au următorul cod de curățare pentru a vă ajuta să le ștergeți:

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

Concluzie

În această postare, am împărtășit rezultatele testelor și analizele noastre pentru diferite modele de rețea neuronală profundă care rulează pe puncte finale multimodel SageMaker cu GPU. Rezultatele și informațiile pe care le-am împărtășit ar trebui să ofere o secțiune transversală rezonabilă a performanței pentru diferite valori și tipuri de instanțe. În acest proces, am introdus și abordarea noastră recomandată pentru a rula teste de referință pentru SageMaker MME cu GPU. Instrumentele și exemplul de cod pe care le-am furnizat vă pot ajuta să începeți rapid testarea de referință și să luați o decizie mai informată cu privire la modul în care puteți găzdui în mod eficient sute de modele DNN pe hardware de calcul accelerat. Pentru a începe să comparați propriile modele cu suport MME pentru GPU, consultați Algoritmi, cadre și instanțe acceptate si GitHub repo pentru exemple suplimentare și documentație.

Despre autori

James Wu este arhitect senior de soluții de specialitate AI/ML la AWS. ajutând clienții să proiecteze și să construiască soluții AI/ML. Munca lui James acoperă o gamă largă de cazuri de utilizare ML, cu un interes principal în viziunea computerizată, învățarea profundă și scalarea ML în întreaga întreprindere. Înainte de a se alătura AWS, James a fost arhitect, dezvoltator și lider tehnologic timp de peste 10 ani, inclusiv 6 ani în inginerie și 4 ani în industriile de marketing și publicitate.

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.

Simon Zamarin este un arhitect de soluții AI/ML al cărui obiectiv principal este să îi ajute pe clienți să extragă valoare din activele lor de date. În timpul liber, lui Simon îi place să petreacă timpul cu familia, să citească SF și să lucreze la diverse proiecte de bricolaj.

Saurabh Trikande este Senior Product Manager pentru Amazon SageMaker Inference. Este pasionat de lucrul cu clienții și este motivat de obiectivul democratizării învățării automate. El se concentrează pe provocările de bază legate de implementarea de aplicații ML complexe, modele ML multi-locatari, optimizări ale costurilor și de a face implementarea modelelor de învățare profundă mai accesibilă. În timpul liber, lui Saurabh îi place să facă drumeții, să învețe despre tehnologii inovatoare, să urmeze TechCrunch și să petreacă timpul cu familia sa.

• Distribuție de conținut bazat pe SEO și PR. Amplifică-te astăzi.
• Platoblockchain. Web3 Metaverse Intelligence. Cunoștințe amplificate. Accesați Aici.
• Sursa: https://aws.amazon.com/blogs/machine-learning/achieve-high-performance-at-scale-for-model-serving-using-amazon-sagemaker-multi-model-endpoints-with-gpu/