Tutvustame Amazon SageMakeri serverita järelduste võrdlusuuringu tööriistakomplekti

Amazon SageMakeri serverita järeldus on sihipäraselt loodud järeldusvõimalus, mis muudab masinõppe (ML) mudelite juurutamise ja skaleerimise lihtsaks. See pakub tasulise kasutamise mudelit, mis sobib ideaalselt teenuste jaoks, kus lõpp-punktide väljakutsed on harvad ja ettearvamatud. Erinevalt reaalajas hostimise lõpp-punktist, mida toetab kaua töötav eksemplar, on serverita lõpp-punktide jaoks ette nähtud arvutusressursid nõudmisel, mis välistab vajaduse valida eksemplaritüüpe või hallata skaleerimispoliitikaid.

Järgmine kõrgetasemeline arhitektuur illustreerib serverita lõpp-punkti toimimist. Klient kutsub esile lõpp-punkti, mida toetab AWS-i hallatav infrastruktuur.

Kuid serverita lõpp-punktid on altid külmkäivitamisele sekundite suurusjärgus ja sobivad seetõttu paremini vahelduva või ettearvamatu töökoormuse jaoks.

Et aidata kindlaks teha, kas serverita lõpp-punkt on kulude ja jõudluse seisukohast õige juurutusvalik, oleme välja töötanud SageMaker Serverless Inference Benchmarking Toolkit, mis testib erinevaid lõpp-punkti konfiguratsioone ja võrdleb optimaalseimat võrreldava reaalajas hostimise eksemplariga.

Selles postituses tutvustame tööriistakomplekti ning anname ülevaate selle konfiguratsioonist ja väljunditest.

Lahenduse ülevaade

Tööriistakomplekti saate alla laadida ja installida saidilt GitHub repo. Alustamine on lihtne: lihtsalt installige raamatukogu, looge a SageMakeri mudelja sisestage oma mudeli nimi koos JSON-ridade vormindatud failiga, mis sisaldab prooviparameetrite komplekti, sealhulgas kasuliku koormuse keha ja sisutüüpi. Pakutakse mugavusfunktsiooni kutsumisargumentide näidisloendi teisendamiseks JSON-i ridade failiks või hapufailiks binaarsete kasulike koormuste (nt pildid, video või heli) jaoks.

Installige tööriistakomplekt

Esmalt installige võrdlusuuringute teek oma Pythoni keskkonda, kasutades pip:

pip install sm-serverless-benchmarking

Saate käivitada järgmise koodi rakendusest Amazon SageMaker Studio näide, SageMakeri märkmiku eksemplarvõi mis tahes juhtum programmiline juurdepääs AWS-ile ja sobivale AWS-i identiteedi- ja juurdepääsuhaldus (IAM) load. Nõutavad IAM-õigused on dokumenteeritud dokumendis GitHub repo. Täiendavate juhiste ja IAM-i poliitika näidete saamiseks vaadake Kuidas Amazon SageMaker IAM-iga töötab. See kood käivitab parameetrite vaikekomplektiga võrdlusaluse mudelil, mis ootab CSV-sisendit koos kahe näidiskirjega. Hea tava on esitada esinduslik näidete kogum, et analüüsida, kuidas lõpp-punkt erinevate sisendkoormustega toimib.

from sm_serverless_benchmarking import benchmark
from sm_serverless_benchmarking.utils import convert_invoke_args_to_jsonl
model_name = ""
example_invoke_args = [
        {'Body': '1,2,3,4,5', "ContentType": "text/csv"},
        {'Body': '6,7,8,9,10', "ContentType": "text/csv"}
        ]
example_args_file = convert_invoke_args_to_jsonl(example_invoke_args,
output_path=".")
r = benchmark.run_serverless_benchmarks(model_name, example_args_file)

Lisaks saate võrdlusuuringut käitada SageMakeri töötlemistööna, mis võib olla usaldusväärsem valik pikemaajaliste ja suure hulga kutsumiste korral. Vaadake järgmist koodi:

from sm_serverless_benchmarking.sagemaker_runner import run_as_sagemaker_job
run_as_sagemaker_job(
                    role="",
                    model_name="",
                    invoke_args_examples_file="",
                    )

