Benchmark og optimaliser endepunktdistribusjon i Amazon SageMaker JumpStart | Amazon Web Services

Når de distribuerer en stor språkmodell (LLM), bryr maskinlæringsutøvere (ML) seg vanligvis om to målinger for modellvisningsytelse: latens, definert av tiden det tar å generere et enkelt token, og gjennomstrømning, definert av antall tokens generert per sekund. Selv om en enkelt forespørsel til det utplasserte endepunktet vil ha en gjennomstrømning som er omtrent lik invers av modelllatens, er dette ikke nødvendigvis tilfellet når flere samtidige forespørsler sendes til endepunktet samtidig. På grunn av modellserveringsteknikker, som for eksempel kontinuerlig batching av samtidige forespørsler på klientsiden, har latens og gjennomstrømning et komplekst forhold som varierer betydelig basert på modellarkitektur, serveringskonfigurasjoner, maskinvare for forekomsttype, antall samtidige forespørsler og variasjoner i input-nyttelast som f.eks. som antall input tokens og output tokens.

Dette innlegget utforsker disse forholdene via en omfattende benchmarking av LLM-er tilgjengelig i Amazon SageMaker JumpStart, inkludert Llama 2, Falcon og Mistral-varianter. Med SageMaker JumpStart kan ML-utøvere velge fra et bredt utvalg av offentlig tilgjengelige grunnmodeller for å distribuere til dedikerte Amazon SageMaker forekomster i et nettverksisolert miljø. Vi gir teoretiske prinsipper for hvordan akseleratorspesifikasjoner påvirker LLM-benchmarking. Vi viser også virkningen av å distribuere flere forekomster bak ett enkelt endepunkt. Til slutt gir vi praktiske anbefalinger for å skreddersy SageMaker JumpStart-distribusjonsprosessen for å samsvare med dine krav til ventetid, gjennomstrømning, kostnader og begrensninger på tilgjengelige forekomsttyper. Alle benchmarking-resultater samt anbefalinger er basert på en allsidig bærbare som du kan tilpasse til ditt bruksområde.

Utplassert endepunktsbenchmarking

Følgende figur viser de laveste ventetidene (venstre) og høyeste gjennomstrømningsverdier (høyre) for distribusjonskonfigurasjoner på tvers av en rekke modelltyper og forekomsttyper. Det er viktig at hver av disse modelldistribusjonene bruker standardkonfigurasjoner som levert av SageMaker JumpStart gitt ønsket modell-ID og forekomsttype for distribusjon.

Disse latens- og gjennomstrømningsverdiene tilsvarer nyttelaster med 256 input tokens og 256 output tokens. Den laveste latenskonfigurasjonen begrenser modellen som betjener en enkelt samtidig forespørsel, og konfigurasjonen med høyeste gjennomstrømming maksimerer det mulige antallet samtidige forespørsler. Som vi kan se i vår benchmarking, øker økende samtidige forespørsler monotont gjennomstrømningen med avtagende forbedring for store samtidige forespørsler. I tillegg er modellene fullstendig sønderdelt på den støttede forekomsten. For eksempel, fordi ml.g5.48xlarge-forekomsten har 8 GPUer, blir alle SageMaker JumpStart-modeller som bruker denne forekomsten sønderdelt ved hjelp av tensorparallellisme på alle de åtte tilgjengelige akseleratorene.

Vi kan merke oss noen få ting fra denne figuren. For det første støttes ikke alle modeller på alle forekomster; noen mindre modeller, for eksempel Falcon 7B, støtter ikke modellskjæring, mens større modeller har høyere krav til dataressurser. For det andre, ettersom sharding øker, forbedres ytelsen vanligvis, men forbedres ikke nødvendigvis for små modeller. Dette er fordi små modeller som 7B og 13B pådrar seg betydelige kommunikasjonskostnader når de deles over for mange akseleratorer. Vi diskuterer dette mer inngående senere. Til slutt har ml.p4d.24xlarge-forekomster en tendens til å ha betydelig bedre gjennomstrømning på grunn av minnebåndbreddeforbedringer av A100 over A10G GPUer. Som vi diskuterer senere, avhenger beslutningen om å bruke en bestemt forekomsttype av distribusjonskravene dine, inkludert ventetid, gjennomstrømning og kostnadsbegrensninger.

