Zaženite in optimizirajte sklepanje več modelov s končnimi točkami več modelov Amazon SageMaker

Amazon SageMaker multi-model endpoint (MME) vam omogoča stroškovno učinkovito uvajanje in gostovanje več modelov v eni končni točki in nato vodoravno prilagajanje končne točke, da dosežete obseg. Kot je prikazano na naslednji sliki, je to učinkovita tehnika za implementacijo večnajemniških modelov znotraj vaše infrastrukture strojnega učenja (ML). Videli smo, da podjetja programske opreme kot storitve (SaaS) uporabljajo to funkcijo za uporabo hiperpersonalizacije v svojih modelih ML in hkrati dosegajo nižje stroške.

Za podroben pregled delovanja MME si oglejte videoposnetek AWS Summit Povečanje ML na naslednjo raven: gostovanje na tisoče modelov na SageMaker. Če želite izvedeti več o hiperpersonaliziranih primerih uporabe z več najemniki, ki jih omogoča MME, glejte Kako razširiti sklepanje strojnega učenja za primere uporabe SaaS z več najemniki.

V nadaljevanju te objave se poglobimo v tehnično arhitekturo SageMaker MME in delimo najboljše prakse za optimizacijo končnih točk z več modeli.

Najbolj primerni primeri uporabe za MME

Večmodelne končne točke SageMaker so zelo primerne za gostovanje velikega števila modelov, ki jih lahko postrežete prek skupnega strežnega vsebnika in vam ni treba dostopati do vseh modelov hkrati. Odvisno od velikosti pomnilnika instance končne točke se lahko model občasno razloži iz pomnilnika v korist nalaganja novega modela, da se poveča učinkovita uporaba pomnilnika, zato mora biti vaša aplikacija tolerantna na občasne skoke zakasnitev pri nenaloženih modelih.

MME je zasnovan tudi za sogostovanje modelov, ki uporabljajo isti okvir ML, ker uporabljajo skupni vsebnik za nalaganje več modelov. Če imate torej v svoji floti modelov mešanico ogrodij ML (kot sta PyTorch in TensorFlow), so namenske končne točke SageMaker ali gostovanje z več vsebniki boljša izbira.

Končno je MME primeren za aplikacije, ki lahko dopuščajo občasno kazen zakasnitve hladnega zagona, ker se modeli naložijo ob prvem priklicu in se lahko redko uporabljeni modeli razložijo iz pomnilnika v korist nalaganja novih modelov. Če imate torej kombinacijo modelov, do katerih dostopate pogosto in redko, lahko končna točka z več modeli učinkovito služi temu prometu z manj viri in višjimi prihranki stroškov.

Videli smo tudi nekaj scenarijev, v katerih stranke uvedejo gručo MME z dovolj agregatne pomnilniške zmogljivosti, da ustreza vsem njihovim modelom, s čimer se popolnoma izognejo razbremenitvi modela, a še vedno dosegajo prihranke pri stroških zaradi skupne infrastrukture sklepanja.

Model posode za serviranje

Ko uporabljate komplet orodij SageMaker Inference Toolkit ali vnaprej izdelan vsebnik za streženje modela SageMaker, ki je združljiv z MME, ima vaš vsebnik Strežnik z več modeli (proces JVM) teče. Najlažji način za vključitev večmodelnega strežnika (MMS) v vsebnik za serviranje modela je uporaba SageMaker model posod za serviranje združljiv z MME (poiščite tiste z Job Type=inference in CPU/GPU=CPU). MMS je odprtokodno orodje, ki je preprosto za uporabo in služi modelom globokega učenja. Ponuja REST API s spletnim strežnikom za strežbo in upravljanje več modelov na enem gostitelju. Vendar pa uporaba MMS ni obvezna; lahko implementirate svoj model strežnika, če le ta izvaja API-ji, ki jih zahteva MME.

