Minimer sanntids slutningsforsinkelse ved å bruke Amazon SageMaker-rutingsstrategier | Amazon Web Services

Amazon SageMaker gjør det enkelt å distribuere maskinlæringsmodeller (ML) for sanntidsslutning og tilbyr et bredt utvalg av ML-forekomster som spenner over CPUer og akseleratorer som f.eks. AWS slutning. Som en fullstendig administrert tjeneste kan du skalere modelldistribusjonene dine, minimere slutningskostnader og administrere modellene dine mer effektivt i produksjon med redusert driftsbyrde. Et SageMaker sanntidsslutningsendepunkt består av et HTTPs-endepunkt og ML-forekomster som er distribuert på tvers av flere tilgjengelighetssoner for høy tilgjengelighet. SageMaker automatisk skalering av applikasjoner kan dynamisk justere antall ML-forekomster klargjort for en modell som svar på endringer i arbeidsbelastning. Endepunktet distribuerer innkommende forespørsler jevnt til ML-instanser ved hjelp av en round-robin-algoritme.

Når ML-modeller distribuert på instanser mottar API-anrop fra et stort antall klienter, kan en tilfeldig fordeling av forespørsler fungere veldig bra når det ikke er mye variasjon i forespørslene og svarene dine. Men i systemer med generative AI-arbeidsbelastninger kan forespørsler og svar være ekstremt varierende. I disse tilfellene er det ofte ønskelig med belastningsbalanse ved å vurdere kapasiteten og utnyttelsen av instansen i stedet for tilfeldig belastningsbalansering.

I dette innlegget diskuterer vi SageMaker-rutingsstrategien for minst utestående forespørsler (LOR) og hvordan den kan minimere ventetiden for visse typer slutningsarbeidsbelastninger i sanntid ved å ta hensyn til kapasiteten og utnyttelsen av ML-forekomster. Vi snakker om fordelene i forhold til standardrutingsmekanismen og hvordan du kan aktivere LOR for modelldistribusjonene dine. Til slutt presenterer vi en komparativ analyse av latenstidsforbedringer med LOR i forhold til standard rutingstrategi for tilfeldig ruting.

SageMaker LOR-strategi

Som standard har SageMaker-endepunkter en tilfeldig rutingstrategi. SageMaker støtter nå en LOR-strategi, som lar SageMaker optimalt rute forespørsler til den instansen som er best egnet til å betjene den forespørselen. SageMaker gjør dette mulig ved å overvåke belastningen av forekomstene bak endepunktet ditt, og modellene eller slutningskomponentene som er distribuert på hver forekomst.

Følgende interaktive diagram viser standard rutingpolicy der forespørsler som kommer til modellendepunktene videresendes på en tilfeldig måte til ML-forekomstene.

Følgende interaktive diagram viser rutingstrategien der SageMaker vil rute forespørselen til forekomsten som har minst antall utestående forespørsler.

Generelt fungerer LOR-ruting bra for grunnleggende modeller eller generative AI-modeller når modellen din reagerer på hundrevis av millisekunder til minutter. Hvis modellresponsen din har lavere ventetid (opptil hundrevis av millisekunder), kan du ha mer nytte av tilfeldig ruting. Uansett anbefaler vi at du tester og identifiserer den beste rutingalgoritmen for arbeidsbelastningene dine.

Hvordan sette SageMaker rutingstrategier

SageMaker lar deg nå stille inn RoutingStrategy parameter mens du oppretter EndpointConfiguration for endepunkter. Forskjellen RoutingStrategy verdier som støttes av SageMaker er:

• LEAST_OUTSTANDING_REQUESTS
• RANDOM

Følgende er et eksempel på distribusjon av en modell på et inferensendepunkt som har LOR aktivert:

1. Opprett endepunktkonfigurasjonen ved å stille inn RoutingStrategy as LEAST_OUTSTANDING_REQUESTS:

   endpoint_config_response = sm_client.create_endpoint_config( EndpointConfigName=endpoint_config_name, ProductionVariants=[ { "VariantName": "variant1", "ModelName": model_name, "InstanceType": "instance_type", "InitialInstanceCount": initial_instance_count, ….. "RoutingConfig": { 'RoutingStrategy': 'LEAST_OUTSTANDING_REQUESTS'} }, ],
   )

