Dosezite visoko zmogljivost v velikem obsegu za streženje modelov z uporabo večmodelnih končnih točk Amazon SageMaker z GPE

Amazon SageMaker končne točke več modelov (MME) zagotavljajo razširljiv in stroškovno učinkovit način za uvajanje velikega števila modelov strojnega učenja (ML). Omogoča vam uvedbo več modelov ML v enem strežnem vsebniku za eno končno točko. Od tam SageMaker upravlja nalaganje in razkladanje modelov ter skaliranje virov v vašem imenu glede na vaše vzorce prometa. Koristili boste od skupne rabe in ponovne uporabe virov gostovanja ter zmanjšanega operativnega bremena upravljanja velike količine modelov.

Novembra 2022, MME je dodal podporo za GPUs, ki vam omogoča izvajanje več modelov na eni napravi GPE in skaliranje primerkov GPE za eno končno točko. To zadovoljuje veliko povpraševanje MME po modelih globokih nevronskih mrež (DNN), ki imajo koristi od pospešenega računanja z GPE. Ti vključujejo računalniški vid (CV), obdelavo naravnega jezika (NLP) in generativne modele AI. Razlogi za povpraševanje vključujejo naslednje:

• Modeli DNN so običajno veliki in zapleteni ter še naprej hitro rastejo. Če za primer vzamemo modele NLP, mnogi od njih presegajo milijarde parametrov, kar zahteva, da grafični procesorji izpolnjujejo zahteve po nizki zakasnitvi in ​​visoki prepustnosti.
• Opazili smo povečano potrebo po prilagajanju teh modelov za zagotavljanje hiperpersonaliziranih izkušenj posameznim uporabnikom. Ker se količina teh modelov povečuje, obstaja potreba po lažji rešitvi za uvajanje in delovanje številnih modelov v velikem obsegu.
• Primerki GPE so dragi in te primerke želite čim bolj ponovno uporabiti, da povečate izkoriščenost GPE in zmanjšate stroške delovanja.

Čeprav vsi ti razlogi kažejo na MME z GPU kot idealno možnost za modele DNN, je priporočljivo izvesti obremenitveno testiranje, da bi našli pravo konfiguracijo končne točke, ki izpolnjuje vaše zahteve primera uporabe. Številni dejavniki lahko vplivajo na rezultate testiranja obremenitve, kot so vrsta primerka, število primerkov, velikost modela in arhitektura modela. Poleg tega lahko testiranje obremenitve pomaga pri vodenju strategij samodejnega skaliranja z uporabo pravih meritev namesto ponavljajočih se metod poskusov in napak.

Zaradi teh razlogov smo pripravili to objavo, da vam pomagamo izvesti pravilno obremenitveno testiranje na MME z GPE in poiskati najboljšo konfiguracijo za vaš primer uporabe ML. Delimo naše rezultate testiranja obremenitve za nekatere najbolj priljubljene modele DNN v NLP in CV, ki gostujejo z uporabo MME na različnih vrstah primerkov. Povzemamo vpoglede in zaključke iz naših rezultatov testiranja, da vam pomagamo sprejeti informirano odločitev o konfiguraciji lastnih uvedb. Ob tem delimo tudi naš priporočeni pristop k izvajanju obremenitvenega testiranja za MME na GPU. Priporočena orodja in tehnika določajo optimalno število modelov, ki jih je mogoče naložiti na vrsto primerka, in vam pomagajo doseči najboljše razmerje med ceno in zmogljivostjo.

Pregled rešitev

Za uvod v MME in MME z GPE glejte Ustvari končno točko več modelov in Zaženite več modelov globokega učenja na GPE s končnimi točkami več modelov Amazon SageMaker. Za kontekst testiranja obremenitve v tej objavi lahko našo vzorčno kodo prenesete iz GitHub repo za reprodukcijo rezultatov ali uporabo kot predlogo za primerjavo lastnih modelov. V skladišču sta na voljo dva zvezka: eden za modele CV za testiranje obremenitve in drugi za NLP. Več modelov različnih velikosti in arhitektur je bilo primerjanih na različnih vrstah primerkov GPU: ml.g4dn.2xlarge, ml.g5.2xlarge in ml.p3.2xlarge. To bi moralo zagotoviti razumen presek zmogljivosti v naslednjih metrikah za vsak primerek in vrsto modela:

• Največje število modelov, ki jih je mogoče naložiti v pomnilnik GPE
• Zakasnitev odgovora od konca do konca, opazovana na strani odjemalca za vsako sklepno poizvedbo
• Največja prepustnost poizvedb na sekundo, ki jo lahko končna točka obdela brez napak
• Največ trenutnih uporabnikov na primerke, preden se opazi neuspela zahteva

Naslednja tabela navaja testirane modele.

V spodnji tabeli so navedeni preizkušeni primerki GPE.

Kot smo že omenili, je primer kode se lahko prilagodi drugim modelom in vrstam primerkov.

Upoštevajte, da MME trenutno podpirajo samo posamezne primerke GPE. Za seznam podprtih vrst primerkov glejte Podprti algoritmi, ogrodja in primerki.

Postopek primerjalne analize je sestavljen iz naslednjih korakov:

1. Pridobite vnaprej usposobljen model iz središča modelov.
2. Pripravite artefakt modela za serviranje na SageMaker MME (glejte Zaženite več modelov globokega učenja na GPE s končnimi točkami več modelov Amazon SageMaker za več podrobnosti).
3. Razmestite SageMaker MME na primer GPE.
4. Določite največje število modelov, ki jih je mogoče naložiti v pomnilnik GPE znotraj določenega praga.
5. Uporabite Locust Load Testing Framework za simulacijo prometa, ki naključno prikliče modele, naložene v instanco.
6. Zberite podatke in analizirajte rezultate.
7. Po želji ponovite korake 2–6 po prevajanju modela v TensorRT.

Koraka 4 in 5 zahtevata globlji pogled. Modeli znotraj SageMaker GPU MME se naložijo v pomnilnik na dinamičen način. Zato v 4. koraku naložimo artefakt začetnega modela v Preprosta storitev shranjevanja Amazon (Amazon S3) in pokličite model, da ga naložite v pomnilnik. Po začetnem priklicu izmerimo količino porabljenega pomnilnika GPE, naredimo kopijo začetnega modela, prikličemo kopijo modela, da jo naložimo v pomnilnik, in ponovno izmerimo skupno količino porabljenega pomnilnika GPE. Ta postopek se ponavlja, dokler ni dosežen določen odstotni prag uporabe pomnilnika GPE. Za primerjalno vrednost smo prag nastavili na 90 %, da zagotovimo primeren pomnilniški medpomnilnik za sklepanje na večje serije ali pustimo nekaj prostora za nalaganje drugih manj pogosto uporabljenih modelov.

Simulacija uporabniškega prometa

Ko določimo število modelov, lahko izvedemo obremenitveni test z uporabo Locust Load Testing Framework. Obremenitveni test simulira uporabniške zahteve za naključne modele in samodejno meri metrike, kot sta zakasnitev odziva in prepustnost.

Locust podpira oblike preizkusa obremenitve po meri, ki vam omogočajo definiranje vzorcev prometa po meri. Oblika, ki je bila uporabljena v tem primerjalnem preizkusu, je prikazana v naslednji tabeli. V prvih 30 sekundah se končna točka ogreje z 10 sočasnimi uporabniki. Po 30 sekundah se ustvarijo novi uporabniki s hitrostjo dveh na sekundo, pri čemer dosežejo 20 sočasnih uporabnikov pri 40-sekundni oznaki. Končna točka se nato enakomerno primerja z 20 sočasnimi uporabniki do 60-sekundne oznake, ko Locust ponovno začne povečevati uporabnike z dvema uporabnikoma na sekundo do 40 sočasnih uporabnikov. Ta vzorec stopnjevanja in enakomernega testiranja se ponavlja, dokler se končna točka ne dvigne na 200 sočasnih uporabnikov. Glede na vaš primer uporabe boste morda želeli prilagoditi obliko preizkusa obremenitve v locust_benchmark_sm.py, da bo natančneje odražala vaše pričakovane vzorce prometa. Na primer, če nameravate gostiti večje jezikovne modele, preizkus obremenitve z 200 sočasnimi uporabniki morda ne bo izvedljiv za model, ki gostuje na enem primerku, zato boste morda želeli zmanjšati število uporabnikov ali povečati število primerkov. Morda boste želeli tudi podaljšati trajanje preskusa obremenitve, da boste natančneje izmerili stabilnost končne točke v daljšem časovnem obdobju.

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

