A végpontok telepítésének összehasonlítása és optimalizálása az Amazon SageMaker JumpStart | Amazon webszolgáltatások

Nagy nyelvi modell (LLM) üzembe helyezésekor a gépi tanulást (ML) gyakorló szakemberek általában a modell kiszolgálási teljesítményének két mérésével foglalkoznak: a késleltetéssel, amelyet egyetlen token generálásához szükséges idő, és az átviteli sebességgel, amelyet a generált tokenek száma határoz meg. másodpercenként. Bár a telepített végponthoz intézett egyetlen kérés átviteli sebessége megközelítőleg megegyezik a modell késleltetésének inverzével, ez nem feltétlenül igaz, ha egyidejűleg több egyidejű kérést küldenek a végpontnak. A modellkiszolgálási technikák miatt, mint például az egyidejű kérések kliensoldali folyamatos kötegelése, a késleltetés és az átviteli sebesség összetett kapcsolatban áll egymással, amely jelentősen eltér a modell architektúrától, a kiszolgálási konfigurációktól, a példánytípus hardverétől, a párhuzamos kérések számától és a bemeneti hasznos terhelések változásaitól függően. mint a bemeneti és kimeneti tokenek száma.

Ez a bejegyzés ezeket a kapcsolatokat vizsgálja az Amazon SageMaker JumpStartban elérhető LLM-ek átfogó benchmarkingján keresztül, beleértve a Llama 2, Falcon és Mistral változatokat. A SageMaker JumpStart segítségével az ML gyakorlói a nyilvánosan elérhető alapmodellek széles választékából választhatnak, amelyeket dedikáltan telepíthetnek. Amazon SageMaker példányok hálózattól elszigetelt környezetben. Elméleti alapelveket biztosítunk arra vonatkozóan, hogy a gyorsító specifikációk hogyan befolyásolják az LLM benchmarkingot. Bemutatjuk a több példány egyetlen végpont mögötti telepítésének hatását is. Végezetül gyakorlati ajánlásokat adunk a SageMaker JumpStart telepítési folyamatának testreszabásához, hogy igazodjon a várakozási időre, az átviteli sebességre, a költségekre és az elérhető példánytípusokra vonatkozó korlátokra vonatkozó követelményekhez. Az összes benchmarking eredmény, valamint az ajánlások sokoldalúan alapulnak jegyzetfüzet hogy alkalmazkodni tud a használati esetéhez.

Telepített végpont-benchmarking

A következő ábra a legalacsonyabb késleltetési időt (balra) és a legnagyobb átviteli sebességet (jobbra) mutatja a telepítési konfigurációkhoz különféle modell- és példánytípusokban. Fontos, hogy ezen modelltelepítések mindegyike a SageMaker JumpStart által biztosított alapértelmezett konfigurációkat használja, megadva a kívánt modellazonosítót és példánytípust a telepítéshez.

Ezek a késleltetési és átviteli értékek a 256 bemeneti és 256 kimeneti jogkivonattal rendelkező hasznos terheléseknek felelnek meg. A legalacsonyabb késleltetésű konfiguráció korlátozza a modell egyetlen egyidejű kérésre történő kiszolgálását, a legnagyobb átviteli sebesség pedig maximalizálja az egyidejű kérések lehetséges számát. Amint azt a teljesítményértékelésünkben láthatjuk, az egyidejű kérések számának növekedése monoton módon növeli az átviteli sebességet, míg a nagy egyidejű kérések csökkenő javulását. Ezenkívül a modellek a támogatott példányon teljesen fel vannak osztva. Például, mivel az ml.g5.48xlarge példány 8 GPU-val rendelkezik, az ezt a példányt használó SageMaker JumpStart modellek mind a nyolc elérhető gyorsítón tenzorpárhuzamot használnak.

Ebből az ábrából megjegyezhetünk néhány kivonatot. Először is, nem minden modell támogatott minden példányon; egyes kisebb modellek, mint például a Falcon 7B, nem támogatják a modell felosztását, míg a nagyobb modellek nagyobb számítási erőforrásigényekkel rendelkeznek. Másodszor, ahogy a szilánkosodás növekszik, a teljesítmény általában javul, de nem feltétlenül javul a kis modellek esetében. Ennek az az oka, hogy az olyan kis modellek, mint a 7B és a 13B, jelentős kommunikációs ráfordítással járnak, ha túl sok gyorsítón keresztül vannak szétosztva. Ezt később részletesebben tárgyaljuk. Végül az ml.p4d.24xlarge példányok általában lényegesen jobb áteresztőképességgel rendelkeznek az A100 memória sávszélesség-javítása miatt az A10G GPU-khoz képest. Amint azt később tárgyaljuk, egy adott példánytípus használatára vonatkozó döntés a telepítési követelményektől függ, beleértve a késleltetést, az átviteli sebességet és a költségkorlátokat.

