Käytettäessä suurta kielimallia (LLM) koneoppimisen (ML) harjoittajat huolehtivat yleensä kahdesta mallin suorituskyvyn mittauksesta: latenssista, joka määritellään yhden tunnuksen luomiseen kuluvan ajan mukaan, ja suorituskyvystä, jonka määrittää luotujen tunnisteiden määrä. sekunnissa. Vaikka yksittäinen pyyntö käyttöön otettuun päätepisteeseen vastaisi suunnilleen mallin latenssin käänteisarvoa, näin ei välttämättä ole, kun päätepisteeseen lähetetään samanaikaisesti useita samanaikaisia ​​pyyntöjä. Mallinkäyttötekniikoista, kuten asiakaspuolen samanaikaisten pyyntöjen jatkuvasta erästä johtuen, latenssilla ja suorituskyvyllä on monimutkainen suhde, joka vaihtelee huomattavasti malliarkkitehtuurin, palvelukokoonpanojen, ilmentymän tyypin laitteiston, samanaikaisten pyyntöjen lukumäärän ja syötteiden hyötykuormien vaihteluiden mukaan. syöttö- ja lähtömerkkien lukumääränä.

Tämä viesti tutkii näitä suhteita Amazon SageMaker JumpStartissa saatavilla olevien LLM-yritysten kattavan vertailun avulla, mukaan lukien Llama 2, Falcon ja Mistral. SageMaker JumpStartin avulla ML-harjoittajat voivat valita laajasta valikoimasta julkisesti saatavilla olevia perustusmalleja käytettäväksi omistetuissa Amazon Sage Maker esiintymiä verkosta eristetyssä ympäristössä. Tarjoamme teoreettisia periaatteita siitä, miten kiihdytinmääritykset vaikuttavat LLM-benchmarkingiin. Osoitamme myös useiden esiintymien käyttöönoton vaikutuksen yhden päätepisteen taakse. Lopuksi tarjoamme käytännön suosituksia SageMaker JumpStart -käyttöönottoprosessin räätälöimiseksi vastaamaan vaatimuksiasi viiveen, suorituskyvyn, kustannusten ja käytettävissä olevien ilmentymien tyyppien rajoitusten suhteen. Kaikki benchmarking-tulokset sekä suositukset perustuvat monipuoliseen muistikirja joita voit mukauttaa käyttötilanteeseesi.

Käytetty päätepisteen vertailu

Seuraavassa kuvassa näkyvät pienimmät viiveet (vasemmalla) ja suurimmat suorituskyvyn (oikealla) arvot käyttöönottokokoonpanoissa useissa eri malli- ja ilmentymätyypeissä. Tärkeää on, että jokainen näistä mallin käyttöönotoista käyttää SageMaker JumpStartin toimittamia oletuskokoonpanoja, joissa on haluttu mallin tunnus ja ilmentymän tyyppi käyttöönottoa varten.

Nämä latenssi- ja suoritustehoarvot vastaavat hyötykuormia, joissa on 256 syöttötunnusta ja 256 lähtötunnusta. Pienin viivemääritys rajoittaa mallin, joka palvelee yhtä samanaikaista pyyntöä, ja suurin suorituskyvyn määritys maksimoi samanaikaisten pyyntöjen mahdollisen määrän. Kuten voimme nähdä vertailussamme, samanaikaisten pyyntöjen lisääntyminen monotonisesti lisää suorituskykyä ja pienenee suurten samanaikaisten pyyntöjen parannusta. Lisäksi mallit ovat täysin sirpaloituja tuettuun ilmentymään. Esimerkiksi koska ml.g5.48xlarge -esiintymässä on 8 grafiikkasuoritinta, kaikki tätä ilmentymää käyttävät SageMaker JumpStart -mallit jaetaan tensorin rinnakkaisuuden avulla kaikissa kahdeksassa käytettävissä olevassa kiihdytinässä.

Voimme huomata muutamia poimintoja tästä luvusta. Ensinnäkin kaikkia malleja ei tueta kaikissa tapauksissa; jotkin pienemmät mallit, kuten Falcon 7B, eivät tue mallien sirpalointia, kun taas suuremmissa malleissa on korkeammat laskentaresurssit. Toiseksi, kun sirpalointi lisääntyy, suorituskyky yleensä paranee, mutta ei välttämättä paranna pienissä malleissa. Tämä johtuu siitä, että pienet mallit, kuten 7B ja 13B, aiheuttavat huomattavia tiedonsiirtokustannuksia, kun niitä jaetaan liian monen kiihdytin välillä. Keskustelemme tästä tarkemmin myöhemmin. Lopuksi ml.p4d.24xlarge-esiintymillä on yleensä huomattavasti parempi suorituskyky, koska A100:n muistin kaistanleveys on parantunut A10G-grafiikkasuorittimiin verrattuna. Kuten kerromme myöhemmin, päätös tietyn ilmentymän tyypin käyttämisestä riippuu käyttöönottovaatimuksistasi, mukaan lukien viiveestä, suorituskyvystä ja kustannusrajoituksista.

