Parhaat käytännöt Amazon SageMakerin reaaliaikaisten päätelmien päätepisteiden kuormitustestaukseen

Amazon Sage Maker on täysin hallittu koneoppimispalvelu (ML). SageMakerin avulla datatieteilijät ja -kehittäjät voivat nopeasti ja helposti rakentaa ja kouluttaa ML-malleja ja ottaa ne sitten suoraan käyttöön tuotantovalmiissa isännöitävissä olosuhteissa. Se tarjoaa integroidun Jupyter-kirjoitusmuistikirjan ilmentymän, joka mahdollistaa helpon pääsyn tietolähteihisi tutkimista ja analysointia varten, joten sinun ei tarvitse hallita palvelimia. Se tarjoaa myös yhteistä ML-algoritmit jotka on optimoitu toimimaan tehokkaasti erittäin suuria tietoja vastaan ​​hajautetussa ympäristössä.

SageMakerin reaaliaikainen päättely on ihanteellinen työkuormille, joilla on reaaliaikaiset, vuorovaikutteiset, matalan latenssin vaatimukset. SageMakerin reaaliaikaisen päättelyn avulla voit ottaa käyttöön REST-päätepisteitä, joita tukee tietty ilmentymätyyppi tietyllä määrällä laskentaa ja muistia. Reaaliaikaisen SageMaker-päätepisteen käyttöönotto on monille asiakkaille vasta ensimmäinen askel tuotantoon. Haluamme pystyä maksimoimaan päätepisteen suorituskyvyn saavuttaaksemme tavoitetapahtumat sekunnissa (TPS) noudattaen samalla viivevaatimuksia. Suuri osa päättelyn suorituskyvyn optimoinnista on varmistaa, että valitset oikean ilmentymän tyypin ja lasket takaisin päätepisteeseen.

Tässä viestissä kuvataan parhaat käytännöt SageMaker-päätepisteen kuormitustestaukseen oikean kokoonpanon löytämiseksi esiintymien lukumäärälle ja koolle. Tämä voi auttaa meitä ymmärtämään varattujen ilmentymien vähimmäisvaatimukset, jotta voimme täyttää latenssi- ja TPS-vaatimukset. Sieltä sukeltamme siihen, kuinka voit seurata ja ymmärtää SageMaker-päätepisteen mittareita ja suorituskykyä käyttämällä amazonin pilvikello mittareita.

Vertailemme ensin mallimme suorituskykyä yhdessä esiintymässä tunnistaaksemme TPS:n, jonka se pystyy käsittelemään hyväksyttävien latenssivaatimustemme mukaisesti. Sitten ekstrapoloimme havainnot päättääksemme, kuinka monta tapausta tarvitsemme tuotantoliikenteen käsittelemiseksi. Lopuksi simuloimme tuotantotason liikennettä ja määritämme kuormitustestit reaaliaikaiselle SageMaker-päätepisteelle varmistaaksemme, että päätepisteemme pystyy käsittelemään tuotantotason kuormitusta. Esimerkin koko koodisarja on saatavilla seuraavassa GitHub-arkisto.

Katsaus ratkaisuun

Tätä virkaa varten käytämme esikoulutettua Halaavat kasvot DistilBERT malli mistä Hugging Face Hub. Tämä malli pystyy suorittamaan useita tehtäviä, mutta lähetämme hyötykuorman erityisesti tunteiden analysointia ja tekstin luokittelua varten. Tällä näytehyötykuormalla pyrimme saavuttamaan 1000 TPS:n.

Ota käyttöön reaaliaikainen päätepiste

Tämä viesti olettaa, että tunnet mallin käyttöönoton. Viitata Luo päätepiste ja ota malli käyttöön ymmärtääksesi päätepisteen isännöinnin takana olevat sisäiset tekijät. Toistaiseksi voimme nopeasti osoittaa tähän malliin Hugging Face Hubissa ja ottaa käyttöön reaaliaikaisen päätepisteen seuraavalla koodinpätkällä:

