Parandage Falconi mudelite jõudlust rakendusega Amazon SageMaker | Amazoni veebiteenused

Milline on optimaalne raamistik ja konfiguratsioon suurte keelemudelite (LLM) majutamiseks teksti genereerivate AI-rakenduste jaoks? Vaatamata LLM-ide teenindamise võimaluste rohkusele, on sellele mudelite suuruse, mudelite erineva arhitektuuri, rakenduste jõudlusnõuete ja muu tõttu raske vastata. The Amazon SageMaker Large Model Inference (LMI) konteiner muudab LLM-ide teenindamise lihtsaks, koondades hulga erinevaid raamistikke ja tehnikaid, mis optimeerivad LLM-ide juurutamist. LMI konteineril on võimas serveerimispakk nn DJL serveerimine mis on aluseks oleva LLM-i suhtes agnostiline. See pakub süsteemitaseme konfiguratsiooniparameetreid, mida saab häälestada antud LLM-i hostimistaristu parima jõudluse saamiseks. Sellel on ka tugi hiljutistele optimeerimistele, nagu pidev pakkimine, mida tuntakse ka korduva partiimise või jooksva partiidena, mis parandab oluliselt läbilaskevõimet.

Varasemas pärast, näitasime, kuidas saate LMI konteinerit kasutada Falconi mudeliperekonna juurutamiseks SageMakeris. Selles postituses näitame, kuidas parandada Falcon-40B teenindamise läbilaskevõimet ja latentsust selliste meetoditega nagu pidev partiide jagamine. Samuti pakume intuitiivset arusaama SageMakeri LMI konteineri pakutavatest konfiguratsiooniparameetritest, mis aitavad teil leida oma tegeliku rakenduse jaoks parima konfiguratsiooni.

LLM-ide tekstigeneratiivse järelduse põhialused

Vaatame esmalt mõningaid põhialuseid selle kohta, kuidas teksti genereerimiseks LLM-ide jaoks järeldusi teha.

Edasipääs, aktiveerimised ja KV vahemälu

Arvestades märkide sisendjada, käivitatakse need a forward pass järgmise märgi genereerimiseks kõigis LLM-i kihtides (nagu Falcon). A forward pass viitab sisendandmete edastamisele närvivõrgu kaudu väljundi saamiseks. Teksti genereerimise korral hõlmab edasiliikumine keelemudelisse algse seemne või konteksti sisestamist ja jadas järgmise märgi või märgi genereerimist. Tekstijada genereerimiseks tehakse protsessi sageli iteratiivselt, mis tähendab, et seda korratakse väljundjada iga sammu või positsiooni jaoks. Igal iteratsioonil genereerib mudel järgmise märgi või märgi, millest saab genereeritud teksti osa, ja see protsess jätkub kuni soovitud pikkusega teksti genereerimiseni.

Teksti genereerimine keelemudelitega, nagu Falcon või GPT autoregressive. See tähendab, et mudel genereerib ühe märgi korraga, tingitades samal ajal eelnevalt loodud žetoonid. Teisisõnu, igal iteratsioonil võtab mudel sisendiks varem loodud teksti ja ennustab selle konteksti põhjal järgmise märgi. Nagu märgitud vLLM: lihtne, kiire ja odav LLM-i serveerimine koos PagedAttentioniga, selles autoregressiivses dekodeerimisprotsessis toodavad kõik LLM-i sisendmärgid tähelepanuvõtme ja väärtustensorid ning neid tensoreid hoitakse GPU mälus järgmiste märkide loomiseks. Neid vahemällu salvestatud võtme- ja väärtustensoreid nimetatakse sageli kui KV cache.

Eeltäitmise ja dekodeerimise faasid

Autoregressiivses dekodeerimisprotsessis, nagu see, mida kasutatakse teksti genereerimisel keelemudelitega nagu Falcon, on tavaliselt kaks peamist faasi: prefill faas ja decode faas. Need etapid on sidusa ja kontekstuaalselt asjakohase teksti loomiseks üliolulised.

Eeltäitmise etapp sisaldab järgmist:

