Benchmark og optimer slutpunktsimplementering i Amazon SageMaker JumpStart | Amazon Web Services

Når de implementerer en stor sprogmodel (LLM), bekymrer maskinlæringsudøvere (ML) sig typisk om to målinger for modelserviceydelse: latens, defineret af den tid, det tager at generere et enkelt token, og gennemløb, defineret af antallet af genererede tokens i sekundet. Selvom en enkelt anmodning til det implementerede slutpunkt ville udvise en gennemstrømning, der omtrent svarer til det omvendte af modellatenstiden, er dette ikke nødvendigvis tilfældet, når flere samtidige anmodninger sendes til slutpunktet samtidigt. På grund af modelserveringsteknikker, såsom klient-side kontinuerlig batching af samtidige anmodninger, har latens og gennemløb et komplekst forhold, der varierer betydeligt baseret på modelarkitektur, serveringskonfigurationer, instanstypehardware, antal samtidige anmodninger og variationer i inputnyttelast som f.eks. som antal input-tokens og output-tokens.

Dette indlæg udforsker disse relationer via en omfattende benchmarking af LLM'er, der er tilgængelige i Amazon SageMaker JumpStart, inklusive Llama 2, Falcon og Mistral-varianter. Med SageMaker JumpStart kan ML-udøvere vælge mellem et bredt udvalg af offentligt tilgængelige fundamentmodeller til at implementere til dedikerede Amazon SageMaker forekomster i et netværksisoleret miljø. Vi leverer teoretiske principper for, hvordan acceleratorspecifikationer påvirker LLM-benchmarking. Vi demonstrerer også virkningen af ​​at implementere flere instanser bag et enkelt slutpunkt. Endelig giver vi praktiske anbefalinger til at skræddersy SageMaker JumpStart-implementeringsprocessen, så den stemmer overens med dine krav til latens, gennemløb, omkostninger og begrænsninger på tilgængelige instanstyper. Alle benchmarking resultater samt anbefalinger er baseret på en alsidig notesbog som du kan tilpasse til din use case.

Implementeret endpoint benchmarking

Følgende figur viser de laveste latenser (venstre) og højeste gennemløbsværdier (højre) for implementeringskonfigurationer på tværs af en række modeltyper og instanstyper. Det er vigtigt, at hver af disse modelimplementeringer bruger standardkonfigurationer som leveret af SageMaker JumpStart givet det ønskede model-id og instanstype til implementering.

Disse latens- og gennemløbsværdier svarer til nyttelaster med 256 input-tokens og 256 output-tokens. Konfigurationen med den laveste latens begrænser model, der betjener en enkelt samtidig anmodning, og den højeste gennemløbskonfiguration maksimerer det mulige antal samtidige anmodninger. Som vi kan se i vores benchmarking, øger stigende samtidige anmodninger monotont gennemstrømningen med aftagende forbedring for store samtidige anmodninger. Derudover er modellerne fuldt sønderdelt på den understøttede instans. For eksempel, fordi ml.g5.48xlarge-instansen har 8 GPU'er, bliver alle SageMaker JumpStart-modeller, der bruger denne instans, sønderdelt ved hjælp af tensor-parallelisme på alle otte tilgængelige acceleratorer.

Vi kan bemærke nogle få ting fra denne figur. For det første er det ikke alle modeller, der understøttes på alle instanser; nogle mindre modeller, såsom Falcon 7B, understøtter ikke modelskæring, hvorimod større modeller har højere krav til computerressourcer. For det andet, efterhånden som sharding øges, forbedres ydeevnen typisk, men forbedres muligvis ikke nødvendigvis for små modeller. Dette skyldes, at små modeller som 7B og 13B pådrager sig betydelige kommunikationsomkostninger, når de fordeles på tværs af for mange acceleratorer. Vi diskuterer dette mere i dybden senere. Endelig har ml.p4d.24xlarge forekomster en tendens til at have betydeligt bedre gennemløb på grund af forbedringer af hukommelsesbåndbredde af A100 i forhold til A10G GPU'er. Som vi diskuterer senere, afhænger beslutningen om at bruge en bestemt instanstype af dine implementeringskrav, herunder latenstid, gennemløb og omkostningsbegrænsninger.