Kuinka saat nämä pienimmän latenssin ja suurimman suorituskyvyn määritysarvot? Aloitetaan piirtämällä latenssi vs. suorituskyky Llama 2 7B -päätepisteelle ml.g5.12xlarge-esiintymässä hyötykuormalle, jossa on 256 syöttötunnusta ja 256 lähtötunnusta, kuten seuraavasta käyrästä näkyy. Samanlainen käyrä on olemassa jokaiselle käyttöönotetulle LLM-päätepisteelle.

Samanaikaisuuden kasvaessa myös suorituskyky ja latenssi kasvavat monotonisesti. Siksi alin latenssipiste esiintyy samanaikaisen pyynnön arvolla 1, ja voit kustannustehokkaasti lisätä järjestelmän suorituskykyä lisäämällä samanaikaisia ​​pyyntöjä. Tässä käyrässä on selvä "polvi", jossa on ilmeistä, että lisäyhtenäisyyteen liittyvät suorituskyvyn lisäykset eivät paina siihen liittyvää latenssin kasvua. Tämän polven tarkka sijainti on käyttötapauskohtainen; Jotkut harjoittajat voivat määrittää polven kohdassa, jossa ennalta määritetty latenssivaatimus ylittyy (esimerkiksi 100 ms/token), kun taas toiset voivat käyttää kuormitustestivertailuja ja jonoteoriamenetelmiä, kuten puolilatenssisääntöä, ja toiset voivat käyttää teoreettiset kiihdytinvaatimukset.

Huomaa myös, että samanaikaisten pyyntöjen enimmäismäärä on rajoitettu. Edellisessä kuvassa linjan jäljitys päättyy 192 samanaikaiseen pyyntöön. Tämän rajoituksen lähde on SageMakerin kutsun aikakatkaisuraja, jossa SageMaker aikakatkaisee kutsuvastauksen 60 sekunnin kuluttua. Tämä asetus on tilikohtainen, eikä sitä voi määrittää yksittäiselle päätepisteelle. LLM:illä suuren määrän tulostokenien luominen voi kestää sekunteja tai jopa minuutteja. Siksi suuret tulo- tai lähtöhyötykuormat voivat aiheuttaa kutsupyyntöjen epäonnistumisen. Lisäksi, jos samanaikaisten pyyntöjen määrä on erittäin suuri, monien pyyntöjen jonotusajat ovat pitkiä, mikä lisää tätä 60 sekunnin aikarajaa. Tässä tutkimuksessa käytämme aikakatkaisurajaa mallin käyttöönoton suurimman mahdollisen suorituskyvyn määrittämiseen. Tärkeää on, että vaikka SageMaker-päätepiste voi käsitellä suuren määrän samanaikaisia ​​pyyntöjä ilman, että havaitset kutsuvastauksen aikakatkaisua, saatat haluta määrittää samanaikaisten pyyntöjen enimmäismäärän polven suhteen latenssi-läpäisytehokäyrässä. Tämä on todennäköisesti kohta, jolloin alat harkita vaakasuuntaista skaalausta, jossa yksi päätepiste varaa useita ilmentymiä mallireplikoilla ja tasapainottaa saapuvat pyynnöt replikoiden välillä samanaikaisempien pyyntöjen tukemiseksi.

Kun tämä viedään askeleen pidemmälle, seuraava taulukko sisältää vertailutuloksia Llama 2 7B -mallin eri kokoonpanoille, mukaan lukien erilaiset tulo- ja lähtötunnisteet, ilmentymätyypit ja samanaikaisten pyyntöjen lukumäärä. Huomaa, että edellinen kuva piirtää vain yhden rivin tästä taulukosta.

Näissä tiedoissa havaitsemme joitain lisämalleja. Kun kontekstin kokoa kasvatetaan, latenssi kasvaa ja suorituskyky pienenee. Esimerkiksi tiedostossa ml.g5.2xlarge, kun samanaikaisuus on 1, läpijuoksu on 30 merkkiä/s, kun merkkien kokonaismäärä on 512, vs. 20 merkkiä/s, jos merkkien kokonaismäärä on 4,096 2. Tämä johtuu siitä, että suuremman syötteen käsittely vie enemmän aikaa. Näemme myös, että grafiikkasuorittimen kapasiteetin lisääminen ja jakaminen vaikuttavat maksimaaliseen suorituskykyyn ja tuettujen samanaikaisten pyyntöjen enimmäismäärään. Taulukko osoittaa, että Llama 7 5.12B:llä on huomattavasti erilaiset maksimiläpäisyarvot eri ilmentymätyypeille, ja nämä maksimiläpäisyarvot esiintyvät samanaikaisten pyyntöjen eri arvoilla. Nämä ominaisuudet saisivat ML-ammattilaisen perustelemaan yhden ilmentymän kustannukset toiseen verrattuna. Esimerkiksi alhaisen latenssivaatimuksen vuoksi lääkäri voi valita ml.g4xlarge-esiintymän (10 A5.2G GPU:ta) ml.g1xlarge-esiintymän (10 A4G GPU) sijaan. Korkean suorituskyvyn vaatimuksen vuoksi ml.p24d.8xlarge-esiintymän (100 A7 GPU:ta) käyttö täydellä shardingilla olisi perusteltua vain suuren samanaikaisuuden yhteydessä. Huomaa kuitenkin, että sen sijaan on usein hyödyllistä ladata useita 4B-mallin päättelykomponentteja yhteen ml.p24d.XNUMXxlarge-esiintymään; tällaista usean mallin tukea käsitellään myöhemmin tässä viestissä.