# Hub Model configuration. https://huggingface.co/models
hub = { 'HF_MODEL_ID':'distilbert-base-uncased', 'HF_TASK':'text-classification'
} # create Hugging Face Model Class
huggingface_model = HuggingFaceModel(
transformers_version='4.17.0',
pytorch_version='1.10.2',
py_version='py38',
env=hub,
role=role,
) # deploy model to SageMaker Inference
predictor = huggingface_model.deploy(
initial_instance_count=1, # number of instances
instance_type='ml.m5.12xlarge' # ec2 instance type
)

Testataan päätepisteemme nopeasti näytehyötykuormalla, jota haluamme käyttää kuormitustestaukseen:

import boto3
import json
client = boto3.client('sagemaker-runtime')
content_type = "application/json"
request_body = {'inputs': "I am super happy right now."}
data = json.loads(json.dumps(request_body))
payload = json.dumps(data)
response = client.invoke_endpoint(
EndpointName=predictor.endpoint_name,
ContentType=content_type,
Body=payload)
result = response['Body'].read()
result

Huomaa, että tuemme päätepistettä käyttämällä sinkkua Amazonin elastinen laskentapilvi (Amazon EC2) ilmentymä tyyppiä ml.m5.12xlarge, joka sisältää 48 vCPU:ta ja 192 GiB muistia. vCPU:iden määrä on hyvä osoitus samanaikaisuudesta, jonka ilmentymä pystyy käsittelemään. Yleensä on suositeltavaa testata eri ilmentymätyyppejä varmistaaksemme, että meillä on ilmentymä, jossa on oikein käytettyjä resursseja. Jos haluat nähdä täydellisen luettelon SageMaker-esiintymistä ja niitä vastaavista laskentatehoista reaaliaikaista päättelyä varten, katso Amazon SageMaker -hinnoittelu.

Seurattavat mittarit

Ennen kuin voimme aloittaa kuormitustestauksen, on tärkeää ymmärtää, mitä mittareita seurata, jotta ymmärrät SageMaker-päätepisteesi suorituskykyjakauman. CloudWatch on ensisijainen lokityökalu, jota SageMaker käyttää auttaakseen sinua ymmärtämään päätepisteesi suorituskykyä kuvaavia mittareita. Voit käyttää CloudWatch-lokeja päätepistekutsujen virheenkorjaukseen; kaikki päättelykoodissasi olevat loki- ja tulostuslausunnot tallennetaan tähän. Lisätietoja on kohdassa Kuinka Amazon CloudWatch toimii.

CloudWatch kattaa SageMakerin kahdenlaisia ​​mittareita: ilmentymätason ja kutsun mittareita.

Instanssitason mittarit

Ensimmäinen huomioitava parametrijoukko on ilmentymätason mittarit: CPUUtilization ja MemoryUtilization (GPU-pohjaisissa tapauksissa GPUUtilization). varten CPUUtilization, saatat nähdä yli 100 % prosenttiosuuksia aluksi CloudWatchissa. On tärkeää ymmärtää CPUUtilization, kaikkien CPU-ytimien summa näytetään. Jos esimerkiksi päätepisteesi takana oleva ilmentymä sisältää 4 vCPU:ta, tämä tarkoittaa, että käyttöaste on jopa 400 %. MemoryUtilization, toisaalta on välillä 0–100 %.

Tarkemmin sanottuna voit käyttää CPUUtilization saadaksesi syvemmän käsityksen siitä, onko sinulla riittävästi tai jopa liikaa laitteistoa. Jos sinulla on vajaakäyttöinen ilmentymä (alle 30 %), voit mahdollisesti pienentää ilmentymääsi tyyppiä. Päinvastoin, jos käyttöaste on noin 80–90 %, kannattaa valita ilmentymä, jolla on enemmän laskentaa/muistia. Testiemme perusteella suosittelemme, että laitteistosi käyttöaste on noin 60–70 %.

Kutsumismittarit

Kuten nimestä voi päätellä, kutsumittareita voimme seurata päätepisteeseesi tulevien kutsujen päästä päähän -viivettä. Voit käyttää kutsumittareita virhemäärän ja päätepisteesi mahdollisesti kohtaamien virheiden (5xx, 4xx ja niin edelleen) kaappaamiseen. Vielä tärkeämpää on, että ymmärrät päätepistekutsujen latenssijakauman. Paljon tästä voidaan ottaa talteen ModelLatency ja OverheadLatency mittareita seuraavan kaavion mukaisesti.