Hvordan kan du opnå disse laveste latency og højeste gennemløbskonfigurationsværdier? Lad os starte med at plotte latens vs. gennemløb for et Llama 2 7B-endepunkt på en ml.g5.12xlarge instans for en nyttelast med 256 input-tokens og 256 output-tokens, som det ses i den følgende kurve. En lignende kurve findes for hvert implementeret LLM-endepunkt.

Efterhånden som samtidigheden stiger, øges gennemløb og latens også monotont. Derfor opstår det laveste latenspunkt ved en samtidig anmodningsværdi på 1, og du kan omkostningseffektivt øge systemgennemstrømningen ved at øge samtidige anmodninger. Der eksisterer et tydeligt "knæ" i denne kurve, hvor det er indlysende, at gennemstrømningsgevinsterne forbundet med yderligere samtidighed ikke opvejer den tilhørende stigning i latens. Den nøjagtige placering af dette knæ er specifik for anvendelsen; nogle praktiserende læger kan definere knæet på det punkt, hvor et forudbestemt latenskrav overskrides (f.eks. 100 ms/token), mens andre kan bruge belastningstestbenchmarks og køteoretiske metoder som halv-latensreglen, og andre kan bruge teoretiske acceleratorspecifikationer.

Vi bemærker også, at det maksimale antal samtidige anmodninger er begrænset. I den foregående figur ender linjesporingen med 192 samtidige anmodninger. Kilden til denne begrænsning er SageMaker påkaldelsestimeoutgrænsen, hvor SageMaker endepunkter timeout et påkaldelsessvar efter 60 sekunder. Denne indstilling er kontospecifik og kan ikke konfigureres for et individuelt slutpunkt. For LLM'er kan det tage sekunder eller endda minutter at generere et stort antal outputtokens. Derfor kan store input- eller output-nyttelaster forårsage, at invokationsanmodningerne mislykkes. Ydermere, hvis antallet af samtidige anmodninger er meget stort, vil mange anmodninger opleve store køtider, hvilket fører til denne 60-sekunders timeoutgrænse. Til formålet med denne undersøgelse bruger vi timeout-grænsen til at definere den maksimalt mulige gennemstrømning for en modelimplementering. Det er vigtigt, at selvom et SageMaker-slutpunkt kan håndtere et stort antal samtidige anmodninger uden at observere en invokationssvar-timeout, vil du måske definere maksimale samtidige anmodninger med hensyn til knæet i latency-throughput-kurven. Dette er sandsynligvis det punkt, hvor du begynder at overveje horisontal skalering, hvor et enkelt slutpunkt sørger for flere forekomster med modelreplikaer og belastningsbalancerer indgående anmodninger mellem replikaerne for at understøtte flere samtidige anmodninger.

Tager man dette et skridt videre, indeholder følgende tabel benchmarking-resultater for forskellige konfigurationer for Llama 2 7B-modellen, herunder forskellige antal input- og output-tokens, instanstyper og antal samtidige anmodninger. Bemærk, at den foregående figur kun plotter en enkelt række i denne tabel.

Vi observerer nogle yderligere mønstre i disse data. Når kontekststørrelsen øges, øges latensen, og gennemløbet falder. For eksempel, på ml.g5.2xlarge med en samtidighed på 1, er gennemløbet 30 tokens/sek., når antallet af samlede tokens er 512, mod 20 tokens/sek., hvis antallet af samlede tokens er 4,096. Dette skyldes, at det tager længere tid at behandle det større input. Vi kan også se, at øget GPU-kapacitet og sharding påvirker den maksimale gennemstrømning og maksimalt understøttede samtidige anmodninger. Tabellen viser, at Llama 2 7B har særligt forskellige maksimale gennemløbsværdier for forskellige instanstyper, og disse maksimale gennemløbsværdier forekommer ved forskellige værdier af samtidige anmodninger. Disse karakteristika ville få en ML-praktiserende læge til at retfærdiggøre omkostningerne ved en instans frem for en anden. For eksempel, givet et lavt latenskrav, kan praktiserende læge vælge en ml.g5.12xlarge instans (4 A10G GPU'er) frem for en ml.g5.2xlarge instans (1 A10G GPU). Hvis der gives et højt gennemløbskrav, vil brugen af ​​en ml.p4d.24xlarge instans (8 A100 GPU'er) med fuld sharding kun være berettiget under høj samtidighed. Bemærk dog, at det ofte er en fordel i stedet at indlæse flere inferenskomponenter af en 7B-model på en enkelt ml.p4d.24xlarge instans; sådan multi-model support diskuteres senere i dette indlæg.