• Esialgne kontekst – Eeltäitmise faas algab kasutaja esitatud esialgse konteksti või algtekstiga. See esialgne kontekst võib olla lause, fraas või isegi ainult üks sõna. See määrab teksti genereerimise lähtepunkti ja loob konteksti järgmiseks.
• Mudeli konditsioneerimine – Pakutud konteksti kasutatakse keelemudeli tingimuseks. Mudel kasutab seda konteksti sisendiks ja genereerib kontekstist arusaamise põhjal jadas järgmise märgi (sõna või märgi).
• Tokenite genereerimine – Mudel genereerib ühe märgi korraga, ennustades, mis peaks tekstis järgmisena tulema. See märk lisatakse kontekstile, laiendades seda tõhusalt.
• Iteratiivne protsess – Märkide genereerimise protsessi korratakse iteratiivselt. Igas etapis loob mudel märgi, võttes arvesse värskendatud konteksti, mis hõlmab nüüd ka eelmistes etappides loodud märke.

Eeltäitmise faas jätkub seni, kuni on täidetud etteantud peatumise tingimus. See tingimus võib olla loodud teksti maksimaalne pikkus, konkreetne märk, mis annab märku teksti lõpust, või mõni muu kasutaja või rakenduse seatud kriteerium.

Dekodeerimise etapp sisaldab järgmist:

• Lõpuleviimine – Pärast eeltäitmisetappi on teil osaliselt loodud tekst, mis võib mingil hetkel olla puudulik või ära lõigatud. Dekodeerimise faas vastutab teksti lõpuleviimise eest, et muuta see sidusaks ja grammatiliselt õigeks.
• Viimase märgi jätk – Dekodeerimise faasis algab mudel viimasest eeltäitmise faasis genereeritud märgist. See kasutab seda märki esialgse kontekstina ja loob teksti jätkamiseks järgmise märgi.
• Iteratiivne lõpetamine – Sarnaselt eeltäitefaasiga on žetoonide genereerimise protsess taas korduv. Mudel genereerib ühe märgi korraga, tingimusel et jada eelnevad märgid.
• Seiskumise tingimus – Dekodeerimisfaasil on ka peatustingimus, mis võib olla sama, mis eeltäitmise faasis, nt maksimaalse pikkuse saavutamine või tekstilõpu märgi leidmine. Kui see tingimus on täidetud, genereerimisprotsess peatub.

Eeltäitmise ja dekodeerimise faaside kombinatsioon võimaldab autoregressiivsetel mudelitel luua teksti, mis põhineb algsel kontekstil ja loob sidusaid, kontekstipõhiseid ja kontekstuaalselt järjepidevaid tekstijadasid.

Viitama Hajutatud teenindussüsteem trafopõhistele generatiivsetele mudelitele protsessi üksikasjaliku selgituse saamiseks.

Läbilaskevõime optimeerimine dünaamilise partiimise abil

Seni oleme rääkinud ainult ühest sisendist. Praktikas eeldame, et käsitleme mitut päringut, mis saabub juhuslikult rakendusklientidelt, et teha järeldusi samaaegselt või astmeliselt. Traditsioonilisel viisil saab graafikaprotsessori läbilaskevõime ja arvutusressursside kasutamise suurendamiseks kasutada põhipakkimist. Pakkimine kombineerib tõhusalt rohkem kui ühe päringu arvulisi esitusi partiis ja teostab paralleelselt autoregressiivseid edasikäike. See nutikas partiide jaotamine toimub serveerimispoolel. SageMaker LMI DJLServingi serverit saab konfigureerida mitme päringu pakkimiseks, et neid paralleelselt töödelda, määrates järgmised parameetrid serveerimine.omadused:

• max_partii_viivitus = 100 – Partii koondamise maksimaalne viivitus millisekundites. Vaikeväärtus on 100 millisekundit.
• partii_suurus = 32 – partii dünaamiline suurus. Vaikimisi on 1.