Ko se uporablja kot del platforme MME, so vsi klici API-ja za predvidevanje, nalaganje in razkladanje v MMS ali vaš lastni strežnik modelov usmerjeni prek krmilnika podatkovne ravnine MME. Klici API-ja iz krmilnika podatkovne ravnine se izvajajo samo prek lokalnega gostitelja, da se prepreči nepooblaščen dostop zunaj primerka. Ena od ključnih prednosti MMS je, da omogoča standardiziran vmesnik za nalaganje, razkladanje in priklic modelov z združljivostjo v širokem naboru ogrodij globokega učenja.

Napredna konfiguracija MMS

Če se odločite za uporabo MMS za streženje modela, razmislite o naslednjih naprednih konfiguracijah za optimizacijo razširljivosti in prepustnosti vaših primerkov MME.

Povečajte vzporednost sklepanja na model

MMS ustvari enega ali več delovnih procesov Python na model glede na vrednost privzeti_delavci_na_model konfiguracijski parameter. Ti Python delavci obravnavajo vsako posamezno zahtevo za sklepanje z izvajanjem vseh funkcij predprocesiranja, predvidevanja in naknadne obdelave, ki jih zagotovite. Za več informacij glejte upravljavec storitve po meri Repo za GitHub.

Če imate več kot enega modelnega delavca, se poveča vzporednost napovedi, ki jih lahko ponudi določen model. Če pa na instanci z velikim številom procesorjev gostuje veliko število modelov, morate izvesti obremenitveni preizkus vašega MME, da poiščete optimalno vrednost za default_workers_per_model da preprečite kakršno koli izčrpanost pomnilnika ali virov procesorja.

Oblikovanje za konice prometa

Vsak proces MMS znotraj instance končne točke ima čakalno vrsto zahtev, ki jo je mogoče konfigurirati z velikost_čakalne_vrste_posla parameter (privzeto je 100). To določa število zahtev, ki jih MMS postavi v čakalno vrsto, ko so vsi delovni procesi zasedeni. Uporabite ta parameter za natančno nastavitev odzivnosti vaših instanc končne točke, potem ko se odločite za optimalno število delavcev na model.

Pri optimalnem razmerju delavcev na model bi morala privzeta vrednost 100 zadostovati za večino primerov. Za tiste primere, ko promet zahtev do končne točke nenavadno narašča, lahko zmanjšate velikost čakalne vrste, če želite, da končna točka ne uspe hitro prenesti nadzora na aplikacijo, ali povečate velikost čakalne vrste, če želite, da končna točka absorbira skok .

Povečajte pomnilniške vire na primerek

Pri uporabi več delovnih procesov na model vsak delovni proces privzeto naloži svojo kopijo modela. To lahko zmanjša razpoložljivi pomnilnik primerkov za druge modele. Uporabo pomnilnika lahko optimizirate tako, da delite en sam model med delovnimi procesi, tako da nastavite konfiguracijski parameter preload_model=true. Tu zamenjate zmanjšan paralelizem sklepanja (zaradi enega primerka modela) z večjo učinkovitostjo pomnilnika. Ta nastavitev skupaj z več delovnimi procesi je lahko dobra izbira za primere uporabe, kjer je zakasnitev modela nizka, vendar imate težjo predprocesiranje in naknadno obdelavo (ki ga izvajajo delovni procesi) na zahtevo za sklepanje.

Nastavite vrednosti za napredne konfiguracije MMS

MMS uporablja datoteko config.properties za shranjevanje konfiguracij. MMS uporablja naslednji vrstni red za iskanje te datoteke config.properties:

1. Če MMS_CONFIG_FILE nastavljena spremenljivka okolja, MMS naloži konfiguracijo iz spremenljivke okolja.
2. Če --mms-config parameter prenese v MMS, naloži konfiguracijo iz parametra.
3. Če obstaja config.properties v trenutni mapi, kjer uporabnik zažene MMS, naloži config.properties datoteko iz trenutnega delovnega imenika.

Če nič od zgoraj navedenega ni navedeno, MMS naloži vgrajeno konfiguracijo s privzetimi vrednostmi.

