Introduktion til Amazon SageMaker Serverless Inference Benchmarking Toolkit

Amazon SageMaker Serverless Inference er en specialbygget inferensindstilling, der gør det nemt for dig at implementere og skalere maskinlæringsmodeller (ML). Det giver en betal-per-brug-model, som er ideel til tjenester, hvor endpoint-ankaldelser er sjældne og uforudsigelige. I modsætning til et hosting-slutpunkt i realtid, som understøttes af en langvarig instans, leveres computerressourcer til serverløse endepunkter efter behov, hvilket eliminerer behovet for at vælge instanstyper eller administrere skaleringspolitikker.

Følgende højniveauarkitektur illustrerer, hvordan et serverløst slutpunkt fungerer. En klient kalder et slutpunkt, som er understøttet af AWS-administreret infrastruktur.

Serverløse endepunkter er dog tilbøjelige til koldstart i størrelsesordenen sekunder og er derfor mere velegnet til intermitterende eller uforudsigelige arbejdsbelastninger.

For at hjælpe med at afgøre, om et serverløst slutpunkt er den rigtige implementeringsmulighed ud fra et omkostnings- og ydeevneperspektiv, har vi udviklet SageMaker Serverless Inference Benchmarking Toolkit, som tester forskellige slutpunktskonfigurationer og sammenligner den mest optimale med en sammenlignelig realtidshostinginstans.

I dette indlæg introducerer vi værktøjssættet og giver et overblik over dets konfiguration og output.

Løsningsoversigt

Du kan downloade værktøjssættet og installere det fra GitHub repo. Det er nemt at komme i gang: Installer blot biblioteket, opret en SageMaker model, og angiv navnet på din model sammen med en JSON-linjeformateret fil, der indeholder et eksempelsæt af invokationsparametre, inklusive nyttelastens krop og indholdstype. En bekvemmelighedsfunktion er tilvejebragt til at konvertere en liste over prøvekaldsargumenter til en JSON-linjefil eller en pickle-fil til binære nyttelaster såsom billeder, video eller lyd.

Installer værktøjssættet

Installer først benchmarking-biblioteket i dit Python-miljø ved hjælp af pip:

pip install sm-serverless-benchmarking

Du kan køre følgende kode fra en Amazon SageMaker Studio eksempel, SageMaker notebook-forekomst, eller enhver instans med programmatisk adgang til AWS og de relevante AWS identitets- og adgangsstyring (IAM) tilladelser. De nødvendige IAM-tilladelser er dokumenteret i GitHub repo. For yderligere vejledning og eksempler på politikker for IAM henvises til Sådan fungerer Amazon SageMaker med IAM. Denne kode kører et benchmark med et standardsæt af parametre på en model, der forventer et CSV-input med to eksempelposter. Det er en god praksis at give et repræsentativt sæt eksempler til at analysere, hvordan endepunktet klarer sig med forskellige input-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)

Derudover kan du køre benchmark som et SageMaker Processing-job, hvilket kan være en mere pålidelig mulighed for længerevarende benchmarks med et stort antal påkaldelser. 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="",
                    )

Bemærk, at dette vil medføre yderligere omkostninger ved at køre en ml.m5.large SageMaker Processing-instans i hele benchmarkens varighed.

Begge metoder accepterer en række parametre, der skal konfigureres, såsom en liste over hukommelseskonfigurationer, der skal benchmarkes, og antallet af gange, hver konfiguration vil blive aktiveret. I de fleste tilfælde bør standardindstillingerne være tilstrækkelige som udgangspunkt, men henvis til GitHub repo for en komplet liste og beskrivelser af hver parameter.

Benchmarking konfiguration

Før du dykker ned i, hvad benchmark gør, og hvilke output det producerer, er det vigtigt at forstå nogle få nøglebegreber, når det kommer til konfiguration af serverløse slutpunkter.

Der er to vigtige konfigurationsmuligheder: MemorySizeInMB , MaxConcurrency. MemorySizeInMB konfigurerer mængden af ​​hukommelse, der er allokeret til instansen, og kan være 1024 MB, 2048 MB, 3072 MB, 4096 MB, 5120 MB eller 6144 MB. Antallet af vCPU'er skaleres også proportionalt med mængden af ​​allokeret hukommelse. Det MaxConcurrency parameter justerer, hvor mange samtidige anmodninger et slutpunkt er i stand til at betjene. Med en MaxConcurrency af 1, kan et serverløst slutpunkt kun behandle en enkelt anmodning ad gangen.

For at opsummere: MemorySizeInMB parameter giver en mekanisme til vertikal skalerbarhed, så du kan justere hukommelse og beregne ressourcer til at betjene større modeller, mens MaxConcurrency giver en mekanisme til horisontal skalerbarhed, hvilket giver dit slutpunkt mulighed for at behandle flere samtidige anmodninger.