De foregående observationer blev lavet for Llama 2 7B-modellen. Imidlertid forbliver lignende mønstre også gældende for andre modeller. En primær takeaway er, at latency- og gennemløbsydelsestal er afhængige af nyttelast, instanstype og antallet af samtidige anmodninger, så du bliver nødt til at finde den ideelle konfiguration til din specifikke applikation. For at generere de foregående tal til din use case, kan du køre den linkede notesbog, hvor du kan konfigurere denne belastningstestanalyse for din model, instanstype og nyttelast.

Giver mening med acceleratorspecifikationer

Valg af passende hardware til LLM-inferens afhænger i høj grad af specifikke use cases, brugeroplevelsesmål og den valgte LLM. Dette afsnit forsøger at skabe en forståelse af knæet i latency-throughput-kurven med hensyn til principper på højt niveau baseret på acceleratorspecifikationer. Disse principper alene er ikke tilstrækkelige til at træffe en beslutning: rigtige benchmarks er nødvendige. Begrebet enhed bruges her til at omfatte alle ML hardwareacceleratorer. Vi hævder, at knæet i latency-throughput-kurven er drevet af en af ​​to faktorer:

• Acceleratoren har brugt hukommelse til at cache KV-matricer, så efterfølgende anmodninger sættes i kø
• Acceleratoren har stadig ledig hukommelse til KV-cachen, men bruger en stor nok batchstørrelse til, at behandlingstiden er drevet af databehandlingsforsinkelse snarere end hukommelsesbåndbredde

Vi foretrækker typisk at være begrænset af den anden faktor, fordi dette indebærer, at acceleratorressourcerne er mættede. Dybest set maksimerer du de ressourcer, du har betalt for. Lad os undersøge denne påstand mere detaljeret.

KV-cache og enhedshukommelse

Standard transformatoropmærksomhedsmekanismer beregner opmærksomheden for hvert nyt token i forhold til alle tidligere tokens. De fleste moderne ML-servere cacher opmærksomhedsnøgler og værdier i enhedshukommelse (DRAM) for at undgå genberegning ved hvert trin. Dette kaldes dette KV cache, og det vokser med batchstørrelse og sekvenslængde. Den definerer, hvor mange brugeranmodninger, der kan betjenes parallelt, og vil bestemme knæet i latency-throughput-kurven, hvis det beregningsbundne regime i det andet scenario nævnt tidligere ikke er opfyldt endnu, givet den tilgængelige DRAM. Følgende formel er en grov tilnærmelse til den maksimale KV-cachestørrelse.

I denne formel er B batchstørrelse, og N er antallet af acceleratorer. For eksempel bruger Llama 2 7B-modellen i FP16 (2 bytes/parameter) serveret på en A10G GPU (24 GB DRAM) cirka 14 GB, hvilket giver 10 GB til KV-cachen. Hvis du tilslutter modellens fulde kontekstlængde (N = 4096) og resterende parametre (n_layers=32, n_kv_attention_heads=32 og d_attention_head=128), viser dette udtryk, at vi er begrænset til at betjene en batchstørrelse på fire brugere parallelt på grund af DRAM-begrænsninger . Hvis du observerer de tilsvarende benchmarks i den foregående tabel, er dette en god tilnærmelse for det observerede knæ i denne latency-throughput-kurve. Metoder som f.eks grupperet forespørgsel opmærksomhed (GQA) kan reducere KV-cachestørrelsen, i GQA's tilfælde med samme faktor reducerer det antallet af KV-hoveder.

Aritmetisk intensitet og enhedshukommelsesbåndbredde

Væksten i regnekraften af ​​ML-acceleratorer har overhalet deres hukommelsesbåndbredde, hvilket betyder, at de kan udføre mange flere beregninger på hver byte af data i den tid, det tager at få adgang til den byte.