Sledi primer ukazne vrstice za zagon MMS z eksplicitno konfiguracijsko datoteko:

multi-model-server --start --mms-config /home/mms/config.properties

Ključne meritve za spremljanje uspešnosti vaše končne točke

Ključne metrike, ki vam lahko pomagajo optimizirati vaš MME, so običajno povezane z uporabo procesorja in pomnilnika ter zakasnitvijo sklepanja. Meritve na ravni primerka oddaja MMS, medtem ko metrike zakasnitve prihajajo iz MME. V tem razdelku razpravljamo o tipičnih meritvah, ki jih lahko uporabite za razumevanje in optimizacijo svojega MME.

Meritve na ravni instance končne točke (metrike MMS)

Iz seznam meritev MMS, CPUUtilization in MemoryUtilization vam lahko pomagajo oceniti, ali je vaš primerek ali gruča MME prave velikosti ali ne. Če imata obe meritvi odstotke med 50–80 %, je vaš MME prave velikosti.

Običajno sta nizka CPUUtilization in visoka MemoryUtilization znak preveč oskrbljene gruče MME, ker kaže, da se redko klicani modeli ne razlagajo. Razlog za to je lahko višje od optimalnega števila instanc končne točke, ki so na voljo za MME, zato je za redko dostopne modele na voljo skupni pomnilnik, ki je večji od optimalnega, da ostanejo v pomnilniku. Nasprotno pa skoraj 100-odstotna izkoriščenost teh meritev pomeni, da je vaša gruča premalo opremljena, zato morate prilagoditi svojo politiko samodejnega skaliranja gruče.

Meritve na ravni platforme (metrike MME)

Iz celoten seznam meritev MME, ključna metrika, ki vam lahko pomaga razumeti zakasnitev vaše zahteve za sklepanje, je ModelCacheHit. Ta metrika prikazuje povprečno razmerje zahtev za priklic, za katere je bil model že naložen v pomnilnik. Če je to razmerje nizko, to pomeni, da je vaša gruča MME premalo oskrbljena, ker v gruči MME verjetno ni dovolj skupne pomnilniške zmogljivosti za število edinstvenih klicev modela, zaradi česar se modeli pogosto razkladajo iz pomnilnika.

Lekcije s terena in strategije za optimizacijo MME

Videli smo naslednja priporočila pri nekaterih obsežnih uporabah MME pri številnih strankah.

Horizontalno skaliranje z manjšimi primerki je boljše od navpičnega skaliranja z večjimi primerki

Pri izvajanju visokih zahtev na sekundo (RPS) na manj instancah končne točke lahko pride do dušenja pri klicih modela. Obstajajo notranje omejitve števila klicev na sekundo (nalaganja in razkladanja, ki se lahko izvajajo hkrati na instanci), zato je vedno bolje imeti večje število manjših instanc. Izvajanje večjega števila manjših primerkov pomeni višjo skupno skupno zmogljivost teh omejitev za končno točko.

Druga prednost vodoravnega skaliranja z manjšimi primerki je, da zmanjšate tveganje izčrpanja CPU in pomnilniških virov primerka pri izvajanju MMS z višjimi stopnjami paralelizma, skupaj z večjim številom modelov v pomnilniku (kot je opisano prej v tej objavi).

Izogibanje udarcem je skupna odgovornost

Razbijanje v MME je, ko se modeli pogosto razkladajo iz pomnilnika in znova nalagajo zaradi nezadostnega pomnilnika, bodisi v posameznem primeru bodisi v agregatu v gruči.

Z vidika uporabe bi morali določiti pravo velikost posameznih primerkov končne točke in ustrezno velikost celotne gruče MME, da zagotovite, da je na voljo dovolj pomnilniške zmogljivosti na primerek in tudi na agregatu za gručo za vaš primer uporabe. Flota usmerjevalnikov platforme MME bo prav tako povečala zadetek predpomnilnika.

Ne bodite agresivni z zbiranjem prevelikega števila modelov na manj in večjih instancah pomnilnika

