Vi introduserer Amazon SageMaker Serverless Inference Benchmarking Toolkit

Amazon SageMaker Serverless Inference er et spesialbygd inferensalternativ som gjør det enkelt for deg å distribuere og skalere maskinlæringsmodeller (ML). Den gir en betal-per-bruk-modell, som er ideell for tjenester der endepunktanrop er sjeldne og uforutsigbare. I motsetning til et vertsendepunkt i sanntid, som støttes av en langvarig forekomst, blir dataressurser for serverløse endepunkter klargjort på forespørsel, og eliminerer dermed behovet for å velge forekomsttyper eller administrere skaleringspolicyer.

Følgende høynivåarkitektur illustrerer hvordan et serverløst endepunkt fungerer. En klient påkaller et endepunkt, som er støttet av AWS-administrert infrastruktur.

Serverløse endepunkter er imidlertid utsatt for kaldstart i størrelsesorden sekunder, og er derfor mer egnet for intermitterende eller uforutsigbare arbeidsbelastninger.

For å hjelpe med å finne ut om et serverløst endepunkt er det riktige distribusjonsalternativet fra et kostnads- og ytelsesperspektiv, har vi utviklet SageMaker Serverless Inference Benchmarking Toolkit, som tester forskjellige endepunktkonfigurasjoner og sammenligner den mest optimale mot en sammenlignbar sanntids hosting-forekomst.

I dette innlegget introduserer vi verktøysettet og gir en oversikt over konfigurasjonen og utgangene.

Løsningsoversikt

Du kan laste ned verktøysettet og installere det fra GitHub repo. Det er enkelt å komme i gang: bare installer biblioteket, lag en SageMaker modell, og oppgi navnet på modellen din sammen med en JSON-linjeformatert fil som inneholder et eksempelsett med påkallingsparametere, inkludert nyttelastens kropp og innholdstype. En bekvemmelighetsfunksjon er gitt for å konvertere en liste over eksempel påkallingsargumenter til en JSON-linjefil eller en pickle-fil for binære nyttelaster som bilder, video eller lyd.

Installer verktøysettet

Installer først benchmarking-biblioteket i Python-miljøet ditt ved å bruke pip:

pip install sm-serverless-benchmarking

Du kan kjøre følgende kode fra en Amazon SageMaker Studio forekomst, SageMaker notatbokforekomst, eller en hvilken som helst instans med programmatisk tilgang til AWS og passende AWS identitets- og tilgangsadministrasjon (IAM) tillatelser. De nødvendige IAM-tillatelsene er dokumentert i GitHub repo. For ytterligere veiledning og eksempler på retningslinjer for IAM, se Hvordan Amazon SageMaker fungerer med IAM. Denne koden kjører en benchmark med et standardsett med parametere på en modell som forventer en CSV-inndata med to eksempelposter. Det er en god praksis å gi et representativt sett med eksempler for å analysere hvordan endepunktet presterer med forskjellige nyttelaster.

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)

I tillegg kan du kjøre benchmark som en SageMaker Processing-jobb, som kan være et mer pålitelig alternativ for lengre løpende benchmarks med et stort antall påkallinger. Se følgende kode:

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

Merk at dette vil medføre ekstra kostnader ved å kjøre en ml.m5.large SageMaker Processing-forekomst så lenge referansen varer.

Begge metodene godtar en rekke parametere som skal konfigureres, for eksempel en liste over minnekonfigurasjoner som skal måles og antall ganger hver konfigurasjon vil bli påkalt. I de fleste tilfeller bør standardalternativene være tilstrekkelig som et utgangspunkt, men referer til GitHub repo for en fullstendig liste og beskrivelser av hver parameter.

Konfigurasjon av benchmarking

Før du fordyper deg i hva benchmarken gjør og hvilke utganger den produserer, er det viktig å forstå noen nøkkelbegreper når det gjelder å konfigurere serverløse endepunkter.

Det finnes to viktige konfigurasjonsalternativer: MemorySizeInMB og MaxConcurrency. MemorySizeInMB konfigurerer mengden minne som er allokert til forekomsten, og kan være 1024 MB, 2048 MB, 3072 MB, 4096 MB, 5120 MB eller 6144 MB. Antall vCPU-er skaleres også proporsjonalt med mengden minne som er tildelt. De MaxConcurrency parameter justerer hvor mange samtidige forespørsler et endepunkt er i stand til å betjene. Med en MaxConcurrency av 1 kan et serverløst endepunkt bare behandle en enkelt forespørsel om gangen.

For å oppsummere, MemorySizeInMB parameter gir en mekanisme for vertikal skalerbarhet, slik at du kan justere minne og beregningsressurser for å betjene større modeller, mens MaxConcurrency gir en mekanisme for horisontal skalerbarhet, slik at endepunktet ditt kan behandle flere samtidige forespørsler.