- ModelLatency metriikka kaappaa ajan, jonka päättely kestää mallisäiliössä SageMaker-päätepisteen takana. Huomaa, että mallisäilö sisältää myös mukautetun päättelykoodin tai komentosarjat, jotka olet välittänyt johtopäätöstä varten. Tämä yksikkö tallennetaan mikrosekunteina kutsumittarina, ja yleensä voit piirtää prosenttipisteen CloudWatchin kautta (p99, p90 ja niin edelleen) nähdäksesi, saavutatko tavoiteviiveen. Huomaa, että useat tekijät voivat vaikuttaa mallin ja säilön viiveeseen, kuten seuraavat:

• Mukautettu päättelykomentosarja – Olitpa sitten ottanut käyttöön oman säilön tai käyttänyt SageMaker-pohjaista säilöä mukautetuilla päätelmien käsittelijillä, on paras käytäntö profiloida komentosarjasi, jotta saat selville kaikki toiminnot, jotka nimenomaan lisäävät paljon aikaa latenssiisi.
• Viestintäprotokolla – Harkitse REST vs. gRPC -yhteyksiä mallipalvelimeen mallisäilön sisällä.
• Mallikehyksen optimoinnit – Tämä on puitekohtaista, esim TensorFlow, voit virittää useita ympäristömuuttujia, jotka ovat TF-käyttökohtaisia. Varmista, että tarkistat, mitä säilöä käytät ja onko olemassa puitekohtaisia ​​optimointeja, joita voit lisätä komentosarjaan tai ympäristömuuttujiksi lisättäväksi säilöön.

OverheadLatency mitataan ajasta, jolloin SageMaker vastaanottaa pyynnön, kunnes se palauttaa vastauksen asiakkaalle, vähennettynä mallin viiveellä. Tämä osa on suurelta osin hallinnassasi, ja se jää SageMakerin yleiskustannusten alle.

Päästä päähän -viive kokonaisuudessaan riippuu useista tekijöistä, eikä se välttämättä ole niiden summa ModelLatency plus OverheadLatency. Esimerkiksi jos asiakkaasi tekee InvokeEndpoint API-puhelu Internetin kautta, asiakkaan näkökulmasta, päästä päähän -latenssi olisi internet + ModelLatency + OverheadLatency. Sellaisenaan, kun päätepistettäsi kuormitetaan, jotta itse päätepiste voidaan verrata tarkasti, on suositeltavaa keskittyä päätepistemittauksiin (ModelLatency, OverheadLatencyja InvocationsPerInstance) vertaillaksesi SageMaker-päätepistettä tarkasti. Kaikki päästä päähän -latenssiin liittyvät ongelmat voidaan sitten eristää erikseen.

Muutama kysymys, joka on otettava huomioon päästä päähän -viiveen suhteen:

• Missä on asiakas, joka käyttää päätepistettäsi?
• Onko asiakkaasi ja SageMaker-ajoajan välillä välitasoja?

Automaattinen skaalaus

Emme käsittele tässä viestissä erityisesti automaattista skaalausta, mutta se on tärkeä näkökohta, jotta voidaan tarjota oikea määrä esiintymiä työmäärän perusteella. Liikennemalleistasi riippuen voit liittää automaattinen skaalauskäytäntö SageMaker-päätepisteeseen. Skaalausvaihtoehtoja on erilaisia, esim TargetTrackingScaling, SimpleScalingja StepScaling. Näin päätepisteesi voi skaalata sisään ja ulos automaattisesti liikennemallisi perusteella.

Yleinen vaihtoehto on kohdeseuranta, jossa voit määrittää määrittämäsi CloudWatch-mittarin tai mukautetun mittarin ja skaalata sen perusteella. Automaattisen skaalauksen yleinen käyttö seuraa InvocationsPerInstance metrinen. Kun olet tunnistanut pullonkaulan tietyssä TPS:ssä, voit usein käyttää sitä mittarina skaalautuaksesi useampaan määrään tapauksia, jotta pystyt käsittelemään liikenteen huippukuormia. Katso tarkempi erittely SageMakerin automaattisen skaalauksen päätepisteistä Autoscaling johtopäätösten päätepisteiden määrittäminen Amazon SageMakerissa.