Pomnilnik ni edini vir v instanci, na katerega morate biti pozorni. Drugi viri, kot je CPE, so lahko omejevalni dejavnik, kot je razvidno iz naslednjih rezultatov preizkusa obremenitve. V nekaterih drugih primerih smo opazili tudi, da so bili drugi viri jedra, kot so ID-ji procesov, izčrpani na primerku, zaradi kombinacije preveč naloženih modelov in osnovnega ogrodja ML (kot je TensorFlow), ki ustvarja niti na model, ki so bile večkratniki razpoložljivih vCPE.

Naslednji preizkus zmogljivosti prikazuje primer omejitve procesorja, ki vpliva na zakasnitev modela. V tem preizkusu je končna točka posameznega primerka z velikim primerkom, čeprav je imela več kot dovolj pomnilnika za ohranitev vseh štirih modelov v pomnilniku, ustvarila razmeroma slabše zakasnitve modela pod obremenitvijo v primerjavi s končno točko s štirimi manjšimi primerki.

zakasnitev modela končne točke enega primerka

poraba procesorja in pomnilnika posamezne končne točke

zakasnitev modela končne točke štirih primerkov

izkoriščenost procesorja in pomnilnika štirih končnih točk

Če želite doseči zmogljivost in stroškovno učinkovitost, prilagodite svojo gručo MME prave velikosti z večjim številom manjših instanc, ki vam skupaj zagotovijo optimalno zmogljivost pomnilnika in procesorja, medtem ko so razmeroma enake cene z manj, a večjimi instancami pomnilnika.

Mentalni model za optimizacijo MME

Obstajajo štiri ključne meritve, ki jih morate vedno upoštevati pri pravilnem določanju velikosti vašega MME:

• Število in velikost modelov
• Število edinstvenih modelov, priklicanih v določenem času
• Vrsta in velikost primerka
• Število primerkov za končno točko

Začnite s prvima dvema točkama, ker pomenita tretjo in četrto. Na primer, če za končno točko ni dovolj primerkov glede na število ali velikost edinstvenih modelov, ki jih imate, bo skupni pomnilnik za končno točko nizek in videli boste nižje razmerje zadetkov v predpomnilniku in razbijanje na ravni končne točke, ker MME bo modele pogosto nalagal in razlagal v pomnilnik in iz njega.

Podobno, če so klici za edinstvene modele višji od skupnega pomnilnika vseh primerkov za končno točko, boste videli nižji zadetek predpomnilnika. To se lahko zgodi tudi, če je velikost primerkov (zlasti pomnilniška zmogljivost) premajhna.

Navpično skaliranje z zelo velikimi primerki pomnilnika lahko povzroči tudi težave, ker čeprav se modeli lahko prilegajo pomnilniku, so lahko drugi viri, kot so procesi procesorja in jedra ter omejitve niti, izčrpani. Obremenitveni test vodoravnega skaliranja v predprodukciji, da dobite optimalno število in velikost primerkov za vaš MME.

Povzetek

V tej objavi ste globlje razumeli platformo MME. Izvedeli ste, za katere tehnične primere uporabe je MME primeren, in pregledali arhitekturo platforme MME. Pridobili ste globlje razumevanje vloge posamezne komponente v arhitekturi MME in katere komponente lahko neposredno vplivate na delovanje. Končno ste si podrobneje ogledali konfiguracijske parametre, ki jih lahko prilagodite, da optimizirate MME za vaš primer uporabe, in meritve, ki jih morate spremljati, da ohranite optimalno delovanje.

Če želite začeti uporabljati MME, preglejte Večmodelne končne točke Amazon SageMaker z uporabo XGBoost in Gostite več modelov v enem vsebniku za eno končno točko.

O Author

Syed Jaffry je glavni arhitekt rešitev pri AWS. Sodeluje s številnimi podjetji iz srednje velikih organizacij, velikih podjetij, finančnih storitev in ISV-jev, da bi jim pomagal zgraditi in upravljati stroškovno učinkovite in razširljive AI/ML aplikacije v oblaku.

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.