Käivitage ja optimeerige mitme mudeli järeldusi Amazon SageMakeri mitme mudeli lõpp-punktidega

Amazon SageMaker mitme mudeli lõpp-punkt (MME) võimaldab kuluefektiivselt juurutada ja hostida mitu mudelit ühes lõpp-punktis ning seejärel mõõtkava saavutamiseks lõpp-punkti horisontaalselt skaleerida. Nagu on näidatud järgmisel joonisel, on see tõhus meetod mudelite mitme rendilepingu rakendamiseks teie masinõppe (ML) infrastruktuuris. Oleme näinud, et tarkvara kui teenuse (SaaS) ettevõtted kasutavad seda funktsiooni oma ML-mudelites hüperpersonaliseerimise rakendamiseks, saavutades samal ajal madalamad kulud.

Kõrgetasemelise ülevaate saamiseks MME tööst vaadake AWS-i tippkohtumise videot ML-i skaleerimine järgmisele tasemele: tuhandete mudelite hostimine SageMakeris. Lisateavet MME lubatavate hüperisikupärastatud mitme rentniku kasutusjuhtude kohta leiate artiklist Kuidas skaleerida masinõppe järeldust mitme rentniku SaaS-i kasutusjuhtude jaoks.

Selle postituse ülejäänud osas sukeldume sügavamale SageMaker MME tehnilisse arhitektuuri ja jagame parimaid tavasid teie mitme mudeli lõpp-punktide optimeerimiseks.

Kasutage MME jaoks kõige paremini sobivaid juhtumeid

SageMakeri mitme mudeli lõpp-punktid sobivad hästi suure hulga mudelite majutamiseks, mida saate teenindada jagatud serveerimiskonteineri kaudu ja te ei pea kõigile mudelitele korraga juurde pääsema. Olenevalt lõpp-punkti eksemplari mälu suurusest võidakse aeg-ajalt mudelit mälust maha laadida, et laadida mälu tõhusaks kasutamiseks võimalikult palju uut mudelit, mistõttu peab teie rakendus taluma laadimata mudelite aeg-ajalt latentsusaega.

MME on mõeldud ka sama ML-i raamistikku kasutavate mudelite kaashostimiseks, kuna nad kasutavad mitme mudeli laadimiseks jagatud konteinerit. Seega, kui teie mudelipargis on ML-raamistike segu (nt PyTorch ja TensorFlow), on SageMakerile pühendatud lõpp-punktid või mitme konteineri hostimine parem valik.

Lõpuks sobib MME rakendustele, mis taluvad aeg-ajalt külmkäivituse latentsusaega, kuna mudelid laaditakse esimesel käivitamisel ja harva kasutatavad mudelid saab uute mudelite laadimise kasuks mälust välja laadida. Seega, kui teil on sageli ja harva kasutatavaid mudeleid, saab mitme mudeliga lõpp-punkt seda liiklust tõhusalt teenindada vähemate ressursside ja suurema kulude kokkuhoiuga.

Oleme näinud ka mõningaid stsenaariume, kus kliendid juurutavad MME-klastri, millel on piisavalt kogumälu, et see sobiks kõigi nende mudelitega, vältides sellega mudelite täielikku mahalaadimist, kuid saavutades siiski kulude kokkuhoiu tänu jagatud järelduste infrastruktuurile.

Serveerimiskonteinerite mudel

Kui kasutate SageMaker Inference Toolkit või MME-ga ühilduvat eelehitatud SageMakeri mudeli serveerimismahutit, on teie konteineril Mitme mudeli server (JVM-protsess) töötab. Lihtsaim viis mitme mudeliserveri (MMS) ühendamiseks mudeli serveerimismahutisse on seda kasutada SageMaker mudeli serveerimiskonteinerid ühildub MME-ga (otsige neid, mille tüüp on Job Type = järeldus ja CPU/GPU = CPU). MMS on avatud lähtekoodiga hõlpsasti kasutatav tööriist süvaõppemudelite teenindamiseks. See pakub REST API-d koos veebiserveriga, et teenindada ja hallata mitut mudelit ühes hostis. Siiski ei ole MMS-i kasutamine kohustuslik; võite rakendada oma mudeliserverit seni, kuni see rakendab MME nõutavad API-d.