Kuormitustestaus

Vaikka käytämme Locustia näyttääksemme, kuinka voimme ladata testin mittakaavassa, jos yrität mitoittaa päätepisteesi takana olevan ilmentymän oikein, SageMakerin päättelysuositus on tehokkaampi vaihtoehto. Kolmannen osapuolen kuormitustestaustyökaluilla sinun on otettava päätepisteet käyttöön manuaalisesti eri instansseissa. Inference Recommenderin avulla voit yksinkertaisesti välittää joukon ilmentymätyyppejä, joita vastaan ​​haluat ladata testin, ja SageMaker pyörii. työpaikat jokaiselle näistä tapauksista.

heinäsirkka

Tässä esimerkissä käytämme heinäsirkka, avoimen lähdekoodin kuormitustestaustyökalu, jonka voit toteuttaa Pythonilla. Locust on samanlainen kuin monet muut avoimen lähdekoodin kuormitustestaustyökalut, mutta sillä on muutamia erityisiä etuja:

• Helppo asentaa – Kuten tässä viestissä osoitamme, välitämme yksinkertaisen Python-komentosarjan, joka voidaan helposti muokata uudelleen tiettyä päätepistettäsi ja hyötykuormaa varten.
• Hajautettu ja skaalautuva – Locust on tapahtumapohjainen ja hyödyntää gevent konepellin alle. Tämä on erittäin hyödyllistä testattaessa erittäin samanaikaisia ​​työkuormia ja simuloitaessa tuhansia samanaikaisia ​​käyttäjiä. Voit saavuttaa korkean TPS:n yhdellä prosessilla, jossa on käynnissä Locust, mutta siinä on myös a hajautettu kuormitus ominaisuus, jonka avulla voit skaalata useisiin prosesseihin ja asiakaskoneisiin, kuten tutkimme tässä viestissä.
• Locust-mittarit ja käyttöliittymä – Locust tallentaa myös päästä päähän -viiveen mittarina. Tämä voi auttaa täydentämään CloudWatch-mittareitasi ja luomaan täydellisen kuvan testeistäsi. Tämä kaikki on tallennettu Locust-käyttöliittymään, jossa voit seurata samanaikaisia ​​käyttäjiä, työntekijöitä ja paljon muuta.

Jos haluat ymmärtää Locustia paremmin, tutustu niihin dokumentointi.

Amazon EC2 -asennus

Voit määrittää Locustin missä tahansa yhteensopivassa ympäristössä. Tätä viestiä varten määritimme EC2-esiintymän ja asennamme siihen Locustin testien suorittamista varten. Käytämme c5.18xlarge EC2-instanssia. Asiakaspuolen laskentateho on myös huomioitava asia. Joskus, kun asiakaspuolen laskentateho loppuu, tätä ei usein kaapata, ja sitä pidetään SageMaker-päätepistevirheenä. On tärkeää sijoittaa asiakas paikkaan, jossa on riittävä laskentateho ja joka kestää testattavan kuormituksen. EC2-esiintymässämme käytämme Ubuntu Deep Learning AMI:tä, mutta voit käyttää mitä tahansa AMI:tä, kunhan voit määrittää Locustin oikein koneelle. Katso opetusohjelmasta, kuinka käynnistät EC2-instanssisi ja muodostat siihen yhteyden Aloita Amazon EC2 Linux -esiintymien käyttö.

Locust-käyttöliittymään pääsee portin 8089 kautta. Voimme avata tämän muokkaamalla saapuvan tietoturvaryhmän sääntöjä EC2-instanssille. Avaamme myös portin 22, jotta voimme SSH:ta EC2-instanssiin. Harkitse lähteen rajaamista tiettyyn IP-osoitteeseen, josta käytät EC2-esiintymää.

Kun olet muodostanut yhteyden EC2-esiintymääsi, määritämme Python-virtuaaliympäristön ja asennamme avoimen lähdekoodin Locust API:n CLI:n kautta:

virtualenv venv #venv is the virtual environment name, you can change as you desire
source venv/bin/activate #activate virtual environment
pip install locust

