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.
Utilizare caz | Nume model | Spațiu pe disk | Numărul de parametri |
CV | resnet50 |
100Mb | 25M |
CV | convnext_base |
352Mb | 88M |
CV | vit_large_patch16_224 |
1.2Gb | 304M |
PNL | bert-base-uncased |
436Mb | 109M |
PNL | roberta-large |
1.3Gb | 335M |
Următorul tabel listează instanțele GPU testate.
Tip de instanță | Tipul GPU | Număr de GPU-uri | Memorie GPU (GiB) |
ml.g4dn.2xlarge | GPU-uri NVIDIA T4 | 1 | 16 |
ml.g5.2xmare | GPU NVIDIA A10G Tensor Core | 1 | 24 |
ml.p3.2xmare | GPU NVIDIA® V100 Tensor Core | 1 | 16 |
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:
- Preluați un model pre-antrenat de la un hub de model.
- 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).
- Implementați un MME SageMaker pe o instanță GPU.
- Determinați numărul maxim de modele care pot fi încărcate în memoria GPU într-un prag specificat.
- Utilizați Cadrul de testare a încărcării Locust pentru a simula traficul care invocă aleatoriu modele încărcate pe instanță.
- Colectați date și analizați rezultatele.
- 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.
Caz de utilizare ML | Arhitectură | Nume model | Tip de instanță | Cadru | Max modele încărcate | Diferență (%) | Mediu Diferență (%) |
CV | CNN | Resnet50 |
ml.g4dn.2xlarge | PyTorch | 46 | -50% | -50% |
TensorRT | 23 | ||||||
ml.g5.2xmare | PyTorch | 70 | -51% | ||||
TensorRT | 34 | ||||||
ml.p3.2xmare | PyTorch | 49 | -51% | ||||
TensorRT | 24 | ||||||
Convnext_base |
ml.g4dn.2xlarge | PyTorch | 33 | -50% | -70% | ||
TensorRT | 10 | ||||||
ml.g5.2xmare | PyTorch | 50 | -70% | ||||
TensorRT | 16 | ||||||
ml.p3.2xmare | PyTorch | 35 | -69% | ||||
TensorRT | 11 | ||||||
Transformator | vit_large_patch16_224 |
ml.g4dn.2xlarge | PyTorch | 10 | -30% | -20% | |
TensorRT | 7 | ||||||
ml.g5.2xmare | PyTorch | 15 | -13% | ||||
TensorRT | 13 | ||||||
ml.p3.2xmare | PyTorch | 11 | -18% | ||||
TensorRT | 9 | ||||||
PNL | Roberta-large |
ml.g4dn.2xlarge | PyTorch | 9 | -11% | -3% | |
TensorRT | 8 | ||||||
ml.g5.2xmare | PyTorch | 13 | 0% | ||||
TensorRT | 13 | ||||||
ml.p3.2xmare | PyTorch | 9 | 0% | ||||
TensorRT | 9 | ||||||
Bert-base-uncased |
ml.g4dn.2xlarge | PyTorch | 26 | 62% | 40% | ||
TensorRT | 42 | ||||||
ml.g5.2xmare | PyTorch | 39 | 28% | ||||
TensorRT | 50 | ||||||
ml.p3.2xmare | PyTorch | 28 | 29% | ||||
TensorRT | 36 |
Următoarele tabele listează rezultatele noastre de referință complete pentru toate valorile din toate cele trei tipuri de instanțe GPU.
ml.g4dn.2xlarge |
||||||||||||
Utilizare caz | Arhitectură | Nume model | Numărul de parametri | Cadru | Max modele încărcate | Diferență (%) | Latența (ms) | Diferență (%) | Debit (qps) | Diferență (%) | Numărul maxim de utilizatori concurenți | Diferență (%) |
CV | CNN | resnet50 |
25M | PyTorch | 46 | -50% | 164 | -32% | 120 | 18% | 180 | NA |
TensorRT | 23 | . | 111 | . | 142 | . | 180 | . | ||||
convnext_base |
88M | PyTorch | 33 | -70% | 154 | -22% | 64 | 102% | 140 | 14% | ||
TensorRT | 10 | . | 120 | . | 129 | . | 160 | . | ||||
Transformator | vit_large_patch16_224 |
304M | PyTorch | 10 | -30% | 425 | -69% | 26 | 304% | 140 | 14% | |
TensorRT | 7 | . | 131 | . | 105 | . | 160 | . | ||||
PNL | bert-base-uncased |
109M | PyTorch | 26 | 62% | 70 | -39% | 105 | 142% | 140 | 29% | |
TensorRT | 42 | . | 43 | . | 254 | . | 180 | . | ||||
roberta-large |
335M | PyTorch | 9 | -11% | 187 | -70% | 33 | 406% | 120 | 50% | ||
TensorRT | 8 | . | 56 | . | 167 | . | 180 | . |
ml.g5.2xmare |
||||||||||||
Utilizare caz | Arhitectură | Nume model | Numărul de parametri | Cadru | Max modele încărcate | Diferență (%) | Latența (ms) | Diferență (%) | Debit (qps) | Diferență (%) | Numărul maxim de utilizatori concurenți | Diferență (%) |
CV | CNN | resnet50 |
25M | PyTorch | 70 | -51% | 159 | -31% | 146 | 14% | 180 | 11% |
TensorRT | 34 | . | 110 | . | 166 | . | 200 | . | ||||
convnext_base |
88M | PyTorch | 50 | -68% | 149 | -23% | 134 | 13% | 180 | 0% | ||
TensorRT | 16 | . | 115 | . | 152 | . | 180 | . | ||||
Transformator | vit_large_patch16_224 |
304M | PyTorch | 15 | -13% | 149 | -22% | 105 | 35% | 160 | 25% | |
TensorRT | 13 | . | 116 | . | 142 | . | 200 | . | ||||
PNL | bert-base-uncased |
109M | PyTorch | 39 | 28% | 65 | -29% | 183 | 38% | 180 | 11% | |
TensorRT | 50 | . | 46 | . | 253 | . | 200 | . | ||||
roberta-large |
335M | PyTorch | 13 | 0% | 97 | -38% | 121 | 46% | 140 | 14% | ||
TensorRT | 13 | . | 60 | . | 177 | . | 160 | . |
ml.p3.2xmare |
||||||||||||
Utilizare caz | Arhitectură | Nume model | Numărul de parametri | Cadru | Max modele încărcate | Diferență (%) | Latența (ms) | Diferență (%) | Debit (qps) | Diferență (%) | Numărul maxim de utilizatori concurenți | Diferență (%) |
CV | CNN | resnet50 |
25M | PyTorch | 49 | -51% | 197 | -41% | 94 | 18% | 160 | -12% |
TensorRT | 24 | . | 117 | . | 111 | . | 140 | . | ||||
convnext_base |
88M | PyTorch | 35 | -69% | 178 | -23% | 89 | 11% | 140 | 14% | ||
TensorRT | 11 | . 137 | 137 | . | 99 | . | 160 | . | ||||
Transformator | vit_large_patch16_224 |
304M | PyTorch | 11 | -18% | 186 | -28% | 83 | 23% | 140 | 29% | |
TensorRT | 9 | . | 134 | . | 102 | . | 180 | . | ||||
PNL | bert-base-uncased |
109M | PyTorch | 28 | 29% | 77 | -40% | 133 | 59% | 140 | 43% | |
TensorRT | 36 | . | 46 | . | 212 | . | 200 | . | ||||
roberta-large |
335M | PyTorch | 9 | 0% | 108 | -44% | 88 | 60% | 160 | 0% | ||
TensorRT | 9 | . | 61 | . | 141 | . | 160 | . |
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ță.
Utilizare caz | Arhitectură | Nume model | Numărul de parametri | Cadru | Tip de instanță | Max modele încărcate | Diferență (%) | Latența (ms) | Diferență (%) | Debit (qps) | Diferență (%) | Numărul maxim de utilizatori concurenți |
CV | CNN | resnet50 |
25M | PyTorch | ml.g5.2xmare | 70 | . | 159 | . | 146 | . | 180 |
. | . | . | . | . | ml.p3.2xmare | 49 | . | 197 | . | 94 | . | 160 |
. | . | . | . | . | ml.g4dn.2xlarge | 46 | . | 164 | . | 120 | . | 180 |
CV | CN | resnet50 |
25M | TensorRT | ml.g5.2xmare | 34 | -51% | 110 | -31% | 166 | 14% | 200 |
. | . | . | . | . | ml.p3.2xmare | 24 | -51% | 117 | -41% | 111 | 18% | 200 |
. | . | . | . | . | ml.g4dn.2xlarge | 23 | -50% | 111 | -32% | 142 | 18% | 180 |
PNL | Transformator | bert-base-uncased |
109M | pitorcă | ml.g5.2xmare | 39 | . | 65 | . | 183 | . | 180 |
. | . | . | . | . | ml.p3.2xmare | 28 | . | 77 | . | 133 | . | 140 |
. | . | . | . | . | ml.g4dn.2xlarge | 26 | . | 70 | . | 105 | . | 140 |
PNL | Transformator | bert-base-uncased |
109M | TensorRT | ml.g5.2xmare | 50 | 28% | 46 | -29% | 253 | 38% | 200 |
. | . | . | . | . | ml.p3.2xmare | 36 | 29% | 46 | -40% | 212 | 59% | 200 |
. | . | . | . | . | ml.g4dn.2xlarge | 42 | 62% | 43 | -39% | 254 | 142% | 180 |
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:
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/
- 10
- 100
- 11
- 2022
- 7
- a
- capacitate
- Despre Noi
- accelerat
- accesibil
- în consecință
- precis
- Obține
- peste
- adăugat
- plus
- Suplimentar
- În plus,
- adoptată
- Promovare
- După
- AI
- AI / ML
- algoritmi
- TOATE
- permite
- Cu toate ca
- Amazon
- Amazon SageMaker
- Amazon Web Services
- sumă
- analiză
- analiza
- și
- O alta
- aplicatii
- abordare
- aproximativ
- arhitectură
- Bunuri
- Auto
- în mod automat
- in medie
- AWS
- bar
- bazat
- deoarece
- înainte
- în spatele
- fiind
- Crede
- Benchmark
- comparativ
- analiza comparativă
- beneficia
- CEL MAI BUN
- Dincolo de
- mai mare
- miliarde
- bord
- a stimula
- De jos
- tampon
- construi
- povară
- caz
- cazuri
- provocări
- Caracteristici
- taxe
- Diagramă
- Grafice
- clar
- client
- CNN
- cod
- combinaţii
- comparație
- compararea
- comparație
- Completă
- complex
- complexitate
- Compus
- Calcula
- calculator
- Computer Vision
- concluzie
- concurent
- Configuraţie
- consistent
- consuma
- consumate
- consum
- Recipient
- context
- continua
- Nucleu
- A costat
- cost-eficiente
- Covers
- Trece
- Curent
- În prezent
- personalizat
- clienţii care
- de date
- puncte de date
- decizie
- adânc
- învățare profundă
- Mai adânc
- implicite
- livra
- Cerere
- democratizarea
- demonstra
- În funcție
- implementa
- Implementarea
- desfășurarea
- implementări
- Amenajări
- dorit
- În ciuda
- detaliu
- detalii
- Determina
- determinat
- Dezvoltator
- dispozitiv
- diferit
- diy
- documentaţie
- Descarca
- dramatic
- dinamic
- fiecare
- Mai devreme
- mai ușor
- oricare
- Punct final
- Inginerie
- Afacere
- Întreg
- eroare
- Chiar
- exemplu
- exemple
- depăși
- de aşteptat
- scump
- Experiențe
- extinde
- extrage
- Față
- factori
- A eșuat
- familie
- Modă
- realizabil
- cifre
- Fişiere
- financiar
- Găsi
- First
- Concentra
- concentrat
- se concentrează
- următor
- Cadru
- cadre
- din
- Complet
- mai mult
- în general
- generată
- generează
- generativ
- AI generativă
- obține
- oferă
- scop
- merge
- GPU
- unități de procesare grafică
- grafice
- În creştere
- ghida
- mână
- Piese metalice
- ajutor
- ajutor
- ajută
- Înalt
- superior
- gazdă
- găzduit
- găzduire
- casă
- Cum
- Cum Pentru a
- Totuși
- HTML
- HTTPS
- Butuc
- sute
- ideal
- imagine
- Impactul
- afectate
- îmbunătățit
- îmbunătățire
- in
- include
- Inclusiv
- Crește
- a crescut
- Creșteri
- crescând
- individ
- industrii
- industrie
- influență
- informat
- Infrastructură
- inițială
- inovatoare
- tehnologii inovatoare
- intrare
- perspective
- instanță
- asigurare
- scop
- interes
- introdus
- Introducere
- invocă
- IT
- aderarea
- Cheie
- limbă
- mare
- mai mare
- cea mai mare
- Latență
- lider
- Conducere
- învăţare
- lăsând
- Lungime
- Limitele
- Linie
- Listă
- liste
- încărca
- încărcare
- mai lung
- Uite
- Jos
- maşină
- masina de învățare
- Principal
- face
- Efectuarea
- manager
- gestionează
- de conducere
- multe
- marca
- Marketing
- Marketing și publicitate
- max
- Maximaliza
- maxim
- măsura
- măsuri
- Memorie
- menționat
- Metode
- Metrici
- minor
- mixt
- ML
- model
- Modele
- mai mult
- cele mai multe
- Cel mai popular
- motivat
- MS
- multiplu
- nume
- Natural
- Procesarea limbajului natural
- Nevoie
- negativ
- negativ
- reţea
- rețele neuronale
- Nou
- nlp
- caiet
- noiembrie
- număr
- numere
- ONE
- de operare
- operațional
- optimizare
- optim
- Opțiune
- original
- Altele
- exterior
- global
- propriu
- Pace
- parametru
- parametrii
- pasionat
- Model
- modele
- la sută
- Efectua
- performanță
- efectuarea
- perioadă
- alege
- Plato
- Informații despre date Platon
- PlatoData
- Punct
- puncte
- Popular
- posibil
- Post
- în prealabil
- primar
- anterior
- proces
- prelucrare
- Produs
- manager de produs
- Proiecte
- adecvat
- furniza
- prevăzut
- furnizează
- pune
- pirtorh
- cantitate
- Rampă
- rampă
- aleator
- gamă
- rapid
- rată
- ajunge
- atins
- ajungând
- Citind
- rezonabil
- motive
- recomanda
- recomandat
- inregistrata
- reduce
- Redus
- reflecta
- reflectat
- ceea ce privește
- legate de
- încredere
- minte
- repeta
- repetat
- solicita
- cereri de
- Cerinţe
- Necesită
- Resurse
- răspuns
- responsabil
- rezultând
- REZULTATE
- Alerga
- funcţionare
- sagemaker
- SageMaker Inference
- acelaşi
- scalabil
- Scară
- scalare
- Sci-Fi
- Al doilea
- secunde
- Secțiune
- senior
- Secvenţă
- Servicii
- servire
- set
- configurarea
- câteva
- Modela
- forme
- Distribuie
- comun
- partajarea
- să
- Arăta
- indicat
- Emisiuni
- parte
- Semnal
- semnificativ
- asemănător
- Simon
- simplu
- singur
- Mărimea
- dimensiuni
- mic
- mai mici
- soluţie
- soluţii
- unele
- Spaţiu
- specialist
- specificată
- Cheltuire
- Stabilitate
- început
- au stat
- constant
- Pas
- paşi
- Încă
- depozitare
- strategii
- puternic
- de succes
- astfel de
- rezuma
- REZUMAT
- superior
- a sustine
- Suportat
- Sprijină
- tabel
- Lua
- luare
- TechCrunch
- Tehnologii
- Tehnologia
- șablon
- şabloane
- termeni
- test
- Testarea
- lor
- prin urmare
- gândit
- conducerea gândirii
- trei
- prag
- Prin
- debit
- timp
- la
- împreună
- Unelte
- top
- Total
- trafic
- Traveling
- proces
- De două ori
- Tipuri
- tipic
- Statele Unite ale Americii
- utilizare
- carcasa de utilizare
- Utilizator
- utilizatorii
- valoare
- diverse
- Virginia
- viziune
- Mandat
- web
- servicii web
- Ce
- dacă
- care
- în timp ce
- întreg
- larg
- Gamă largă
- voi
- în
- fără
- Apartamente
- muncitorii
- de lucru
- ar
- ani
- Randament
- Tu
- Ta
- zephyrnet