Gradient gjør LLM-benchmarking kostnadseffektiv og uanstrengt med AWS Inferentia | Amazon Web Services

Dette er et gjesteinnlegg skrevet sammen med Michael Feil på Gradient.

Evaluering av ytelsen til store språkmodeller (LLM) er et viktig trinn i foropplærings- og finjusteringsprosessen før distribusjon. Jo raskere og hyppigere du er i stand til å validere ytelsen, desto større er sjansene for at du vil kunne forbedre ytelsen til modellen.

At Gradient, jobber vi med tilpasset LLM-utvikling, og lanserte nylig vår AI Development Lab, og tilbyr bedriftsorganisasjoner en personlig, ende-til-ende utviklingstjeneste for å bygge private, tilpassede LLM-er og andrepiloter med kunstig intelligens (AI). Som en del av denne prosessen evaluerer vi regelmessig ytelsen til modellene våre (innstilt, opplært og åpne) mot åpne og proprietære benchmarks. Mens du jobber med AWS-teamet for å trene modellene våre på AWS Trainium, innså vi at vi var begrenset til både VRAM og tilgjengeligheten av GPU-forekomster når det kom til det vanlige verktøyet for LLM-evaluering, lm-evaluering-sele. Dette rammeverket med åpen kildekode lar deg score ulike generative språkmodeller på tvers av ulike evalueringsoppgaver og benchmarks. Den brukes av topplister som f.eks Klemme ansiktet for offentlig benchmarking.

For å overkomme disse utfordringene bestemte vi oss for å bygge og åpne kildekodeløsningen vår – integrerende AWS nevron, biblioteket bak AWS slutning og Trainium, inn lm-evaluation-harness. Denne integrasjonen gjorde det mulig å benchmarke v-alpha-tross, en tidlig versjon av vår Albatross-modell, mot andre offentlige modeller under opplæringsprosessen og etterpå.

For kontekst kjører denne integrasjonen som en ny modellklasse innen lm-evaluation-harness, og abstraherer slutningen av tokens og log-sannsynlighetsestimering av sekvenser uten å påvirke selve evalueringsoppgaven. Beslutningen om å flytte vår interne testpipeline til Amazon Elastic Compute Cloud (Amazon EC2) Inf2-forekomster (drevet av AWS Inferentia2) gjorde det mulig for oss å få tilgang til opptil 384 GB delt akseleratorminne, og passet enkelt til alle våre nåværende offentlige arkitekturer. Ved å bruke AWS Spot-forekomster kunne vi dra nytte av ubrukt EC2-kapasitet i AWS Cloud – noe som muliggjorde kostnadsbesparelser på opptil 90 % rabatt på bestillingspriser. Dette minimerte tiden det tok for testing og tillot oss å teste oftere fordi vi var i stand til å teste på tvers av flere forekomster som var lett tilgjengelige og frigi forekomstene når vi var ferdige.

I dette innlegget gir vi en detaljert oversikt over testene våre, utfordringene vi møtte, og et eksempel på bruk av testselen på AWS Inferentia.

Benchmarking på AWS Inferentia2

Målet med dette prosjektet var å generere identiske poengsummer som vist i Åpne LLM Leaderboard (for mange CausalLM-modeller tilgjengelig på Hugging Face), mens du beholder fleksibiliteten til å kjøre den mot private benchmarks. For å se flere eksempler på tilgjengelige modeller, se AWS Inferentia og Trainium på Hugging Face.

Kodeendringene som kreves for å overføre en modell fra Hugging Face-transformatorer til Hugging Face Optimal nevron Python-biblioteket var ganske lavt. Fordi lm-evaluering-sele bruker AutoModelForCausalLM, er det et fall i erstatning ved hjelp av NeuronModelForCausalLM. Uten en forhåndskompilert modell blir modellen automatisk kompilert i øyeblikket, noe som kan legge til 15–60 minutter på en jobb. Dette ga oss fleksibiliteten til å distribuere testing for enhver AWS Inferentia2-forekomst og støttet CausalLM-modell.

Resultater

På grunn av måten benchmarkene og modellene fungerer på, forventet vi ikke at poengsummene skulle samsvare nøyaktig på tvers av forskjellige løp. De bør imidlertid være veldig nære basert på standardavviket, og det har vi konsekvent sett, som vist i følgende tabell. De første benchmarkene vi kjørte på AWS Inferentia2 ble alle bekreftet av Hugging Face-ledertavlen.

In lm-evaluation-harness, er det to hovedstrømmer som brukes av forskjellige tester: generate_until og loglikelihood. Gsm8k-testen bruker primært generate_until å generere svar akkurat som under inferens. Loglikelihood brukes hovedsakelig i benchmarking og testing, og undersøker sannsynligheten for at ulike utganger produseres. Begge jobber i Neuron, men de loglikelihood metoden i SDK 2.16 bruker flere trinn for å bestemme sannsynlighetene og kan ta ekstra tid.

Kom i gang med Neuron og lm-evaluering-sele

Koden i denne delen kan hjelpe deg å bruke lm-evaluation-harness og kjøre den mot støttede modeller på Hugging Face. For å se noen tilgjengelige modeller, besøk AWS Inferentia og Trainium på Hugging Face.