Hogyan szerezheti meg ezeket a legalacsonyabb késleltetési és legnagyobb áteresztőképességű konfigurációs értékeket? Kezdjük azzal, hogy ábrázoljuk egy Llama 2 7B végpont látenciáját az átviteli sebesség függvényében egy ml.g5.12xnagy példányon egy 256 bemeneti és 256 kimeneti jogkivonattal rendelkező hasznos adathoz, amint az a következő görbén látható. Hasonló görbe létezik minden telepített LLM-végponthoz.

Az egyidejűség növekedésével az átviteli sebesség és a késleltetés is monoton nő. Ezért a legalacsonyabb késleltetési pont 1-es egyidejű kérésértéknél jelentkezik, és költséghatékonyan növelheti a rendszer átviteli sebességét az egyidejű kérések növelésével. Ezen a görbén van egy külön „térd”, ahol nyilvánvaló, hogy a további egyidejűséghez kapcsolódó átviteli növekedés nem haladja meg a késleltetés kapcsolódó növekedését. Ennek a térdnek a pontos elhelyezkedése használati esetspecifikus; egyes gyakorlók meghatározhatják a térdet azon a ponton, ahol az előre meghatározott késleltetési követelményt túllépik (például 100 ms/token), míg mások terhelési tesztet és sorelméleti módszereket használhatnak, például a féllatencia szabályt, mások pedig elméleti gyorsító specifikációk.

Azt is megjegyezzük, hogy az egyidejű kérések maximális száma korlátozott. Az előző ábrán a vonalkövetés 192 egyidejű kéréssel végződik. Ennek a korlátozásnak a forrása a SageMaker hívási időtúllépési korlátja, ahol a SageMaker 60 másodperc után leállítja a hívási választ. Ez a beállítás fiókspecifikus, és nem konfigurálható egyedi végpontokhoz. LLM-eknél a nagyszámú kimeneti token generálása másodpercekig vagy akár percekig is eltarthat. Ezért a nagy bemeneti vagy kimeneti hasznos adatok a hívási kérelmek sikertelenségét okozhatják. Továbbá, ha az egyidejű kérések száma nagyon nagy, akkor sok kérésnél hosszú várakozási idők lesznek, ami megnöveli ezt a 60 másodperces időtúllépési korlátot. E tanulmány céljaira az időtúllépési korlátot használjuk a modell üzembe helyezéséhez lehetséges maximális átviteli sebesség meghatározására. Fontos, hogy bár a SageMaker végpontok nagyszámú egyidejű kérést kezelhetnek anélkül, hogy figyelembe vennék a hívási válasz időtúllépését, érdemes lehet maximális egyidejű kéréseket meghatározni a késleltetés-átbocsátási görbe térdére vonatkozóan. Valószínűleg ezen a ponton kezdi el fontolóra venni a vízszintes skálázást, ahol egyetlen végpont több példányt biztosít modellreplikákkal, és terheléselosztja a bejövő kéréseket a replikák között, hogy támogassa az egyidejű kéréseket.

Egy lépéssel továbblépve, a következő táblázat a Llama 2 7B modell különböző konfigurációira vonatkozó benchmarking eredményeket tartalmazza, beleértve a különböző számú bemeneti és kimeneti tokeneket, példánytípusokat és az egyidejű kérések számát. Vegye figyelembe, hogy az előző ábra ennek a táblázatnak csak egy sorát ábrázolja.

Néhány további mintát is megfigyelünk ezekben az adatokban. A kontextus méretének növelésekor a várakozási idő növekszik és az átviteli sebesség csökken. Például az ml.g5.2xlarge oldalon 1-es egyidejűség mellett az átviteli sebesség 30 token/mp, ha az összes token száma 512, szemben a 20 token/sec-tel, ha az összes token száma 4,096. Ez azért van, mert a nagyobb bemenet feldolgozása több időt vesz igénybe. Azt is láthatjuk, hogy a GPU-képesség növelése és a felosztás befolyásolja a maximális átviteli sebességet és a maximálisan támogatott egyidejű kéréseket. A táblázat azt mutatja, hogy a Llama 2 7B jelentősen eltérő maximális átviteli értékekkel rendelkezik a különböző példánytípusokhoz, és ezek a maximális átviteli értékek az egyidejű kérések különböző értékeinél fordulnak elő. Ezek a jellemzők arra késztetnék az ML-gyakorlót, hogy igazolja az egyik példány költségét a másikkal szemben. Például alacsony késleltetési követelmény miatt a szakember választhat egy ml.g5.12xlarge példányt (4 A10G GPU) egy ml.g5.2xlarge példány (1 A10G GPU) helyett. Ha nagy átviteli követelményt adunk, akkor egy ml.p4d.24xlarge példány (8 A100 GPU) használata teljes felosztással csak nagy egyidejűség esetén lenne indokolt. Ne feledje azonban, hogy gyakran előnyös ehelyett egy 7B modell több következtetési összetevőjét betölteni egyetlen ml.p4d.24xlarge példányra; az ilyen többmodell-támogatást ebben a bejegyzésben később tárgyaljuk.