Upoštevajte, da smo končno točko primerjali samo s homogenimi modeli, ki se vsi izvajajo na doslednih strežnih osnovah z uporabo PyTorcha ali TensorRT. To je zato, ker so MME najprimernejši za gostovanje številnih modelov s podobnimi lastnostmi, kot sta poraba pomnilnika in odzivni čas. Primerjalne predloge, ki so na voljo v GitHub repo še vedno lahko uporabimo za ugotavljanje, ali bi serviranje heterogenih modelov na MME prineslo želeno zmogljivost in stabilnost.

Primerjalni rezultati za modele CV

Uporabite prenosni računalnik cv-benchmark.ipynb za izvajanje testiranja obremenitve za modele računalniškega vida. Vnaprej usposobljeno ime modela in parametre tipa primerka lahko prilagodite obremenitvenemu testiranju zmogljivosti na različnih kombinacijah modela in tipa primerka. Namenoma smo testirali tri modele CV v različnih velikostih od najmanjšega do največjega: resnet50 (25 milijonov), convnext_base (88M) in vit_large_patch16_224 (304M). Morda se boste morali prilagoditi kodi, če izberete model zunaj tega seznama. poleg tega prenosnik privzeto nastavi obliko vhodne slike na slikovni tenzor 224x224x3. Ne pozabite ustrezno prilagoditi oblike vnosa, če morate primerjati modele, ki imajo sliko drugačne velikosti.

Po pregledu celotnega zvezka boste dobili več vizualizacij analize uspešnosti. Prva dva podrobno opisujeta zmogljivost modela glede na povečanje sočasnih uporabnikov. Naslednje slike so primeri vizualizacij, ustvarjenih za ResNet50 model, ki deluje na ml.g4dn.2xlarge, primerjava PyTorch (levo) in TensorRT (desno). Zgornji črtni grafi prikazujejo zakasnitev modela in prepustnost na osi y z naraščajočim številom sočasnih delavcev strank, ki se odražajo na osi x. Spodnji stolpčni grafikoni prikazujejo število uspešnih in neuspelih zahtev.

Če pogledamo vse modele računalniškega vida, ki smo jih preizkusili, smo opazili naslednje:

• Zakasnitev (v milisekundah) je višja, prepustnost (zahteve na sekundo) pa manjša pri večjih modelih (resnet50 > convnext_base > vit_large_patch16_224).
• Povečanje zakasnitve je sorazmerno s številom uporabnikov, saj je več zahtev v čakalni vrsti na strežniku sklepanja.
• Veliki modeli porabijo več računalniških virov in lahko dosežejo svoje največje prepustne meje z manj uporabniki kot manjši modeli. To opazimo pri vit_large_patch16_224 model, ki je zabeležil prvo neuspešno zahtevo pri 140 sočasnih uporabnikih. Ker je bil bistveno večji od drugih dveh testiranih modelov, je imel največ vseh neuspešnih zahtev tudi pri višji sočasnosti. To je jasen znak, da bi morala končna točka preseči eno samo instanco, če je namen podpirati več kot 140 sočasnih uporabnikov.