Pange tähele, et sellega kaasnevad lisakulud ml.m5.large SageMaker Processingi eksemplari käitamisega kogu võrdlusaluse kestuse jooksul.

Mõlemad meetodid aktsepteerivad konfigureerimiseks mitmeid parameetreid, näiteks võrdluseks kasutatavate mälukonfiguratsioonide loendit ja iga konfiguratsiooni käivitamise kordade arvu. Enamikul juhtudel peaksid vaikevalikutest piisama lähtepunktiks, kuid viidake GitHub repo iga parameetri täieliku loendi ja kirjelduste jaoks.

Võrdlusuuringu konfiguratsioon

Enne kui hakkate uurima, mida etalon teeb ja milliseid väljundeid see toodab, on oluline mõista mõnda põhimõistet serverita lõpp-punktide konfigureerimisel.

Seal on kaks peamist konfiguratsioonivalikut: MemorySizeInMB ja MaxConcurrency. MemorySizeInMB konfigureerib eksemplarile eraldatava mälumahu ja see võib olla 1024 MB, 2048 MB, 3072 MB, 4096 MB, 5120 MB või 6144 MB. Ka vCPU-de arv skaleerub proportsionaalselt eraldatud mälumahuga. The MaxConcurrency parameeter reguleerib, mitut samaaegset päringut lõpp-punkt suudab teenindada. Koos MaxConcurrency 1-st saab serverita lõpp-punkt töödelda ainult ühte päringut korraga.

Kokkuvõtteks võib öelda, et MemorySizeInMB parameeter pakub vertikaalse skaleeritavuse mehhanismi, mis võimaldab teil kohandada mälu ja arvutada ressursse suuremate mudelite teenindamiseks. MaxConcurrency pakub horisontaalse skaleeritavuse mehhanismi, võimaldades teie lõpp-punktil töödelda rohkem samaaegseid taotlusi.

Lõpp-punkti käitamise kulud määrab suuresti mälumaht ja maksimaalse samaaegsuse suurendamisega ei kaasne mingeid kulusid. Siiski on kõigi lõpp-punktide maksimaalseks samaaegsuseks piirkonnapõhine konto piirang. Viitama SageMakeri lõpp-punktid ja kvoodid viimaste limiitide jaoks.

Võrdlusuuringu väljundid

Seda arvestades on serverita lõpp-punkti võrdlusuuringu eesmärk määrata kindlaks kõige kuluefektiivsem ja usaldusväärsem mälumahu säte ning minimaalne maksimaalne samaaegsus, mis suudab teie eeldatavaid liiklusmustreid käsitleda.

Vaikimisi töötab tööriist kahte võrdlusalust. Esimene on stabiilsuse etalon, mis juurutab lõpp-punkti iga määratud mälukonfiguratsiooni jaoks ja kutsub iga lõpp-punkti koos esitatud näidiskoormustega. Selle võrdlusaluse eesmärk on määrata kõige tõhusam ja stabiilsem MemorySizeInMB säte. Võrdlusnäitaja fikseerib väljakutse latentsusajad ja arvutab iga lõpp-punkti jaoks eeldatava ühe kutsumiskulu. Seejärel võrdleb see kulusid sarnase reaalajas hostimise eksemplariga.

Kui võrdlusuuringud on lõpule viidud, genereerib tööriist mitu määratud väljundit result_save_path kataloog järgmise kataloogistruktuuriga:

├── benchmarking_report
├── concurrency_benchmark_raw_results
├── concurrency_benchmark_summary_results
├── cost_analysis_summary_results
├── stability_benchmark_raw_results
├── stability_benchmark_summary_results

. benchmarking_report kataloog sisaldab konsolideeritud aruannet kõigi kokkuvõtlike väljunditega, mida selles postituses kirjeldame. Täiendavad kataloogid sisaldavad töötlemata ja vaheväljundeid, mida saate kasutada täiendavate analüüside jaoks. Vaadake GitHub repo iga väljundartefakti üksikasjalikuma kirjelduse jaoks.