Edelliset havainnot tehtiin Llama 2 7B -mallille. Samanlaiset mallit ovat kuitenkin päteviä myös muille malleille. Ensisijainen huomio on, että latenssi- ja suoritusteholuvut riippuvat hyötykuormasta, ilmentymän tyypistä ja samanaikaisten pyyntöjen määrästä, joten sinun on löydettävä ihanteellinen kokoonpano sovelluksellesi. Luodaksesi edelliset numerot käyttötapaukseesi, voit suorittaa linkitetyn muistikirja, jossa voit määrittää tämän kuormitustestianalyysin mallillesi, ilmentymätyypille ja hyötykuormallesi.

Kiihdyttimen teknisten tietojen järkeä

Sopivan laitteiston valinta LLM-päätelmää varten riippuu suuresti erityisistä käyttötapauksista, käyttökokemuksen tavoitteista ja valitusta LLM:stä. Tässä osiossa yritetään luoda käsitys polvesta latenssi-läpäisykykykäyrässä korkean tason periaatteiden mukaisesti, jotka perustuvat kiihdytinspesifikaatioihin. Nämä periaatteet eivät yksinään riitä päätöksentekoon: tarvitaan todellisia vertailuarvoja. Termi laite käytetään tässä kattamaan kaikki ML-laitteistokiihdyttimet. Väitämme, että latenssi-läpäisykykykäyrän polvi perustuu jompaankumpaan kahdesta tekijästä:

• Kiihdytin on käyttänyt muistia KV-matriisien välimuistiin, joten seuraavat pyynnöt ovat jonossa
• Kiihdyttimessä on vielä ylimääräistä muistia KV-välimuistia varten, mutta se käyttää riittävän suurta eräkokoa, jotta käsittelyaika määräytyy laskennan viiveen sijaan muistin kaistanleveyden perusteella.

Tyypillisesti pidämme parempana toisen tekijän rajoittamista, koska tämä tarkoittaa, että kiihdytinresurssit ovat kyllästyneet. Periaatteessa maksimoit maksamasi resurssit. Tutkitaanpa tätä väitettä tarkemmin.

KV-välimuisti ja laitemuisti

Tavalliset muuntajan huomiomekanismit laskevat huomion jokaiselle uudelle tunnukselle kaikkia aiempia tokeneita vastaan. Useimmat nykyaikaiset ML-palvelimet tallentavat huomioavaimet ja arvot laitteen muistiin (DRAM) välttääkseen uudelleenlaskennan jokaisessa vaiheessa. Tätä kutsutaan nimellä KV-välimuisti, ja se kasvaa erän koon ja sarjan pituuden mukaan. Se määrittää, kuinka monta käyttäjän pyyntöä voidaan palvella rinnakkain, ja määrittää latenssi-läpäisytehokäyrän polven, jos aiemmin mainitun toisen skenaarion laskentaan sidottu järjestelmä ei vielä täyty, kun otetaan huomioon käytettävissä oleva DRAM. Seuraava kaava on karkea arvio KV-välimuistin enimmäiskoosta.

Tässä kaavassa B on eräkoko ja N on kiihdyttimien lukumäärä. Esimerkiksi Llama 2 7B -malli FP16:ssa (2 tavua/parametri), jota käytetään A10G-grafiikkasuorittimessa (24 Gt DRAM), kuluttaa noin 14 Gt, joten KV-välimuistille jää 10 Gt. Kun mallin koko kontekstin pituus (N = 4096) ja loput parametrit (n_layers=32, n_kv_attention_heads=32 ja d_attention_head=128) kytketään, tämä lauseke osoittaa, että DRAM-rajoitusten vuoksi rajoitamme palvelemaan neljän käyttäjän eräkokoa rinnakkain. . Jos tarkastelet edellisen taulukon vastaavia vertailuarvoja, tämä on hyvä arvio havaitulle polvelle tässä latenssi-läpäisykykykäyrässä. Menetelmät, kuten ryhmäkyselyn huomio (GQA) voi pienentää KV-välimuistin kokoa, GQA:n tapauksessa samalla kertoimella se vähentää KV-päiden määrää.

Aritmeettinen intensiteetti ja laitteen muistin kaistanleveys

ML-kiihdyttimien laskentatehon kasvu on ylittänyt niiden muistin kaistanleveyden, mikä tarkoittaa, että ne voivat suorittaa paljon enemmän laskutoimituksia jokaiselle datatavulle siinä ajassa, joka kuluu kyseisen tavun käyttämiseen.

