Benchmark och optimera slutpunktsdistribution i Amazon SageMaker JumpStart | Amazon webbtjänster

När de använder en stor språkmodell (LLM) bryr sig utövare av maskininlärning (ML) vanligtvis om två mätningar för prestanda för modellbetjäning: latens, definierad av den tid det tar att generera en enskild token, och genomströmning, definierad av antalet tokens som genereras per sekund. Även om en enda begäran till den distribuerade slutpunkten skulle uppvisa en genomströmning som är ungefär lika med inversen av modelllatens, är detta inte nödvändigtvis fallet när flera samtidiga förfrågningar skickas samtidigt till slutpunkten. På grund av modellbetjäningstekniker, såsom kontinuerlig batchning av samtidiga förfrågningar på klientsidan, har latens och genomströmning ett komplext förhållande som varierar avsevärt baserat på modellarkitektur, serverkonfigurationer, hårdvara av instanstyp, antal samtidiga förfrågningar och variationer i indatanyttolaster som t.ex. som antal inmatade tokens och output tokens.

Det här inlägget utforskar dessa relationer via en omfattande benchmarking av LLMs tillgängliga i Amazon SageMaker JumpStart, inklusive Llama 2, Falcon och Mistral-varianter. Med SageMaker JumpStart kan ML-utövare välja från ett brett urval av allmänt tillgängliga grundmodeller att distribuera till dedikerade Amazon SageMaker instanser i en nätverksisolerad miljö. Vi tillhandahåller teoretiska principer om hur acceleratorspecifikationer påverkar LLM-benchmarking. Vi visar också effekten av att distribuera flera instanser bakom en enda slutpunkt. Slutligen ger vi praktiska rekommendationer för att skräddarsy SageMaker JumpStart-distributionsprocessen för att anpassas till dina krav på latens, genomströmning, kostnad och begränsningar för tillgängliga instanstyper. Alla benchmarking-resultat samt rekommendationer är baserade på en mångsidig anteckningsbok som du kan anpassa efter ditt användningsfall.

Utplacerad benchmarking för slutpunkter

Följande figur visar de lägsta latenserna (vänster) och högsta genomströmningsvärdena (höger) för distributionskonfigurationer över en mängd olika modelltyper och instanstyper. Viktigt är att var och en av dessa modellinstallationer använder standardkonfigurationer som tillhandahålls av SageMaker JumpStart givet det önskade modell-ID och instanstyp för distribution.

Dessa latens- och genomströmningsvärden motsvarar nyttolaster med 256 inmatade tokens och 256 output tokens. Den lägsta latenskonfigurationen begränsar modellens betjäning till en enda samtidig begäran, och den högsta genomströmningskonfigurationen maximerar det möjliga antalet samtidiga förfrågningar. Som vi kan se i vår benchmarking ökar ökande samtidiga förfrågningar monotont genomströmningen med minskande förbättringar för stora samtidiga förfrågningar. Dessutom är modellerna helt delade på den instans som stöds. Till exempel, eftersom ml.g5.48xlarge-instansen har 8 GPU:er, är alla SageMaker JumpStart-modeller som använder denna instans sönderdelade med tensorparallellism på alla åtta tillgängliga acceleratorer.

Vi kan notera några takeaways från denna siffra. För det första stöds inte alla modeller på alla instanser; vissa mindre modeller, som Falcon 7B, stöder inte modellskärning, medan större modeller har högre krav på beräkningsresurser. För det andra, när skärningen ökar, förbättras vanligtvis prestandan, men kanske inte nödvändigtvis förbättras för små modeller. Detta beror på att små modeller som 7B och 13B ådrar sig betydande kommunikationskostnader när de sprids över för många acceleratorer. Vi diskuterar detta mer ingående senare. Slutligen tenderar ml.p4d.24xlarge-instanser att ha betydligt bättre genomströmning på grund av förbättringar av minnesbandbredden för A100 jämfört med A10G GPU:er. Som vi diskuterar senare beror beslutet att använda en viss instanstyp på dina distributionskrav, inklusive latens, genomströmning och kostnadsbegränsningar.