Az előző megfigyeléseket a Llama 2 7B modellnél végeztük. A hasonló minták azonban más modellekre is érvényesek. Az elsődleges szempont, hogy a várakozási idő és az átviteli teljesítmény számai a hasznos terheléstől, a példány típusától és az egyidejű kérések számától függenek, ezért meg kell találnia az ideális konfigurációt az adott alkalmazáshoz. Az előző számok létrehozásához a használati esethez futtassa a linkelt jegyzetfüzet, ahol beállíthatja ezt a terhelési teszt elemzést a modellhez, a példánytípushoz és a hasznos terheléshez.

A gyorsító specifikációinak értelme

Az LLM-következtetéshez megfelelő hardver kiválasztása nagymértékben függ a konkrét használati esetektől, a felhasználói élmény céljaitól és a választott LLM-től. Ez a rész megpróbálja megérteni a térd látencia-átbocsátási görbéjét, tekintettel a gyorsító specifikációkon alapuló magas szintű elvekre. Ezek az elvek önmagukban nem elegendőek a döntéshez: valódi referenciaértékekre van szükség. A kifejezés eszköz itt az összes ML hardvergyorsítót magában foglalja. Azt állítjuk, hogy a látencia-átbocsátási görbében a térd két tényező egyike vezérli:

• A gyorsító kimerítette a memóriát a KV mátrixok gyorsítótárazásához, ezért a következő kérések sorba kerülnek
• A gyorsítónak még van tartalék memóriája a KV gyorsítótár számára, de elég nagy kötegméretet használ ahhoz, hogy a feldolgozási időt a számítási művelet késleltetése határozza meg, nem pedig a memória sávszélessége.

Általában inkább a második tényező korlátozza, mert ez azt jelenti, hogy a gyorsító erőforrásai telítettek. Alapvetően maximalizálja a kifizetett erőforrásokat. Vizsgáljuk meg ezt az állítást részletesebben.

KV gyorsítótár és eszközmemória

A szabványos transzformátorfigyelmeztetési mechanizmusok minden új tokennél kiszámítják a figyelmet az összes korábbi tokenhez képest. A legtöbb modern ML-kiszolgáló gyorsítótárazza a figyelemkulcsokat és értékeket az eszközmemóriában (DRAM), hogy elkerülje minden lépésben az újraszámítást. Ezt hívják a KV gyorsítótár, és a tétel méretével és sorozathosszával nő. Meghatározza, hogy hány felhasználói kérést lehet párhuzamosan kiszolgálni, és meghatározza a késleltetés-átbocsátási görbe térdét, ha a korábban említett második forgatókönyvben a számításhoz kötött rendszer még nem teljesül, tekintettel a rendelkezésre álló DRAM-ra. A következő képlet a KV gyorsítótár maximális méretének durva közelítése.

Ebben a képletben B a tétel mérete, N pedig a gyorsítók száma. Például az A2G GPU-n (7 GB DRAM) kiszolgált Llama 16 2B modell FP10-ban (24 bájt/paraméter) körülbelül 14 GB-ot fogyaszt, így 10 GB marad a KV gyorsítótár számára. A modell teljes környezeti hosszának (N = 4096) és a többi paraméternek (n_layers=32, n_kv_attention_heads=32 és d_attention_head=128) csatlakoztatásával ez a kifejezés azt mutatja, hogy a DRAM-korlátok miatt négy felhasználó kötegméretének párhuzamos kiszolgálására korlátozódik. . Ha megfigyeli az előző táblázatban szereplő megfelelő referenciaértékeket, ez jó közelítés a megfigyelt térdre ezen a látencia-átbocsátási görbén. Olyan módszerek, mint pl csoportosított lekérdezés figyelem (GQA) csökkentheti a KV gyorsítótár méretét, a GQA esetében ugyanezzel a tényezővel csökkenti a KV fejek számát.