Kostnaden for å betjene et endepunkt bestemmes i stor grad av minnestørrelsen, og det er ingen kostnader forbundet med å øke maks samtidighet. Det er imidlertid en kontogrense per region for maksimal samtidighet på tvers av alle endepunkter. Referere til SageMaker-endepunkter og kvoter for de siste grensene.

Benchmarking utganger

Gitt dette er målet med benchmarking av et serverløst endepunkt å bestemme den mest kostnadseffektive og pålitelige innstillingen for minnestørrelse, og minimum maks samtidighet som kan håndtere dine forventede trafikkmønstre.

Som standard kjører verktøyet to benchmarks. Den første er en stabilitetsreferanse, som distribuerer et endepunkt for hver av de spesifiserte minnekonfigurasjonene og påkaller hvert endepunkt med de oppgitte prøvens nyttelast. Målet med denne benchmarken er å bestemme den mest effektive og stabile MemorySizeInMB-innstillingen. Referansemålet fanger opp påkallingsforsinkelser og beregner den forventede kostnaden per påkalling for hvert endepunkt. Den sammenligner deretter kostnadene mot en lignende sanntids hosting-forekomst.

Når benchmarkingen er fullført, genererer verktøyet flere utganger i det spesifiserte result_save_path katalog med følgende katalogstruktur:

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

De benchmarking_report katalogen inneholder en konsolidert rapport med alle sammendragene som vi skisserer i dette innlegget. Ytterligere kataloger inneholder rå- og mellomutdata som du kan bruke til ytterligere analyser. Referere til GitHub repo for en mer detaljert beskrivelse av hver utdataartefakt.

La oss undersøke noen faktiske benchmarking-utganger for et endepunkt som betjener en datamaskinvisjon MobileNetV2 TensorFlow-modell. Hvis du vil reprodusere dette eksemplet, kan du se eksempel notatbøker katalogen i GitHub-repoen.

Det første resultatet i den konsoliderte rapporten er en sammendragstabell som gir beregningene for minimum, gjennomsnitt, middels og maksimum latens for hver MemorySizeInMB vellykket konfigurasjon av minnestørrelse. Som vist i følgende tabell, gjennomsnittlig påkallingsforsinkelse (invocation_latency_mean) fortsatte å forbedre seg ettersom minnekonfigurasjonen ble økt til 3072 MB, men sluttet å forbedre seg deretter.

I tillegg til den beskrivende statistikken på høyt nivå, er det gitt et diagram som viser fordelingen av latens som observert fra klienten for hver av minnekonfigurasjonene. Igjen kan vi observere at 1024 MB-konfigurasjonen ikke er like effektiv som de andre alternativene, men det er ikke en vesentlig forskjell i ytelse i konfigurasjoner fra 2048 og over.

Amazon CloudWatch målinger knyttet til hver endepunktkonfigurasjon er også gitt. En nøkkelberegning her er ModelSetupTime, som måler hvor lang tid det tok å laste modellen når endepunktet ble påkalt i kald tilstand. Beregningen vises kanskje ikke alltid i rapporten ettersom et endepunkt lanseres i varm tilstand. EN cold_start_delay parameter er tilgjengelig for å spesifisere antall sekunder til hvilemodus før du starter benchmark på et distribuert endepunkt. Hvis du setter denne parameteren til et høyere tall, for eksempel 600 sekunder, bør du øke sannsynligheten for en kall tilstand og forbedre sjansene for å fange opp denne beregningen. I tillegg er det langt mer sannsynlig at denne beregningen fanges opp med benchmark for samtidig påkalling, som vi diskuterer senere i denne delen.

Følgende tabell viser beregningene tatt opp av CloudWatch for hver minnekonfigurasjon.

Det neste diagrammet viser ytelsen og kostnadsavveiningene til forskjellige minnekonfigurasjoner. Den ene linjen viser den estimerte kostnaden ved å påkalle endepunktet 1 million ganger, og den andre viser gjennomsnittlig responsforsinkelse. Disse beregningene kan informere deg om hvilken endepunktkonfigurasjon som er mest kostnadseffektiv. I dette eksemplet ser vi at den gjennomsnittlige ventetiden flater ut etter 2048 MB, mens kostnadene fortsetter å øke, noe som indikerer at for denne modellen vil en minnestørrelseskonfigurasjon på 2048 være mest optimal.