Hur kan du få dessa konfigurationsvärden för lägsta latens och högsta genomströmning? Låt oss börja med att plotta latens vs. genomströmning för en Llama 2 7B-slutpunkt på en ml.g5.12xlarge instans för en nyttolast med 256 inmatade tokens och 256 output-tokens, som visas i följande kurva. En liknande kurva finns för varje utplacerad LLM-slutpunkt.

När samtidigheten ökar ökar också genomströmningen och latensen monotont. Därför inträffar den lägsta latenspunkten vid ett samtidig förfrågningsvärde på 1, och du kan kostnadseffektivt öka systemgenomströmningen genom att öka samtidiga förfrågningar. Det finns ett distinkt "knä" i denna kurva, där det är uppenbart att genomströmningsvinsterna förknippade med ytterligare samtidighet inte uppväger den associerade ökningen av latens. Den exakta platsen för detta knä är användningsfallsspecifik; vissa utövare kan definiera knäet vid den punkt där ett förutbestämt latenskrav överskrids (till exempel 100 ms/token), medan andra kan använda belastningstest-benchmarks och köteoretiska metoder som halv-latensregeln, och andra kan använda teoretiska acceleratorspecifikationer.

Vi noterar också att det maximala antalet samtidiga förfrågningar är begränsat. I föregående figur slutar linjespåret med 192 samtidiga förfrågningar. Källan till denna begränsning är SageMakers anropstidsgräns, där SageMaker slutpunkter timeout ett anropssvar efter 60 sekunder. Den här inställningen är kontospecifik och kan inte konfigureras för en enskild slutpunkt. För LLM:er kan det ta sekunder eller till och med minuter att generera ett stort antal utdatatokens. Därför kan stora in- eller utgångsnyttolaster göra att anropsbegäran misslyckas. Dessutom, om antalet samtidiga förfrågningar är mycket stort, kommer många förfrågningar att uppleva stora kötider, vilket leder till denna tidsgräns på 60 sekunder. För syftet med denna studie använder vi tidsgränsen för att definiera den maximala genomströmningen som är möjlig för en modellinstallation. Viktigt, även om en SageMaker-slutpunkt kan hantera ett stort antal samtidiga förfrågningar utan att observera en tidsgräns för anropssvar, kanske du vill definiera maximala samtidiga förfrågningar med avseende på knäet i latens-genomströmningskurvan. Det här är förmodligen den punkt där du börjar överväga horisontell skalning, där en enda slutpunkt tillhandahåller flera instanser med modellrepliker och lastbalanserar inkommande förfrågningar mellan replikerna, för att stödja fler samtidiga förfrågningar.

För att ta detta ett steg längre, innehåller följande tabell benchmarking-resultat för olika konfigurationer för Llama 2 7B-modellen, inklusive olika antal in- och utmatningstoken, instanstyper och antal samtidiga förfrågningar. Observera att föregående figur endast plottar en enda rad i denna tabell.

Vi observerar några ytterligare mönster i denna data. När kontextstorleken ökar ökar latensen och genomströmningen minskar. Till exempel, på ml.g5.2xlarge med en samtidighet av 1, är genomströmningen 30 tokens/sek när antalet totala tokens är 512, jämfört med 20 tokens/sek om antalet totala tokens är 4,096 2. Detta beror på att det tar längre tid att bearbeta den större ingången. Vi kan också se att ökad GPU-kapacitet och skärning påverkar maximal genomströmning och maximalt stödda samtidiga förfrågningar. Tabellen visar att Llama 7 5.12B har märkbart olika maximala genomströmningsvärden för olika instanstyper, och dessa maximala genomströmningsvärden förekommer vid olika värden av samtidiga förfrågningar. Dessa egenskaper skulle få en ML-utövare att motivera kostnaden för en instans framför en annan. Till exempel, givet ett lågt latenskrav, kan utövaren välja en ml.g4xlarge instans (10 A5.2G GPU: er) framför en ml.g1xlarge instans (10 A4G GPU). Om det ges ett högt genomströmningskrav, skulle användningen av en ml.p24d.8xlarge-instans (100 A7 GPU:er) med full sharding endast vara motiverad under hög samtidighet. Observera dock att det ofta är fördelaktigt att istället ladda flera inferenskomponenter av en 4B-modell på en enda ml.p24d.XNUMXxlarge-instans; sådant stöd för flera modeller diskuteras senare i det här inlägget.