Aritmetikai intenzitás és az eszköz memória sávszélessége

Az ML-gyorsítók számítási teljesítményének növekedése meghaladta a memória sávszélességét, ami azt jelenti, hogy sokkal több számítást tudnak végrehajtani minden egyes adatbájton az adott bájt eléréséhez szükséges idő alatt.

A aritmetikai intenzitás, vagy a számítási műveletek és a memóriaelérések aránya határozza meg, hogy a műveletet korlátozza-e a memória sávszélessége vagy a kiválasztott hardver számítási kapacitása. Például egy A10G GPU (g5 példánytípus-család) 70 TFLOPS FP16-tal és 600 GB/sec sávszélességgel körülbelül 116 művelet/byte-ot tud kiszámolni. Egy A100 GPU (p4d példánytípus-család) körülbelül 208 műveletet tud kiszámolni bájtonként. Ha egy transzformátormodell aritmetikai intenzitása ennél az értéknél kisebb, akkor az memória kötött; ha fent van, akkor számításhoz kötött. A Llama 2 7B figyelemmechanizmusa 62 művelet/byte-ot igényel az 1-es kötegmérethez (a magyarázatért lásd Útmutató az LLM következtetésekhez és a teljesítményhez), ami azt jelenti, hogy memóriához kötött. Ha a figyelemmechanizmus memóriához kötött, a drága FLOPS-ok kihasználatlanul maradnak.

Kétféleképpen lehet jobban kihasználni a gyorsítót és növelni az aritmetikai intenzitást: csökkenteni kell a művelethez szükséges memória-eléréseket (ez az, ami FlashAttention fókusz) vagy növelje a köteg méretét. Előfordulhat azonban, hogy nem tudjuk eléggé növelni a köteg méretét, hogy elérjük a számításhoz kötött rendszert, ha a DRAM túl kicsi a megfelelő KV gyorsítótár tárolására. A B* kritikus kötegméret nyers közelítését, amely elválasztja a számításhoz kötött és a memóriához kötött rezsimet a szabványos GPT dekóder következtetéshez, a következő kifejezés írja le, ahol A_mb a gyorsító memória sávszélessége, A_f a gyorsító FLOPS és N a szám gyorsítók. Ez a kritikus kötegméret úgy származtatható, hogy megtaláljuk, ahol a memória-elérési idő egyenlő a számítási idővel. Hivatkozni ez a blogbejegyzés hogy részletesebben megértsük a 2. egyenletet és annak feltevéseit.

Ez ugyanaz a művelet/byte arány, mint amit korábban az A10G-hez számoltunk, tehát a kritikus kötegméret ezen a GPU-n 116. Az elméleti, kritikus kötegméret megközelítésének egyik módja a modell felosztásának növelése és a gyorsítótár felosztása több N gyorsító között. Ez hatékonyan növeli a KV gyorsítótár kapacitását, valamint a memóriához kötött kötegméretet.

A modellfelosztás másik előnye a modellparaméterek és az adatbetöltési munka felosztása N gyorsító között. Ez a fajta felosztás a modellpárhuzam egyik típusa, amelyet más néven tenzor párhuzamosság. Naiv módon a memória sávszélessége és számítási teljesítménye N-szerese aggregált. Feltételezve, hogy nincs semmiféle többletköltség (kommunikáció, szoftver stb.), ez N-vel csökkentené a tokenenkénti dekódolási késleltetést, ha memóriakötöttek vagyunk, mivel ebben a rendszerben a token dekódolási késleltetése a modell betöltéséhez szükséges idő függvénye. súlyok és gyorsítótár. A való életben azonban a megosztás mértékének növelése megnövekedett kommunikációt eredményez az eszközök között, hogy megosszák a közbenső aktiválásokat minden modellrétegen. Ezt a kommunikációs sebességet az eszköz összekapcsolási sávszélessége korlátozza. Hatását nehéz pontosan megbecsülni (a részleteket lásd Modellpárhuzam), de ez végül nem hoz hasznot, vagy ronthatja a teljesítményt – ez különösen igaz a kisebb modellekre, mert a kisebb adatátvitel alacsonyabb átviteli sebességet eredményez.

Az ML-gyorsítók specifikációi alapján történő összehasonlításához a következőket javasoljuk. Először számítsa ki a hozzávetőleges kritikus kötegméretet minden egyes gyorsítótípushoz a második egyenlet szerint, és a KV gyorsítótár méretét a kritikus kötegmérethez az első egyenlet szerint. Ezután a gyorsítón rendelkezésre álló DRAM segítségével kiszámíthatja a KV gyorsítótár és a modellparaméterek beillesztéséhez szükséges gyorsítók minimális számát. Ha több gyorsító között dönt, a gyorsítókat a legalacsonyabb GB/másodperc memóriasávszélesség szerinti költség sorrendjében adja meg. Végül végezze el ezeket a konfigurációkat, és ellenőrizze, hogy mi a legjobb költség/token a kívánt késleltetés felső határához.