aritmetisk intensitet, eller forholdet mellem beregningsoperationer og hukommelsesadgange, for en operation bestemmer, om den er begrænset af hukommelsesbåndbredde eller beregningskapacitet på den valgte hardware. For eksempel kan en A10G GPU (g5-instanstypefamilie) med 70 TFLOPS FP16 og 600 GB/sek. båndbredde beregne cirka 116 ops/byte. En A100 GPU (p4d-instanstypefamilie) kan beregne cirka 208 ops/byte. Hvis den aritmetiske intensitet for en transformermodel er under denne værdi, er den hukommelsesbundet; hvis den er over, er den beregnet. Opmærksomhedsmekanismen for Llama 2 7B kræver 62 ops/byte for batchstørrelse 1 (for en forklaring, se En guide til LLM-slutning og ydeevne), hvilket betyder, at den er hukommelsesbundet. Når opmærksomhedsmekanismen er hukommelsesbundet, efterlades dyre FLOPS uudnyttede.

Der er to måder at bedre udnytte acceleratoren og øge den aritmetiske intensitet: Reducer de nødvendige hukommelsesadgange til operationen (dette er hvad FlashAttention fokuserer på) eller øge batchstørrelsen. Vi er dog muligvis ikke i stand til at øge vores batchstørrelse nok til at nå et computerbundet regime, hvis vores DRAM er for lille til at indeholde den tilsvarende KV-cache. En grov tilnærmelse af den kritiske batchstørrelse B*, der adskiller computerbundne fra hukommelsesbundne regimer for standard GPT-dekoderinferens, er beskrevet ved følgende udtryk, hvor A_mb er acceleratorhukommelsens båndbredde, A_f er accelerator FLOPS, og N er tallet af acceleratorer. Denne kritiske batchstørrelse kan udledes ved at finde, hvor hukommelsesadgangstid er lig med beregningstid. Henvise til dette blogindlæg at forstå ligning 2 og dens antagelser mere detaljeret.

Dette er det samme ops/byte-forhold, som vi tidligere har beregnet for A10G, så den kritiske batchstørrelse på denne GPU er 116. En måde at nærme sig denne teoretiske, kritiske batchstørrelse på er at øge modelsharding og opdele cachen på tværs af flere N acceleratorer. Dette øger effektivt KV-cachekapaciteten såvel som den hukommelsesbundne batchstørrelse.

En anden fordel ved modelskæring er at opdele modelparameter og dataindlæsningsarbejde på tværs af N acceleratorer. Denne type skæring er en type modelparallelisme, der også kaldes tensor parallelisme. Naivt er der N gange hukommelsesbåndbredden og regnekraften samlet. Hvis vi antager, at der ikke er nogen form for overhead (kommunikation, software og så videre), vil dette reducere afkodningsforsinkelse pr. token med N, hvis vi er hukommelsesbundet, fordi token-afkodningsforsinkelse i dette regime er bundet af den tid, det tager at indlæse modellen vægte og cache. I det virkelige liv resulterer øget grad af sharding imidlertid i øget kommunikation mellem enheder for at dele mellemliggende aktiveringer på hvert modellag. Denne kommunikationshastighed er begrænset af enhedens sammenkoblingsbåndbredde. Det er svært at estimere dens virkning præcist (se for detaljer Model parallelisme), men dette kan i sidste ende stoppe med at give fordele eller forringe ydeevnen - dette gælder især for mindre modeller, fordi mindre dataoverførsler fører til lavere overførselshastigheder.

For at sammenligne ML-acceleratorer baseret på deres specifikationer anbefaler vi følgende. Beregn først den omtrentlige kritiske batchstørrelse for hver acceleratortype i henhold til den anden ligning og KV-cachestørrelsen for den kritiske batchstørrelse ifølge den første ligning. Du kan derefter bruge den tilgængelige DRAM på acceleratoren til at beregne det mindste antal acceleratorer, der kræves for at passe til KV-cachen og modelparametrene. Hvis du vælger mellem flere acceleratorer, skal du prioritere acceleratorer i rækkefølge efter laveste pris pr. GB/sek. hukommelsesbåndbredde. Til sidst skal du benchmarke disse konfigurationer og kontrollere, hvad der er den bedste pris/token for din øvre grænse for ønsket latenstid.

Vælg en slutpunktsimplementeringskonfiguration