Uurime mõnda tegelikku võrdlusuuringu väljundit arvutivisiooni MobileNetV2 TensorFlow mudelit teenindava lõpp-punkti jaoks. Kui soovite seda näidet reprodutseerida, vaadake näiteks märkmikud kataloogi GitHubi repos.

Konsolideeritud aruande esimene väljund on kokkuvõtlik tabel, mis sisaldab iga jaoks minimaalse, keskmise, keskmise ja maksimaalse latentsusaja mõõdikuid. MemorySizeInMB edukas mälumahu seadistamine. Nagu on näidatud järgmises tabelis, on kutsumise keskmine latentsus (invocation_latency_mean) jätkas paranemist, kuna mälu konfiguratsiooni suurendati 3072 MB-ni, kuid paranes pärast seda.

Lisaks kõrgetasemelisele kirjeldavale statistikale on esitatud diagramm, mis näitab latentsusaja jaotust, mida jälgib klient iga mälukonfiguratsiooni kohta. Jällegi võime täheldada, et 1024 MB konfiguratsioon ei ole nii tõhus kui teised valikud, kuid 2048 ja kõrgemate konfiguratsioonide jõudluses pole olulisi erinevusi.

Amazon CloudWatch Samuti on esitatud iga lõpp-punkti konfiguratsiooniga seotud mõõdikud. Üks põhinäitaja siin on ModelSetupTime, mis mõõdab, kui kaua kulus mudeli laadimiseks, kui lõpp-punkt käivitati külmas olekus. Mõõdik ei pruugi alati aruandes ilmuda, kuna lõpp-punkt käivitatakse soojas olekus. A cold_start_delay parameeter on saadaval selleks, et määrata enne juurutatud lõpp-punkti võrdlusaluse käivitamist unerežiimi sekundite arvu. Selle parameetri määramine suuremale arvule, näiteks 600 sekundile, peaks suurendama külma oleku kutsumise tõenäosust ja parandama selle mõõdiku jäädvustamise võimalusi. Lisaks on see mõõdik palju tõenäolisem hõivatud samaaegse kutsumise etaloniga, mida käsitleme selles jaotises hiljem.

Järgmises tabelis on CloudWatchi jäädvustatud mõõdikud iga mälukonfiguratsiooni kohta.

Järgmine diagramm näitab erinevate mälukonfiguratsioonide jõudlust ja kulude kompromisse. Üks rida näitab lõpp-punkti kutsumise hinnangulist maksumust 1 miljon korda ja teine ​​​​keskmist vastuse latentsust. Need mõõdikud võivad teie otsust teha selle kohta, milline lõpp-punkti konfiguratsioon on kõige kuluefektiivsem. Selles näites näeme, et keskmine latentsusaeg väheneb pärast 2048 MB, samas kui kulud kasvavad jätkuvalt, mis näitab, et selle mudeli jaoks oleks kõige optimaalsem mälumahu konfiguratsioon 2048.

Kulude ja stabiilsuse võrdlusaluse lõplik väljund on soovitatav mälukonfiguratsioon koos tabeliga, mis võrdleb serverita lõpp-punkti ja võrreldava SageMakeri hostieksemplari kasutamise kulusid. Kogutud andmete põhjal tegi tööriist kindlaks, et 2048 MB konfiguratsioon on selle mudeli jaoks kõige optimaalsem. Kuigi 3072 konfiguratsioon pakub ligikaudu 10 millisekundit paremat latentsusaega, kaasneb sellega 30% kulude kasv, 4.55 dollarilt 5.95 dollarile miljoni päringu kohta. Lisaks näitab väljund, et serverita lõpp-punkt säästaks kuni 1% võrreldes võrreldava reaalajas hostimise eksemplariga, kui igakuised kutsumispäringud on vähem kui 88.72 miljon, ja reaalajas lõpp-punkt on isegi katkenud pärast 1 miljonit päringut.

Teist tüüpi etalon on valikuline ja testib erinevaid MaxConcurency seaded erinevate liiklusmustrite alusel. Seda võrdlusalust kasutatakse tavaliselt optimaalset MemorySizeInMB konfiguratsiooni stabiilsuse etalonist. Selle võrdlusaluse kaks peamist parameetrit on loetelu MaxConcurency testitavad seaded koos kliendikordajate loendiga, mis määravad simuleeritud samaaegsete klientide arvu, millega lõpp-punkti testitakse.