Põhimõtteliselt näitab see, et DJLServing seab päringud järjekorda 100 millisekundit korraga või kui järjekorras olevate päringute arv on kuni määratud partii_suuruseni, plaanitakse partii käivitada järelduste tegemiseks taustaprogrammi. Seda tuntakse kui dynamic batching. See on dünaamiline, kuna partii suurus võib partiide lõikes muutuda sõltuvalt sellest, kui palju taotlusi selle aja jooksul lisati. Kuid kuna päringutel võivad olla erinevad omadused (näiteks võivad mõned päringud olla 20 sisendi ja 500 väljundmärgi kujuga, samas kui teised võivad olla vastupidised, 500 sisendiga, kuid ainult 20 väljundit), võivad mõned päringud olla lõpetavad töötlemise kiiremini kui teised samas partiis. Selle tulemuseks võib olla GPU alakasutamine, oodates, kuni kõik partii pardapäringud dekodeerimisetapi lõpule viivad, isegi kui järjekorras on töötlemist ootavaid täiendavaid taotlusi. Seda protsessi illustreerib järgmine diagramm.

Läbilaskevõime optimeerimine pideva partiimise abil

koos continuous batching, tuntud ka kui iterative or rolling partiides kasutame ära eeltäitmise ja dekodeerimise etapi erinevused. Pideva pakkimise aktiveerimiseks pakub DJServing järgmisi lisakonfiguratsioone vastavalt serving.propertiesile.

• mootor=MPI – soovitame kasutada MPI-mootorit pidevaks partiide täitmiseks.
• option.rolling_batch=auto või lmi-dist – soovitame kasutada automaatset, kuna see valib tulevikus koos muude optimeeringutega automaatselt kõige sobivama jooksva partii algoritmi.
• option.max_rolling_batch_size=32 – see piirab samaaegsete päringute arvu. Vaikimisi on 32.

Pideva partiimise korral ei oota serveerimispinn (DJLServing), kuni kõik partii pardapäringud dekodeerimisetapi lõpule jõuavad. Pigem tõmbab see loogiliste katkestuste korral (dekodeerimisetapi ühe iteratsiooni lõpus) ​​sisse täiendavaid päringuid, mis ootavad järjekorras, kuni praegune partii veel töötleb (sellest ka nimi veerev partii). See kontrollib dekodeerimisetapi iga iteratsiooni lõpus ootelolevaid taotlusi. Pidage meeles, et iga päringu puhul peame käivitama eeltäitmise etapi, millele järgneb järjestikune dekodeerimise etapp. Kuna saame päringu eeltäidetapi jaoks paralleelselt töödelda kõiki päringu esialgsest viipast pärit märke, peatame iga kord, kui uus taotlus sisse tõmmatakse, ajutiselt partii pardapäringute dekodeerimisetapi – salvestame ajutiselt selle KV vahemälu. ja aktiveerimised mällu ning käivitada uute päringute eeltäitmise etapp.

Selle vahemälu suurust saab konfigureerida järgmise valikuga:

Kui eeltäitmine on lõppenud, ühendame uued päringud ja vanad peatatud päringud uude jooksvasse partii, mis saab paralleelselt jätkata oma dekodeerimisetappi. Pange tähele, et vanad peatatud päringud võivad jätkata oma dekodeerimisetappi sealt, kus need pooleli jäid ja uued päringud algavad nende esimesest uuest märgist.

Võib-olla olete juba aru saanud, et pidev komplekteerimine on peaaegu sarnane lähenemine, millega me oma igapäevaelus ülesandeid loomulikult paralleelseks teeme. Meile tulevad sõnumid, meilid ja telefoniteatised (potentsiaalselt uued päringud) juhuslikel aegadel (analoogselt mitme päringuga, mis saabuvad GPU-de puhul juhuslikult jaotatuna). See kõik toimub siis, kui täidame oma lennuülesandeid – meilide koostamine, kodeerimine, koosolekutel osalemine (analoogselt GPU-des praegu töödeldavate ülesannetega). Loogiliste pauside ajal peatame oma lennuülesannete täitmise ja kontrollime oma teatisi, et otsustada, kas meil on vaja mingeid toiminguid teha, ja kui on, siis lisame selle oma lennuülesannete hulka (päriselu jooksev partii) või pane see ülesannete nimekirja (järjekorda).

Kõik kokku: kuidas mõelda GPU-de mälukasutusele