Mange LLM'er distribueret af SageMaker JumpStart bruger tekst-generation-inferens (TGI) SageMaker beholder til modelservering. Følgende tabel diskuterer, hvordan man justerer en række modelserveringsparametre for enten at påvirke modelserveringen, som påvirker latency-throughput-kurven, eller beskytte slutpunktet mod anmodninger, der ville overbelaste slutpunktet. Dette er de primære parametre, du kan bruge til at konfigurere din slutpunktsimplementering til dit brugstilfælde. Medmindre andet er angivet, bruger vi standard parametre for tekstgenerering af nyttelast , TGI miljøvariabler.

TGI-serveren bruger kontinuerlig batching, som dynamisk batcher samtidige anmodninger sammen for at dele en enkelt modelslutningsfremgang. Der er to typer fremadgående gennemløb: prefill og decode. Hver ny anmodning skal køre en enkelt forhåndsudfyldning for at udfylde KV-cachen for inputsekvenstokenserne. Efter at KV-cachen er udfyldt, udfører en afkodningsforlænsning en enkelt næste-token-forudsigelse for alle batchforespørgsler, som gentages iterativt for at producere outputsekvensen. Da nye anmodninger sendes til serveren, skal det næste afkodningstrin vente, så prefill-trinnet kan køre for de nye anmodninger. Dette skal ske, før disse nye anmodninger inkluderes i efterfølgende kontinuerligt batchede afkodningstrin. På grund af hardwarebegrænsninger inkluderer den kontinuerlige batching, der bruges til afkodning, muligvis ikke alle anmodninger. På dette tidspunkt kommer anmodninger ind i en behandlingskø, og slutningsforsinkelsen begynder at stige markant med kun mindre gennemløbsforøgelse.

Det er muligt at adskille LLM-latens-benchmarking-analyser i prefill-latens, afkode-latens og kø-latens. Den tid, der forbruges af hver af disse komponenter, er fundamentalt forskellig af natur: Prefill er en engangsberegning, afkodning finder sted én gang for hvert token i outputsekvensen, og kø involverer serverbatch-processer. Når flere samtidige anmodninger behandles, bliver det vanskeligt at adskille forsinkelserne fra hver af disse komponenter, fordi forsinkelsen, der opleves af en given klientanmodning, involverer køforsinkelser drevet af behovet for at forududfylde nye samtidige anmodninger såvel som køforsinkelser drevet af inklusion af anmodningen i batch-afkodningsprocesser. Af denne grund fokuserer dette indlæg på ende-til-ende behandlingsforsinkelse. Knæet i latency-throughput-kurven forekommer på det mætningspunkt, hvor kølatenserne begynder at stige betydeligt. Dette fænomen opstår for enhver modelinferensserver og er drevet af acceleratorspecifikationer.

Fælles krav under udrulning omfatter opfyldelse af et minimum påkrævet gennemløb, maksimal tilladt latens, maksimal pris pr. time og maksimal pris for at generere 1 million tokens. Du bør betinge disse krav på nyttelast, der repræsenterer slutbrugeranmodninger. Et design, der opfylder disse krav, bør tage højde for mange faktorer, herunder den specifikke modelarkitektur, modellens størrelse, instanstyper og instansantal (horisontal skalering). I de følgende afsnit fokuserer vi på at implementere slutpunkter for at minimere latens, maksimere gennemløb og minimere omkostninger. Denne analyse betragter 512 samlede tokens og 256 output-tokens.

Minimer latenstid

Latency er et vigtigt krav i mange tilfælde af brug i realtid. I den følgende tabel ser vi på minimum latency for hver model og hver instanstype. Du kan opnå minimum latenstid ved at indstille MAX_CONCURRENT_REQUESTS = 1.

For at opnå minimumsforsinkelse for en model kan du bruge følgende kode, mens du erstatter dit ønskede model-id og instanstype:

from sagemaker.jumpstart.model import JumpStartModel model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.12xlarge", env={ "MAX_CONCURRENT_REQUESTS": "1", "MAX_INPUT_TOKENS": "256", "MAX_TOTAL_TOKENS": "512", },
)
predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True