Hvordan kan du oppnå disse konfigurasjonsverdiene for lavest ventetid og høyest gjennomstrømming? La oss starte med å plotte latens vs. gjennomstrømning for et Llama 2 7B-endepunkt på en ml.g5.12xlarge forekomst for en nyttelast med 256 input-tokens og 256 output-tokens, som vist i følgende kurve. En lignende kurve eksisterer for hvert utplassert LLM-endepunkt.

Når samtidigheten øker, øker også gjennomstrømning og latens monotont. Derfor oppstår det laveste latenspunktet ved en samtidig forespørselsverdi på 1, og du kan kostnadseffektivt øke systemgjennomstrømningen ved å øke samtidige forespørsler. Det eksisterer et distinkt "kne" i denne kurven, der det er åpenbart at gjennomstrømningsgevinsten forbundet med ytterligere samtidighet ikke oppveier den tilhørende økningen i latens. Den nøyaktige plasseringen av dette kneet er bruksspesifikk; noen utøvere kan definere kneet på punktet der et forhåndsspesifisert latenskrav overskrides (for eksempel 100 ms/token), mens andre kan bruke belastningstestbenchmarks og køteorimetoder som halvlatensregelen, og andre kan bruke teoretiske akseleratorspesifikasjoner.

Vi legger også merke til at det maksimale antallet samtidige forespørsler er begrenset. I den foregående figuren ender linjesporingen med 192 samtidige forespørsler. Kilden til denne begrensningen er SageMaker tidsavbruddsgrensen for påkalling, der SageMaker endepunkter tidsavbrudd for et påkallingssvar etter 60 sekunder. Denne innstillingen er kontospesifikk og kan ikke konfigureres for et individuelt endepunkt. For LLM-er kan det ta sekunder eller til og med minutter å generere et stort antall utdata-tokens. Derfor kan store input- eller output-nyttelaster føre til at invokasjonsforespørslene mislykkes. Videre, hvis antallet samtidige forespørsler er veldig stort, vil mange forespørsler oppleve store køtider, noe som fører til denne tidsavbruddsgrensen på 60 sekunder. For formålet med denne studien bruker vi tidsavbruddsgrensen for å definere maksimal gjennomstrømning som er mulig for en modelldistribusjon. Viktigere, selv om et SageMaker-endepunkt kan håndtere et stort antall samtidige forespørsler uten å observere et tidsavbrudd for invokasjonssvar, kan det være lurt å definere maksimale samtidige forespørsler med hensyn til kneet i latency-throughput-kurven. Dette er sannsynligvis punktet der du begynner å vurdere horisontal skalering, der et enkelt endepunkt sørger for flere forekomster med modellreplikaer og lastbalanserer innkommende forespørsler mellom replikene, for å støtte flere samtidige forespørsler.

For å ta dette ett skritt videre, inneholder følgende tabell benchmarking-resultater for ulike konfigurasjoner for Llama 2 7B-modellen, inkludert forskjellig antall input- og output-tokens, instanstyper og antall samtidige forespørsler. Merk at den foregående figuren bare plotter en enkelt rad i denne tabellen.

