Izboljšajte delovanje modelov Falcon z Amazon SageMaker | Spletne storitve Amazon

Kakšno je optimalno ogrodje in konfiguracija za gostovanje velikih jezikovnih modelov (LLM) za generativne aplikacije AI, ki ustvarjajo besedilo? Kljub obilici možnosti za opravljanje študija LLM je na to vprašanje težko odgovoriti zaradi velikosti modelov, različnih arhitektur modelov, zahtev glede zmogljivosti aplikacij in drugega. The Amazon SageMaker Vsebnik Large Model Inference (LMI). omogoča enostavno streženje LLM z združevanjem množice različnih ogrodij in tehnik, ki optimizirajo uvajanje LLM. Vsebnik LMI ima močan servirni sklad, imenovan DJL postrežba ki je agnostičen glede na osnovni LLM. Zagotavlja konfiguracijske parametre na ravni sistema, ki jih je mogoče nastaviti za pridobivanje najboljše zmogljivosti gostiteljske infrastrukture za dani LLM. Ima tudi podporo za nedavne optimizacije, kot je neprekinjeno doziranje, znano tudi kot iterativno doziranje ali tekoče doziranje, ki zagotavlja znatne izboljšave v pretoku.

V zgodnejšem objava, smo pokazali, kako lahko uporabite vsebnik LMI za namestitev družine modelov Falcon na SageMaker. V tem prispevku prikazujemo, kako izboljšati prepustnost in zakasnitev pri streženju Falcon-40B s tehnikami, kot je neprekinjeno šarženje. Zagotavljamo tudi intuitivno razumevanje konfiguracijskih parametrov, ki jih zagotavlja vsebnik SageMaker LMI, ki vam lahko pomagajo najti najboljšo konfiguracijo za vašo aplikacijo v resničnem svetu.

Osnove besedilno generativnega sklepanja za LLM

Najprej si oglejmo nekaj osnov o tem, kako izvajati sklepanje za LLM za generiranje besedila.

Naprej, aktivacije in predpomnilnik KV

Glede na vhodno zaporedje žetonov se izvajajo v a forward pass čez vse plasti LLM (kot je Falcon), da ustvarite naslednji žeton. A forward pass se nanaša na postopek prenosa vhodnih podatkov skozi nevronsko mrežo, da se ustvari izhod. V primeru generiranja besedila napredni prehod vključuje dovajanje začetnega semena ali konteksta v jezikovni model in generiranje naslednjega znaka ali žetona v zaporedju. Za ustvarjanje zaporedja besedila se postopek pogosto izvaja iterativno, kar pomeni, da se ponovi za vsak korak ali položaj v izhodnem zaporedju. Pri vsaki ponovitvi model ustvari naslednji znak ali žeton, ki postane del generiranega besedila, in ta proces se nadaljuje, dokler ni generirana želena dolžina besedila.

Generiranje besedila z jezikovnimi modeli, kot sta Falcon ali GPT autoregressive. To pomeni, da model ustvari en žeton naenkrat, medtem ko pogojeva s predhodno ustvarjenimi žetoni. Z drugimi besedami, pri vsaki ponovitvi model vzame predhodno ustvarjeno besedilo kot vhod in predvidi naslednji žeton na podlagi tega konteksta. Kot je navedeno v vLLM: Enostavno, hitro in poceni LLM storitev s PagedAttention, v tem procesu avtoregresijskega dekodiranja vsi vhodni žetoni v LLM proizvajajo svoje tenzorje ključa in vrednosti, ti tenzorji pa se hranijo v pomnilniku GPE za ustvarjanje naslednjih žetonov. Ti predpomnjeni tenzorji ključev in vrednosti se pogosto imenujejo KV cache.

Fazi predizpolnjevanja in dekodiranja

V procesu avtoregresivnega dekodiranja, kot je tisti, ki se uporablja pri ustvarjanju besedila z jezikovnimi modeli, kot je Falcon, sta običajno dve glavni fazi: prefill faza in decode faza. Te faze so ključne za ustvarjanje koherentnega in vsebinsko ustreznega besedila.

Faza predpolnjenja vključuje naslednje:

• Začetni kontekst – Faza predizpolnjevanja se začne z začetnim kontekstom ali začetnim besedilom, ki ga zagotovi uporabnik. Ta začetni kontekst je lahko stavek, fraza ali celo samo ena beseda. Postavi izhodišče za ustvarjanje besedila in zagotovi kontekst za naslednje.
• Kondicioniranje modela – Podani kontekst se uporablja za pogojevanje jezikovnega modela. Model vzame ta kontekst kot vhod in ustvari naslednji žeton (besedo ali znak) v zaporedju na podlagi svojega razumevanja konteksta.
• Generiranje žetonov – Model generira en žeton naenkrat in napove, kaj naj sledi v besedilu. Ta žeton je pripet kontekstu in ga dejansko razširi.
• Iterativni proces – Postopek generiranja žetonov se iterativno ponavlja. V vsakem koraku model ustvari žeton, medtem ko upošteva posodobljen kontekst, ki zdaj vključuje žetone, ustvarjene v prejšnjih korakih.

Faza predpolnjenja se nadaljuje, dokler ni izpolnjen vnaprej določen pogoj zaustavitve. Ta pogoj je lahko največja dolžina ustvarjenega besedila, določen žeton, ki signalizira konec besedila, ali katero koli drugo merilo, ki ga nastavi uporabnik ali aplikacija.

Faza dekodiranja vključuje naslednje:

• Zaključek – Po fazi predizpolnjevanja imate delno ustvarjeno besedilo, ki je lahko na neki točki nepopolno ali odrezano. Faza dekodiranja je odgovorna za dokončanje besedila, da postane koherentno in slovnično pravilno.
• Nadaljevanje od zadnjega žetona – V fazi dekodiranja se model začne od zadnjega žetona, ustvarjenega med fazo predizpolnjevanja. Ta žeton uporabi kot začetni kontekst in ustvari naslednji žeton za nadaljevanje besedila.
• Iterativno dokončanje – Tako kot v fazi predizpolnjevanja je postopek generiranja žetonov spet iterativen. Model generira en žeton naenkrat, odvisno od predhodnih žetonov v zaporedju.
• Stanje ustavitve – Faza dekodiranja ima tudi pogoj zaustavitve, ki je lahko enak kot v fazi predizpolnjevanja, kot je doseganje največje dolžine ali nalet na žeton konca besedila. Ko je ta pogoj izpolnjen, se proces generiranja ustavi.

Kombinacija faz predizpolnjevanja in dekodiranja omogoča avtoregresijskim modelom ustvarjanje besedila, ki gradi na začetnem kontekstu in proizvaja koherentna, kontekstualno pomembna in kontekstualno dosledna zaporedja besedila.

Nanašati se na Distribuirani strežni sistem za transformatorske generatorske modele za podrobno razlago postopka.

Optimizacija pretoka z uporabo dinamičnega doziranja

Doslej smo govorili le o enem vnosu. V praksi pričakujemo, da bomo obravnavali več zahtev, ki prihajajo naključno od aplikacijskih odjemalcev za sklepanje hkrati ali razporejeno. Na tradicionalen način je mogoče uporabiti osnovno šaržiranje za povečanje prepustnosti in izkoriščenosti računalniških virov GPE. Paket je učinkovito združevanje numeričnih predstavitev več kot ene zahteve v paketu in izvajanje vzporednih tekov avtoregresivnih prehodov naprej. To inteligentno doziranje se izvede na strani serviranja. Strežnik DJLServing SageMaker LMI je mogoče konfigurirati za serijsko združevanje več zahtev za njihovo vzporedno obdelavo z nastavitvijo naslednjih parametrov v serviranje.lastnosti:

• max_batch_delay = 100 – Največja zakasnitev za paketno združevanje v milisekundah. Privzeta vrednost je 100 milisekund.
• velikost_serije = 32 – dinamična velikost paketa. Privzeta vrednost je 1.