Den endelige utgangen av kostnads- og stabilitetsreferansen er en anbefalt minnekonfigurasjon, sammen med en tabell som sammenligner kostnadene ved drift av et serverløst endepunkt med en sammenlignbar SageMaker-vertsinstans. Basert på dataene som ble samlet inn, bestemte verktøyet at 2048 MB-konfigurasjonen er den mest optimale for denne modellen. Selv om 3072-konfigurasjonen gir omtrent 10 millisekunder bedre ventetid, kommer det med en kostnadsøkning på 30 %, fra $4.55 til $5.95 per 1 million forespørsler. I tillegg viser utdataene at et serverløst endepunkt vil gi besparelser på opptil 88.72 % mot en sammenlignbar sanntids hosting-forekomst når det er færre enn 1 million månedlige invokasjonsforespørsler, og går i balanse med et sanntidsendepunkt etter 8.5 millioner forespørsler.

Den andre typen benchmark er valgfri og tester forskjellige MaxConcurency innstillinger under ulike trafikkmønstre. Denne referansen kjøres vanligvis ved å bruke den optimale MemorySizeInMB konfigurasjon fra stabilitetsreferansen. De to nøkkelparametrene for denne referansen er en liste over MaxConcurency innstillinger for å teste sammen med en liste over klientmultiplikatorer, som bestemmer antallet simulerte samtidige klienter som endepunktet testes med.

For eksempel ved å stille inn concurrency_benchmark_max_conc parameter til [4, 8] og concurrency_num_clients_multiplier til [1, 1.5, 2], lanseres to endepunkter: ett med MaxConcurency av 4 og de andre 8. Hvert endepunkt blir deretter benchmarket med en (MaxConcurency x multiplikator) antall simulerte samtidige klienter, som for endepunktet med en samtidighet på 4 oversettes til belastningstester med 4, 6 og 8 samtidige klienter.

Den første utgangen av denne referansen er en tabell som viser ventetid, reguleringsunntak og transaksjoner per sekund (TPS) knyttet til hver MaxConcurrency konfigurasjon med forskjellig antall samtidige klienter. Disse beregningene hjelper til med å bestemme riktig MaxConcurrency innstilling for å håndtere forventet trafikkbelastning. I den følgende tabellen kan vi se at et endepunkt konfigurert med en maksimal samtidighet på 8 var i stand til å håndtere opptil 16 samtidige klienter med bare to struping-unntak av 2,500 påkallinger gjort med et gjennomsnitt på 24 transaksjoner per sekund.

Det neste settet med utganger gir et diagram for hver MaxConcurrency innstilling som viser fordelingen av latens under forskjellige belastninger. I dette eksemplet kan vi se at et endepunkt med en MaxConcurrency innstilling på 4 var i stand til å behandle alle forespørsler med opptil 8 samtidige klienter med en minimal økning i påkallingsforsinkelse.

Den endelige utgangen gir en tabell med CloudWatch-beregninger for hver MaxConcurrency konfigurasjon. I motsetning til den forrige tabellen som viser fordelingen av latens for hver minnekonfigurasjon, som kanskje ikke alltid viser kaldstart ModelSetupTime beregning, er det langt mer sannsynlig at denne beregningen vises i denne tabellen på grunn av det større antallet påkallingsforespørsler og et større antall MaxConcurrency.

konklusjonen

I dette innlegget introduserte vi SageMaker Serverless Inference Benchmarking Toolkit og ga en oversikt over konfigurasjonen og utgangene. Verktøyet kan hjelpe deg med å ta en mer informert beslutning med hensyn til serverløs slutning ved å lastetesting av forskjellige konfigurasjoner med realistiske trafikkmønstre. Prøv benchmarking-verktøysettet med dine egne modeller for selv å se ytelsen og kostnadsbesparelsen du kan forvente ved å distribuere et serverløst endepunkt. Vennligst referer til GitHub repo for ytterligere dokumentasjon og eksempel notatbøker.

Tilleggsressurser

Om forfatterne

Simon Zamarin er en AI / ML-løsningsarkitekt som har hovedfokus på å hjelpe kunder med å hente ut verdi fra dataenes eiendeler. På fritiden liker Simon å tilbringe tid med familien, lese sci-fi og jobbe med forskjellige DIY-husprosjekter.

Dhawal Patel er en hovedmaskinlæringsarkitekt ved AWS. Han har jobbet med organisasjoner som spenner fra store bedrifter til mellomstore startups med problemer knyttet til distribuert databehandling og kunstig intelligens. Han fokuserer på dyp læring, inkludert NLP og datasynsdomener. Han hjelper kundene med å oppnå høyytelsesmodellslutning på SageMaker.

Rishabh Ray Chaudhury er senior produktsjef hos Amazon SageMaker, med fokus på maskinlæringsslutning. Han brenner for å innovere og bygge nye opplevelser for maskinlæringskunder på AWS for å hjelpe med å skalere arbeidsmengdene deres. På fritiden liker han å reise og lage mat. Du kan finne ham på Linkedin.