Vi observerer noen tilleggsmønstre i disse dataene. Når kontekststørrelsen økes, øker latensen og gjennomstrømningen reduseres. For eksempel, på ml.g5.2xlarge med en samtidighet på 1, er gjennomstrømmingen 30 tokens/sek når antallet totalt tokens er 512, vs. 20 tokens/sek hvis antallet totalt tokens er 4,096. Dette er fordi det tar mer tid å behandle de større innspillene. Vi kan også se at økt GPU-kapasitet og sharding påvirker maksimal gjennomstrømning og maksimalt støttede samtidige forespørsler. Tabellen viser at Llama 2 7B har spesielt forskjellige maksimale gjennomstrømningsverdier for forskjellige instanstyper, og disse maksimale gjennomstrømningsverdiene forekommer ved forskjellige verdier av samtidige forespørsler. Disse egenskapene vil få en ML-utøver til å rettferdiggjøre kostnadene ved en instans fremfor en annen. For eksempel, gitt et lavt latenskrav, kan utøveren velge en ml.g5.12xlarge forekomst (4 A10G GPUer) fremfor en ml.g5.2xlarge forekomst (1 A10G GPU). Hvis det gis et høyt gjennomstrømningskrav, vil bruken av en ml.p4d.24xlarge-instans (8 A100 GPUer) med full sharding bare være rettferdiggjort under høy samtidighet. Vær imidlertid oppmerksom på at det ofte er fordelaktig å i stedet laste flere inferenskomponenter av en 7B-modell på en enkelt ml.p4d.24xlarge-forekomst; slik multi-modell støtte diskuteres senere i dette innlegget.

De foregående observasjonene ble gjort for Llama 2 7B-modellen. Imidlertid forblir lignende mønstre gjeldende for andre modeller også. En primær takeaway er at latens- og gjennomstrømningsytelsestall er avhengig av nyttelast, forekomsttype og antall samtidige forespørsler, så du må finne den ideelle konfigurasjonen for din spesifikke applikasjon. For å generere de foregående tallene for brukstilfellet ditt, kan du kjøre den tilknyttede bærbare, hvor du kan konfigurere denne lasttestanalysen for din modell, forekomsttype og nyttelast.

Gir mening med akseleratorspesifikasjonene

Å velge passende maskinvare for LLM-slutninger avhenger i stor grad av spesifikke brukstilfeller, brukeropplevelsesmål og den valgte LLM. Denne delen forsøker å skape en forståelse av kneet i latency-throughput-kurven med hensyn til høynivåprinsipper basert på akseleratorspesifikasjoner. Disse prinsippene alene er ikke nok til å ta en avgjørelse: ekte benchmarks er nødvendige. Begrepet enhet brukes her for å omfatte alle ML-maskinvareakseleratorer. Vi hevder at kneet i latency-throughput-kurven er drevet av en av to faktorer:

• Akseleratoren har brukt opp minnet for å cache KV-matriser, så påfølgende forespørsler settes i kø
• Akseleratoren har fortsatt ledig minne for KV-hurtigbufferen, men bruker en stor nok batchstørrelse til at behandlingstiden drives av ventetid for databehandling i stedet for minnebåndbredde

Vi foretrekker vanligvis å være begrenset av den andre faktoren fordi dette innebærer at akseleratorressursene er mettede. I utgangspunktet maksimerer du ressursene du har betalt for. La oss utforske denne påstanden mer detaljert.

KV-bufring og enhetsminne

Standard transformatoroppmerksomhetsmekanismer beregner oppmerksomhet for hvert nytt token mot alle tidligere tokens. De fleste moderne ML-servere hurtigbufrer oppmerksomhetsnøkler og verdier i enhetsminne (DRAM) for å unngå re-beregning ved hvert trinn. Dette kalles dette KV cache, og den vokser med batchstørrelse og sekvenslengde. Den definerer hvor mange brukerforespørsler som kan betjenes parallelt og vil bestemme kneet i latency-throughput-kurven hvis det beregningsbundne regimet i det andre scenariet nevnt tidligere ikke er oppfylt ennå, gitt tilgjengelig DRAM. Følgende formel er en grov tilnærming for maksimal KV-bufferstørrelse.

I denne formelen er B batchstørrelse og N er antall akseleratorer. For eksempel bruker Llama 2 7B-modellen i FP16 (2 byte/parameter) servert på en A10G GPU (24 GB DRAM) omtrent 14 GB, og det blir igjen 10 GB til KV-cachen. Plugger inn modellens fulle kontekstlengde (N = 4096) og gjenværende parametere (n_layers=32, n_kv_attention_heads=32 og d_attention_head=128), viser dette uttrykket at vi er begrenset til å betjene en batchstørrelse på fire brukere parallelt på grunn av DRAM-begrensninger . Hvis du observerer de tilsvarende benchmarkene i den forrige tabellen, er dette en god tilnærming for det observerte kneet i denne latens-gjennomstrømningskurven. Metoder som f.eks gruppert søk oppmerksomhet (GQA) kan redusere KV-cache-størrelsen, i GQAs tilfelle med samme faktor reduserer det antall KV-hoder.