Soovitatav on testida oma mudelit, et näha, milline konfiguratsioon on teie ettevõtte jaoks kõige kuluefektiivsem. Arusaadavuse loomiseks visualiseerime GPU-de mälujalajälge mudeli laadimisel ja järjestikuste päringute töötlemisel jooksva partiina. Selle postituse jaoks oletame, et laadime mudeli Falcon-40B ühte G5 eksemplari tüüpi eksemplari, mis on installitud NVIDIA A10G GPU-dega, millest igaühel on 24 GB mälu. Pange tähele, et sarnane arusaam kehtib p3, p4 ja p5 eksemplaritüüpide puhul, mis on kaasas V100, A100 ja H100 GPU seeriatega.

Järgmine on Falcon-40B teenindamiseks vajaliku kogumälu ligikaudse väärtuse saamise ülevaade:

• Mudeli suurus = mudeli parameetrite arv (40 miljardit Falcon-40B puhul) x 4 baiti parameetri kohta (FP32 jaoks) = 160 GB
• Ligikaudne kogumälu, mis on vajalik Falcon-40B laadimiseks järelduste tegemiseks = Mudeli suurus (=160 GB) + KV vahemälu (tähelepanu vahemälu) (=*20 GB) + ML Frameworksi lisamälu (umbes 2 GB)

Falcon-40B puhul, kui tihendame mudeli, kvantifitseerides mudeli bfloat16 (2 baiti) andmetüübile, muutub mudeli suuruseks ligikaudu 80 GB. Nagu näete, on see siiski suurem kui ühe kiirendi toetatud mälu, seega peame kasutama mudeli jagamise (sharding) tehnikat koos spetsiaalse seadmega. tensori paralleelsus (TP) läheneb ja killustab mudelit mitmes kiirendis. Oletame, et oleme valinud g5.24xlarge, millel on 4 A10G GPU seadet. Kui konfigureerime DJLServingu (serving.properties) järgmisega, võime eeldada, et 80 GB mudelikaalu jagatakse võrdselt kõigi 4 GPU vahel:

koos tensor_parallel_degree 4-le on 20 GB GPU mälust umbes 24 GB (ligikaudu 84%) juba kasutusel isegi enne ühe taotluse töötlemist. Ülejäänud 16% GPU-st kasutatakse sissetulevate päringute jaoks KV vahemälu jaoks. Võimalik, et teie äristsenaariumi ning selle latentsus- ja läbilaskevõimenõuete jaoks on 2–3 GB allesjäänud mälust enam kui piisav. Kui ei, siis saate eksemplari suurust suurendada väärtusele g5.48xlarge, millel on 8 GPU-d ja mis kasutab parameetri tensor_parallel_degree väärtuseks 8. Sellisel juhul kasutatakse mudelite kaalumiseks iga GPU saadaolevast 10 GB mälust ainult umbes 24 GB ja me neil on umbes 60% ülejäänud GPU-st aktiveerimiste ja KV vahemälu jaoks. Intuitiivselt näeme, et see konfiguratsioon võib võimaldada meil suuremat läbilaskevõimet. Lisaks, kuna meil on praegu suurem puhver, saame seda suurendada max_rolling_batch_prefill_tokens ja max_rolling_batch_size parameetrid läbilaskevõime edasiseks optimeerimiseks. Need kaks parameetrit koos juhivad mudeli aktiveerimise eeltäidete ja KV vahemälu eeljaotust. Nende kahe parameetri suurem arv on seotud suurema läbilaskevõimega, eeldades, et teil on GPU mälus piisavalt puhvrit KV vahemälu jaoks.

Pidev komplekteerimine PagedAttentioniga

PagedAttention on UC Berkeley poolt välja töötatud uus optimeerimisalgoritm, mis parandab pidevat komplekteerimisprotsessi, võimaldades tähelepanu vahemälu (KV vahemälu) olla mittekülgne, eraldades mälu fikseeritud suurusega lehtedele või plokkidele. See on inspireeritud virtuaalsest mälust ja opsüsteemides kasutatavatest otsingukontseptsioonidest.

Nagu iga vLLM paberil jaotatakse iga märgijada tähelepanu vahemälu plokkideks ja kaardistatakse plokitabeli kaudu füüsilisteks plokkideks. Tähelepanu arvutamise ajal saab PagedAttentioni tuum kasutada plokitabelit, et tõhusalt tuua plokid füüsilisest mälust. Selle tulemuseks on mälu raiskamise märkimisväärne vähenemine ja suurem partii suurus, suurem GPU kasutamine ja suurem läbilaskevõime.