De föregående observationerna gjordes för Llama 2 7B-modellen. Liknande mönster kvarstår dock även för andra modeller. En primär faktor är att latens- och genomströmningsprestandasiffror beror på nyttolast, instanstyp och antal samtidiga förfrågningar, så du måste hitta den perfekta konfigurationen för din specifika applikation. För att generera de föregående siffrorna för ditt användningsfall kan du köra den länkade anteckningsbok, där du kan konfigurera denna lasttestanalys för din modell, instanstyp och nyttolast.

Att förstå acceleratorspecifikationer

Att välja lämplig hårdvara för LLM-inferens beror i hög grad på specifika användningsfall, mål för användarupplevelsen och den valda LLM. Detta avsnitt försöker skapa en förståelse för knäet i latens-genomströmningskurvan med avseende på högnivåprinciper baserade på acceleratorspecifikationer. Dessa principer ensamma räcker inte för att fatta ett beslut: riktiga riktmärken är nödvändiga. Termen anordning används här för att omfatta alla ML-hårdvaruacceleratorer. Vi hävdar att knät i latens-genomströmningskurvan drivs av en av två faktorer:

• Acceleratorn har tömt minne för att cachelagra KV-matriser, så efterföljande förfrågningar ställs i kö
• Acceleratorn har fortfarande ledigt minne för KV-cachen, men använder en tillräckligt stor batchstorlek för att bearbetningstiden styrs av beräkningsdriftslatens snarare än minnesbandbredd

Vi föredrar vanligtvis att begränsas av den andra faktorn eftersom detta innebär att acceleratorresurserna är mättade. I grund och botten maximerar du de resurser du betalat för. Låt oss utforska detta påstående mer i detalj.

KV-caching och enhetsminne

Standarduppmärksamhetsmekanismer för transformatorer beräknar uppmärksamhet för varje ny token mot alla tidigare tokens. De flesta moderna ML-servrar cachelagrar uppmärksamhetsnycklar och värden i enhetsminne (DRAM) för att undvika omräkning vid varje steg. Detta kallas detta KV-cache, och den växer med batchstorlek och sekvenslängd. Den definierar hur många användarförfrågningar som kan betjänas parallellt och kommer att bestämma knäet i latens-genomströmningskurvan om den beräkningsbundna regimen i det andra scenariot som nämnts tidigare inte uppfylls ännu, givet tillgängligt DRAM. Följande formel är en grov uppskattning av den maximala KV-cachestorleken.

I denna formel är B batchstorlek och N är antalet acceleratorer. Till exempel förbrukar Llama 2 7B-modellen i FP16 (2 byte/parameter) på en A10G GPU (24 GB DRAM) cirka 14 GB, vilket ger 10 GB till KV-cache. Om du kopplar in modellens fulla kontextlängd (N = 4096) och återstående parametrar (n_layers=32, n_kv_attention_heads=32 och d_attention_head=128), visar detta uttryck att vi är begränsade till att servera en batchstorlek på fyra användare parallellt på grund av DRAM-begränsningar . Om du observerar motsvarande riktmärken i föregående tabell är detta en bra approximation för det observerade knäet i denna latens-genomströmningskurva. Metoder som t.ex grupperad fråga uppmärksamhet (GQA) kan minska KV-cachestorleken, i GQA:s fall med samma faktor minskar det antalet KV-huvuden.

Aritmetisk intensitet och enhetsminnesbandbredd