To v bistvu kaže, da bo DJLServing postavil zahteve v čakalno vrsto za 100 milisekund naenkrat ali če je število zahtev, ki so postavljene v čakalno vrsto, do podane batch_size, bo serija načrtovana za izvajanje v ozadju za sklepanje. To je znano kot dynamic batching. Je dinamičen, ker se lahko velikost paketa med paketi spreminja glede na to, koliko zahtev je bilo dodanih v tem časovnem obdobju. Ker pa imajo lahko zahteve drugačne značilnosti (nekatere zahteve so lahko na primer v obliki 20 žetonov vnosa in 500 žetonov izhoda, medtem ko so druge lahko obrnjene, s 500 žetoni vnosa, vendar le 20 za izhod), lahko nekatere zahteve dokončanje obdelave hitreje kot drugi v isti seriji. To bi lahko povzročilo premajhno izkoriščenost GPE-ja med čakanjem, da vse zahteve med letom v paketu dokončajo svojo stopnjo dekodiranja, tudi če v čakalni vrsti obstajajo dodatne zahteve, ki čakajo na obdelavo. Naslednji diagram prikazuje ta postopek.

Optimizacija pretoka z neprekinjenim doziranjem

z continuous batching, poznan tudi kot iterative or rolling paketno izkoriščamo razlike med stopnjama predizpolnjevanja in dekodiranja. Za aktiviranje neprekinjenega pakiranja DJServing zagotavlja naslednje dodatne konfiguracije glede na serving.properties:

• motor=MPI – Priporočamo vam uporabo mehanizma MPI za neprekinjeno pakiranje.
• option.rolling_batch=auto ali lmi-dist – Priporočamo uporabo samodejnega, ker bo samodejno izbral najprimernejši algoritem tekoče serije skupaj z drugimi optimizacijami v prihodnosti.
• option.max_rolling_batch_size=32 – To omejuje število sočasnih zahtev. Privzeto je 32.

Pri neprekinjenem pakiranju strežni sklad (DJLServing) ne čaka na vse zahteve med letom v paketu, da zaključi svojo stopnjo dekodiranja. Namesto tega ob logičnih prekinitvah (na koncu ene iteracije v fazi dekodiranja) potegne dodatne zahteve, ki čakajo v čakalni vrsti, medtem ko trenutni paket še obdeluje (od tod tudi ime serija za valjanje). To preverjanje čakajočih zahtev opravi na koncu vsake ponovitve stopnje dekodiranja. Ne pozabite, da moramo za vsako zahtevo zagnati stopnjo predizpolnjevanja, ki ji sledi stopnja zaporednega dekodiranja. Ker lahko obdelamo vse žetone iz začetnega poziva zahteve vzporedno za njegovo stopnjo predizpolnjevanja, vsakič, ko je potegnjena nova zahteva, začasno ustavimo stopnjo dekodiranja med poletnimi zahtevami paketa – začasno shranimo njegov predpomnilnik KV in aktivacije v pomnilniku ter zaženite fazo predizpolnjevanja novih zahtev.

Velikost tega predpomnilnika je mogoče konfigurirati z naslednjo možnostjo:

Ko je predizpolnjevanje končano, združimo nove zahteve in stare začasno ustavljene zahteve v nov tekoči paket, ki lahko vzporedno nadaljuje s stopnjo dekodiranja. Upoštevajte, da lahko stare začasno ustavljene zahteve nadaljujejo svojo stopnjo dekodiranja, kjer so končale, nove zahteve pa se bodo začele s svojim prvim novim žetonom.

Morda ste že ugotovili, da je neprekinjeno serijsko zbiranje skoraj podoben pristop, s katerim naravno vzporedimo naloge v vsakdanjem življenju. Sporočila, e-poštna sporočila, telefonska obvestila (potencialno nove zahteve) prihajajo ob naključnih trenutkih (podobno več zahtevam, ki prihajajo naključno razporejeno za GPE). Vse to se dogaja, medtem ko opravljamo svoje naloge med letom – sestavljamo e-pošto, kodiramo, sodelujemo na sestankih (analogno trenutnim nalogam obdelave v grafičnih procesorjih). Ob logičnih prekinitvah začasno ustavimo svoje naloge med letom in preverimo svoja obvestila, da se odločimo, ali je potrebno kakšno dejanje z naše strani, in če je potrebno, ga dodamo našim opravilom med letom (resnična tekoča serija) ali ga postavite na seznam opravil (čakalna vrsta).

Vse skupaj: Kako razmišljati o uporabi pomnilnika GPE