Toimivuse võrdlus

Juurutuskonfiguratsiooni tõhusa koormustesti tagamiseks on soovitatav alustada äristsenaariumi kaalumisest ning LLM-põhise rakenduse sisendi ja väljundi omaduste selgelt määratlemisest. Näiteks kui töötate kõnekeskuse kokkuvõtte kasutusjuhtumi kallal, võib sisend koosneda suuremast tekstist, näiteks 500 märgiga vestluse ärakiri klienditeenindaja ja kliendi vahel, kuid väljund võib olla suhteliselt väiksem, umbes 100 märgid, mis kujutavad ärakirja kokkuvõtet. Teisest küljest, kui töötate koodi genereerimise stsenaariumi kallal, võib sisend olla nii lühike kui 15 luba, näiteks "kirjutage Pythonis tõhus juurutus kõigi EC2 ressursside, sealhulgas lehekülgede kirjeldamiseks", kuid väljund võib olla palju suurem, ulatudes 500 märgini. Samuti on oluline kaaluda, kas väiksema latentsusaja saavutamine või läbilaskevõime maksimeerimine on teie konkreetse stsenaariumi jaoks esmatähtis.

Pärast äristsenaariumi tervikliku mõistmise omandamist saate analüüsida ja määrata oma hostimiskeskkonna optimaalse konfiguratsiooni. Selles kontekstis hõlmab hostimiskeskkond mitmesuguseid põhielemente, sealhulgas eksemplari tüüpi ja muid konfiguratsiooniparameetreid, nagu tensor_parallel_degree, max_rolling_batch_size, max_rolling_batch_prefill_tokens, ja veel. Meie eesmärk on tuvastada kõige tõhusam seadistus, mis toetab meie reageerimisaja, läbilaskevõime ja mudeli väljundkvaliteedi nõudeid.

Analüüsis võrdlesime jõudlust, et illustreerida pideva partiide jaotamise eeliseid võrreldes traditsioonilise dünaamilise partiidega. Kasutasime serving.properties'is järgmises tabelis kirjeldatud konfiguratsioone dünaamilise ja iteratiivse partiimise jaoks, kasutades SageMakeri LMI konteinerit.

Dünaamiline pakkimine	Pidev partiide komplekteerimine	Pidev komplekteerimine PagedAttentioniga
mootor = Python option.model_id=tiiuae/falcon-40b option.tensor_parallel_degree=8 option.dtype=fp16 partii_suurus=4 max_batch_delay=100 option.trust_remote_code = tõene	mootor = MPI option.model_id = {{s3_url}} option.trust_remote_code = tõene option.tensor_parallel_degree = 8 option.max_rolling_batch_size = 32 option.rolling_batch = auto option.dtype = fp16 option.max_rolling_batch_prefill_tokens = 1024 option.paged_attention = Vale	mootor = MPI option.model_id = {{s3_url}} option.trust_remote_code = tõene option.tensor_parallel_degree = 8 option.max_rolling_batch_size = 32 option.rolling_batch = auto option.dtype = fp16 option.max_rolling_batch_prefill_tokens = 1024 option.paged_attention = Tõene

Neid kahte konfiguratsiooni võrreldi Falcon-40B jaoks FP16 andmetüübiga, mis oli juurutatud saidil ml.g5.48xlarge paaris erinevas stsenaariumis, mis esindavad reaalseid rakendusi:

• Väike arv sisendmärke koos suure hulga märkide genereerimisega - Selle stsenaariumi korral määrati sisendmärkide arv 32-le ja genereeriti 128 uut märgi

Pakkimisstrateegia	Läbilaskevõime (märke/s)	Latentsus p90 (s)
Dünaamiline pakkimine	5.53	58.34
Pidev partiide komplekteerimine	56.04	4.74
Pidev komplekteerimine PagedAttentioniga	59.18	4.76

• Suur sisend koos väikese arvu märkide genereerimisega – Siin fikseerime sisendmärkide arvuks 256 ja palume LLM-il võtta sisendi kokkuvõtteks 32 märgini

Pakkimisstrateegia	Läbilaskevõime (märke/s)	Latentsus p90 (s)
Dünaamiline pakkimine	19.96	59.31
Pidev partiide komplekteerimine	46.69	3.88
Pidev komplekteerimine PagedAttentioniga	44.75	2.67