Aritmetisk intensitet og enhetsminnebåndbredde

Veksten i beregningskraften til ML-akseleratorer har overgått minnebåndbredden deres, noe som betyr at de kan utføre mange flere beregninger på hver byte med data i den tiden det tar å få tilgang til den byten.

De aritmetisk intensitet, eller forholdet mellom beregningsoperasjoner og minnetilganger, for en operasjon avgjør om den er begrenset av minnebåndbredde eller beregningskapasitet på den valgte maskinvaren. For eksempel kan en A10G GPU (g5-forekomsttypefamilie) med 70 TFLOPS FP16 og 600 GB/sek båndbredde beregne omtrent 116 ops/byte. En A100 GPU (p4d-forekomsttypefamilie) kan beregne omtrent 208 ops/byte. Hvis den aritmetiske intensiteten for en transformatormodell er under den verdien, er den minnebundet; hvis det er over, er det beregningsbundet. Oppmerksomhetsmekanismen for Llama 2 7B krever 62 ops/byte for batchstørrelse 1 (for en forklaring, se En guide til LLM-slutning og ytelse), som betyr at den er minnebundet. Når oppmerksomhetsmekanismen er minnebundet, blir dyre FLOPS stående ubrukt.

Det er to måter å bedre utnytte akseleratoren og øke aritmetisk intensitet: reduser de nødvendige minnetilgangene for operasjonen (dette er hva FlashAttention fokuserer på) eller øke batchstørrelsen. Imidlertid kan vi kanskje ikke øke batchstørrelsen nok til å nå et beregningsbundet regime hvis DRAM-en vår er for liten til å holde den tilsvarende KV-cachen. En grov tilnærming av den kritiske batchstørrelsen B* som skiller beregningsbundne fra minnebundne regimer for standard GPT-dekoderslutning er beskrevet ved følgende uttrykk, der A_mb er akseleratorens minnebåndbredde, A_f er akselerator FLOPS, og N er tallet av akseleratorer. Denne kritiske batchstørrelsen kan utledes ved å finne hvor minnetilgangstid er lik beregningstid. Referere til dette blogginnlegget for å forstå ligning 2 og dens forutsetninger mer detaljert.

Dette er det samme ops/byte-forholdet som vi tidligere har beregnet for A10G, så den kritiske batchstørrelsen på denne GPUen er 116. En måte å nærme seg denne teoretiske, kritiske batchstørrelsen er å øke modellsharding og dele hurtigbufferen på flere N akseleratorer. Dette øker effektivt KV-bufferkapasiteten så vel som den minnebundne batchstørrelsen.

En annen fordel med modellskjæring er å dele modellparametere og datainnlastingsarbeid på tvers av N-akseleratorer. Denne typen skjæring er en type modellparallellisme også referert til som tensorparallellisme. Naivt sett er det N ganger minnebåndbredden og datakraften til sammen. Forutsatt ingen overhead av noe slag (kommunikasjon, programvare og så videre), vil dette redusere dekodingsforsinkelsen per token med N hvis vi er minnebundet, fordi tokendekodingsforsinkelsen i dette regimet er bundet av tiden det tar å laste modellen vekter og cache. I det virkelige liv resulterer imidlertid økende grad av sharding i økt kommunikasjon mellom enheter for å dele mellomliggende aktiveringer på hvert modelllag. Denne kommunikasjonshastigheten er begrenset av enhetens sammenkoblingsbåndbredde. Det er vanskelig å anslå effekten nøyaktig (for detaljer, se Modellparallellisme), men dette kan til slutt slutte å gi fordeler eller svekke ytelsen - dette gjelder spesielt for mindre modeller, fordi mindre dataoverføringer fører til lavere overføringshastigheter.