Priporočljivo je, da svoj model preizkusite z nalaganjem, da vidite, katera konfiguracija je stroškovno najučinkovitejša za vaš primer poslovne uporabe. Da bi razumeli, si vizualizirajmo pomnilniški odtis grafičnih procesorjev, ko se model nalaga in ko se zaporedne zahteve obdelujejo v tekočem paketu. Za to objavo predpostavimo, da nalagamo model Falcon-40B na eno od instanc tipa G5, ki so nameščene z grafičnimi procesorji NVIDIA A10G, vsak s 24 GB pomnilnika. Upoštevajte, da podobno razumevanje velja za vrste instanc p3, p4 in p5, ki so priložene serijam GPU V100, A100 in H100.

Sledi pregled pridobivanja približne vrednosti celotnega pomnilnika, potrebnega za delovanje Falcon-40B:

• Velikost modela = Število parametrov modela (40 milijard za Falcon-40B) x 4 bajtov na parameter (za FP32) = 160 GB
• Približen skupni pomnilnik, potreben za nalaganje Falcon-40B za sklepanje = Velikost modela (=160 GB) + KV Cache (Attention Cache) (=*20 GB) + Dodatna poraba pomnilnika zaradi ML Frameworks (približno 2 GB)

Za Falcon-40B, če stisnemo model s kvantizacijo modela na podatkovni tip bfloat16 (2 bajta), velikost modela postane približno 80 GB. Kot lahko vidite, je to še vedno večje od pomnilnika, ki ga podpira ena pospeševalna naprava, zato moramo sprejeti tehniko particioniranja modela (sharding) s posebnim tenzorski paralelizem (TP) pristopite in razdelite model na več pospeševalnih naprav. Predpostavimo, da smo izbrali g5.24xlarge, ki ima 4 naprave A10G GPU. Če DJLServing (serving.properties) konfiguriramo z naslednjim, lahko pričakujemo, da bo 80 GB uteži modela enakomerno razdeljenih med vse 4 GPE:

z tensor_parallel_degree nastavljen na 4, je približno 20 GB od 24 GB pomnilnika GPE (približno 84 %) že uporabljenih, še preden je bila obdelana ena zahteva. Preostalih 16 % GPE-ja bo uporabljenih za predpomnilnik KV za dohodne zahteve. Možno je, da je za vaš poslovni scenarij in njegove zahteve glede zakasnitve in prepustnosti 2–3 GB preostalega pomnilnika več kot dovolj. Če ne, lahko povečate velikost primerka na g5.48xlarge, ki ima 8 grafičnih procesorjev in uporablja tensor_parallel_degree, nastavljeno na 8. V takem primeru je za uteži modela uporabljenih le približno 10 GB od razpoložljivih 24 GB pomnilnika vsakega GPE-ja in mi imajo približno 60 % preostale GPU za aktivacije in predpomnilnik KV. Intuitivno lahko vidimo, da nam ta konfiguracija lahko omogoči večjo prepustnost. Poleg tega, ker imamo zdaj večji medpomnilnik, lahko povečamo max_rolling_batch_prefill_tokens in max_rolling_batch_size parametrov za nadaljnjo optimizacijo pretoka. Ta dva parametra bosta skupaj nadzorovala vnaprejšnje dodelitve aktivacijskih predizpolnjevanj in predpomnilnika KV za model. Večje število za ta dva parametra bo povezano z večjo prepustnostjo, ob predpostavki, da imate dovolj medpomnilnika za predpomnilnik KV v pomnilniku GPE.

Neprekinjeno pakiranje s PagedAttention

PagedAttention je nov optimizacijski algoritem, ki ga je razvila UC Berkeley in izboljšuje proces neprekinjenega paketnega zbiranja tako, da omogoča, da predpomnilnik pozornosti (KV predpomnilnik) ni zvezen z dodeljevanjem pomnilnika na straneh ali blokih fiksne velikosti. To se zgleduje po konceptih navideznega pomnilnika in ostranjenja, ki jih uporabljajo operacijski sistemi.