- aritmeettinen voimakkuus, tai laskentatoimintojen suhde muistin käyttöihin, määrittää, rajoittaako sitä muistin kaistanleveys tai valitun laitteiston laskentakapasiteetti. Esimerkiksi A10G GPU (g5-instanssityyppiperhe), jossa on 70 TFLOPS FP16 ja 600 Gt/s kaistanleveys, voi laskea noin 116 operaatiota/tavu. A100 GPU (p4d-ilmentymätyyppiperhe) voi laskea noin 208 ops/tavu. Jos muuntajamallin aritmeettinen intensiteetti on tämän arvon alapuolella, se on muistiin sidottu; jos se on edellä, se on laskennallisesti sidottu. Llama 2 7B:n huomiomekanismi vaatii 62 toimintoa/tavu eräkoolla 1 (selitys, katso Opas LLM-johtopäätökseen ja suorituskykyyn), mikä tarkoittaa, että se on sidottu muistiin. Kun huomiomekanismi on sidottu muistiin, kalliit FLOPSit jäävät käyttämättä.

On kaksi tapaa hyödyntää kiihdytintä paremmin ja lisätä aritmeettista intensiteettiä: vähentää operaatioon tarvittavia muistin käyttöjä (tämä on mitä FlashAttention keskittyy) tai suurenna eräkokoa. Emme kuitenkaan ehkä pysty kasvattamaan eräkokoamme tarpeeksi saavuttaaksemme laskentaan sidotun järjestelmän, jos DRAM-muistimme on liian pieni vastaavan KV-välimuistin säilyttämiseen. Karkea likiarvo kriittisestä eräkoon B*, joka erottaa laskennalliset ja muistiin sidotut järjestelmät standardi GPT-dekooderin päättelyssä, kuvataan seuraavalla lausekkeella, jossa A_mb on kiihdytinmuistin kaistanleveys, A_f on kiihdytin FLOPS ja N on luku. kiihdyttimistä. Tämä kriittinen eräkoko voidaan johtaa etsimällä, missä muistin käyttöaika on yhtä suuri kuin laskentaaika. Viitata tämä blogikirja ymmärtääksesi yhtälöä 2 ja sen oletuksia yksityiskohtaisemmin.

Tämä on sama operaatio/tavu-suhde, jonka laskemme aiemmin A10G:lle, joten tämän GPU:n kriittinen eräkoko on 116. Yksi tapa lähestyä tätä teoreettista, kriittistä eräkokoa on lisätä mallin jakamista ja jakaa välimuisti useammille N kiihdyttimille. Tämä lisää tehokkaasti KV-välimuistin kapasiteettia sekä muistiin sidottua eräkokoa.

Toinen mallin jakamisen etu on malliparametrien ja tietojen lataustyön jakaminen N kiihdyttimien kesken. Tämän tyyppinen sirpalointi on eräänlainen mallin rinnakkaisuus, jota kutsutaan myös nimellä tensorin rinnakkaisuus. Naiivisti, muistin kaistanleveys ja laskentateho on N kertaa yhteensä. Olettaen, ettei mitään ylimääräisiä kuluja (viestintä, ohjelmisto ja niin edelleen) ole, tämä vähentäisi dekoodausviivettä merkkiä kohti N:llä, jos olemme muistiin sidottu, koska tunnuksen dekoodausviive tässä järjestelmässä on sidottu mallin lataamiseen kuluvaan aikaan. painot ja kätkö. Todellisessa elämässä sirpalointiasteen lisääminen johtaa kuitenkin lisääntyneeseen kommunikaatioon laitteiden välillä, jotta väliaktivoinnit voidaan jakaa jokaisessa mallikerroksessa. Tätä tiedonsiirtonopeutta rajoittaa laitteen yhteenliittämisen kaistanleveys. Sen vaikutusta on vaikea arvioida tarkasti (katso lisätietoja Malli rinnakkaisuus), mutta tämä voi lopulta lakata tuomasta etuja tai heikentää suorituskykyä – tämä pätee erityisesti pienempiin malleihin, koska pienemmät tiedonsiirrot johtavat alhaisempaan siirtonopeuteen.

ML-kiihdyttimien vertaamiseksi niiden teknisten tietojen perusteella suosittelemme seuraavaa. Ensin lasketaan likimääräinen kriittinen eräkoko kullekin kiihdytintyypille toisen yhtälön mukaisesti ja KV-välimuistin koko kriittiselle eräkoolle ensimmäisen yhtälön mukaisesti. Voit sitten käyttää kiihdytin käytettävissä olevaa DRAM-muistia laskeaksesi vähimmäismäärän kiihdyttimiä, jotka tarvitaan KV-välimuistiin ja malliparametreihin. Jos päätät useiden kiihdyttimien välillä, priorisoi kiihdykkeet alimman hinnan mukaan muistin kaistanleveyden gigatavua sekunnissa. Vertaile lopuksi näitä kokoonpanoja ja varmista, mikä on paras hinta/tunnus halutun viiveen ylärajalle.

Valitse päätepisteen käyttöönottokokoonpano