Válasszon ki egy végpont-telepítési konfigurációt

Sok, a SageMaker JumpStart által terjesztett LLM használja a szöveggenerálás-következtetés (TGI) SageMaker konténer modelltálaláshoz. A következő táblázat bemutatja, hogyan állíthat be számos modellkiszolgálási paramétert a várakozási idő-átviteli görbét befolyásoló modellkiszolgálásra, vagy a végpont védelmére olyan kérések ellen, amelyek túlterhelnék a végpontot. Ezek azok az elsődleges paraméterek, amelyek segítségével konfigurálhatja a végpont-telepítést az adott használati esethez. Ha nincs másképp megadva, az alapértelmezettet használjuk szöveggenerálás hasznos terhelési paraméterei és a TGI környezeti változók.

A TGI-kiszolgáló folyamatos kötegelést használ, amely dinamikusan kötegeli az egyidejű kéréseket, hogy megosszon egyetlen modellkövetkeztetési továbbítást. Kétféle előrelépés létezik: előtöltés és dekódolás. Minden új kérésnek egyetlen előre kitöltött továbbítást kell futtatnia a KV gyorsítótár feltöltéséhez a bemeneti sorozatjogkivonatokhoz. A KV-gyorsítótár feltöltése után a dekódolási továbbítás egyetlen következő jogkivonat előrejelzését hajtja végre az összes kötegelt kérésre, amelyet ismétlődően megismételnek a kimeneti sorozat létrehozásához. Amikor új kéréseket küldenek a kiszolgálónak, a következő dekódolási lépésnek várnia kell, hogy az előtöltési lépés lefusson az új kérésekre. Ennek meg kell történnie, mielőtt ezeket az új kéréseket a következő, folyamatosan kötegelt dekódolási lépésekbe bevonnák. A hardveres korlátok miatt előfordulhat, hogy a dekódoláshoz használt folyamatos kötegelés nem tartalmazza az összes kérést. Ezen a ponton a kérések bekerülnek a feldolgozási sorba, és a következtetési késleltetés jelentősen növekedni kezd, csekély átviteli sebességnövekedéssel.

Az LLM késleltetési benchmarking elemzései szétválaszthatók előtöltési késleltetésre, dekódolási késleltetésre és várakozási várakozási időre. Az egyes összetevők által felhasznált idő alapvetően eltérő természetű: az előtöltés egyszeri számítás, a dekódolás minden egyes tokennél egyszer történik meg a kimeneti szekvenciában, és a sorban állás a szerver kötegelési folyamatait foglalja magában. Több egyidejű kérés feldolgozása során nehéz lesz elkülöníteni a késéseket ezen összetevők mindegyikétől, mivel az adott ügyfélkérelem által tapasztalt várakozási idő magában foglalja az új párhuzamos kérések előtöltésének szükségessége miatti várakozási időt, valamint a felvétel által előidézett várakozási időket. a kérelem kötegelt dekódolási folyamataiban. Emiatt ez a bejegyzés a végpontok közötti feldolgozási késleltetésre összpontosít. A látencia-átbocsátási görbe térd pontja a telítettségi ponton történik, ahol a várakozási várakozási idő jelentősen növekedni kezd. Ez a jelenség bármely modellkövetkeztetés-kiszolgálónál előfordul, és a gyorsító specifikációi vezérlik.

Az üzembe helyezés során általános követelmények közé tartozik a minimálisan szükséges átviteli sebesség, a maximális megengedett késleltetés, a maximális óránkénti költség és az 1 millió token létrehozásának maximális költsége. Ezeket a követelményeket a végfelhasználói kéréseket képviselő hasznos terhelésekhez kell kötnie. A követelményeknek megfelelő tervezésnek számos tényezőt figyelembe kell vennie, beleértve az adott modell architektúrát, a modell méretét, a példánytípusokat és a példányszámot (vízszintes méretezés). A következő szakaszokban a végpontok üzembe helyezésére összpontosítunk a késleltetés minimalizálása, az átviteli sebesség maximalizálása és a költségek minimalizálása érdekében. Ez az elemzés összesen 512 tokent és 256 kimeneti tokent vesz figyelembe.

Minimalizálja a késleltetést