2. Opprett endepunktet ved hjelp av endepunktkonfigurasjonen (ingen endring):

   create_endpoint_response = sm_client.create_endpoint( EndpointName="endpoint_name", EndpointConfigName="endpoint_config_name"
   )

Ytelsesresultater

Vi kjørte ytelsesbenchmarking for å måle ende-til-ende slutningsforsinkelse og gjennomstrømning av kodegen2-7B modell vert for ml.g5.24xl-forekomster med standard ruting og smart ruting-endepunkter. CodeGen2-modellen tilhører familien av autoregressive språkmodeller og genererer kjørbar kode når det gis engelske spørsmål.

I vår analyse økte vi antallet ml.g5.24xl-forekomster bak hvert endepunkt for hver testkjøring ettersom antallet samtidige brukere ble økt, som vist i følgende tabell.

Test	Antall samtidige brukere	Antall forekomster
1	4	1
2	20	5
3	40	10
4	60	15
5	80	20

Vi målte ende-til-ende P99-latens for begge endepunktene og observerte en 4–33 % forbedring i latens når antall forekomster ble økt fra 5 til 20, som vist i følgende graf.

Tilsvarende observerte vi en forbedring på 15–16 % i gjennomstrømmingen per minutt per forekomst når antall forekomster ble økt fra 5 til 20.

Dette illustrerer at smart ruting er i stand til å forbedre trafikkfordelingen mellom endepunktene, noe som fører til forbedringer i ende-til-ende-latens og total gjennomstrømning.

konklusjonen

I dette innlegget forklarte vi SageMaker-rutingsstrategiene og det nye alternativet for å aktivere LOR-ruting. Vi forklarte hvordan du aktiverer LOR og hvordan det kan være til nytte for modelldistribusjonene dine. Ytelsestestene våre viste forbedringer av ventetid og gjennomstrømning under sanntidsslutning. For å lære mer om SageMaker rutingfunksjoner, se dokumentasjon. Vi oppfordrer deg til å evaluere arbeidsbelastningene dine og finne ut om du er optimalt konfigurert med rutingstrategien.

---

Om forfatterne

James Park er løsningsarkitekt hos Amazon Web Services. Han jobber med Amazon.com for å designe, bygge og distribuere teknologiløsninger på AWS, og har en spesiell interesse for AI og maskinlæring. På fritiden liker han å oppsøke nye kulturer, nye opplevelser og holde seg oppdatert med de nyeste teknologitrendene. Du kan finne ham på Linkedin.

Venugopal Pai er løsningsarkitekt hos AWS. Han bor i Bengaluru, India, og hjelper digital-native kunder med å skalere og optimalisere applikasjonene sine på AWS.

David Nigenda er en senior programvareutviklingsingeniør på Amazon SageMaker-teamet, og jobber for tiden med å forbedre arbeidsflyter for maskinlæring i produksjon, samt lanserer nye inferensfunksjoner. På fritiden prøver han å holde tritt med barna sine.

Deepti Ragha er en programvareutviklingsingeniør i Amazon SageMaker-teamet. Hennes nåværende arbeid fokuserer på å bygge funksjoner for å være vert for maskinlæringsmodeller effektivt. På fritiden liker hun å reise, gå tur og dyrke planter.

Alan Tan er en senior produktsjef hos SageMaker, og leder innsatsen for store modellslutninger. Han brenner for å bruke maskinlæring på analyseområdet. Utenom jobben liker han å være ute.

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 Computer Vision-domener. Han hjelper kundene med å oppnå høy ytelse modellslutning på SageMaker.

• SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
• PlatoData.Network Vertical Generative Ai. Styrk deg selv. Tilgang her.
• PlatoAiStream. Web3 Intelligence. Kunnskap forsterket. Tilgang her.
• PlatoESG. Karbon, CleanTech, Energi, Miljø, Solenergi, Avfallshåndtering. Tilgang her.
• PlatoHelse. Bioteknologisk og klinisk etterretning. Tilgang her.
• kilde: https://aws.amazon.com/blogs/machine-learning/minimize-real-time-inference-latency-by-using-amazon-sagemaker-routing-strategies/