Monet SageMaker JumpStartin jakamat LLM:t käyttävät teksti-sukupolvi-päätelmä (TGI) SageMaker-säiliö mallin tarjoilua varten. Seuraavassa taulukossa käsitellään useita mallin käyttöparametreja säätämällä joko viive-läpäisykykykäyrään vaikuttavaa mallin käyttöä tai päätepisteen suojaamista pyynnöiltä, ​​jotka ylikuormittaisivat päätepistettä. Nämä ovat ensisijaiset parametrit, joita voit käyttää päätepisteen käyttöönoton määrittämiseen käyttötapauksesi mukaan. Ellei toisin mainita, käytämme oletusarvoa tekstin luomisen hyötykuorman parametrit ja TGI-ympäristömuuttujat.

TGI-palvelin käyttää jatkuvaa eräajoa, joka dynaamisesti yhdistää samanaikaiset pyynnöt jakaakseen yhden mallin päättelyn eteenpäin. Eteenpäinkulkuja on kahta tyyppiä: esitäyttö ja dekoodaus. Jokaisen uuden pyynnön on suoritettava yksi esitäytön välitys KV-välimuistin täyttämiseksi syöttösekvenssitokeneille. Sen jälkeen, kun KV-välimuisti on täytetty, dekoodauksen eteenpäinkulku suorittaa yhden seuraavan merkin ennusteen kaikille eräpyynnöille, joka toistetaan iteratiivisesti tulossekvenssin tuottamiseksi. Kun uusia pyyntöjä lähetetään palvelimelle, seuraavan dekoodausvaiheen on odotettava, jotta esitäyttövaihe voidaan suorittaa uusille pyynnöille. Tämän on tapahduttava ennen kuin nämä uudet pyynnöt sisällytetään seuraaviin jatkuvasti eriteltyihin dekoodausvaiheisiin. Laitteiston rajoituksista johtuen dekoodaukseen käytetty jatkuva erä ei välttämättä sisällä kaikkia pyyntöjä. Tässä vaiheessa pyynnöt siirtyvät prosessointijonoon ja päättelyviive alkaa kasvaa merkittävästi vain pienellä suorituskyvyn vahvistuksella.

On mahdollista jakaa LLM-viiveen vertailuanalyysit esitäytön latenssiin, dekoodauksen latenssiin ja jonoviiveeseen. Kunkin näistä komponenteista kuluma aika on luonteeltaan pohjimmiltaan erilainen: esitäyttö on kertaluonteinen laskenta, dekoodaus tapahtuu kerran jokaiselle lähtösekvenssissä olevalle tokenille ja jonotukseen liittyy palvelimen eräprosesseja. Kun useita samanaikaisia ​​pyyntöjä käsitellään, on vaikeaa erottaa viiveet kustakin näistä komponenteista, koska minkä tahansa asiakaspyynnön kokemaan latenssiin liittyy jonoviiveitä, jotka johtuvat tarpeesta esitäytä uusia samanaikaisia ​​pyyntöjä sekä sisällyttämisen aiheuttamia jonoviiveitä. pyynnöstä erädekoodausprosesseissa. Tästä syystä tämä viesti keskittyy päästä päähän -käsittelyn latenssiin. Latenssi-läpivirtauskäyrän polvi tapahtuu kyllästymispisteessä, jossa jonolatenssit alkavat kasvaa merkittävästi. Tämä ilmiö esiintyy kaikissa mallien päättelypalvelimissa, ja sitä ohjaavat kiihdytin tekniset tiedot.

Yleisiä vaatimuksia käyttöönoton aikana ovat vaaditun vähimmäissuorituskyvyn, suurimman sallitun latenssin, enimmäishinnan tuntikohtaisen ja maksimikustannusten täyttäminen miljoonan tunnuksen luomiseen. Sinun tulee asettaa nämä vaatimukset hyötykuormille, jotka edustavat loppukäyttäjien pyyntöjä. Nämä vaatimukset täyttävässä suunnittelussa tulee ottaa huomioon monia tekijöitä, mukaan lukien tietty malliarkkitehtuuri, mallin koko, ilmentymien tyypit ja ilmentymien määrä (vaakasuuntainen skaalaus). Seuraavissa osissa keskitymme päätepisteiden käyttöönottoon viiveen minimoimiseksi, suorituskyvyn maksimoimiseksi ja kustannusten minimoimiseksi. Tämä analyysi ottaa huomioon yhteensä 1 merkkiä ja 512 tulostetunnusta.

Minimoi latenssi

Latenssi on tärkeä vaatimus monissa reaaliaikaisissa käyttötapauksissa. Seuraavassa taulukossa tarkastellaan kunkin mallin ja kunkin ilmentymän tyypin vähimmäisviivettä. Voit saavuttaa vähimmäisviiveen asettamalla MAX_CONCURRENT_REQUESTS = 1.

Mallin vähimmäisviiveen saavuttamiseksi voit käyttää seuraavaa koodia samalla, kun korvaat haluamasi mallitunnuksen ja ilmentymän tyypin:

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