Olemme nyt valmiita työskentelemään Locustin kanssa päätepisteemme kuormitustestauksessa.

Heinäsirkkatestaus

Kaikki Locust-kuormitustestit suoritetaan a Locust-tiedosto jonka tarjoat. Tämä Locust-tiedosto määrittää tehtävän kuormitustestille; tässä määrittelemme Boto3:n invoke_endpoint API-kutsu. Katso seuraava koodi:

config = Config(
retries = { 'max_attempts': 0, 'mode': 'standard'
}
) self.sagemaker_client = boto3.client('sagemaker-runtime',config=config)
self.endpoint_name = host.split('/')[-1]
self.region = region
self.content_type = content_type
self.payload = payload

Säädä edellisessä koodissa kutsun päätepistekutsuparametreja vastaamaan tiettyä mallikutsuasi. Käytämme InvokeEndpoint API käyttäen seuraavaa koodinpätkää Locust-tiedostossa; tämä on kuormitustestipisteemme. Käyttämämme Locust-tiedosto on locust_script.py.

def send(self): request_meta = { "request_type": "InvokeEndpoint", "name": "SageMaker", "start_time": time.time(), "response_length": 0, "response": None, "context": {}, "exception": None,
}
start_perf_counter = time.perf_counter() try:
response = self.sagemaker_client.invoke_endpoint(
EndpointName=self.endpoint_name,
Body=self.payload,
ContentType=self.content_type
)
response_body = response["Body"].read()

Nyt kun meillä on Locust-skripti valmiina, haluamme suorittaa hajautettuja Locust-testejä yksittäisen esiintymän stressitestaamiseksi selvittääksemme, kuinka paljon liikennettä ilmentymämme pystyy käsittelemään.

Locust-hajautettu tila on hieman vivahteikas kuin yhden prosessin Locust-testi. Hajautetussa tilassa meillä on yksi ensisijainen ja useita työntekijöitä. Ensisijainen työntekijä opastaa työntekijöitä luomaan ja hallitsemaan samanaikaisia ​​​​käyttäjiä, jotka lähettävät pyynnön. Meidän jaettu.sh Näemme oletuksena, että 240 käyttäjää jaetaan 60 työntekijän kesken. Huomaa, että --headless lippu Locustin CLI:ssä poistaa Locustin käyttöliittymäominaisuuden.

#replace with your endpoint name in format https://<<endpoint-name>>
export ENDPOINT_NAME=https://$1 export REGION=us-east-1
export CONTENT_TYPE=application/json
export PAYLOAD='{"inputs": "I am super happy right now."}'
export USERS=240
export WORKERS=60
export RUN_TIME=1m
export LOCUST_UI=false # Use Locust UI .
.
. locust -f $SCRIPT -H $ENDPOINT_NAME --master --expect-workers $WORKERS -u $USERS -t $RUN_TIME --csv results &
.
.
. for (( c=1; c<=$WORKERS; c++ ))
do
locust -f $SCRIPT -H $ENDPOINT_NAME --worker --master-host=localhost &
done

./distributed.sh huggingface-pytorch-inference-2022-10-04-02-46-44-677 #to execute Distributed Locust test

Suoritamme ensin hajautetun testin yhdelle päätepisteen taustalla olevalle ilmentymälle. Ajatuksena tässä on, että haluamme maksimoida yksittäisen esiintymän täysin ymmärtääksemme ilmentymien määrän, jota tarvitsemme saavuttaaksemme TPS-tavoitteemme ja pysyäksemme latenssivaatimuksissamme. Huomaa, että jos haluat käyttää käyttöliittymää, muuta Locust_UI ympäristömuuttujan arvoksi True ja ota EC2-ilmentymäsi julkinen IP-osoite ja yhdistä portti 8089 URL-osoitteeseen.

Seuraava kuvakaappaus näyttää CloudWatch-mittarimme.

Lopulta huomaamme, että vaikka saavutamme aluksi 200 TPS:n, alamme havaita 5xx-virheitä EC2-asiakaspuolen lokeissamme, kuten seuraavassa kuvakaappauksessa näkyy.

Voimme myös varmistaa tämän tarkastelemalla erityisesti esiintymätason mittareitamme CPUUtilization.