Näeme, et pidev komplekteerimine PagedAttentioniga tagab 10. stsenaariumi korral 1 korda suurema läbilaskevõime ja 2.3. stsenaariumi korral 2 korda suurema läbilaskevõime võrreldes SageMakeris dünaamilise pakkimise kasutamisega LMI konteineri kasutamise ajal.

Järeldus

Selles postituses vaatlesime, kuidas LLM-id mälu kasutavad, ja selgitasime, kuidas pidev komplekteerimine parandab läbilaskevõimet, kasutades SageMakeri LMI konteinerit. Demonstreerisime Falcon-40B pideva partiide komplekteerimise eeliseid, kasutades SageMakeris LMI konteinerit, näidates võrdlusuuringu tulemusi. Koodi leiate aadressilt GitHub repo.

---

Autoritest

Abhi Shivaditya on AWS-i lahenduste vanemarhitekt, kes teeb koostööd strateegiliste ülemaailmsete ettevõtete organisatsioonidega, et hõlbustada AWS-i teenuste kasutuselevõttu sellistes valdkondades nagu tehisintellekt, hajutatud andmetöötlus, võrgundus ja salvestusruum. Tema teadmised seisnevad süvaõppes loomuliku keele töötlemise (NLP) ja arvutinägemise valdkondades. Abhi abistab kliente suure jõudlusega masinõppemudelite tõhusal juurutamisel AWS-i ökosüsteemis.

Dhawal Patel on AWS-i peamine masinõppearhitekt. Ta on töötanud hajutatud andmetöötluse ja tehisintellektiga seotud probleemide lahendamisel organisatsioonidega alates suurettevõtetest kuni keskmise suurusega idufirmadeni. Ta keskendub süvaõppele, sealhulgas NLP ja Computer Vision domeenidele. Ta aitab klientidel teha SageMakeris suure jõudlusega mudeli järeldusi.

Pinak Panigrahi töötab koos klientidega, et luua masinõppepõhiseid lahendusi, et lahendada strateegilisi äriprobleeme AWS-is. Kui ta pole masinõppega hõivatud, võib teda leida matkamas, raamatut lugemas või sporti vaatamas.

Abhi Sodhani töötab AWS-is AI/ML-lahenduste vanemarhitekti ametikohal, kus ta on spetsialiseerunud klientidele generatiivsete AI- ja ML-lahenduste tehniliste teadmiste ja juhiste pakkumisele. Tema põhirõhk on aidata digitaalsetel kohalikel ettevõtetel generatiivse AI ja ML tehnoloogiate täielikku potentsiaali realiseerida, võimaldades neil oma ärieesmärke tõhusalt saavutada. Lisaks oma ametialastele püüdlustele avaldab Abhi tugevat kirge intellektuaalsete tegevuste vastu, nagu lugemine, ning tegeleb ka füüsilist ja vaimset heaolu edendavate tegevustega, nagu jooga, meditatsioon.

Qing Lan on AWS-i tarkvaraarenduse insener. Ta on Amazonis töötanud mitmete väljakutset pakkuvate toodetega, sealhulgas suure jõudlusega ML järelduslahenduste ja suure jõudlusega logimissüsteemiga. Qingi meeskond käivitas Amazon Advertisingis edukalt esimese miljardi parameetriga mudeli, mille latentsusaeg on väga väike. Qingil on põhjalikud teadmised infrastruktuuri optimeerimise ja süvaõppe kiirendamise kohta.

• SEO-põhise sisu ja PR-levi. Võimenduge juba täna.
• PlatoData.Network Vertikaalne generatiivne Ai. Jõustage ennast. Juurdepääs siia.
• PlatoAiStream. Web3 luure. Täiustatud teadmised. Juurdepääs siia.
• PlatoESG. Süsinik, CleanTech, Energia, Keskkond päikeseenergia, Jäätmekäitluse. Juurdepääs siia.
• PlatoTervis. Biotehnoloogia ja kliiniliste uuringute luureandmed. Juurdepääs siia.
• Allikas: https://aws.amazon.com/blogs/machine-learning/improve-performance-of-falcon-models-with-amazon-sagemaker/