Huomaa, että latenssinumerot vaihtelevat tulo- ja lähtötunnisteiden lukumäärän mukaan. Käyttöönottoprosessi pysyy kuitenkin samana ympäristömuuttujia lukuun ottamatta MAX_INPUT_TOKENS ja MAX_TOTAL_TOKENS. Tässä nämä ympäristömuuttujat on asetettu takaamaan päätepisteen latenssivaatimukset, koska suuremmat syöttösekvenssit voivat rikkoa latenssivaatimusta. Huomaa, että SageMaker JumpStart tarjoaa jo muita optimaalisia ympäristömuuttujia valittaessa ilmentymän tyyppiä; esimerkiksi käyttämällä ml.g5.12xlarge asetetaan SM_NUM_GPUS 4:ään malliympäristössä.

Maksimoi suorituskyky

Tässä osiossa maksimoimme luotujen merkkien määrän sekunnissa. Tämä saavutetaan tyypillisesti mallin ja ilmentymän tyypin enimmäiskelvollisilla samanaikaisilla pyynnöillä. Seuraavassa taulukossa raportoimme suorituskyvyn, joka saavutettiin suurimmalla samanaikaisen pyynnön arvolla, ennen kuin havaitaan SageMaker-kutsujen aikakatkaisu mille tahansa pyynnölle.

Voit saavuttaa mallin suurimman suorituskyvyn käyttämällä seuraavaa koodia:

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

Huomaa, että samanaikaisten pyyntöjen enimmäismäärä riippuu mallin tyypistä, ilmentymän tyypistä, syöttötunnisteiden enimmäismäärästä ja lähtötunnisteiden enimmäismäärästä. Siksi sinun tulee asettaa nämä parametrit ennen asetusta MAX_CONCURRENT_REQUESTS.

Huomaa myös, että viiveen minimoimisesta kiinnostunut käyttäjä on usein ristiriidassa suorituskyvyn maksimoimisesta kiinnostuneen käyttäjän kanssa. Edellinen on kiinnostunut reaaliaikaisista vastauksista, kun taas jälkimmäinen on kiinnostunut eräkäsittelystä siten, että päätepistejono on aina kyllästetty, mikä minimoi käsittelyn seisokit. Käyttäjät, jotka haluavat maksimoida läpäisykyvyn latenssivaatimusten perusteella, ovat usein kiinnostuneita toimimaan polven kohdalla latenssi-läpäisytehokäyrässä.

Minimoi kustannukset

Ensimmäinen vaihtoehto kustannusten minimoimiseksi sisältää tuntikustannusten minimoimisen. Tämän avulla voit ottaa käyttöön valitun mallin SageMaker-esiintymässä alhaisin tuntikustannuksin. Katso SageMaker-esiintymien reaaliaikainen hinnoittelu kohdasta Amazon SageMaker -hinnoittelu. Yleensä SageMaker JumpStart LLM:iden oletusilmentymätyyppi on halvin käyttöönottovaihtoehto.

Toinen vaihtoehto kustannusten minimoimiseksi sisältää 1 miljoonan merkin luomiskustannusten minimoimisen. Tämä on yksinkertainen muunnos taulukosta, josta keskustelimme aiemmin suorituskyvyn maksimoimiseksi, jossa voit ensin laskea tunnin, joka kuluu miljoonan tunnuksen luomiseen (1e1 / suorituskyky / 6). Voit sitten kertoa tämän ajan luodaksesi miljoona merkkiä määritetyn SageMaker-esiintymän tuntihinnalla.

Huomaa, että esiintymät, joiden tuntikohtainen hinta on alhaisin, eivät ole samoja kuin tapaukset, joiden kustannukset ovat alhaisimmat luoda miljoona tokenia. Jos esimerkiksi kutsupyynnöt ovat satunnaisia, alhaisimman tuntihinnan omaava ilmentymä saattaa olla optimaalinen, kun taas kuritusskenaarioissa alhaisin kustannus miljoonan tunnuksen luomiseksi saattaa olla sopivampi.

Tensorin rinnakkainen vs. monen mallin kompromissi

Kaikissa aiemmissa analyyseissä harkitsimme yhden mallireplikan käyttöönottoa, jonka tensorin rinnakkaisaste on yhtä suuri kuin käyttöönottoinstanssityypin GPU:iden lukumäärä. Tämä on oletusarvoinen SageMaker JumpStart -käyttäytyminen. Kuten aiemmin todettiin, mallin jakaminen voi kuitenkin parantaa mallin latenssia ja suorituskykyä vain tiettyyn rajaan asti, jonka ylittyessä laitteiden väliset viestintävaatimukset hallitsevat laskenta-aikaa. Tämä tarkoittaa, että on usein hyödyllistä ottaa käyttöön useita malleja, joilla on pienempi tensorin rinnakkaisaste, yhteen esiintymään sen sijaan, että yksi malli, jolla on korkeampi tensorin rinnakkaisaste, ottaa käyttöön.

