Minimer slutningsforsinkelse i realtid ved at bruge Amazon SageMaker routingstrategier | Amazon Web Services

Amazon SageMaker gør det nemt at implementere maskinlæringsmodeller (ML) til realtidsslutning og tilbyder et bredt udvalg af ML-instanser, der spænder over CPU'er og acceleratorer som f.eks. AWS-inferens. Som en fuldt administreret service kan du skalere dine modelimplementeringer, minimere slutningsomkostninger og administrere dine modeller mere effektivt i produktionen med reduceret driftsbyrde. Et SageMaker-slutpunkt i realtid består af et HTTPs-slutpunkt og ML-instanser, der er implementeret på tværs af flere tilgængelighedszoner for høj tilgængelighed. SageMaker applikations automatisk skalering kan dynamisk justere antallet af ML-forekomster, der er klargjort for en model, som svar på ændringer i arbejdsbyrden. Slutpunktet fordeler indgående anmodninger ensartet til ML-instanser ved hjælp af en round-robin-algoritme.

Når ML-modeller implementeret på instanser modtager API-kald fra et stort antal klienter, kan en tilfældig fordeling af anmodninger fungere meget godt, når der ikke er meget variation i dine anmodninger og svar. Men i systemer med generative AI-arbejdsbelastninger kan anmodninger og svar være ekstremt varierende. I disse tilfælde er det ofte ønskeligt at load balance ved at overveje kapaciteten og udnyttelsen af ​​instansen frem for tilfældig load balancering.

I dette indlæg diskuterer vi SageMaker-routingstrategien for mindst udestående anmodninger (LOR), og hvordan den kan minimere latens for visse typer af realtids-inferensarbejdsbelastninger ved at tage hensyn til kapaciteten og udnyttelsen af ​​ML-instanser. Vi taler om dens fordele i forhold til standardrutingsmekanismen, og hvordan du kan aktivere LOR for dine modelimplementeringer. Til sidst præsenterer vi en komparativ analyse af latenstidsforbedringer med LOR i forhold til standardrutingsstrategien for tilfældig routing.

SageMaker LOR strategi

Som standard har SageMaker-endepunkter en tilfældig routingstrategi. SageMaker understøtter nu en LOR-strategi, som giver SageMaker mulighed for optimalt at dirigere anmodninger til den instans, der er bedst egnet til at betjene denne anmodning. SageMaker gør dette muligt ved at overvåge belastningen af ​​forekomsterne bag dit slutpunkt og de modeller eller inferenskomponenter, der er implementeret på hver forekomst.

Det følgende interaktive diagram viser standardrutingspolitikken, hvor anmodninger, der kommer til modelslutpunkterne, videresendes på en tilfældig måde til ML-instanserne.

Det følgende interaktive diagram viser routingstrategien, hvor SageMaker vil dirigere anmodningen til den instans, der har det mindste antal udestående anmodninger.

Generelt fungerer LOR-routing godt for grundlæggende modeller eller generative AI-modeller, når din model reagerer på hundredvis af millisekunder til minutter. Hvis dit modelsvar har lavere latenstid (op til hundreder af millisekunder), kan du få mere gavn af tilfældig routing. Uanset hvad, anbefaler vi, at du tester og identificerer den bedste routingalgoritme til dine arbejdsbelastninger.

Sådan indstilles SageMaker routingstrategier

SageMaker giver dig nu mulighed for at indstille RoutingStrategy parameter, mens du opretter EndpointConfiguration for endepunkter. Det anderledes RoutingStrategy værdier, der understøttes af SageMaker er:

• LEAST_OUTSTANDING_REQUESTS
• RANDOM

Følgende er et eksempel på implementering af en model på et inferensendepunkt, der har LOR aktiveret:

1. Opret slutpunktskonfigurationen ved at indstille 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. Opret slutpunktet ved hjælp af slutpunktskonfigurationen (ingen ændring):

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