For å sammenligne ML-akseleratorer basert på deres spesifikasjoner, anbefaler vi følgende. Beregn først den omtrentlige kritiske batchstørrelsen for hver akseleratortype i henhold til den andre ligningen og KV-cachestørrelsen for den kritiske batchstørrelsen i henhold til den første ligningen. Du kan deretter bruke den tilgjengelige DRAM-en på akseleratoren til å beregne minimumsantallet av akseleratorer som kreves for å passe til KV-cachen og modellparameterne. Hvis du velger mellom flere akseleratorer, prioriter akseleratorer i rekkefølge etter laveste kostnad per GB/sek minnebåndbredde. Til slutt, benchmark disse konfigurasjonene og kontroller hva som er den beste kostnaden/tokenet for den øvre grensen for ønsket ventetid.

Velg en endepunktsimplementeringskonfigurasjon

Mange LLM-er distribuert av SageMaker JumpStart bruker tekst-generasjon-slutning (TGI) SageMaker beholder for modellservering. Tabellen nedenfor diskuterer hvordan du justerer en rekke modellserveringsparametere for enten å påvirke modellvisningen som påvirker latency-throughput-kurven eller beskytte endepunktet mot forespørsler som vil overbelaste endepunktet. Dette er de primære parametrene du kan bruke til å konfigurere endepunktsdistribusjonen for brukstilfellet ditt. Med mindre annet er spesifisert, bruker vi standard nyttelastparametere for tekstgenerering og TGI miljøvariabler.

TGI-serveren bruker kontinuerlig batching, som dynamisk grupperer samtidige forespørsler sammen for å dele en enkelt modellslutning videresending. Det er to typer foroverpasseringer: forhåndsutfylling og dekoding. Hver ny forespørsel må kjøre en enkelt forhåndsutfylling for å fylle ut KV-bufferen for inndatasekvenstokenene. Etter at KV-hurtigbufferen er fylt ut, utfører en dekode fremoverpassering en enkelt neste-token-prediksjon for alle batchforespørsler, som gjentas iterativt for å produsere utdatasekvensen. Ettersom nye forespørsler sendes til serveren, må neste dekodetrinn vente slik at forhåndsutfyllingstrinnet kan kjøres for de nye forespørslene. Dette må skje før de nye forespørslene inkluderes i påfølgende kontinuerlig batchede dekodingstrinn. På grunn av maskinvarebegrensninger kan det hende at den kontinuerlige batchen som brukes for dekoding ikke inkluderer alle forespørsler. På dette tidspunktet kommer forespørsler inn i en behandlingskø, og slutningsforsinkelsen begynner å øke betydelig med bare mindre gjennomstrømningsforsterkning.

Det er mulig å skille LLM-latens-benchmarking-analyser inn i forhåndsutfyllingsforsinkelse, dekodeforsinkelse og køforsinkelse. Tiden som brukes av hver av disse komponentene er fundamentalt forskjellig i naturen: forhåndsutfylling er en engangsberegning, dekoding skjer én gang for hvert token i utdatasekvensen, og kø involverer serverbatch-prosesser. Når flere samtidige forespørsler behandles, blir det vanskelig å skille ut forsinkelsene fra hver av disse komponentene fordi forsinkelsen som oppleves av en gitt klientforespørsel involverer køforsinkelser drevet av behovet for å forhåndsfylle nye samtidige forespørsler, samt køforsinkelser drevet av inkluderingen av forespørselen i batch-dekodingsprosesser. Av denne grunn fokuserer dette innlegget på ende-til-ende behandlingsforsinkelse. Kneet i latency-throughput-kurven oppstår ved metningspunktet hvor kølatensene begynner å øke betydelig. Dette fenomenet forekommer for enhver modellslutningsserver og er drevet av akseleratorspesifikasjoner.

Vanlige krav under utrulling inkluderer å tilfredsstille et minimum påkrevd gjennomstrømning, maksimal tillatt ventetid, maksimal kostnad per time og maksimal kostnad for å generere 1 million tokens. Du bør betinge disse kravene på nyttelaster som representerer sluttbrukerforespørsler. Et design som oppfyller disse kravene bør ta hensyn til mange faktorer, inkludert den spesifikke modellarkitekturen, størrelsen på modellen, forekomsttyper og antall forekomster (horisontal skalering). I de følgende delene fokuserer vi på å distribuere endepunkter for å minimere latens, maksimere gjennomstrømning og minimere kostnadene. Denne analysen tar for seg totalt 512 tokens og 256 output-tokens.