Tässä otamme käyttöön Llama 2 7B- ja 13B -päätepisteitä ml.p4d.24xlarge-esiintymissä, joiden tensorisuuntaiset (TP) asteet ovat 1, 2, 4 ja 8. Mallin toiminnan selkeyden vuoksi jokainen näistä päätepisteistä lataa vain yhden mallin.

Aiemmat analyysimme osoittivat jo merkittäviä suorituskykyetuja ml.p4d.24xlarge-esiintymissä, mikä usein tarkoittaa parempaa suorituskykyä kustannusten kannalta miljoonan tunnuksen luomiseksi g1-ilmentymäperheeseen verrattuna korkean samanaikaisen pyynnön kuormitusolosuhteissa. Tämä analyysi osoittaa selvästi, että sinun tulee harkita mallin jakamisen ja mallin replikoinnin välistä kompromissia yhdessä esiintymässä. toisin sanoen täysin sirpaloitu malli ei tyypillisesti ole paras käyttötarkoitus ml.p5d.4xlarge-laskentaresursseille 24B- ja 7B-malliperheille. Itse asiassa 13B-malliperheessä saat parhaan suorituskyvyn yksittäiselle mallireplikalle, jonka tensorin rinnakkaisaste on 7 4:n sijaan.

Tästä voit ekstrapoloida, että 7B-mallin suurin suorituskyvyn konfiguraatio sisältää tensorin rinnakkaisasteen 1 kahdeksalla mallikopiolla, ja 13B-mallin suurin suorituskyvyn konfiguraatio on todennäköisesti tensorin rinnakkaisaste 2 neljällä mallikopiolla. Lisätietoja tämän suorittamisesta on kohdassa Vähennä mallin käyttöönottokustannuksia keskimäärin 50 % käyttämällä Amazon SageMakerin uusimpia ominaisuuksia, joka osoittaa päättelykomponenttipohjaisten päätepisteiden käytön. Kuormantasaustekniikoiden, palvelimen reitityksen ja suoritinresurssien jakamisen vuoksi et välttämättä saavuta täydellisiä suorituskyvyn parannuksia, jotka ovat täsmälleen yhtä suuria kuin replikoiden määrä kertaa yhden replikan suoritusteho.

Vaakasuuntainen skaalaus

Kuten aiemmin todettiin, jokaisella päätepisteen käyttöönotolla on rajoitus samanaikaisten pyyntöjen lukumäärälle tulo- ja lähtötunnisteiden määrästä sekä ilmentymän tyypistä riippuen. Jos tämä ei täytä suorituskyvyn tai samanaikaisen pyynnön vaatimuksiasi, voit skaalata useampaa kuin yhtä esiintymää käyttöönotetun päätepisteen takana. SageMaker suorittaa automaattisesti kuormituksen tasauksen kyselyille esiintymien välillä. Esimerkiksi seuraava koodi ottaa käyttöön päätepisteen, jota tukee kolme esiintymää:

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,
)

Seuraava taulukko näyttää suorituskyvyn vahvistuksen kertoimena esiintymien lukumäärällä Llama 2 7B -mallissa.

Erityisesti latenssi-läpäisykykykäyrän polvi siirtyy oikealle, koska korkeammat esiintymämäärät voivat käsitellä suurempia määriä samanaikaisia ​​pyyntöjä usean esiintymän päätepisteessä. Tässä taulukossa samanaikaisen pyynnön arvo koskee koko päätepistettä, ei kunkin yksittäisen esiintymän vastaanottamien samanaikaisten pyyntöjen määrää.

Voit myös käyttää automaattista skaalausta, ominaisuutta, jolla voit seurata työkuormituksiasi ja säätää kapasiteettia dynaamisesti tasaisen ja ennustettavan suorituskyvyn ylläpitämiseksi mahdollisimman alhaisin kustannuksin. Tämä ei kuulu tämän postauksen piiriin. Lisätietoja automaattisesta skaalauksesta on kohdassa Autoscaling johtopäätösten päätepisteiden määrittäminen Amazon SageMakerissa.

Kutsu päätepiste samanaikaisilla pyynnöillä

Oletetaan, että sinulla on suuri joukko kyselyjä, joita haluat käyttää vastausten luomiseen käyttöönotetusta mallista suuren suorituskyvyn olosuhteissa. Esimerkiksi seuraavassa koodilohkossa kokoamme luettelon 1,000 100 hyötykuormasta, ja jokainen hyötykuorma pyytää 100,000 tokenin luomista. Kaiken kaikkiaan pyydämme XNUMX XNUMX tokenin luomista.

payload = { "inputs": "I believe the meaning of life is to ", "parameters": {"max_new_tokens": 100, "details": True},
}
total_requests = 1000
payloads = [payload,] * total_requests

Kun lähetät suuren määrän pyyntöjä SageMaker runtime API:lle, saatat kohdata kuristusvirheitä. Voit lieventää tätä luomalla mukautetun SageMaker-ajonaikaisen asiakasohjelman, joka lisää uudelleenyritysten määrää. Voit antaa tuloksena olevan SageMaker-istuntoobjektin jommallekummalle JumpStartModel rakentaja tai sagemaker.predictor.retrieve_default jos haluat liittää uuden ennustajan jo käyttöön otettuun päätepisteeseen. Seuraavassa koodissa käytämme tätä istuntoobjektia, kun otamme käyttöön Llama 2 -mallin SageMaker JumpStart -oletuskokoonpanoilla:

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

