Gradient gør LLM-benchmarking omkostningseffektiv og ubesværet med AWS Inferentia | Amazon Web Services

Dette er et gæsteindlæg skrevet sammen med Michael Feil på Gradient.

Evaluering af ydeevnen af ​​store sprogmodeller (LLM'er) er et vigtigt trin i fortrænings- og finjusteringsprocessen før implementering. Jo hurtigere og hyppigere du er i stand til at validere ydeevnen, jo større er chancerne for, at du vil kunne forbedre modellens ydeevne.

At Gradient, vi arbejder på tilpasset LLM-udvikling og lancerede for nylig vores AI Development Lab, der tilbyder virksomhedsorganisationer en personlig, end-to-end udviklingstjeneste til at bygge private, tilpassede LLM'er og co-piloter med kunstig intelligens (AI). Som en del af denne proces evaluerer vi regelmæssigt ydeevnen af ​​vores modeller (tunede, trænede og åbne) i forhold til åbne og proprietære benchmarks. Mens vi arbejder med AWS-teamet for at træne vores modeller på AWS Trainium, indså vi, at vi var begrænset til både VRAM og tilgængeligheden af ​​GPU-instanser, når det kom til det almindelige værktøj til LLM-evaluering, lm-evaluering-sele. Denne open source-ramme giver dig mulighed for at score forskellige generative sprogmodeller på tværs af forskellige evalueringsopgaver og benchmarks. Det bruges af leaderboards som f.eks Knusende ansigt til offentlig benchmarking.

For at overvinde disse udfordringer besluttede vi at bygge og åbne vores løsning – integrerende AWS Neuron, biblioteket bagved AWS-inferens og Trainium, ind lm-evaluation-harness. Denne integration gjorde det muligt at benchmarke v-alpha-tross, en tidlig version af vores Albatross-model, mod andre offentlige modeller under uddannelsesprocessen og efter.

Til kontekst kører denne integration som en ny modelklasse inden for lm-evaluation-harness, der abstraherer inferensen af ​​tokens og log-sandsynlighedsestimering af sekvenser uden at påvirke den faktiske evalueringsopgave. Beslutningen om at flytte vores interne testpipeline til Amazon Elastic Compute Cloud (Amazon EC2) Inf2 forekomster (drevet af AWS Inferentia2) gjorde det muligt for os at få adgang til op til 384 GB delt acceleratorhukommelse, hvilket ubesværet passede til alle vores nuværende offentlige arkitekturer. Ved at bruge AWS Spot Instances var vi i stand til at drage fordel af ubrugt EC2-kapacitet i AWS Cloud – hvilket muliggjorde omkostningsbesparelser på op til 90 % nedsat fra on-demand-priser. Dette minimerede den tid, det tog at teste, og gav os mulighed for at teste oftere, fordi vi var i stand til at teste på tværs af flere forekomster, der var let tilgængelige og frigive forekomsterne, når vi var færdige.

I dette indlæg giver vi en detaljeret oversigt over vores test, de udfordringer, vi stødte på, og et eksempel på brug af testselen på AWS Inferentia.

Benchmarking på AWS Inferentia2

Målet med dette projekt var at generere identiske scores som vist i Åbn LLM Leaderboard (for mange CausalLM-modeller tilgængelige på Hugging Face), mens du bevarer fleksibiliteten til at køre den mod private benchmarks. For at se flere eksempler på tilgængelige modeller, se AWS Inferentia og Trainium på Hugging Face.

Kodeændringerne, der kræves for at overføre en model fra Hugging Face-transformere til Hugging Face Optimal neuron Python-biblioteket var ret lavt. Fordi lm-evaluering-sele bruger AutoModelForCausalLM, er der et fald i udskiftning vha NeuronModelForCausalLM. Uden en prækompileret model kompileres modellen automatisk i øjeblikket, hvilket kan tilføje 15-60 minutter til et job. Dette gav os fleksibiliteten til at implementere test for enhver AWS Inferentia2-instans og understøttet CausalLM-model.

Resultater

På grund af den måde, benchmarks og modeller fungerer på, forventede vi ikke, at resultaterne ville matche nøjagtigt på tværs af forskellige kørsler. De skulle dog ligge meget tæt baseret på standardafvigelsen, og det har vi konsekvent set, som vist i følgende tabel. De første benchmarks, vi kørte på AWS Inferentia2, blev alle bekræftet af Hugging Face leaderboardet.

In lm-evaluation-harness, er der to hovedstrømme, der bruges af forskellige tests: generate_until , loglikelihood. Gsm8k-testen bruger primært generate_until at generere svar ligesom under inferens. Loglikelihood bruges hovedsageligt i benchmarking og test, og undersøger sandsynligheden for, at forskellige output bliver produceret. Begge arbejder i Neuron, men den loglikelihood metode i SDK 2.16 bruger yderligere trin til at bestemme sandsynligheden og kan tage ekstra tid.

Kom godt i gang med Neuron og lm-evaluering-sele

Koden i dette afsnit kan hjælpe dig med at bruge lm-evaluation-harness og kør det mod understøttede modeller på Hugging Face. For at se nogle tilgængelige modeller, besøg AWS Inferentia og Trainium på Hugging Face.

Hvis du er bekendt med at køre modeller på AWS Inferentia2, bemærker du måske, at der ikke er nogen num_cores indstilling sendt ind. Vores kode registrerer, hvor mange kerner der er tilgængelige og sender automatisk dette nummer ind som en parameter. Dette lader dig køre testen med den samme kode, uanset hvilken instansstørrelse du bruger. Du vil måske også bemærke, at vi refererer til den originale model, ikke en Neuron-kompileret version. Selen sammensætter automatisk modellen for dig efter behov.

De følgende trin viser dig, hvordan du implementerer Gradienten gradientai/v-alpha-tross model vi testede. Hvis du vil teste med et mindre eksempel på en mindre instans, kan du bruge mistralai/Mistral-7B-v0.1 model.

1. Standardkvoten for at køre On-Demand Inf-instanser er 0, så du bør anmode om en stigning via Service Quotas. Tilføj endnu en anmodning for alle Inf Spot Instance-anmodninger, så du kan teste med Spot Instances. Du skal bruge en kvote på 192 vCPU'er til dette eksempel ved at bruge en inf2.48xlarge-instans eller en kvote på 4 vCPU'er for en grundlæggende inf2.xlarge (hvis du implementerer Mistral-modellen). Kvoter er AWS-regionsspecifikke, så sørg for at anmode om ind us-east-1 or us-west-2.
2. Beslut dig for din instans baseret på din model. Fordi v-alpha-tross er en 70B-arkitektur, besluttede vi at bruge en inf2.48xlarge-instans. Implementer en inf2.xlarge (til 7B Mistral-modellen). Hvis du tester en anden model, skal du muligvis justere din instans afhængigt af størrelsen på din model.
3. Implementer forekomsten ved hjælp af Hugging Face DLAMI version 20240123, så alle nødvendige drivere er installeret. (Den viste pris inkluderer instansomkostningerne, og der er ingen ekstra softwareafgift.)
4. Juster drevstørrelsen til 600 GB (100 GB for Mistral 7B).
5. Klon og installer lm-evaluation-harness på instansen. Vi specificerer en build, så vi ved, at enhver afvigelse skyldes modelændringer, ikke test- eller kodeændringer.

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. Kør lm_eval med hf-neuron modeltypen og sørg for at du har et link til stien tilbage 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 kører det foregående eksempel med Mistral, skulle du modtage følgende output (på den mindre inf2.xlarge kan det tage 250 minutter at kø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|

Ryd op

Når du er færdig, skal du sørge for at stoppe EC2-forekomsterne via Amazon EC2-konsollen.

Konklusion

Gradient- og Neuron-holdene er glade for at se en bredere anvendelse af LLM-evaluering med denne udgivelse. Prøv det selv, og kør den mest populære evalueringsramme på AWS Inferentia2-forekomster. Du kan nu drage fordel af on-demand tilgængeligheden af ​​AWS Inferentia2, når du bruger tilpasset LLM-udvikling fra Gradient. Kom i gang med at hoste modeller på AWS Inferentia med disse tutorials.

Om forfatterne

Michael Feil er AI-ingeniør hos Gradient og har tidligere arbejdet som ML-ingeniør hos Rodhe & Schwarz og forsker ved Max-Plank Institute for Intelligent Systems og Bosch Rexroth. Michael er en førende bidragyder til forskellige open source-inferensbiblioteker for LLM'er og open source-projekter såsom StarCoder. Michael har en bachelorgrad i mekatronik og IT fra KIT og en kandidatgrad i robotteknologi fra Technical University of München.

Jim Burtoft er Senior Startup Solutions Architect hos AWS og arbejder direkte med startups som Gradient. Jim er en CISSP, en del af AWS AI/ML Technical Field Community, en Neuron-ambassadør og arbejder med open source-fællesskabet for at muliggøre brugen af ​​Inferentia og Trainium. Jim har en bachelorgrad i matematik fra Carnegie Mellon University og en kandidatgrad i økonomi fra University of Virginia.

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