Præstationsresultater

Vi kørte performance benchmarking for at måle ende-til-ende inferens latens og gennemløb af codegen2-7B model hostet på ml.g5.24xl-instanser med standard routing og smart routing-endepunkter. CodeGen2-modellen tilhører familien af ​​autoregressive sprogmodeller og genererer eksekverbar kode, når der gives engelske prompter.

I vores analyse øgede vi antallet af ml.g5.24xl-forekomster bag hvert endepunkt for hver testkørsel, efterhånden som antallet af samtidige brugere blev øget, som vist i følgende tabel.

Test	Antal samtidige brugere	Antal 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 endepunkter og observerede en 4-33% forbedring i latens, når antallet af tilfælde blev øget fra 5 til 20, som vist i følgende graf.

Tilsvarende observerede vi en forbedring på 15-16 % i gennemløbet pr. minut pr. tilfælde, når antallet af tilfælde blev øget fra 5 til 20.

Dette illustrerer, at smart routing er i stand til at forbedre trafikfordelingen mellem endepunkterne, hvilket fører til forbedringer i ende-til-ende latency og overordnet gennemløb.

Konklusion

I dette indlæg forklarede vi SageMaker-routingstrategierne og den nye mulighed for at aktivere LOR-routing. Vi forklarede, hvordan du aktiverer LOR, og hvordan det kan gavne dine modelimplementeringer. Vores præstationstest viste forbedringer af ventetid og gennemløb under realtidsinferencing. For at lære mere om SageMakers routingfunktioner, se dokumentation. Vi opfordrer dig til at evaluere dine inferensarbejdsbelastninger og afgøre, om du er optimalt konfigureret med routingstrategien.

---

Om forfatterne

James Park er Solutions Architect hos Amazon Web Services. Han arbejder sammen med Amazon.com om at designe, bygge og implementere teknologiløsninger på AWS og har en særlig interesse for kunstig intelligens og maskinlæring. I fritiden nyder han at opsøge nye kulturer, nye oplevelser og holde sig ajour med de nyeste teknologitrends. Du kan finde ham på LinkedIn.

Venugopal Pai er Solutions Architect hos AWS. Han bor i Bengaluru, Indien, og hjælper digital-native kunder med at skalere og optimere deres applikationer på AWS.

David Nigenda er en Senior Software Development Engineer på Amazon SageMaker-teamet, der i øjeblikket arbejder på at forbedre produktionsprocesser for maskinlæring samt lancering af nye inferensfunktioner. I sin fritid forsøger han at følge med sine børn.

Deepti Ragha er softwareudviklingsingeniør i Amazon SageMaker-teamet. Hendes nuværende arbejde fokuserer på at bygge funktioner til effektivt at være vært for maskinlæringsmodeller. I sin fritid nyder hun at rejse, vandre og dyrke planter.

Alan Tan er en Senior Product Manager hos SageMaker, der leder indsatsen inden for store modelslutninger. Han brænder for at anvende maskinlæring til analyseområdet. Uden for arbejdet nyder han udendørslivet.

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 computing og kunstig intelligens. Han fokuserer på Deep learning, herunder NLP og Computer Vision domæner. Han hjælper kunder med at opnå højtydende modelslutning på SageMaker.

• SEO Powered Content & PR Distribution. Bliv forstærket i dag.
• PlatoData.Network Vertical Generative Ai. Styrk dig selv. Adgang her.
• PlatoAiStream. Web3 intelligens. Viden forstærket. Adgang her.
• PlatoESG. Kulstof, CleanTech, Energi, Miljø, Solenergi, Affaldshåndtering. Adgang her.
• PlatoHealth. Bioteknologiske og kliniske forsøgs intelligens. Adgang her.
• Kilde: https://aws.amazon.com/blogs/machine-learning/minimize-real-time-inference-latency-by-using-amazon-sagemaker-routing-strategies/