A késleltetés sok valós idejű felhasználási esetben fontos követelmény. A következő táblázatban megvizsgáljuk az egyes modellek és példánytípusok minimális késleltetését. A minimális késleltetést a beállítással érheti el MAX_CONCURRENT_REQUESTS = 1.

A modell minimális késleltetésének eléréséhez a következő kódot használhatja, miközben helyettesíti a kívánt modellazonosítót és példánytípust:

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

Vegye figyelembe, hogy a késleltetési idő a bemeneti és kimeneti tokenek számától függően változik. A telepítési folyamat azonban a környezeti változók kivételével változatlan marad MAX_INPUT_TOKENS és a MAX_TOTAL_TOKENS. Itt ezek a környezeti változók úgy vannak beállítva, hogy segítsenek garantálni a végpont késleltetési követelményeit, mivel a nagyobb bemeneti sorozatok megsérthetik a késleltetési követelményt. Vegye figyelembe, hogy a SageMaker JumpStart már biztosítja a többi optimális környezeti változót a példánytípus kiválasztásakor; például az ml.g5.12xlarge használatával beállítja SM_NUM_GPUS 4-re a modellkörnyezetben.

Maximalizálja az áteresztőképességet

Ebben a részben maximalizáljuk a másodpercenként generált tokenek számát. Ez általában a modell és a példánytípus maximális érvényes egyidejű kérése esetén érhető el. A következő táblázatban a legnagyobb egyidejű kérésérték mellett elért átviteli sebességet mutatjuk be, mielőtt bármely kérésnél SageMaker hívási időtúllépésbe ütköznénk.

Egy modell maximális átviteli sebességének eléréséhez a következő kódot használhatja:

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

Vegye figyelembe, hogy az egyidejű kérések maximális száma a modell típusától, a példány típusától, a bemeneti tokenek maximális számától és a kimeneti tokenek maximális számától függ. Ezért ezeket a paramétereket a beállítás előtt be kell állítani MAX_CONCURRENT_REQUESTS.

Vegye figyelembe azt is, hogy a késleltetés minimalizálása iránt érdeklődő felhasználó gyakran ellentétben áll az átviteli sebesség maximalizálása iránt érdeklődő felhasználóval. Az előbbit a valós idejű válaszok érdeklik, míg az utóbbit a kötegelt feldolgozás érdekli, hogy a végponti sor mindig telített legyen, ezáltal minimalizálva a feldolgozási leállást. Azok a felhasználók, akik a késleltetési követelményektől függő átviteli sebességet szeretnék maximalizálni, gyakran érdeklődnek a késleltetés-átbocsátási görbe térdénél történő működés iránt.

Minimalizálja a költségeket

Az első lehetőség a költségek minimalizálására az óránkénti költség minimalizálása. Ezzel a legalacsonyabb óránkénti költséggel telepíthet egy kiválasztott modellt a SageMaker példányon. A SageMaker példányok valós idejű árazásához lásd: Amazon SageMaker árképzés. Általában a SageMaker JumpStart LLM-ek alapértelmezett példánytípusa a legalacsonyabb költségű telepítési lehetőség.

A második lehetőség a költségek minimalizálására az 1 millió token előállításához szükséges költségek minimalizálása. Ez a táblázat egyszerű átalakítása, amelyet korábban tárgyaltunk az átviteli sebesség maximalizálása érdekében, ahol először kiszámolhatja, hogy mennyi időre van szükség órákban 1 millió token előállításához (1e6 / átviteli sebesség / 3600). Ezután megszorozhatja ezt az időt, hogy 1 millió tokent generáljon a megadott SageMaker példány óránkénti árával.

Ne feledje, hogy a legalacsonyabb óránkénti költséggel rendelkező példányok nem ugyanazok, mint az 1 millió token létrehozásának legalacsonyabb költsége. Például, ha a hívási kérelmek szórványosak, a legalacsonyabb óránkénti költséggel rendelkező példány lehet az optimális, míg a fojtogató forgatókönyvekben az egymillió token létrehozásának legalacsonyabb költsége lehet megfelelőbb.

Tenzor párhuzamos vs. többmodell kompromisszum

Az összes korábbi elemzés során egyetlen modellreplika üzembe helyezését fontolgattuk, amelynek tenzor párhuzamos foka megegyezik a telepítési példánytípuson lévő GPU-k számával. Ez a SageMaker JumpStart alapértelmezett viselkedése. Azonban, amint azt korábban megjegyeztük, egy modell felosztása csak egy bizonyos határig javíthatja a modell késleltetését és áteresztőképességét, amelyen túl az eszközök közötti kommunikációs követelmények uralják a számítási időt. Ez azt jelenti, hogy gyakran előnyös több, alacsonyabb tenzorpárhuzamos fokú modellt telepíteni egyetlen példányra, nem pedig egyetlen, magasabb tenzorpárhuzamos fokú modellt.