Näiteks määrates concurrency_benchmark_max_conc parameter kuni [4, 8] ja concurrency_num_clients_multiplier väärtusele [1, 1.5, 2], käivitatakse kaks lõpp-punkti: üks koos MaxConcurency 4 ja teine ​​8. Seejärel võrreldakse iga lõpp-punkti väärtusega (MaxConcurency x kordaja) simuleeritud samaaegsete klientide arv, mis 4 samaaegsusega lõpp-punkti puhul tähendab 4, 6 ja 8 samaaegse kliendiga laadimistesti võrdlusalust.

Selle võrdlusaluse esimene väljund on tabel, mis näitab iga nendega seotud latentsusmõõdikuid, piirangute erandeid ja tehingute kohta sekundis mõõdikuid (TPS). MaxConcurrency konfiguratsioon erineva arvu samaaegsete klientidega. Need mõõdikud aitavad määrata sobiva MaxConcurrency seadistus eeldatava liikluskoormusega toimetulemiseks. Järgmisest tabelist näeme, et lõpp-punkt, mis on konfigureeritud maksimaalse samaaegsusega 8, suutis käsitleda kuni 16 samaaegset klienti, välja arvatud ainult kaks piirava erandit 2,500 kutsest, mis tehti keskmiselt 24 tehinguga sekundis.

Järgmine väljundite komplekt sisaldab iga jaoks diagrammi MaxConcurrency säte, mis näitab latentsusaja jaotust erinevatel koormustel. Selles näites näeme, et lõpp-punkt koos a MaxConcurrency seadistus 4 suutis edukalt töödelda kõiki päringuid kuni 8 samaaegse kliendiga, suurendades kutsumise latentsust minimaalselt.

Lõplik väljund sisaldab tabelit CloudWatchi mõõdikutega igaühe jaoks MaxConcurrency konfiguratsiooni. Erinevalt eelmisest tabelist, mis näitab latentsusaja jaotust iga mälukonfiguratsiooni jaoks, mis ei pruugi alati kuvada külmkäivitust ModelSetupTime mõõdik, kuvatakse see mõõdik selles tabelis palju tõenäolisemalt, kuna kutsumistaotluste arv on suurem ja MaxConcurrency.

Järeldus

Selles postituses tutvustasime SageMaker Serverless Inference Benchmarking Toolkit ning andsime ülevaate selle konfiguratsioonist ja väljunditest. Tööriist aitab teil teha teadlikumaid otsuseid serverita järelduste osas, testides erinevaid konfiguratsioone realistlike liiklusmustritega. Proovige oma mudelitega võrdlusuuringu tööriistakomplekti, et veenduda jõudluses ja kulude kokkuhoius, mida serverita lõpp-punkti juurutamisel oodata võite. Palun vaadake GitHub repo lisadokumentatsiooni ja näidismärkmike jaoks.

Lisaressursid

Autoritest

Simon Zamarin on AI/ML-lahenduste arhitekt, kelle põhirõhk on aidata klientidel oma andmevaradest väärtust ammutada. Vabal ajal veedab Simon meelsasti perega aega, loeb ulmet ja töötab erinevate isetegemismajade projektidega.

Dhawal Patel on AWS-i peamine masinõppe arhitekt. Ta on hajutatud andmetöötluse ja tehisintellektiga seotud probleemide lahendamisel töötanud organisatsioonidega alates suurettevõtetest kuni keskmise suurusega idufirmadeni. Ta keskendub sügavale õppimisele, sealhulgas NLP ja arvutinägemise valdkondadele. Ta aitab klientidel teha SageMakeris suure jõudlusega mudeli järeldusi.

Rishabh Ray Chaudhury on Amazon SageMakeri vanem tootejuht, kes keskendub masinõppe järeldustele. Ta on kirglik uuenduste ja uute kogemuste loomise vastu AWS-is masinõppe klientidele, et aidata nende töökoormust skaleerida. Vabal ajal meeldib talle reisida ja süüa teha. Leiad ta siit LinkedIn.