Na koncu prenosnika dobite tudi povzetek primerjave modelov PyTorch in TensorRT za vsako od štirih ključnih metrik. Iz našega primerjalnega testiranja je bilo pri vseh modelih CV po kompilaciji TensorRT izboljšana zmogljivost modela. Ob našem ResNet50 model kot primer, se je zakasnitev zmanjšala za 32 %, medtem ko se je pretok povečal za 18 %. Čeprav je največje število sočasnih uporabnikov ostalo enako za ResNet50, sta pri drugih dveh modelih opazili 14-odstotno izboljšanje števila sočasnih uporabnikov, ki jih lahko podpirata. Izboljšanje zmogljivosti TensorRT pa je prišlo na račun večje uporabe pomnilnika, kar je povzročilo manj modelov, ki so jih naložili MME. Vpliv je večji pri modelih, ki uporabljajo konvolucijsko nevronsko mrežo (CNN). Dejansko je naš model ResNet50 porabil približno dvakrat več pomnilnika GPE, ki je prehajal iz PyTorcha v TensorRT, kar je povzročilo 50 % manj naloženih modelov (46 proti 23). To vedenje podrobneje diagnosticiramo v naslednjem razdelku.

Primerjalni rezultati za modele NLP

Za modele NLP uporabite prenosni računalnik nlp-benchmark.ipynb za izvajanje obremenitvenega testa. Nastavitev prenosnega računalnika bi morala biti zelo podobna. Preizkusili smo dva modela NLP: bert-base-uncased (109M) in roberta-large (335M). Vnaprej usposobljeni model in tokenizer se preneseta iz središča Hugging Face, testni tovor pa se ustvari iz tokenizerja z uporabo vzorčnega niza. Največja dolžina zaporedja je privzeto 128. Če morate preizkusiti daljše nize, ne pozabite prilagoditi tega parametra. Tekanje po zvezku NLP ustvari enak nabor vizualizacij: Pytorch (levo) proti TensorRT (desno).

Iz teh smo opazili še večjo učinkovitost TensorRT za modele NLP. Jemanje roberta-large modelu na primerku ml.g4dn.2xlarge se je na primer zakasnitev sklepanja močno zmanjšala s 180 milisekund na 56 milisekund (70-odstotno izboljšanje), medtem ko se je prepustnost izboljšala za 406 % s 33 zahtev na sekundo na 167. Poleg tega je največje število sočasnih število uporabnikov se je povečalo za 50 %; neuspelih zahtev nismo opazili, dokler nismo dosegli 180 sočasnih uporabnikov v primerjavi s 120 za prvotni model PyTorch. Kar zadeva izkoriščenost pomnilnika, smo videli en model manj, naložen za TensorRT (z devetih na osem modelov). Vendar pa je negativni vpliv veliko manjši v primerjavi s tistim, kar smo opazili pri modelih, ki temeljijo na CNN.

Analiza izkoriščenosti pomnilnika

Naslednja tabela prikazuje celotno analizo vpliva uporabe pomnilnika, ki poteka od PyTorcha do TensorRT. Prej smo omenili, da imajo modeli, ki temeljijo na CNN, vpliv bolj negativen. The ResNet50 model je imel več kot 50-odstotno zmanjšanje števila modelov, naloženih v vseh treh vrstah primerkov GPE. Convnext_base imel še večje zmanjšanje na približno 70 % na vseh področjih. Po drugi strani pa je vpliv na modele transformatorjev majhen ali mešan. vit_large_patch16_224 in roberta-large imela povprečno zmanjšanje za približno 20 % oziroma 3 %, medtem ko bert-base-uncased imel približno 40-odstotno izboljšanje.

Če pogledamo vse podatkovne točke kot celoto v zvezi z vrhunsko zmogljivostjo v zakasnitvi, prepustnosti in zanesljivosti ter manjšim vplivom na največje število naloženih modelov, priporočamo model TensorRT za arhitekture modelov, ki temeljijo na transformatorjih. Za CNN menimo, da je potrebna nadaljnja analiza stroškovne uspešnosti, da zagotovimo, da bodo prednosti zmogljivosti odtehtale stroške dodatne infrastrukture gostovanja.

V naslednjih tabelah so navedeni naši celotni primerjalni rezultati za vse meritve v vseh treh vrstah primerkov GPU.