Glede na vLLM papir, je predpomnilnik pozornosti vsakega zaporedja žetonov razdeljen na bloke in preslikan v fizične bloke prek tabele blokov. Med izračunom pozornosti lahko jedro PagedAttention uporabi tabelo blokov za učinkovito pridobivanje blokov iz fizičnega pomnilnika. Posledica tega je občutno zmanjšanje izgube pomnilnika in omogoča večjo velikost paketa, povečano uporabo GPE in večjo prepustnost.

Primerjava zmogljivosti

Za zagotovitev učinkovitega obremenitvenega testiranja vaše konfiguracije uvedbe je priporočljivo, da začnete z upoštevanjem poslovnega scenarija in jasno opredelitvijo značilnosti vhoda in izhoda za aplikacijo, ki temelji na LLM. Na primer, če delate na primeru uporabe povzemanja v klicnem centru, bi lahko bil vhod sestavljen iz večjega besedila, kot je prepis klepeta s 500 žetoni med agentom za pomoč strankam in stranko, vendar bi bil izhod lahko relativno manjši, okoli 100 žetonov, ki predstavljajo povzetek prepisa. Po drugi strani pa, če delate na scenariju generiranja kode, je lahko vnos kratek kot 15 žetonov, na primer »napišite učinkovito implementacijo v Pythonu za opisovanje vseh virov EC2, vključno s paginacijo«, vendar je lahko izhod veliko večji, doseže 500 žetonov. Pomembno je tudi razmisliti, ali je doseganje nižje zakasnitve ali maksimiranje prepustnosti glavna prednostna naloga za vaš specifični scenarij.

Ko pridobite celovito razumevanje poslovnega scenarija, lahko analizirate in določite optimalno konfiguracijo za vaše gostiteljsko okolje. V tem kontekstu gostiteljsko okolje zajema različne ključne elemente, vključno z vrsto primerka in drugimi konfiguracijskimi parametri, kot so tenzorska_vzporedna_stopnja, max_rolling_batch_size, max_rolling_batch_prefill_tokens, in več. Naš cilj je identificirati najučinkovitejšo nastavitev, ki podpira naše zahteve glede odzivnega časa, prepustnosti in kakovosti izhodnih modelov.

V naši analizi smo primerjali uspešnost, da bi ponazorili prednosti neprekinjenega šarženja pred tradicionalnim dinamičnim šarženjem. Uporabili smo konfiguracije, ki so podrobno opisane v naslednji tabeli v serving.properties za dinamično in iterativno pakiranje z uporabo vsebnika LMI na SageMaker.

Dinamično šaržiranje	Neprekinjeno doziranje	Neprekinjeno pakiranje s PagedAttention
motor=Python option.model_id=tiiuae/falcon-40b option.tensor_parallel_degree=8 option.dtype=fp16 velikost_serije=4 max_batch_delay=100 option.trust_remote_code = res	motor = MPI option.model_id = {{s3_url}} option.trust_remote_code = res option.tensor_parallel_degree = 8 option.max_rolling_batch_size = 32 option.rolling_batch = avto option.dtype = fp16 option.max_rolling_batch_prefill_tokens = 1024 option.paged_attention = False	motor = MPI option.model_id = {{s3_url}} option.trust_remote_code = res option.tensor_parallel_degree = 8 option.max_rolling_batch_size = 32 option.rolling_batch = avto option.dtype = fp16 option.max_rolling_batch_prefill_tokens = 1024 option.paged_attention = True

Obe konfiguraciji sta bili primerjani za Falcon-40B s podatkovnim tipom FP16, razporejenim na ml.g5.48xlarge v nekaj različnih scenarijih, ki predstavljajo aplikacije iz resničnega sveta:

• Majhno število vhodnih žetonov z velikim številom ustvarjenih žetonov – V tem scenariju je bilo število vhodnih žetonov določeno na 32 in ustvarjenih je bilo 128 novih žetonov

Strategija šarženja	Prepustnost (žetoni/s)	Zakasnitev p90 (sekund)
Dinamično šaržiranje	5.53	58.34
Neprekinjeno doziranje	56.04	4.74
Neprekinjeno pakiranje s PagedAttention	59.18	4.76

• Velik vnos z majhnim številom ustvarjenih žetonov – Tukaj popravimo število vhodnih žetonov na 256 in pozovemo LLM, da povzame vnos na 32 žetonov