Minimer latens

Latency er et viktig krav i mange sanntidsbrukstilfeller. I tabellen nedenfor ser vi på minimumsforsinkelse for hver modell og hver forekomsttype. Du kan oppnå minimum latens ved å stille inn MAX_CONCURRENT_REQUESTS = 1.

For å oppnå minimumsforsinkelse for en modell, kan du bruke følgende kode mens du erstatter ønsket modell-ID og forekomsttype:

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

Vær oppmerksom på at latenstidstallene endres avhengig av antall input- og output-tokens. Imidlertid forblir distribusjonsprosessen den samme bortsett fra miljøvariablene MAX_INPUT_TOKENS og MAX_TOTAL_TOKENS. Her er disse miljøvariablene satt til å bidra til å garantere endepunktslatenskrav fordi større inngangssekvenser kan bryte med latenskravet. Merk at SageMaker JumpStart allerede gir de andre optimale miljøvariablene når du velger forekomsttype; for eksempel vil bruk av ml.g5.12xlarge settes SM_NUM_GPUS til 4 i modellmiljøet.

Maksimer gjennomstrømmingen

I denne delen maksimerer vi antall genererte tokens per sekund. Dette oppnås vanligvis ved maksimalt gyldige samtidige forespørsler for modellen og instanstypen. I tabellen nedenfor rapporterer vi gjennomstrømningen oppnådd ved den største samtidige forespørselsverdien som er oppnådd før vi møter et SageMaker-påkallingstidsavbrudd for en forespørsel.

For å oppnå maksimal gjennomstrømning for en modell, kan du bruke 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

Merk at det maksimale antallet samtidige forespørsler avhenger av modelltypen, forekomsttypen, maksimalt antall inndatatokens og maksimalt antall utdatatokens. Derfor bør du stille inn disse parameterne før du stiller inn MAX_CONCURRENT_REQUESTS.

Vær også oppmerksom på at en bruker som er interessert i å minimere latens, ofte er i strid med en bruker som er interessert i å maksimere gjennomstrømmingen. Førstnevnte er interessert i sanntidssvar, mens sistnevnte er interessert i batchbehandling slik at endepunktskøen alltid er mettet, og derved minimerer nedetid for behandling. Brukere som ønsker å maksimere gjennomstrømningen betinget av latenskrav er ofte interessert i å operere ved kneet i latency-throughput-kurven.

Minimer kostnadene

Det første alternativet for å minimere kostnadene innebærer å minimere kostnaden per time. Med dette kan du distribuere en valgt modell på SageMaker-forekomsten med den laveste kostnaden per time. For sanntidsprising av SageMaker-forekomster, se Amazon SageMaker-priser. Generelt er standardforekomsttypen for SageMaker JumpStart LLM-er det billigste distribusjonsalternativet.

Det andre alternativet for å minimere kostnadene innebærer å minimere kostnadene for å generere 1 million tokens. Dette er en enkel transformasjon av tabellen vi diskuterte tidligere for å maksimere gjennomstrømningen, hvor du først kan beregne tiden det tar i timer å generere 1 million tokens (1e6 / throughput / 3600). Du kan deretter multiplisere denne tiden for å generere 1 million tokens med prisen per time for den angitte SageMaker-forekomsten.

Vær oppmerksom på at forekomster med den laveste kostnaden per time ikke er det samme som forekomster med den laveste kostnaden for å generere 1 million tokens. For eksempel, hvis invokasjonsforespørslene er sporadiske, kan en forekomst med den laveste kostnaden per time være optimal, mens den laveste kostnaden for å generere en million tokens i strupingsscenariene kan være mer passende.

Tensorparallell kontra multimodellavveining