Bemærk, at latency-tallene ændrer sig afhængigt af antallet af input- og output-tokens. Implementeringsprocessen forbliver dog den samme undtagen miljøvariablerne MAX_INPUT_TOKENS , MAX_TOTAL_TOKENS. Her er disse miljøvariabler indstillet til at hjælpe med at garantere krav til slutpunktsforsinkelse, fordi større inputsekvenser kan overtræde latenskravet. Bemærk, at SageMaker JumpStart allerede leverer de andre optimale miljøvariabler, når du vælger instanstype; for eksempel vil brug af ml.g5.12xlarge indstilles SM_NUM_GPUS til 4 i modelmiljøet.

Maksimer gennemløbet

I dette afsnit maksimerer vi antallet af genererede tokens pr. sekund. Dette opnås typisk ved de maksimale gyldige samtidige anmodninger for modellen og instanstypen. I den følgende tabel rapporterer vi den opnåede gennemstrømning ved den største samtidige anmodningsværdi, der er opnået, før vi støder på en SageMaker-påkaldelsestimeout for enhver anmodning.

For at opnå maksimal gennemstrømning for en model, kan du bruge følgende kode:

from sagemaker.jumpstart.model import JumpStartModel model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.12xlarge", env={ "MAX_CONCURRENT_REQUESTS": "128", # For your application, identify it from the benchmarking table with the maximum feasible concurrent requests. "MAX_INPUT_TOKENS": "256", "MAX_TOTAL_TOKENS": "512", },
)
predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True

Bemærk, at det maksimale antal samtidige anmodninger afhænger af modeltypen, instanstypen, det maksimale antal inputtokens og det maksimale antal outputtokens. Derfor bør du indstille disse parametre før indstilling MAX_CONCURRENT_REQUESTS.

Bemærk også, at en bruger, der er interesseret i at minimere latens, ofte er i modstrid med en bruger, der er interesseret i at maksimere gennemløbet. Førstnævnte er interesseret i realtidssvar, hvorimod sidstnævnte er interesseret i batchbehandling, således at endepunktskøen altid er mættet, og derved minimerer nedetid for behandling. Brugere, der ønsker at maksimere gennemløbet betinget af latenskrav, er ofte interesserede i at operere ved knæet i latency-throughput-kurven.

Minimer omkostningerne

Den første mulighed for at minimere omkostningerne involverer at minimere omkostningerne pr. time. Med dette kan du implementere en udvalgt model på SageMaker-instansen med den laveste pris pr. time. For realtidspriser for SageMaker-forekomster, se Amazon SageMaker-priser. Generelt er standardinstanstypen for SageMaker JumpStart LLM'er den laveste udrulningsmulighed.

Den anden mulighed for at minimere omkostningerne involverer at minimere omkostningerne for at generere 1 million tokens. Dette er en simpel transformation af den tabel, vi diskuterede tidligere for at maksimere gennemløbet, hvor du først kan beregne den tid, det tager i timer at generere 1 million tokens (1e6 / throughput / 3600). Du kan derefter gange denne tid for at generere 1 million tokens med prisen per time for den angivne SageMaker-instans.

Bemærk, at tilfælde med den laveste pris pr. time ikke er det samme som tilfælde med den laveste pris for at generere 1 million tokens. For eksempel, hvis invokationsanmodningerne er sporadiske, kan en instans med den laveste pris pr. time være optimal, hvorimod den laveste omkostning til at generere en million tokens i reguleringsscenarierne kan være mere passende.

Tensor parallel vs. multi-model trade-off

I alle tidligere analyser overvejede vi at implementere en enkelt model replika med en tensor parallel grad svarende til antallet af GPU'er på implementeringsforekomsttypen. Dette er standard SageMaker JumpStart-adfærd. Som tidligere nævnt kan sønderdeling af en model imidlertid kun forbedre modelforsinkelse og gennemløb op til en vis grænse, ud over hvilken kommunikationskrav mellem enheder dominerer beregningstiden. Dette indebærer, at det ofte er fordelagtigt at implementere flere modeller med en lavere tensor parallel grad på en enkelt instans i stedet for en enkelt model med en højere tensor parallel grad.

Her implementerer vi Llama 2 7B og 13B endepunkter på ml.p4d.24xlarge forekomster med tensor parallel (TP) grader på 1, 2, 4 og 8. For klarhed i modeladfærd indlæser hvert af disse endepunkter kun en enkelt model.