Kui seda kasutatakse MME platvormi osana, suunatakse kõik MMS-i või teie enda mudeliserverisse suunduvad API-kõned ennustamiseks, laadimiseks ja mahalaadimiseks läbi MME andmetasandi kontrolleri. API-kutsed andmetasandi kontrollerist tehakse ainult kohaliku hosti kaudu, et vältida volitamata juurdepääsu eksemplari väljastpoolt. MMS-i üks peamisi eeliseid on see, et see võimaldab mudelite laadimiseks, mahalaadimiseks ja käivitamiseks standardiseeritud liidest, mis ühildub paljude süvaõppe raamistikega.

MMS-i täpsem konfiguratsioon

Kui otsustate mudelite teenindamiseks kasutada MMS-i, kaaluge oma MME eksemplaride skaleeritavuse ja läbilaskevõime optimeerimiseks järgmisi täpsemaid konfiguratsioone.

Suurendage järelduste paralleelsust mudeli kohta

MMS loob mudeli väärtuse põhjal ühe või mitu Pythoni töötaja protsessi iga mudeli kohta vaikimisi_töötajad_mudeli kohta konfiguratsiooni parameeter. Need Pythoni töötajad käsitlevad iga üksikut järelduspäringut, käivitades teie pakutavad eeltöötlus-, ennustamis- ja järeltöötlusfunktsioonid. Lisateabe saamiseks vaadake kohandatud teenuse käitleja GitHubi repo.

Rohkem kui ühe mudeli töötaja olemasolu suurendab ennustuste paralleelsust, mida antud mudel saab teenindada. Kui aga suure hulga protsessoritega eksemplaris hostitakse suurt hulka mudeleid, peaksite optimaalse väärtuse leidmiseks tegema oma MME koormustesti. default_workers_per_model mälu või protsessori ressursi ammendumise vältimiseks.

Disain liiklustippude jaoks

Igal lõpp-punkti eksemplari MMS-protsessil on päringujärjekord, mida saab konfigureerida rakendusega tööjärjekorra_suurus parameeter (vaikimisi on 100). See määrab taotluste arvu, mille MMS järjekorda paneb, kui kõik tööprotsessid on hõivatud. Kasutage seda parameetrit lõpp-punkti eksemplaride reageerimisvõime täpsustamiseks pärast seda, kui olete otsustanud optimaalse töötajate arvu mudeli kohta.

Optimaalse töötaja ja mudeli suhte korral peaks enamikul juhtudel piisama vaikeväärtusest 100. Nendel juhtudel, kui taotlusliiklus lõpp-punktini kasvab ebatavaliselt, saate järjekorra suurust vähendada, kui soovite, et lõpp-punkt ei saaks kiiresti rakendusele juhtimist üle anda, või suurendada järjekorra suurust, kui soovite, et lõpp-punkt neelaks hüppe. .

Maksimeerige mäluressursse eksemplari kohta

Kui mudeli kohta kasutatakse mitut tööprotsessi, laadib iga töötaja protsess vaikimisi mudelist oma koopia. See võib vähendada teiste mudelite jaoks saadaolevat eksemplari mälu. Saate optimeerida mälukasutust, jagades tööprotsesside vahel üht mudelit, määrates konfiguratsiooniparameetri preload_model=true. Siin kauplete välja vähendatud järelduste paralleelsusega (ühe mudeli eksemplari tõttu) suurema mälutõhususega. See säte koos mitme töötaja protsessiga võib olla hea valik kasutusjuhtudel, kus mudeli latentsusaeg on madal, kuid teil on ühe järelduspäringu kohta raskem eel- ja järeltöötlus (mida teevad töötaja protsessid).

Määrake MMS-i täpsemate konfiguratsioonide väärtused

MMS kasutab konfiguratsioonide salvestamiseks faili config.properties. MMS kasutab faili config.properties leidmiseks järgmist järjekorda:

1. Kui MMS_CONFIG_FILE keskkonnamuutuja on määratud, laadib MMS konfiguratsiooni keskkonnamuutujast.
2. Kui --mms-config parameeter edastatakse MMS-ile, laadib see parameetrist konfiguratsiooni.
3. Kui on olemas config.properties praeguses kaustas, kus kasutaja MMS-i käivitab, laadib see config.properties faili praegusest töökataloogist.

Kui ükski ülaltoodust pole määratud, laadib MMS sisseehitatud konfiguratsiooni vaikeväärtustega.

Järgmine on käsurea näide MMS-i käivitamisest selgesõnalise konfiguratsioonifailiga:

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

Peamised mõõdikud lõpp-punkti toimivuse jälgimiseks