I alle tidligere analyser vurderte vi å distribuere en enkelt modellreplika med en tensorparallellgrad lik antall GPUer på distribusjonsforekomsttypen. Dette er standard SageMaker JumpStart-oppførsel. Imidlertid, som tidligere nevnt, kan sønderdeling av en modell forbedre modellforsinkelse og gjennomstrømning bare opp til en viss grense, utover hvilken kommunikasjonskrav mellom enheter dominerer beregningstiden. Dette innebærer at det ofte er fordelaktig å distribuere flere modeller med lavere tensorparallellgrad på en enkelt forekomst i stedet for en enkelt modell med høyere tensorparallellgrad.

Her distribuerer vi Llama 2 7B og 13B endepunkter på ml.p4d.24xlarge forekomster med tensorparallelle (TP) grader på 1, 2, 4 og 8. For klarhet i modellens oppførsel, laster hvert av disse endepunktene kun en enkelt modell.

Våre tidligere analyser viste allerede betydelige gjennomstrømsfordeler på ml.p4d.24xlarge-forekomster, noe som ofte betyr bedre ytelse når det gjelder kostnad for å generere 1 million tokens over g5-forekomstfamilien under høye samtidige forespørselsbelastningsforhold. Denne analysen viser tydelig at du bør vurdere avveiningen mellom modellskjæring og modellreplikering i en enkelt forekomst; det vil si at en fullstendig sønderdelt modell vanligvis ikke er den beste bruken av ml.p4d.24xlarge dataressurser for 7B og 13B modellfamilier. Faktisk, for 7B-modellfamilien, oppnår du den beste gjennomstrømningen for en enkelt modellreplika med en tensorparallellgrad på 4 i stedet for 8.

Herfra kan du ekstrapolere at den høyeste gjennomstrømningskonfigurasjonen for 7B-modellen involverer en tensorparallellgrad på 1 med åtte modellreplikaer, og den høyeste gjennomstrømningskonfigurasjonen for 13B-modellen er sannsynligvis en tensorparallellgrad på 2 med fire modellreplikaer. For å lære mer om hvordan du oppnår dette, se Reduser modelldistribusjonskostnadene med 50 % i gjennomsnitt ved å bruke de nyeste funksjonene til Amazon SageMaker, som demonstrerer bruken av inferenskomponentbaserte endepunkter. På grunn av lastbalanseringsteknikker, serverruting og deling av CPU-ressurser, kan det hende at du ikke oppnår full gjennomstrømningsforbedringer nøyaktig lik antall replikaer ganger gjennomstrømningen for en enkelt replika.

Horisontal skalering

Som observert tidligere, har hver endepunkt-distribusjon en begrensning på antall samtidige forespørsler avhengig av antall input- og output-tokens samt instanstypen. Hvis dette ikke oppfyller kravet om gjennomstrømning eller samtidig forespørsel, kan du skalere opp for å bruke mer enn én forekomst bak det distribuerte endepunktet. SageMaker utfører automatisk lastbalansering av spørringer mellom instanser. For eksempel distribuerer følgende kode et endepunkt som støttes av 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,
)

Tabellen nedenfor viser gjennomstrømningsforsterkningen som en faktor på antall forekomster for Llama 2 7B-modellen.

Spesielt skifter kneet i latency-throughput-kurven til høyre fordi høyere forekomsttellinger kan håndtere et større antall samtidige forespørsler innenfor multi-forekomstendepunktet. For denne tabellen er verdien for samtidig forespørsel for hele endepunktet, ikke antallet samtidige forespørsler som hver enkelt forekomst mottar.

Du kan også bruke autoskalering, en funksjon for å overvåke arbeidsbelastningen og dynamisk justere kapasiteten for å opprettholde jevn og forutsigbar ytelse til lavest mulig kostnad. Dette er utenfor rammen av dette innlegget. For å lære mer om autoskalering, se Konfigurering av autoskalering av slutningsendepunkter i Amazon SageMaker.

Påkall endepunkt med samtidige forespørsler