Vores tidligere analyser viste allerede betydelige gennemløbsfordele på ml.p4d.24xlarge-instanser, hvilket ofte oversættes til bedre ydeevne i form af omkostninger for at generere 1 million tokens over g5-instansfamilien under høje samtidige anmodningsbelastningsforhold. Denne analyse viser tydeligt, at du bør overveje afvejningen mellem modelsharding og modelreplikering inden for en enkelt instans; det vil sige, at en fuldt sønderdelt model typisk ikke er den bedste brug af ml.p4d.24xlarge computerressourcer til 7B og 13B modelfamilier. Faktisk opnår du for 7B-modelfamilien den bedste gennemstrømning for en enkelt modelreplika med en tensorparallelgrad på 4 i stedet for 8.

Herfra kan du ekstrapolere, at den højeste gennemløbskonfiguration for 7B-modellen involverer en tensorparallelgrad på 1 med otte modelreplikaer, og den højeste gennemløbskonfiguration for 13B-modellen er sandsynligvis en tensorparallelgrad på 2 med fire modelreplikaer. For at lære mere om, hvordan du opnår dette, se Reducer omkostningerne til modelimplementering med 50 % i gennemsnit ved at bruge de nyeste funktioner i Amazon SageMaker, som demonstrerer brugen af ​​inferenskomponentbaserede endepunkter. På grund af belastningsbalanceringsteknikker, serverrouting og deling af CPU-ressourcer opnår du muligvis ikke fuld gennemstrømningsforbedringer, der nøjagtigt svarer til antallet af replikaer gange gennemløbet for en enkelt replika.

Horisontal skalering

Som observeret tidligere har hver endpoint-implementering en begrænsning på antallet af samtidige anmodninger afhængigt af antallet af input- og outputtokens samt instanstypen. Hvis dette ikke opfylder dit krav om gennemløb eller samtidige anmodninger, kan du skalere op for at bruge mere end én instans bag det implementerede slutpunkt. SageMaker udfører automatisk belastningsbalancering af forespørgsler mellem instanser. For eksempel implementerer følgende kode et slutpunkt, der understøttes af tre forekomster:

model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.2xlarge",
)
predictor = model.deploy( accept_eula=False, # Change EULA acceptance to True initial_instance_count = 3,
)

Følgende tabel viser gennemløbsforstærkningen som en faktor for antallet af tilfælde for Llama 2 7B-modellen.

Det er bemærkelsesværdigt, at knæet i latency-throughput-kurven skifter til højre, fordi højere instanstællinger kan håndtere et større antal samtidige anmodninger inden for multi-instans-endepunktet. For denne tabel er værdien for samtidig anmodning for hele slutpunktet, ikke antallet af samtidige anmodninger, som hver enkelt instans modtager.

Du kan også bruge autoskalering, en funktion til at overvåge dine arbejdsbelastninger og dynamisk justere kapaciteten for at opretholde en stabil og forudsigelig ydeevne til den laveste pris. Dette ligger uden for dette indlægs rammer. For at lære mere om autoskalering, se Konfiguration af autoskalering af inferensslutpunkter i Amazon SageMaker.

Påkald slutpunkt med samtidige anmodninger

Lad os antage, at du har en stor gruppe af forespørgsler, som du gerne vil bruge til at generere svar fra en implementeret model under høje gennemstrømningsforhold. For eksempel, i den følgende kodeblok kompilerer vi en liste med 1,000 nyttelaster, hvor hver nyttelast anmoder om generering af 100 tokens. I alt anmoder vi om generering af 100,000 tokens.

payload = { "inputs": "I believe the meaning of life is to ", "parameters": {"max_new_tokens": 100, "details": True},
}
total_requests = 1000
payloads = [payload,] * total_requests

Når du sender et stort antal anmodninger til SageMaker runtime API, kan du opleve reguleringsfejl. For at afbøde dette kan du oprette en brugerdefineret SageMaker runtime-klient, der øger antallet af genforsøg. Du kan give det resulterende SageMaker-sessionsobjekt til enten JumpStartModel konstruktør eller sagemaker.predictor.retrieve_default hvis du gerne vil knytte en ny forudsigelse til et allerede implementeret slutpunkt. I den følgende kode bruger vi dette sessionsobjekt, når vi implementerer en Llama 2-model med standard SageMaker JumpStart-konfigurationer:

import boto3
from botocore.config import Config
from sagemaker.session import Session
from sagemaker.jumpstart.model import JumpStartModel sagemaker_session = Session( sagemaker_runtime_client=boto3.client( "sagemaker-runtime", config=Config(connect_timeout=10, retries={"mode": "standard", "total_max_attempts": 20}), )
)
model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", sagemaker_session=sagemaker_session
)
predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True

Dette implementerede slutpunkt har MAX_CONCURRENT_REQUESTS = 128 som standard. I den følgende blok bruger vi det samtidige futures-bibliotek til at iterere over at kalde slutpunktet for alle nyttelaster med 128 arbejdstråde. Højst vil endepunktet behandle 128 samtidige anmodninger, og hver gang en anmodning returnerer et svar, vil eksekveren straks sende en ny anmodning til endepunktet.

import time
from concurrent import futures concurrent_requests = 128 time_start = time.time()
with futures.ThreadPoolExecutor(max_workers=concurrent_requests) as executor: responses = list(executor.map(predictor.predict, payloads)) total_tokens = sum([response[0]["details"]["generated_tokens"] for response in responses])
token_throughput = total_tokens / (time.time() - time_start)

Dette resulterer i at generere 100,000 tokens i alt med en gennemstrømning på 1255 tokens/sek. på en enkelt ml.g5.2xlarge instans. Dette tager cirka 80 sekunder at behandle.

Bemærk, at denne gennemløbsværdi er væsentligt anderledes end den maksimale gennemstrømning for Llama 2 7B på ml.g5.2xlarge i de foregående tabeller i dette indlæg (486 tokens/sek. ved 64 samtidige anmodninger). Dette skyldes, at input-nyttelasten bruger 8 tokens i stedet for 256, output-token-antallet er 100 i stedet for 256, og det mindre token-antal tillader 128 samtidige anmodninger. Dette er en sidste påmindelse om, at alle latens- og gennemløbstal er afhængige af nyttelast! Ændring af antal tokener for nyttelast vil påvirke batchprocesser under modelservering, hvilket igen vil påvirke de nye præfill-, afkodnings- og køtider for din applikation.

Konklusion

I dette indlæg præsenterede vi benchmarking af SageMaker JumpStart LLM'er, herunder Llama 2, Mistral og Falcon. Vi præsenterede også en guide til at optimere latenstid, gennemløb og omkostninger for din konfiguration af slutpunktimplementering. Du kan komme i gang ved at køre tilhørende notesbog at benchmarke din use case.

Om forfatterne

 Dr. Kyle Ulrich er en anvendt videnskabsmand hos Amazon SageMaker JumpStart-teamet. Hans forskningsinteresser omfatter skalerbare maskinlæringsalgoritmer, computervision, tidsserier, Bayesianske ikke-parametriske og Gaussiske processer. Hans ph.d. er fra Duke University, og han har udgivet artikler i NeurIPS, Cell og Neuron.

Dr. Vivek Madan er en anvendt videnskabsmand hos Amazon SageMaker JumpStart-teamet. Han fik sin ph.d. fra University of Illinois i Urbana-Champaign og var postdoktor ved Georgia Tech. Han er en aktiv forsker i maskinlæring og algoritmedesign og har publiceret artikler i EMNLP, ICLR, COLT, FOCS og SODA konferencer.

Dr. Ashish Khetan er en Senior Applied Scientist hos Amazon SageMaker JumpStart og hjælper med at udvikle maskinlæringsalgoritmer. Han fik sin ph.d. fra University of Illinois Urbana-Champaign. Han er en aktiv forsker i maskinlæring og statistisk inferens og har publiceret mange artikler i NeurIPS, ICML, ICLR, JMLR, ACL og EMNLP konferencer.

João Moura er Senior AI/ML Specialist Solutions Architect hos AWS. João hjælper AWS-kunder – fra små startups til store virksomheder – med at træne og implementere store modeller effektivt og mere bredt med at bygge ML-platforme på AWS.

• 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/benchmark-and-optimize-endpoint-deployment-in-amazon-sagemaker-jumpstart/