Tillväxten i beräkningskraften hos ML-acceleratorer har överträffat deras minnesbandbredd, vilket innebär att de kan utföra många fler beräkningar på varje byte med data under den tid det tar att komma åt den byten.

Smakämnen aritmetisk intensitet, eller förhållandet mellan beräkningsoperationer och minnesåtkomster, för en operation avgör om den begränsas av minnesbandbredd eller beräkningskapacitet på den valda hårdvaran. Till exempel kan en A10G GPU (g5-instanstypsfamilj) med 70 TFLOPS FP16 och 600 GB/sek bandbredd beräkna cirka 116 ops/byte. En A100 GPU (p4d-instanstyp familj) kan beräkna cirka 208 ops/byte. Om den aritmetiska intensiteten för en transformatormodell är under det värdet är den minnesbunden; om den är ovan är den beräkningsbunden. Uppmärksamhetsmekanismen för Llama 2 7B kräver 62 ops/byte för batchstorlek 1 (för en förklaring, se En guide till LLM slutledning och prestanda), vilket betyder att den är minnesbunden. När uppmärksamhetsmekanismen är minnesbunden lämnas dyra FLOPS outnyttjade.

Det finns två sätt att bättre utnyttja acceleratorn och öka den aritmetiska intensiteten: minska de nödvändiga minnesåtkomsterna för operationen (detta är vad FlashAttention fokuserar på) eller öka batchstorleken. Men vi kanske inte kan öka vår batchstorlek tillräckligt för att nå en beräkningsbunden regim om vårt DRAM är för litet för att hålla motsvarande KV-cache. En grov approximation av den kritiska batchstorleken B* som skiljer beräkningsbundna från minnesbundna regimer för standard GPT-avkodar slutledning beskrivs med följande uttryck, där A_mb är acceleratorminnets bandbredd, A_f är accelerator FLOPS och N är talet av acceleratorer. Denna kritiska batchstorlek kan härledas genom att hitta var minnesåtkomsttid är lika med beräkningstid. Hänvisa till detta blogginlägg att förstå ekvation 2 och dess antaganden mer i detalj.

Detta är samma ops/byte-förhållande som vi tidigare beräknat för A10G, så den kritiska batchstorleken på denna GPU är 116. Ett sätt att närma sig denna teoretiska, kritiska batchstorlek är att öka modellskärningen och dela upp cachen mellan fler N acceleratorer. Detta ökar effektivt KV-cachekapaciteten såväl som den minnesbundna batchstorleken.

En annan fördel med modellskärning är att dela upp modellparametrar och dataladdningsarbete över N acceleratorer. Denna typ av skärning är en typ av modellparallellism som också kallas tensorparallellism. Naivt är det N gånger minnesbandbredden och beräkningskraften sammanlagt. Om vi ​​antar att ingen overhead av något slag (kommunikation, mjukvara och så vidare) skulle minska avkodningslatensen per token med N om vi är minnesbundna, eftersom tokenavkodningslatensen i denna regim är bunden av den tid det tar att ladda modellen vikter och cache. I det verkliga livet resulterar dock en ökad skärningsgrad i ökad kommunikation mellan enheter för att dela mellanaktiveringar på varje modelllager. Denna kommunikationshastighet begränsas av enhetens sammankopplingsbandbredd. Det är svårt att uppskatta dess inverkan exakt (för detaljer, se Modell parallellism), men detta kan så småningom sluta ge fördelar eller försämra prestanda - detta gäller särskilt för mindre modeller, eftersom mindre dataöverföringar leder till lägre överföringshastigheter.

För att jämföra ML-acceleratorer baserat på deras specifikationer rekommenderar vi följande. Beräkna först den ungefärliga kritiska batchstorleken för varje acceleratortyp enligt den andra ekvationen och KV-cachestorleken för den kritiska batchstorleken enligt den första ekvationen. Du kan sedan använda det tillgängliga DRAM-minnet på acceleratorn för att beräkna det minsta antalet acceleratorer som krävs för att passa KV-cachen och modellparametrarna. Om du väljer mellan flera acceleratorer, prioritera acceleratorer efter lägsta kostnad per GB/sek minnesbandbredd. Slutligen, benchmark dessa konfigurationer och verifiera vad som är den bästa kostnaden/token för din övre gräns för önskad latens.