La oss anta at du har en stor gruppe med spørringer som du ønsker å bruke til å generere svar fra en distribuert modell under forhold med høy gjennomstrømning. For eksempel, i den følgende kodeblokken, kompilerer vi en liste med 1,000 nyttelaster, der hver nyttelast ber om generering av 100 tokens. I alt ber vi om generering av 100,000 XNUMX 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 antall forespørsler til SageMaker runtime API, kan du oppleve strupefeil. For å redusere dette kan du opprette en egendefinert SageMaker-runtime-klient som øker antallet gjenforsøk. Du kan gi det resulterende SageMaker-sesjonsobjektet til enten JumpStartModel konstruktør eller sagemaker.predictor.retrieve_default hvis du ønsker å knytte en ny prediktor til et allerede utplassert endepunkt. I den følgende koden bruker vi dette sesjonsobjektet når vi distribuerer en Llama 2-modell med standard SageMaker JumpStart-konfigurasjoner:

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 utplasserte endepunktet har MAX_CONCURRENT_REQUESTS = 128 som standard. I den følgende blokken bruker vi det samtidige futures-biblioteket til å iterere over å påkalle endepunktet for alle nyttelaster med 128 arbeidertråder. På det meste vil endepunktet behandle 128 samtidige forespørsler, og hver gang en forespørsel returnerer et svar, vil eksekveren umiddelbart sende en ny forespørsel 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 å generere totalt 100,000 1255 tokens med en gjennomstrømning på 5.2 tokens/sek på en enkelt ml.g80xlarge forekomst. Dette tar omtrent XNUMX sekunder å behandle.

Merk at denne gjennomstrømningsverdien er spesielt forskjellig fra maksimal gjennomstrømning for Llama 2 7B på ml.g5.2xlarge i de forrige tabellene i dette innlegget (486 tokens/sek ved 64 samtidige forespørsler). Dette er fordi input-nyttelasten bruker 8 tokens i stedet for 256, utdata-token-tallet er 100 i stedet for 256, og de mindre token-tellingene tillater 128 samtidige forespørsler. Dette er en siste påminnelse om at alle latens- og gjennomstrømstall er avhengig av nyttelast! Endring av nyttelasttokenantall vil påvirke batchprosesser under modellservering, som igjen vil påvirke de nye forhåndsutfyllings-, dekode- og køtidene for applikasjonen din.

konklusjonen

I dette innlegget presenterte vi benchmarking av SageMaker JumpStart LLM-er, inkludert Llama 2, Mistral og Falcon. Vi presenterte også en veiledning for å optimalisere ventetid, gjennomstrømning og kostnader for endepunktsimplementeringskonfigurasjonen. Du kan komme i gang ved å kjøre tilhørende notatbok for å benchmarke brukssaken din.

Om forfatterne

 Dr. Kyle Ulrich er en Applied Scientist med Amazon SageMaker JumpStart-teamet. Hans forskningsinteresser inkluderer skalerbare maskinlæringsalgoritmer, datasyn, tidsserier, Bayesianske ikke-parametriske og Gaussiske prosesser. Hans doktorgrad er fra Duke University og han har publisert artikler i NeurIPS, Cell og Neuron.

Dr. Vivek Madan er en Applied Scientist med Amazon SageMaker JumpStart-teamet. Han fikk sin doktorgrad fra University of Illinois i Urbana-Champaign og var postdoktor ved Georgia Tech. Han er en aktiv forsker innen maskinlæring og algoritmedesign og har publisert artikler på EMNLP-, ICLR-, COLT-, FOCS- og SODA-konferanser.

Dr. Ashish Khetan er en Senior Applied Scientist med Amazon SageMaker JumpStart og hjelper til med å utvikle maskinlæringsalgoritmer. Han fikk sin doktorgrad fra University of Illinois Urbana-Champaign. Han er en aktiv forsker innen maskinlæring og statistisk inferens, og har publisert mange artikler på NeurIPS, ICML, ICLR, JMLR, ACL og EMNLP-konferanser.

João Moura er senior AI/ML spesialistløsningsarkitekt hos AWS. João hjelper AWS-kunder – fra små startups til store bedrifter – med å trene og distribuere store modeller effektivt, og mer bredt bygge ML-plattformer på AWS.

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