Strategija šarženja	Prepustnost (žetoni/s)	Zakasnitev p90 (sekund)
Dinamično šaržiranje	19.96	59.31
Neprekinjeno doziranje	46.69	3.88
Neprekinjeno pakiranje s PagedAttention	44.75	2.67

Vidimo lahko, da neprekinjeno pakiranje s PagedAttention zagotavlja 10-krat večje izboljšanje prepustnosti v scenariju 1 in 2.3-krat v scenariju 2 v primerjavi z uporabo dinamičnega šarženja na SageMakerju med uporabo vsebnika LMI.

zaključek

V tej objavi smo preučili, kako LLM-ji uporabljajo pomnilnik, in razložili, kako neprekinjeno šarženje izboljša prepustnost z uporabo vsebnika LMI na SageMakerju. S prikazom primerjalnih rezultatov smo prikazali prednosti neprekinjenega doziranja za Falcon-40B z uporabo vsebnika LMI na SageMakerju. Kodo najdete na GitHub repo.

---

O avtorjih

Abhi Shivaditya je višji arhitekt rešitev pri AWS, ki sodeluje s strateškimi globalnimi podjetniškimi organizacijami, da bi olajšal sprejemanje storitev AWS na področjih, kot so umetna inteligenca, porazdeljeno računalništvo, mreženje in shranjevanje. Njegovo strokovno znanje je globoko učenje na področjih obdelave naravnega jezika (NLP) in računalniškega vida. Abhi strankam pomaga pri učinkovitem uvajanju visoko zmogljivih modelov strojnega učenja znotraj ekosistema AWS.

Dhawal Patel je glavni arhitekt strojnega učenja pri AWS. Sodeloval je z organizacijami, od velikih podjetij do srednje velikih zagonskih podjetij, pri problemih, povezanih s porazdeljenim računalništvom in umetno inteligenco. Osredotoča se na poglobljeno učenje, vključno s področja NLP in računalniškega vida. Strankam pomaga doseči visoko zmogljivo sklepanje o modelih na SageMakerju.

Pinak Panigrahi sodeluje s strankami pri izdelavi rešitev, ki temeljijo na strojnem učenju, za reševanje strateških poslovnih problemov na AWS. Ko se ne ukvarja s strojnim učenjem, ga lahko najdemo na pohodu, bere knjigo ali gleda šport.

Abhi Sodhani ima položaj višjega arhitekta rešitev AI/ML pri AWS, kjer je specializiran za ponujanje tehničnega strokovnega znanja in navodil za rešitve Generative AI in ML strankam. Njegov glavni poudarek je pomoč digitalnim domačim podjetjem pri uresničitvi celotnega potenciala tehnologij Generative AI in ML, kar jim omogoča učinkovito doseganje poslovnih ciljev. Poleg svojih poklicnih prizadevanj Abhi izkazuje močno strast do intelektualnih dejavnosti, kot je branje, pa tudi do dejavnosti, ki spodbujajo fizično in duševno dobro počutje, kot sta joga in meditacija.

Qing Lan je inženir za razvoj programske opreme v AWS. Delal je na več zahtevnih izdelkih v Amazonu, vključno z visoko zmogljivimi rešitvami sklepanja ML in visoko zmogljivim sistemom beleženja. Qingova ekipa je uspešno lansirala prvi model z milijardami parametrov v Amazon Advertising z zelo nizko zahtevano zakasnitvijo. Qing ima poglobljeno znanje o optimizaciji infrastrukture in pospeševanju globokega učenja.

• Distribucija vsebine in PR s pomočjo SEO. Okrepite se še danes.
• PlatoData.Network Vertical Generative Ai. Opolnomočite se. Dostopite tukaj.
• PlatoAiStream. Web3 Intelligence. Razširjeno znanje. Dostopite tukaj.
• PlatoESG. Ogljik, CleanTech, Energija, Okolje, sončna energija, Ravnanje z odpadki. Dostopite tukaj.
• PlatoHealth. Obveščanje o biotehnologiji in kliničnih preskušanjih. Dostopite tukaj.
• vir: https://aws.amazon.com/blogs/machine-learning/improve-performance-of-falcon-models-with-amazon-sagemaker/