Välj en slutpunktsdistributionskonfiguration

Många LLMs distribuerade av SageMaker JumpStart använder text-generation-inferens (TGI) SageMaker behållare för modellservering. Följande tabell diskuterar hur man justerar en mängd olika modellbetjäningsparametrar för att antingen påverka modellbetjäningen som påverkar latens-genomströmningskurvan eller skydda ändpunkten mot förfrågningar som skulle överbelasta ändpunkten. Det här är de primära parametrarna du kan använda för att konfigurera din slutpunktsdistribution för ditt användningsfall. Om inget annat anges använder vi standard parametrar för nyttolast för textgenerering och TGI miljövariabler.

TGI-servern använder kontinuerlig batchning, som dynamiskt batchar samman samtidiga förfrågningar för att dela en enkel modellslutledning framåt. Det finns två typer av framåtpassningar: förfyllning och avkodning. Varje ny begäran måste köra en enda förfyllning framåt för att fylla i KV-cachen för inmatningssekvenstoken. Efter att KV-cachen har fyllts i, utför en avkodning framåtpassning en enda nästa-token-prediktion för alla batchförfrågningar, som upprepas iterativt för att producera utdatasekvensen. När nya förfrågningar skickas till servern måste nästa avkodningssteg vänta så att förfyllningssteget kan köras för de nya förfrågningarna. Detta måste ske innan dessa nya förfrågningar inkluderas i efterföljande kontinuerligt batchade avkodningssteg. På grund av hårdvarubegränsningar kanske den kontinuerliga batchningen som används för avkodning inte inkluderar alla förfrågningar. Vid denna tidpunkt kommer förfrågningar in i en bearbetningskö och slutledningslatens börjar öka avsevärt med endast mindre genomströmningsförstärkning.

Det är möjligt att separera benchmarkinganalyser för LLM-latens i förfyllningsfördröjning, avkodningsfördröjning och köfördröjning. Den tid som åtgår av var och en av dessa komponenter är fundamentalt annorlunda till sin natur: förfyllning är en engångsberäkning, avkodning sker en gång för varje token i utdatasekvensen, och köer involverar serverbatchprocesser. När flera samtidiga förfrågningar bearbetas, blir det svårt att reda ut latenserna från var och en av dessa komponenter eftersom latensen som upplevs av en given klientförfrågan involverar köfördröjningar som drivs av behovet av att förfylla nya samtidiga förfrågningar såväl som köfördröjningar som drivs av inkluderingen av begäran i batchavkodningsprocesser. Av denna anledning fokuserar det här inlägget på bearbetningsfördröjning från slut till ände. Knäet i latens-genomströmningskurvan inträffar vid mättnadspunkten där kölatenserna börjar öka markant. Detta fenomen inträffar för alla modeller av slutledningsserver och drivs av acceleratorspecifikationer.

Vanliga krav under driftsättning inkluderar att uppfylla en minsta nödvändig genomströmning, maximal tillåten latens, maximal kostnad per timme och maximal kostnad för att generera 1 miljon tokens. Du bör villkora dessa krav på nyttolaster som representerar slutanvändarförfrågningar. En design för att uppfylla dessa krav bör ta hänsyn till många faktorer, inklusive den specifika modellarkitekturen, modellens storlek, instanstyper och instansantal (horisontell skalning). I följande avsnitt fokuserar vi på att distribuera slutpunkter för att minimera latens, maximera genomströmningen och minimera kostnaden. Denna analys tar hänsyn till totalt 512 tokens och 256 output-tokens.

Minimera latens

Latens är ett viktigt krav i många realtidsanvändningsfall. I följande tabell tittar vi på minsta latens för varje modell och varje instanstyp. Du kan uppnå minsta latens genom att ställa in MAX_CONCURRENT_REQUESTS = 1.