Tällä käyttöönotetulla päätepisteellä on MAX_CONCURRENT_REQUESTS = 128 oletuksena. Seuraavassa lohkossa käytämme samanaikaista futuurikirjastoa toistamaan päätepisteen kutsumista kaikille hyötykuormille, joissa on 128 työntekijäsäiettä. Päätepiste käsittelee enintään 128 samanaikaista pyyntöä, ja aina kun pyyntö palauttaa vastauksen, suorittaja lähettää välittömästi uuden pyynnön päätepisteelle.

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)

Tämä johtaa 100,000 1255 tunnuksen kokonaismäärään luomiseen 5.2 tokenin/sek:n suorituskyvyllä yhdessä ml.g80xlarge-esiintymässä. Tämän käsittely kestää noin XNUMX sekuntia.

Huomaa, että tämä suoritusarvo poikkeaa huomattavasti tämän viestin aiemmissa taulukoissa olevasta Llama 2 7B:n enimmäisläpäisykyvystä ml.g5.2xlargessa (486 merkkiä/s 64 samanaikaisella pyynnöllä). Tämä johtuu siitä, että syöttöhyötykuorma käyttää 8 merkkiä 256 sijasta, lähtömerkkien määrä on 100 256 sijasta ja pienemmät merkkien määrät mahdollistavat 128 samanaikaista pyyntöä. Tämä on viimeinen muistutus siitä, että kaikki latenssi- ja suoritusteholuvut ovat hyötykuormasta riippuvaisia! Hyötykuorman tunnuslukujen muuttaminen vaikuttaa eräprosesseihin mallin käytön aikana, mikä puolestaan ​​vaikuttaa sovelluksesi esitäyttö-, dekoodaus- ja jonoaikoihin.

Yhteenveto

Tässä viestissä esittelimme SageMaker JumpStart LLM:ien, mukaan lukien Llama 2:n, Mistralin ja Falconin, vertailua. Esitimme myös oppaan, jonka avulla voit optimoida päätepisteen käyttöönottokokoonpanon latenssin, suorituskyvyn ja kustannusten. Voit aloittaa suorittamalla liittyvä muistikirja vertailla käyttötapaustasi.

Tietoja Tekijät

 Tohtori Kyle Ulrich on soveltuva tutkija Amazon SageMaker JumpStart -tiimin kanssa. Hänen tutkimusalueitaan ovat skaalautuvat koneoppimisalgoritmit, tietokonenäkö, aikasarjat, Bayesin ei-parametrit ja Gaussin prosessit. Hänen tohtorinsa on Duken yliopistosta ja hän on julkaissut artikkeleita NeurIPS-, Cell- ja Neuron-julkaisuissa.

Dr. Vivek Madan on soveltuva tutkija Amazon SageMaker JumpStart -tiimin kanssa. Hän sai tohtorin tutkinnon Illinoisin yliopistosta Urbana-Champaignissa ja oli tutkijatohtorina Georgia Techissä. Hän on aktiivinen koneoppimisen ja algoritmisuunnittelun tutkija ja julkaissut julkaisuja EMNLP-, ICLR-, COLT-, FOCS- ja SODA-konferensseissa.

Tohtori Ashish Khetan on vanhempi soveltuva tutkija Amazon SageMaker JumpStartissa ja auttaa kehittämään koneoppimisalgoritmeja. Hän sai tohtorin tutkinnon Illinois Urbana-Champaignin yliopistosta. Hän on aktiivinen koneoppimisen ja tilastollisen päättelyn tutkija, ja hän on julkaissut monia artikkeleita NeurIPS-, ICML-, ICLR-, JMLR-, ACL- ja EMNLP-konferensseissa.

João Moura on AWS:n vanhempi AI/ML Specialist Solutions -arkkitehti. João auttaa AWS-asiakkaita – pienistä startupeista suuriin yrityksiin – kouluttamaan ja ottamaan käyttöön suuria malleja tehokkaasti sekä rakentamaan laajemmin ML-alustoja AWS:lle.

• SEO-pohjainen sisällön ja PR-jakelu. Vahvista jo tänään.
• PlatoData.Network Vertical Generatiivinen Ai. Vahvista itseäsi. Pääsy tästä.
• PlatoAiStream. Web3 Intelligence. Tietoa laajennettu. Pääsy tästä.
• PlatoESG. hiili, CleanTech, energia, ympäristö, Aurinko, Jätehuolto. Pääsy tästä.
• PlatonHealth. Biotekniikan ja kliinisten kokeiden älykkyys. Pääsy tästä.
• Lähde: https://aws.amazon.com/blogs/machine-learning/benchmark-and-optimize-endpoint-deployment-in-amazon-sagemaker-jumpstart/