Peamised mõõdikud, mis aitavad teil MME-d optimeerida, on tavaliselt seotud protsessori ja mälu kasutamise ning järelduste latentsusega. Eksemplaritaseme mõõdikud väljastatakse MMS-ist, latentsusmõõdikud aga MME-st. Selles jaotises käsitleme tüüpilisi mõõdikuid, mida saate kasutada oma MME mõistmiseks ja optimeerimiseks.

Lõpp-punkti eksemplari tasemel mõõdikud (MMS-i mõõdikud)

Alates MMS-i mõõdikute loend, CPUUtilization ja MemoryUtilization aitavad teil hinnata, kas teie eksemplar või MME klaster on õige suurusega või mitte. Kui mõlema mõõdiku protsendid on vahemikus 50–80%, on teie MME õige suurusega.

Tavaliselt viitavad madal CPUU- ja kõrge mälukasutus ülevarustatud MME-klastrile, kuna see näitab, et harva käivitatud mudeleid ei laadita maha. Selle põhjuseks võib olla optimaalsest suurem MME jaoks ette nähtud lõpp-punktide arv ja seetõttu on harva kasutatavate mudelite mällu jäämiseks saadaval optimaalsest suurem koondmälu. Vastupidi, nende mõõdikute peaaegu 100% ärakasutamine tähendab, et teie klaster on alavarustatud, seega peate kohandama oma klastri automaatse skaleerimise poliitikat.

Platvormitaseme mõõdikud (MME mõõdikud)

Alates MME mõõdikute täielik loetelu, on ModelCacheHit peamine mõõdik, mis aitab teil järelduspäringu latentsust mõista. See mõõdik näitab nende kutsumistaotluste keskmist suhet, mille jaoks mudel oli juba mällu laaditud. Kui see suhe on madal, näitab see, et teie MME-klaster on alavarustatud, kuna tõenäoliselt ei ole MME-klastris unikaalsete mudelikutsete arvu jaoks piisavalt koondmälu mahtu, mis põhjustab mudelite sagedast mälust väljalaadimist.

Õppetunnid valdkonnast ja strateegiad MME optimeerimiseks

Oleme näinud järgmisi soovitusi mõne MME laiaulatusliku kasutuse kohta paljude klientide jaoks.

Horisontaalne skaleerimine väiksemate eksemplaridega on parem kui vertikaalne skaleerimine suuremate eksemplaride puhul

Kui käitate arvukaid taotlusi sekundis (RPS) vähematel lõpp-punktieksemplaridel, võite mudeli kutsumise korral piirata. Kutsumiste arvul sekundis on sisemised piirangud (laadimised ja mahalaadimised, mis võivad eksemplaril toimuda samaaegselt), mistõttu on alati parem kasutada rohkem väiksemaid eksemplare. Suurema arvu väiksemate eksemplaride käitamine tähendab lõpp-punkti jaoks nende piirangute suuremat koondvõimsust.

Väiksemate eksemplaride horisontaalse skaleerimise teine ​​eelis on see, et vähendate suurema paralleelsuse tasemega MMS-i käitamisel eksemplari CPU- ja mäluressursside ammendumise ohtu koos suurema arvu mudelitega mälus (nagu selles postituses varem kirjeldatud).

Peksmise vältimine on jagatud vastutus

Löömine MME-s on see, kui mudeleid laaditakse sageli mälust välja ja laaditakse uuesti ebapiisava mälu tõttu kas üksikult või klastris kokku.

Kasutamise seisukohast peaksite valima õige suurusega üksikute lõpp-punkti eksemplaride ja õige suurusega MME klastri, et tagada piisav mälumaht iga eksemplari kohta ja ka kogu klastri jaoks teie kasutusjuhtumi jaoks. MME platvormi ruuteripark maksimeerib ka vahemälu tabamust.

Ärge olge agressiivne, pakkides liiga palju mudeleid vähematele ja suurematele mälueksemplaridele

Mälu pole eksemplaris ainus ressurss, millest teadlik olla. Muud ressursid, nagu protsessor, võivad olla piiravaks teguriks, nagu on näha järgmistest koormustesti tulemustest. Mõnel muul juhul oleme täheldanud ka teiste tuumaressursside, näiteks protsessi ID-de ammendumist eksemplaris, kuna laaditi liiga palju mudeleid ja aluseks oleva ML-raamistiku (nt TensorFlow) kudemislõime mudeli kohta, mis olid saadaolevate arvude kordne. vCPU-d.