För att uppnå minsta latens för en modell kan du använda följande kod samtidigt som du ersätter ditt önskade modell-ID och instanstyp:

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

Observera att latensnumren ändras beroende på antalet in- och utmatningstoken. Men distributionsprocessen förblir densamma förutom miljövariablerna MAX_INPUT_TOKENS och MAX_TOTAL_TOKENS. Här är dessa miljövariabler inställda för att garantera slutpunktslatenskrav eftersom större indatasekvenser kan bryta mot latenskravet. Observera att SageMaker JumpStart redan tillhandahåller de andra optimala miljövariablerna när du väljer instanstyp; till exempel kommer användning av ml.g5.12xlarge att ställas in SM_NUM_GPUS till 4 i modellmiljön.

Maximera genomströmningen

I det här avsnittet maximerar vi antalet genererade tokens per sekund. Detta uppnås vanligtvis vid maximalt giltiga samtidiga förfrågningar för modellen och instanstypen. I följande tabell rapporterar vi genomströmningen som uppnåtts vid det största samtidiga förfrågningsvärdet som uppnåtts innan vi stöter på en SageMaker-anropstidsgräns för någon begäran.

För att uppnå maximal genomströmning för en modell kan du använda följande kod:

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

Observera att det maximala antalet samtidiga förfrågningar beror på modelltyp, instanstyp, maximalt antal indatatoken och maximalt antal utdatatoken. Därför bör du ställa in dessa parametrar innan du ställer in MAX_CONCURRENT_REQUESTS.

Observera också att en användare som är intresserad av att minimera latens ofta står i strid med en användare som är intresserad av att maximera genomströmningen. Den förra är intresserad av realtidssvar, medan den senare är intresserad av batchbearbetning så att slutpunktskön alltid är mättad, vilket minimerar bearbetningsavbrottstid. Användare som vill maximera genomströmningen beroende på latenskrav är ofta intresserade av att arbeta vid knäet i latens-genomströmningskurvan.

Minimera kostnaden

Det första alternativet för att minimera kostnaden innebär att minimera kostnaden per timme. Med detta kan du distribuera en utvald modell på SageMaker-instansen med den lägsta kostnaden per timme. För realtidsprissättning av SageMaker-instanser, se Amazon SageMaker-prissättning. I allmänhet är standardinstanstypen för SageMaker JumpStart LLM:er det billigaste distributionsalternativet.

Det andra alternativet för att minimera kostnaden innebär att minimera kostnaden för att generera 1 miljon tokens. Detta är en enkel omvandling av tabellen vi diskuterade tidigare för att maximera genomströmningen, där du först kan beräkna tiden det tar i timmar att generera 1 miljon tokens (1e6 / throughput / 3600). Du kan sedan multiplicera denna tid för att generera 1 miljon tokens med priset per timme för den angivna SageMaker-instansen.

Observera att instanser med lägst kostnad per timme inte är samma som instanser med lägst kostnad för att generera 1 miljon tokens. Till exempel, om anropsförfrågningarna är sporadiska, kan en instans med den lägsta kostnaden per timme vara optimal, medan i strypningsscenarierna kan den lägsta kostnaden för att generera en miljon tokens vara mer lämplig.

Tensor parallell kontra multi-modell kompromiss

I alla tidigare analyser övervägde vi att distribuera en enstaka modellreplik med en tensorparallellgrad lika med antalet GPU:er på distributionsinstanstypen. Detta är SageMaker JumpStarts standardbeteende. Men, som tidigare noterats, kan skärning av en modell förbättra modellens latens och genomströmning endast upp till en viss gräns, bortom vilken kommunikationskrav mellan enheter dominerar beräkningstiden. Detta innebär att det ofta är fördelaktigt att distribuera flera modeller med en lägre tensorparallellgrad på en enda instans snarare än en enda modell med en högre tensorparallellgrad.