Omkostningerne ved at betjene et endepunkt bestemmes i høj grad af hukommelsesstørrelsen, og der er ingen omkostninger forbundet med at øge den maksimale samtidighed. Der er dog en kontogrænse pr. region for maksimal samtidighed på tværs af alle endepunkter. Henvise til SageMaker-endepunkter og kvoter for de seneste grænser.

Benchmarking af output

Givet dette er målet med benchmarking af et serverløst slutpunkt at bestemme den mest omkostningseffektive og pålidelige hukommelsesstørrelsesindstilling og den minimale maksimale samtidighed, der kan håndtere dine forventede trafikmønstre.

Som standard kører værktøjet to benchmarks. Den første er et stabilitetsbenchmark, som implementerer et slutpunkt for hver af de angivne hukommelseskonfigurationer og påberåber hvert slutpunkt med de medfølgende prøvedata. Målet med dette benchmark er at bestemme den mest effektive og stabile MemorySizeInMB-indstilling. Benchmark fanger kaldforsinkelserne og beregner de forventede omkostninger pr. kald for hvert endepunkt. Det sammenligner derefter omkostningerne med en lignende hosting-instans i realtid.

Når benchmarkingen er fuldført, genererer værktøjet flere output i det angivne result_save_path mappe med følgende mappestruktur:

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

benchmarking_report bibliotek indeholder en konsolideret rapport med alle de sammenfattende output, som vi skitserer i dette indlæg. Yderligere mapper indeholder rå- og mellemoutput, som du kan bruge til yderligere analyser. Der henvises til GitHub repo for en mere detaljeret beskrivelse af hver output-artefakt.

Lad os undersøge et par faktiske benchmarking-output for et slutpunkt, der tjener en computervision MobileNetV2 TensorFlow-model. Hvis du gerne vil gengive dette eksempel, skal du se eksempel notesbøger mappe i GitHub-repoen.

Det første output i den konsoliderede rapport er en oversigtstabel, der giver minimums-, middel-, middel- og maksimumsforsinkelses-metrics for hver MemorySizeInMB vellykket konfiguration af hukommelsesstørrelse. Som vist i nedenstående tabel er den gennemsnitlige påkaldelsesforsinkelse (invocation_latency_mean) fortsatte med at forbedre, da hukommelseskonfigurationen blev øget til 3072 MB, men stoppede med at forbedres derefter.

Ud over de beskrivende statistikker på højt niveau er der tilvejebragt et diagram, der viser fordelingen af ​​latens som observeret fra klienten for hver af hukommelseskonfigurationerne. Igen kan vi observere, at 1024 MB-konfigurationen ikke er så effektiv som de andre muligheder, men der er ikke en væsentlig forskel i ydeevnen i konfigurationer fra 2048 og derover.

amazoncloudwatch målinger, der er knyttet til hver slutpunktskonfiguration, er også tilvejebragt. En nøglemåling her er ModelSetupTime, som måler, hvor lang tid det tog at indlæse modellen, når endepunktet blev påkaldt i en kold tilstand. Metrikken vises muligvis ikke altid i rapporten, da et slutpunkt lanceres i en varm tilstand. EN cold_start_delay parameter er tilgængelig til at angive antallet af sekunder, der skal sove, før benchmark startes på et implementeret slutpunkt. Indstilling af denne parameter til et højere tal, f.eks. 600 sekunder, skulle øge sandsynligheden for en kold tilstandsindkaldelse og forbedre chancerne for at fange denne metric. Derudover er der langt større sandsynlighed for, at denne metrik bliver opfanget med benchmark for samtidig invokation, som vi diskuterer senere i dette afsnit.

Følgende tabel viser de metrics, der er fanget af CloudWatch for hver hukommelseskonfiguration.

Det næste diagram viser ydelse og omkostninger afvejning af forskellige hukommelseskonfigurationer. Den ene linje viser de estimerede omkostninger ved at påkalde slutpunktet 1 million gange, og den anden viser den gennemsnitlige svarforsinkelse. Disse metrics kan informere din beslutning om, hvilken slutpunktskonfiguration der er mest omkostningseffektiv. I dette eksempel ser vi, at den gennemsnitlige latenstid flader ud efter 2048 MB, hvorimod omkostningerne fortsætter med at stige, hvilket indikerer, at for denne model ville en hukommelsesstørrelseskonfiguration på 2048 være mest optimal.