Tässä huomaamme CPUUtilization lähes 4,800 %. Meidän ml.m5.12x.large ilmentymässä on 48 vCPU:ta (48 * 100 = 4800~). Tämä kyllästää koko ilmentymän, mikä auttaa myös selittämään 5xx-virheemme. Näemme myös kasvun ModelLatency.

Näyttää siltä, ​​​​että yksittäinen ilmentymämme on kaatumassa, eikä sillä ole laskentaa kestämään havaitsemamme 200 TPS:n ylittävää kuormaa. Tavoite-TPS:mme on 1000, joten yritetään nostaa ilmentymien lukumäärä 5:een. Tuotantoympäristössä tämä saattaa olla vieläkin suurempi, koska havaitsimme virheitä 200 TPS:ssä tietyn pisteen jälkeen.

Näemme sekä Locust UI- että CloudWatch-lokeissa, että meillä on lähes 1000 XNUMX TPS:ää ja viisi esiintymää tukee päätepistettä.

Jos alat kokea virheitä jopa tämän laitteiston asennuksen kanssa, muista seurata CPUUtilization ymmärtääksesi kokonaiskuvan päätepisteesi ylläpidosta. On erittäin tärkeää ymmärtää laitteistosi käyttöaste, jotta näet, tarvitseeko sinun skaalata ylös vai jopa alas. Joskus säilötason ongelmat johtavat 5xx-virheisiin, mutta jos CPUUtilization on alhainen, se osoittaa, että näihin ongelmiin saattaa johtua jokin laitteistosi, vaan jokin säilön tai mallin tasolla (esim. oikeaa ympäristömuuttujaa työntekijöiden lukumäärälle ei ole asetettu). Toisaalta, jos huomaat ilmentymäsi olevan täysin kyllästynyt, se on merkki siitä, että sinun on joko lisättävä nykyistä ilmentymää tai kokeiltava suurempaa ilmentymää pienemmällä kalustolla.

Vaikka lisäsimme esiintymien lukumäärän viiteen 5 TPS:n käsittelemiseksi, voimme nähdä, että ModelLatency mittari on edelleen korkea. Tämä johtuu siitä, että esiintymät ovat kyllästyneet. Yleisesti suosittelemme, että instanssin resursseja käytetään 60–70 %.

Puhdistaa

Muista puhdistaa kuormitustestauksen jälkeen kaikki resurssit, joita et käytä SageMaker-konsolin tai delete_endpoint Boto3 API -kutsu. Varmista lisäksi, että lopetat EC2-esiintymän tai minkä tahansa asiakkaan asennuksen, jotta siitä ei myöskään aiheudu lisäkuluja.

Yhteenveto

Tässä viestissä kuvailimme, kuinka voit ladata reaaliaikaisen SageMaker-päätepisteesi. Keskustelimme myös siitä, mitä mittareita sinun tulisi arvioida päätepisteen kuormitustestauksen aikana, jotta voit ymmärtää tehokkuuden jakautumisen. Muista tarkistaa SageMakerin päättelysuositus ymmärtää paremmin ilmentymän oikean kokoista ja enemmän suorituskyvyn optimointitekniikoita.

Tietoja Tekijät

Marc Karp on ML-arkkitehti SageMaker Service -tiimin kanssa. Hän keskittyy auttamaan asiakkaita suunnittelemaan, ottamaan käyttöön ja hallitsemaan ML-työkuormia mittakaavassa. Vapaa-ajallaan hän nauttii matkustamisesta ja uusien paikkojen tutkimisesta.

Ram Vegiraju on ML-arkkitehti SageMaker Service -tiimin kanssa. Hän keskittyy auttamaan asiakkaita rakentamaan ja optimoimaan AI/ML-ratkaisujaan Amazon SageMakerissa. Vapaa-ajallaan hän rakastaa matkustamista ja kirjoittamista.

• SEO-pohjainen sisällön ja PR-jakelu. Vahvista jo tänään.
• Platoblockchain. Web3 Metaverse Intelligence. Tietoa laajennettu. Pääsy tästä.
• Lähde: https://aws.amazon.com/blogs/machine-learning/best-practices-for-load-testing-amazon-sagemaker-real-time-inference-endpoints/