Hvis du er kjent med å kjøre modeller på AWS Inferentia2, vil du kanskje legge merke til at det ikke er noen num_cores innstilling som sendes inn. Koden vår oppdager hvor mange kjerner som er tilgjengelige og sender automatisk dette tallet inn som en parameter. Dette lar deg kjøre testen med samme kode uavhengig av hvilken forekomststørrelse du bruker. Du kan også legge merke til at vi refererer til den originale modellen, ikke en Neuron-kompilert versjon. Selen sammenstiller automatisk modellen for deg etter behov.

Følgende trinn viser deg hvordan du distribuerer gradienten gradientai/v-alpha-tross modell vi testet. Hvis du vil teste med et mindre eksempel på en mindre forekomst, kan du bruke mistralai/Mistral-7B-v0.1 modell.

1. Standardkvoten for å kjøre On-Demand Inf-instanser er 0, så du bør be om en økning via Service Quotas. Legg til en ny forespørsel for alle Inf Spot Instance-forespørsler slik at du kan teste med Spot Instances. Du trenger en kvote på 192 vCPUer for dette eksemplet ved å bruke en inf2.48xlarge-forekomst, eller en kvote på 4 vCPUer for en grunnleggende inf2.xlarge (hvis du distribuerer Mistral-modellen). Kvoter er AWS-regionspesifikke, så sørg for at du ber om inn us-east-1 or us-west-2.
2. Bestem forekomsten din basert på modellen din. Fordi v-alpha-tross er en 70B-arkitektur, bestemte vi oss for å bruke en inf2.48xlarge-forekomst. Distribuer en inf2.xlarge (for 7B Mistral-modellen). Hvis du tester en annen modell, må du kanskje justere forekomsten avhengig av størrelsen på modellen.
3. Distribuer forekomsten ved å bruke Hugging Face DLAMI versjon 20240123, slik at alle nødvendige drivere er installert. (Prisen som vises inkluderer forekomstkostnaden, og det er ingen ekstra programvareavgift.)
4. Juster stasjonsstørrelsen til 600 GB (100 GB for Mistral 7B).
5. Klon og installer lm-evaluation-harness på instansen. Vi spesifiserer en build slik at vi vet at eventuelle avvik skyldes modellendringer, ikke test- eller kodeendringer.

git clone https://github.com/EleutherAI/lm-evaluation-harness
cd lm-evaluation-harness
# optional: pick specific revision from the main branch version to reproduce the exact results
git checkout 756eeb6f0aee59fc624c81dcb0e334c1263d80e3
# install the repository without overwriting the existing torch and torch-neuronx installation
pip install --no-deps -e . 
pip install peft evaluate jsonlines numexpr pybind11 pytablewriter rouge-score sacrebleu sqlitedict tqdm-multiprocess zstandard hf_transfer

6. Kjør lm_eval med hf-neuron modelltypen og sørg for at du har en lenke til veien tilbake til modellen på Hugging Face:

# e.g use mistralai/Mistral-7B-v0.1 if you are on inf2.xlarge
MODEL_ID=gradientai/v-alpha-tross

python -m lm_eval --model "neuronx" --model_args "pretrained=$MODEL_ID,dtype=bfloat16" --batch_size 1 --tasks gsm8k

Hvis du kjører det foregående eksemplet med Mistral, bør du motta følgende utdata (på den mindre inf2.xlarge kan det ta 250 minutter å kjøre):

███████████████████████| 1319/1319 [32:52<00:00,  1.50s/it]
neuronx (pretrained=mistralai/Mistral-7B-v0.1,dtype=bfloat16), gen_kwargs: (None), limit: None, num_fewshot: None, batch_size: 1
|Tasks|Version|  Filter  |n-shot|  Metric   |Value |   |Stderr|
|-----|------:|----------|-----:|-----------|-----:|---|-----:|
|gsm8k|      2|get-answer|     5|exact_match|0.3806|±  |0.0134|

Rydd opp

Når du er ferdig, sørg for å stoppe EC2-forekomstene via Amazon EC2-konsollen.

konklusjonen

Gradient- og Neuron-teamene er glade for å se en bredere bruk av LLM-evaluering med denne utgivelsen. Prøv det selv og kjør det mest populære evalueringsrammeverket på AWS Inferentia2-forekomster. Du kan nå dra nytte av tilgjengeligheten på forespørsel til AWS Inferentia2 når du bruker tilpasset LLM-utvikling fra Gradient. Kom i gang med å hoste modeller på AWS Inferentia med disse tutorials.

Om forfatterne

Michael Feil er AI-ingeniør ved Gradient og har tidligere jobbet som ML-ingeniør hos Rodhe & Schwarz og forsker ved Max-Plank Institute for Intelligent Systems og Bosch Rexroth. Michael er en ledende bidragsyter til ulike åpen kildekode-inferensbiblioteker for LLM-er og åpen kildekode-prosjekter som StarCoder. Michael har en bachelorgrad i mekatronikk og IT fra KIT og en mastergrad i robotikk fra Technical University of München.

Jim Burtoft er Senior Startup Solutions Architect hos AWS og jobber direkte med startups som Gradient. Jim er en CISSP, en del av AWS AI/ML Technical Field Community, en Neuron Ambassador, og jobber med åpen kildekode-fellesskapet for å muliggjøre bruk av Inferentia og Trainium. Jim har en bachelorgrad i matematikk fra Carnegie Mellon University og en mastergrad i økonomi fra University of Virginia.

• 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/gradient-makes-llm-benchmarking-cost-effective-and-effortless-with-aws-inferentia/