Naslednja tabela povzema rezultate za vse vrste primerkov. Primerek ml.g5.2xlarge zagotavlja najboljšo zmogljivost, medtem ko je primerek ml.p3.2xlarge na splošno slabši, čeprav je najdražji od treh. Primerki g5 in g4dn prikazujejo najboljšo vrednost za delovne obremenitve sklepanja.

Čiščenje

Ko končate preizkus obremenitve, počistite ustvarjene vire, da se izognete dodatnim stroškom. Glavni viri so končne točke SageMaker in datoteke artefaktov modela v Amazonu S3. Da bi vam olajšali delo, imajo datoteke v zvezku to kodo za čiščenje, ki vam pomaga pri brisanju:

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

zaključek

V tej objavi smo delili rezultate naših testov in analize za različne modele globokih nevronskih mrež, ki se izvajajo na večmodelnih končnih točkah SageMaker z GPE. Rezultati in vpogledi, ki smo jih delili, bi morali zagotoviti razumen presek uspešnosti v različnih meritvah in vrstah primerkov. Med tem procesom smo predstavili tudi naš priporočeni pristop za izvajanje primerjalnega testiranja za SageMaker MME z GPE. Orodja in vzorčna koda, ki smo jih zagotovili, vam lahko pomagajo pri hitrem začetku primerjalnega testiranja in sprejemanju bolj ozaveščene odločitve o tem, kako stroškovno učinkovito gostiti na stotine modelov DNN na pospešeni računalniški strojni opremi. Če želite začeti s primerjalno analizo lastnih modelov s podporo MME za GPE, glejte Podprti algoritmi, ogrodja in primerki in GitHub repo za dodatne primere in dokumentacijo.

O avtorjih

James Wu je višji specialist za AI/ML rešitve pri AWS. pomoč strankam pri načrtovanju in izdelavi rešitev AI/ML. Jamesovo delo pokriva širok spekter primerov uporabe ML, s primarnim zanimanjem za računalniški vid, globoko učenje in razširjanje ML v podjetju. Preden se je pridružil podjetju AWS, je bil James več kot 10 let arhitekt, razvijalec in tehnološki vodja, od tega 6 let v inženiringu in 4 leta v trženju in oglaševalski industriji.

Vikram Elango je specialist za rešitve AI/ML pri Amazon Web Services s sedežem v Virginiji, ZDA. Vikram pomaga strankam v finančni in zavarovalniški industriji z oblikovanjem, miselnim vodstvom za izdelavo in uvajanje aplikacij strojnega učenja v velikem obsegu. Trenutno je osredotočen na obdelavo naravnega jezika, odgovorno umetno inteligenco, optimizacijo sklepanja in skaliranje ML v podjetju. V prostem času uživa v potovanjih, pohodništvu, kuhanju in kampiranju z družino.

Simon Zamarin je arhitekt rešitev AI / ML, katerega glavni poudarek je pomagati strankam izvleči vrednost iz njihovih podatkovnih sredstev. V prostem času Simon rad preživlja čas z družino, bere znanstvene fantastike in dela na različnih hišnih projektih.

Saurabh Trikande je višji produktni vodja za Amazon SageMaker Inference. Navdušen je nad delom s strankami in ga motivira cilj demokratizacije strojnega učenja. Osredotoča se na ključne izzive, povezane z uvajanjem kompleksnih aplikacij ML, modelov ML z več najemniki, optimizacijo stroškov in zagotavljanjem dostopnosti uvajanja modelov globokega učenja. V prostem času Saurabh uživa v pohodništvu, spoznavanju inovativnih tehnologij, spremlja TechCrunch in preživlja čas s svojo družino.

• Distribucija vsebine in PR s pomočjo SEO. Okrepite se še danes.
• Platoblockchain. Web3 Metaverse Intelligence. Razširjeno znanje. Dostopite tukaj.
• vir: https://aws.amazon.com/blogs/machine-learning/achieve-high-performance-at-scale-for-model-serving-using-amazon-sagemaker-multi-model-endpoints-with-gpu/