Här distribuerar vi Llama 2 7B och 13B endpoints på ml.p4d.24xlarge instanser med tensor parallella (TP) grader på 1, 2, 4 och 8. För tydlighetens skull i modellens beteende laddar var och en av dessa endpoints bara en enda modell.

Våra tidigare analyser visade redan betydande genomströmningsfördelar på ml.p4d.24xlarge-instanser, vilket ofta leder till bättre prestanda i form av kostnad för att generera 1 miljon tokens över g5-instansfamiljen under höga samtidiga förfrågningsbelastningsförhållanden. Denna analys visar tydligt att du bör överväga avvägningen mellan modellskärning och modellreplikering inom en enda instans; det vill säga en helt sönderdelad modell är vanligtvis inte den bästa användningen av ml.p4d.24xlarge beräkningsresurser för 7B- och 13B-modellfamiljer. Faktum är att för 7B-modellfamiljen får du den bästa genomströmningen för en enskild modellreplik med en tensorparallellgrad på 4 istället för 8.

Härifrån kan du extrapolera att den högsta genomströmningskonfigurationen för 7B-modellen involverar en tensorparallellgrad på 1 med åtta modellkopior, och den högsta genomströmningskonfigurationen för 13B-modellen är sannolikt en tensorparallellgrad på 2 med fyra modellrepliker. För att lära dig mer om hur du gör detta, se Minska kostnaderna för modelldistribution med 50 % i genomsnitt med de senaste funktionerna i Amazon SageMaker, som visar användningen av slutledningskomponentbaserade endpoints. På grund av lastbalanseringstekniker, serverrouting och delning av CPU-resurser kanske du inte helt uppnår genomströmningsförbättringar som exakt motsvarar antalet repliker gånger genomströmningen för en enskild replik.

Horisontell skalning

Som observerats tidigare har varje slutpunktsdistribution en begränsning av antalet samtidiga förfrågningar beroende på antalet in- och utdatatoken samt instanstypen. Om detta inte uppfyller kraven för din genomströmning eller samtidiga begäran kan du skala upp för att använda mer än en instans bakom den distribuerade slutpunkten. SageMaker utför automatiskt lastbalansering av frågor mellan instanser. Till exempel distribuerar följande kod en slutpunkt som stöds av tre instanser:

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öljande tabell visar genomströmningsförstärkningen som en faktor för antalet instanser för Llama 2 7B-modellen.

Noterbart är att knät i latens-genomströmningskurvan skiftar åt höger eftersom högre instansantal kan hantera ett större antal samtidiga förfrågningar inom multi-instans endpoint. För den här tabellen är värdet för samtidig begäran för hela slutpunkten, inte antalet samtidiga förfrågningar som varje enskild instans tar emot.

Du kan också använda automatisk skalning, en funktion för att övervaka dina arbetsbelastningar och dynamiskt justera kapaciteten för att bibehålla en stabil och förutsägbar prestanda till lägsta möjliga kostnad. Detta ligger utanför ramen för detta inlägg. För att lära dig mer om automatisk skalning, se Konfigurera slutpunkter för automatisk skalning av slutpunkter i Amazon SageMaker.

Anropa slutpunkt med samtidiga förfrågningar

Låt oss anta att du har ett stort antal frågor som du skulle vilja använda för att generera svar från en utplacerad modell under förhållanden med hög genomströmning. Till exempel, i följande kodblock, sammanställer vi en lista med 1,000 100 nyttolaster, där varje nyttolast begär generering av 100,000 tokens. Sammanlagt begär vi generering av XNUMX 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 skickar ett stort antal förfrågningar till SageMaker runtime API kan du uppleva begränsningsfel. För att mildra detta kan du skapa en anpassad SageMaker runtime-klient som ökar antalet återförsök. Du kan tillhandahålla det resulterande SageMaker-sessionsobjektet till antingen JumpStartModel konstruktör eller sagemaker.predictor.retrieve_default om du vill koppla en ny prediktor till en redan distribuerad slutpunkt. I följande kod använder vi det här sessionsobjektet när vi distribuerar en Llama 2-modell med standardkonfigurationer för SageMaker JumpStart:

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