Det endelige output af benchmark for omkostninger og stabilitet er en anbefalet hukommelseskonfiguration sammen med en tabel, der sammenligner omkostningerne ved at drive et serverløst slutpunkt med en sammenlignelig SageMaker-hostinginstans. Baseret på de indsamlede data, fastslog værktøjet, at 2048 MB-konfigurationen er den mest optimale for denne model. Selvom 3072-konfigurationen giver omkring 10 millisekunder bedre latency, kommer det med en stigning på 30 % i omkostningerne, fra $4.55 til $5.95 pr. 1 million anmodninger. Derudover viser outputtet, at et serverløst endepunkt ville give besparelser på op til 88.72 % i forhold til en sammenlignelig real-time hosting-instans, når der er færre end 1 million månedlige anmodninger om kald, og bryder lige med et real-time endepunkt efter 8.5 millioner anmodninger.

Den anden type benchmark er valgfri og tester forskellige MaxConcurency indstillinger under forskellige trafikmønstre. Dette benchmark køres normalt ved at bruge det optimale MemorySizeInMB konfiguration fra stabilitetsbenchmark. De to nøgleparametre for dette benchmark er en liste over MaxConcurency indstillinger for at teste sammen med en liste over klientmultiplikatorer, som bestemmer antallet af simulerede samtidige klienter, som endepunktet testes med.

For eksempel ved at indstille concurrency_benchmark_max_conc parameter til [4, 8] og concurrency_num_clients_multiplier til [1, 1.5, 2], lanceres to endepunkter: et med MaxConcurency af 4 og de andre 8. Hvert endepunkt benchmarkes derefter med en (MaxConcurency x multiplikator) antal simulerede samtidige klienter, som for slutpunktet med en samtidighed på 4 oversættes til belastningstestbenchmarks med 4, 6 og 8 samtidige klienter.

Det første output af dette benchmark er en tabel, der viser ventetid-metrics, drossel-undtagelser og transaktioner pr. sekund-metrics (TPS), der er knyttet til hver MaxConcurrency konfiguration med forskellige antal samtidige klienter. Disse målinger hjælper med at bestemme den passende MaxConcurrency indstilling til at håndtere den forventede trafikbelastning. I den følgende tabel kan vi se, at et slutpunkt konfigureret med en maks. samtidighed på 8 var i stand til at håndtere op til 16 samtidige klienter med kun to begrænsende undtagelser ud af 2,500 opkald foretaget med et gennemsnit på 24 transaktioner i sekundet.

Det næste sæt af output giver et diagram for hver MaxConcurrency indstilling, der viser fordelingen af ​​latens under forskellige belastninger. I dette eksempel kan vi se, at et endepunkt med en MaxConcurrency indstilling på 4 var i stand til at behandle alle anmodninger med op til 8 samtidige klienter med en minimal stigning i invocation latency.

Det endelige output giver en tabel med CloudWatch-metrics for hver MaxConcurrency konfiguration. I modsætning til den foregående tabel, der viser fordelingen af ​​latens for hver hukommelseskonfiguration, som muligvis ikke altid viser koldstart ModelSetupTime metric, er der langt større sandsynlighed for, at denne metric vises i denne tabel på grund af det større antal påkaldelsesanmodninger og et større antal MaxConcurrency.

Konklusion

I dette indlæg introducerede vi SageMaker Serverless Inference Benchmarking Toolkit og gav et overblik over dets konfiguration og output. Værktøjet kan hjælpe dig med at træffe en mere informeret beslutning med hensyn til serverløs inferens ved at afprøve forskellige konfigurationer med realistiske trafikmønstre. Prøv benchmarking-værktøjssættet med dine egne modeller for selv at se den ydeevne og omkostningsbesparelse, du kan forvente ved at implementere et serverløst slutpunkt. Der henvises til GitHub repo for yderligere dokumentation og eksempler på notesbøger.

Yderligere ressourcer

Om forfatterne

Simon Zamarin er en AI/ML Solutions Architect, hvis hovedfokus er at hjælpe kunder med at udvinde værdi fra deres dataaktiver. I sin fritid nyder Simon at bruge tid med familien, læse sci-fi og arbejde på forskellige DIY-husprojekter.

Dhawal Patel er Principal Machine Learning Architect hos AWS. Han har arbejdet med organisationer lige fra store virksomheder til mellemstore startups om problemer relateret til distribueret databehandling og kunstig intelligens. Han fokuserer på dyb læring, herunder NLP og computer vision domæner. Han hjælper kunder med at opnå højtydende modelslutning på SageMaker.

Rishabh Ray Chaudhury er en Senior Product Manager hos Amazon SageMaker, med fokus på maskinlæringsslutning. Han brænder for at innovere og bygge nye oplevelser for maskinlæringskunder på AWS for at hjælpe med at skalere deres arbejdsbyrder. I sin fritid nyder han at rejse og lave mad. Du kan finde ham på LinkedIn.