Itt telepítjük a Llama 2 7B és 13B végpontjait ml.p4d.24xlarge példányokon, ahol a tenzorral párhuzamos (TP) fokok 1, 2, 4 és 8. A modell viselkedésének egyértelműsége érdekében ezek a végpontok csak egy modellt töltenek be.

Korábbi elemzéseink már jelentős átviteli előnyöket mutattak az ml.p4d.24xlarge példányokon, ami gyakran jobb teljesítményt jelent a költség szempontjából, ha 1 millió token generál a g5 példánycsaládhoz képest magas egyidejű kérésterhelési feltételek mellett. Ez az elemzés egyértelműen bemutatja, hogy mérlegelnie kell a modell felosztása és a modell replikációja közötti kompromisszumot egyetlen példányon belül; vagyis a teljesen feldarabolt modell általában nem a legjobb felhasználása az ml.p4d.24xlarge számítási erőforrásoknak a 7B és 13B modellcsaládokhoz. Valójában a 7B modellcsalád esetében a legjobb átviteli sebességet kapja egyetlen modellreplikához, amelynek tenzorpárhuzamos foka 4 helyett 8.

Innen extrapolálható, hogy a 7B modell legnagyobb átviteli sebessége 1-es tenzorpárhuzamos fokot tartalmaz nyolc modellreplikával, a 13B modell legnagyobb átviteli sebessége pedig valószínűleg 2-es tenzorpárhuzamos fokot négy modellreplikával. Ha többet szeretne megtudni ennek végrehajtásáról, tekintse meg a Az Amazon SageMaker legújabb funkcióival átlagosan 50%-kal csökkentheti a modell telepítési költségeit, amely a következtetési komponens alapú végpontok használatát mutatja be. A terheléselosztási technikák, a szerver-útválasztás és a CPU-erőforrások megosztása miatt előfordulhat, hogy nem éri el teljes mértékben az egyetlen replika átviteli sebességével megegyező replikák számának szorzatát.

Vízszintes méretezés

Amint azt korábban megfigyeltük, minden végpont-telepítés korlátozza az egyidejű kérések számát a bemeneti és kimeneti tokenek számától, valamint a példány típusától függően. Ha ez nem felel meg az átviteli sebességre vagy az egyidejű kérésre vonatkozó követelménynek, akkor a telepített végpont mögött egynél több példányt használhat fel. A SageMaker automatikusan elvégzi a lekérdezések terheléselosztását a példányok között. A következő kód például három példány által támogatott végpontot telepít:

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

A következő táblázat az átviteli teljesítmény-növekedést mutatja a példányok számának tényezőjeként a Llama 2 7B modellnél.

Nevezetesen, a késleltetés-átbocsátási görbe térdrésze jobbra tolódik el, mert a nagyobb példányszám nagyobb számú egyidejű kérést képes kezelni a többpéldányos végponton belül. Ebben a táblázatban az egyidejű kérés értéke a teljes végpontra vonatkozik, nem pedig az egyes példányok által kapott egyidejű kérések számára.

Használhatja az automatikus skálázást is, amely a munkaterhelés figyelésére és a kapacitás dinamikus beállítására szolgál, hogy a lehető legalacsonyabb költséggel fenntartsa az egyenletes és kiszámítható teljesítményt. Ez meghaladja ennek a bejegyzésnek a kereteit. Ha többet szeretne megtudni az automatikus skálázásról, lásd: Automatikus skálázási következtetési végpontok konfigurálása az Amazon SageMakerben.

Végpont meghívása egyidejű kérésekkel

Tegyük fel, hogy van egy nagy köteg lekérdezésed, amelyeket nagy átviteli sebesség mellett szeretne válaszokat generálni egy telepített modellből. Például a következő kódblokkban összeállítunk egy 1,000 hasznos adatot tartalmazó listát, és minden egyes rakomány 100 token generálását kéri. Összességében 100,000 XNUMX token generálását kérünk.

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

Ha nagyszámú kérelmet küld a SageMaker futásidejű API-nak, szabályozási hibákat tapasztalhat. Ennek enyhítésére létrehozhat egy egyéni SageMaker futásidejű klienst, amely növeli az újrapróbálkozások számát. Az eredményül kapott SageMaker munkamenet objektumot bármelyik a JumpStartModel kivitelező ill sagemaker.predictor.retrieve_default ha új előrejelzőt szeretne csatolni egy már telepített végponthoz. A következő kódban ezt a munkamenet-objektumot használjuk, amikor egy Llama 2 modellt telepítünk alapértelmezett SageMaker JumpStart konfigurációkkal:

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