Järgmine jõudlustest näitab näidet protsessori piirangust, mis mõjutab mudeli latentsust. Selles testis andis ühe eksemplari lõpp-punkt suure eksemplariga, kuigi sellel oli rohkem kui piisavalt mälu kõigi nelja mudeli mälus hoidmiseks, võrreldes nelja väiksema eksemplariga lõpp-punktiga suhteliselt halvemad mudeli latentsused koormuse all.

ühe eksemplari lõpp-punkti mudeli latentsusaeg

ühe eksemplari lõpp-punkti protsessori ja mälu kasutamine

nelja eksemplari lõpp-punkti mudeli latentsusaeg

nelja eksemplari lõpp-punkti CPU ja mälu kasutamine

Nii jõudluse kui ka kulutõhususe saavutamiseks kohandage oma MME-klastrit suurema arvu väiksemate eksemplaridega, mis kokkuvõttes annavad teile optimaalse mälu ja protsessori mahu, olles samal ajal kuludega suhteliselt võrdsed vähemate, kuid suuremate mälueksemplaridega.

Vaimne mudel MME optimeerimiseks

MME õige suuruse määramisel peaksite alati arvestama nelja peamise mõõdikuga:

• Mudelite arv ja suurus
• Teatud ajahetkel välja kutsutud unikaalsete mudelite arv
• Eksemplari tüüp ja suurus
• Eksemplaride arv lõpp-punkti taga

Alustage kahe esimese punktiga, sest need teavitavad kolmandat ja neljandat. Näiteks kui teie kordumatute mudelite arvu või suuruse jaoks pole lõpp-punktist taga piisavalt esinemisjuhte, on lõpp-punkti koondmälu madal ja näete lõpp-punkti tasemel väiksemat vahemälu tabamussuhet ja peksmist, kuna MME laadib mudelid sageli mälusse ja sealt välja.

Samamoodi, kui unikaalsete mudelite väljakutsed on suuremad kui kõigi lõpp-punkti taga olevate eksemplaride koondmälu, näete väiksemat vahemälu tabamust. See võib juhtuda ka siis, kui eksemplaride suurus (eriti mälumaht) on liiga väike.

Tõeliselt suurte mälueksemplaride vertikaalne skaleerimine võib samuti põhjustada probleeme, sest kuigi mudelid võivad mällu mahtuda, võivad muud ressursid, nagu CPU ja kerneli protsessid ning lõimepiirangud, olla ammendatud. Laadige testimise horisontaalne skaleerimine eeltootmises, et saada oma MME jaoks optimaalne arv ja suurus.

kokkuvõte

Selles postituses saite MME platvormist sügavama ülevaate. Õppisite, millisteks tehnilisteks kasutusjuhtudeks MME sobib, ja vaatasite üle MME platvormi arhitektuuri. Saite sügavamalt aru iga komponendi rollist MME arhitektuuris ja sellest, milliste komponentide toimimist saate otseselt mõjutada. Lõpuks uurisite põhjalikumalt konfiguratsiooniparameetreid, mida saate kohandada, et optimeerida MME-d vastavalt oma kasutusjuhtumile, ja mõõdikuid, mida peaksite optimaalse jõudluse säilitamiseks jälgima.

MME-ga alustamiseks vaadake üle Amazon SageMakeri mitme mudeli lõpp-punktid, kasutades XGBoosti ja Hostige mitu mudelit ühes konteineris ühe lõpp-punkti taga.

Teave Autor

Syed Jaffry on AWS-i peamiste lahenduste arhitekt. Ta teeb koostööd paljude ettevõtetega keskmise suurusega organisatsioonidest, suurettevõtetest, finantsteenustest ja sõltumatutest tarkvarapakkujatest, et aidata neil pilves kulutõhusaid ja skaleeritavaid AI/ML-rakendusi luua ja hallata.

Saurabh Trikande on Amazon SageMaker Inference'i vanemtootejuht. Ta on kirglik töö klientidega ja teda motiveerib eesmärk demokratiseerida masinõpe. Ta keskendub põhiprobleemidele, mis on seotud keeruliste ML-rakenduste, mitme rentniku ML-mudelite, kulude optimeerimise ja süvaõppemudelite juurutamise kättesaadavamaks muutmisega. Vabal ajal naudib Saurabh matkamist, uuenduslike tehnoloogiate õppimist, TechCrunchi jälgimist ja perega aega veetmist.