Denna utplacerade slutpunkt har MAX_CONCURRENT_REQUESTS = 128 som standard. I följande block använder vi det samtidiga terminsbiblioteket för att iterera över anropa slutpunkten för alla nyttolaster med 128 arbetstrådar. Som mest kommer slutpunkten att behandla 128 samtidiga förfrågningar, och närhelst en begäran returnerar ett svar, kommer verkställaren omedelbart att skicka en ny begäran till slutpunkten.

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)

Detta resulterar i att totalt 100,000 1255 tokens genereras med en genomströmning på 5.2 tokens/sek på en enda ml.g80xlarge instans. Detta tar cirka XNUMX sekunder att bearbeta.

Observera att detta genomströmningsvärde skiljer sig markant från den maximala genomströmningen för Llama 2 7B på ml.g5.2xlarge i de tidigare tabellerna i detta inlägg (486 tokens/sek vid 64 samtidiga förfrågningar). Detta beror på att den ingående nyttolasten använder 8 tokens istället för 256, utdatatokenantalet är 100 istället för 256, och de mindre tokenantalet tillåter 128 samtidiga förfrågningar. Detta är en sista påminnelse om att alla latens- och genomströmningsnummer är nyttolastberoende! Att ändra antalet nyttolasttoken kommer att påverka batchprocesser under modellbetjäning, vilket i sin tur kommer att påverka de nya förfyllnings-, avkodnings- och kötiderna för din applikation.

Slutsats

I det här inlägget presenterade vi benchmarking av SageMaker JumpStart LLM, inklusive Llama 2, Mistral och Falcon. Vi presenterade också en guide för att optimera latens, genomströmning och kostnad för din slutpunktsinstallationskonfiguration. Du kan komma igång genom att köra tillhörande anteckningsbok för att jämföra ditt användningsfall.

Om författarna

 Dr Kyle Ulrich är en tillämpad forskare med Amazon SageMaker JumpStart-teamet. Hans forskningsintressen inkluderar skalbara maskininlärningsalgoritmer, datorseende, tidsserier, Bayesianska icke-parametriska och Gaussiska processer. Hans doktorsexamen är från Duke University och han har publicerat artiklar i NeurIPS, Cell och Neuron.

Dr. Vivek Madan är en tillämpad forskare med Amazon SageMaker JumpStart-teamet. Han tog sin doktorsexamen från University of Illinois i Urbana-Champaign och var postdoktor vid Georgia Tech. Han är en aktiv forskare inom maskininlärning och algoritmdesign och har publicerat artiklar på EMNLP-, ICLR-, COLT-, FOCS- och SODA-konferenser.

Dr Ashish Khetan är en Senior Applied Scientist med Amazon SageMaker JumpStart och hjälper till att utveckla maskininlärningsalgoritmer. Han tog sin doktorsexamen från University of Illinois Urbana-Champaign. Han är en aktiv forskare inom maskininlärning och statistisk slutledning och har publicerat många artiklar i NeurIPS, ICML, ICLR, JMLR, ACL och EMNLP-konferenser.

João Moura är Senior AI/ML Specialist Solutions Architect på AWS. João hjälper AWS-kunder – från små startups till stora företag – att utbilda och distribuera stora modeller effektivt, och mer brett bygga ML-plattformar på AWS.

• SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
• PlatoData.Network Vertical Generative Ai. Styrka dig själv. Tillgång här.
• PlatoAiStream. Web3 Intelligence. Kunskap förstärkt. Tillgång här.
• Platoesg. Kol, CleanTech, Energi, Miljö, Sol, Avfallshantering. Tillgång här.
• PlatoHealth. Biotech och kliniska prövningar Intelligence. Tillgång här.
• Källa: https://aws.amazon.com/blogs/machine-learning/benchmark-and-optimize-endpoint-deployment-in-amazon-sagemaker-jumpstart/