Ez a telepített végpont rendelkezik MAX_CONCURRENT_REQUESTS = 128 alapértelmezés szerint. A következő blokkban a párhuzamos határidős könyvtárat használjuk a végpont meghívásának ismétlésére az összes, 128 munkaszálból álló hasznos terhelésnél. A végpont legfeljebb 128 egyidejű kérést dolgoz fel, és amikor egy kérés választ ad, a végrehajtó azonnal új kérést küld a végpontnak.

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)

Ennek eredményeként összesen 100,000 1255 token jön létre 5.2 token/sec átviteli sebességgel egyetlen ml.g80xlarge példányon. Ennek feldolgozása körülbelül XNUMX másodpercet vesz igénybe.

Ne feledje, hogy ez az átviteli érték jelentősen eltér a Llama 2 7B maximális átviteli sebességétől az ml.g5.2xlarge formátumban a bejegyzés előző táblázataiban (486 token/mp 64 egyidejű kérés esetén). Ennek az az oka, hogy a bemeneti hasznos terhelés 8 tokent használ 256 helyett, a kimeneti tokenszám 100 256 helyett, és a kisebb tokenszámok 128 egyidejű kérést tesznek lehetővé. Ez egy utolsó emlékeztető, hogy minden késleltetési és átviteli szám hasznos terheléstől függ! A hasznos teherjogkivonatok számának módosítása hatással lesz a kötegelési folyamatokra a modell kiszolgálása során, ami viszont hatással lesz az alkalmazás előtöltésére, dekódolására és várakozási idejére.

Következtetés

Ebben a bejegyzésben bemutattuk a SageMaker JumpStart LLM-ek teljesítményértékelését, beleértve a Llama 2-t, a Mistral-t és a Falcont. Bemutattunk egy útmutatót is a késleltetés, az átviteli sebesség és a végpont-telepítési konfiguráció költségeinek optimalizálásához. Elkezdheti futtatni a kapcsolódó jegyzetfüzet a használati eset összehasonlításához.

A szerzőkről

 Dr. Kyle Ulrich az Amazon SageMaker JumpStart csapatának alkalmazott tudósa. Kutatási területei közé tartoznak a skálázható gépi tanulási algoritmusok, a számítógépes látás, az idősorok, a Bayes-féle nem-paraméterek és a Gauss-folyamatok. Doktori fokozatát a Duke Egyetemen szerezte, és publikációkat publikált a NeurIPS-ben, a Cell-ben és a Neuron-ban.

Dr. Vivek Madan az Amazon SageMaker JumpStart csapatának alkalmazott tudósa. PhD fokozatát az Illinoisi Egyetemen szerezte, az Urbana-Champaign-ben, és a Georgia Tech posztdoktori kutatója volt. Aktív kutatója a gépi tanulásnak és az algoritmustervezésnek, és publikált előadásokat EMNLP, ICLR, COLT, FOCS és SODA konferenciákon.

Dr. Ashish Khetan az Amazon SageMaker JumpStart vezető alkalmazott tudósa, és segít gépi tanulási algoritmusok fejlesztésében. PhD fokozatát az Illinois Urbana-Champaign Egyetemen szerezte. A gépi tanulás és a statisztikai következtetések aktív kutatója, és számos közleményt publikált NeurIPS, ICML, ICLR, JMLR, ACL és EMNLP konferenciákon.

João Moura az AWS vezető AI/ML-megoldások specialistája. A João segít az AWS-ügyfeleknek – a kis startupoktól a nagyvállalatokig – a nagy modellek hatékony képzésében és üzembe helyezésében, valamint szélesebb körben az ML platformok AWS-en való felépítésében.

• SEO által támogatott tartalom és PR terjesztés. Erősödjön még ma.
• PlatoData.Network Vertical Generative Ai. Erősítse meg magát. Hozzáférés itt.
• PlatoAiStream. Web3 Intelligence. Felerősített tudás. Hozzáférés itt.
• PlatoESG. Carbon, CleanTech, Energia, Környezet, Nap, Hulladékgazdálkodás. Hozzáférés itt.
• PlatoHealth. Biotechnológiai és klinikai vizsgálatok intelligencia. Hozzáférés itt.
• Forrás: https://aws.amazon.com/blogs/machine-learning/benchmark-and-optimize-endpoint-deployment-in-amazon-sagemaker-jumpstart/