Érjen el hiperskálás teljesítményt a modellkiszolgáláshoz az NVIDIA Triton Inference Server segítségével az Amazon SageMakeren

A gépi tanulási (ML) alkalmazások telepítése bonyolult, és gyakran több ML-modellre van szükség egyetlen következtetési kérelem kiszolgálásához. Egy tipikus kérés több modellen is áthaladhat olyan lépésekkel, mint az előfeldolgozás, az adatátalakítások, a modellkiválasztási logika, a modell-összesítés és az utófeldolgozás. Ez olyan általános tervezési minták kialakulásához vezetett, mint például a soros következtetési folyamatok, az együttesek (szórt összegyűjtés) és az üzleti logikai munkafolyamatok, amelyek eredményeképpen a kérés teljes munkafolyamata irányított aciklikus gráfként (DAG) valósult meg. Ahogy azonban a munkafolyamatok bonyolultabbá válnak, ez az alkalmazások általános válaszidejének vagy késleltetésének növekedéséhez vezet, ami viszont hatással van az általános felhasználói élményre. Továbbá, ha ezeket az összetevőket különböző példányokon tárolják, a példányok közötti további hálózati késés növeli a teljes várakozási időt. Tekintsünk egy példát egy népszerű ML használati esetre az ügyfélszolgálat virtuális asszisztense számára. Egy tipikus kérésnek több lépésen kell keresztülmennie, amelyek magukban foglalják a beszédfelismerést, a természetes nyelvi feldolgozást (NLP), a párbeszédpanel állapotának követését, a párbeszédszabályokat, a szöveggenerálást és végül a szöveget beszédté. Ezenkívül a felhasználói interakció személyre szabottabbá tétele érdekében korszerű, transzformátor alapú NLP-modelleket is használhat, mint például a BERTI, BARTés GPT. A végeredmény hosszú válaszidő ezeknél a modell-együtteseknél és rossz felhasználói élmény.

Az általános átviteli sebesség csökkentése nélkül lecsökkent válaszidő elérésének általános mintája az, hogy ezeket a modelleket ugyanazon a példányon tárolják, és a beágyazott könnyű üzleti logikát. Ezek a modellek egy vagy több tárolóba is beépíthetők ugyanazon a példányon, hogy elkülönítsék a futó folyamatokat, és alacsonyan tartsák a késleltetést. Ezenkívül az általános késleltetés a következtetési alkalmazáslogikától, a modelloptimalizálástól, a mögöttes infrastruktúrától (beleértve a számítást, a tárolást és a hálózatépítést), valamint a következtetési kéréseket fogadó webszervertől is függ. NVIDIA Triton következtetés szerver egy nyílt forráskódú következtetést kiszolgáló szoftver, amely ultraalacsony (egy számjegyű ezredmásodperces) következtetési késleltetéssel maximalizálja az átviteli sebességet és a hardver kihasználtságát. Széles körben támogatja az ML keretrendszereket (többek között TensorFlow, PyTorch, ONNX, XGBoost és NVIDIA TensorRT) és infrastruktúra háttérrendszereket, beleértve a GPU-kat, CPU-kat és AWS Inferentia. Ezenkívül a Triton Inference Server integrálva van Amazon SageMaker, egy teljesen felügyelt, végpontok közötti ML szolgáltatás, amely valós idejű következtetési lehetőségeket biztosít, beleértve egyetlen és a több modell hosting. Ezek a következtetési lehetőségek magukban foglalják több modell tárolását ugyanabban a tárolóban a mögött egyetlen végpontés hosting több modell több konténerrel egyetlen végpont mögött.

2021 novemberében bejelentettük a Triton Inference Server integrációja a SageMakeren. Az AWS szorosan együttműködött az NVIDIA-val annak érdekében, hogy mindkét világból a legjobbat hozhassa ki, és megkönnyítse a modellek telepítését a Triton segítségével az AWS-en.

Ebben a bejegyzésben a transzformátormodellek nagyszabású GPU-kon történő telepítésének bevált gyakorlatait tekintjük át a SageMakeren található Triton Inference Server használatával. Először a SageMaker késleltetésével kapcsolatos kulcsfogalmak összefoglalásával kezdjük, és áttekintjük a teljesítményhangolási irányelveket. Ezután áttekintést adunk a Tritonról és szolgáltatásairól, valamint példakódot adunk a SageMakeren történő telepítéshez. Végül terhelési teszteket végzünk a segítségével SageMaker Inference Recommender és összefoglalja a Hugging Face által biztosított népszerű transzformátormodell terhelési teszteléséből származó meglátásokat és következtetéseket.

Áttekintheti a jegyzetfüzet korábban modelleket telepítettünk és terhelési teszteket végeztünk önállóan a on kód használatával GitHub.

Teljesítményhangolás és -optimalizálás a SageMaker modell kiszolgálásához

A teljesítményhangolás és -optimalizálás empirikus folyamat, amely gyakran több iterációt is magában foglal. A hangolandó paraméterek száma kombinatorikus, és a konfigurációs paraméterek értékei nem függetlenek egymástól. Különféle tényezők befolyásolják az optimális paraméterhangolást, beleértve a hasznos adatmennyiséget, a típust és az ML-modellek számát a következtetési kérés folyamatábrájában, a tárolótípust, a számítási példány típusát, a hálózati infrastruktúrát, az alkalmazáskódot, a következtetéseket kiszolgáló szoftver futási idejét és konfigurációját stb.

Ha a SageMaker-t használja az ML-modellek telepítéséhez, akkor a legjobb ár-teljesítményű számítási példányt kell kiválasztania, ami bonyolult és ismétlődő folyamat, amely hetekig tartó kísérletezést igényel. Először is ki kell választania a megfelelő ML-példánytípust a több mint 70 lehetőség közül a modellek erőforrásigénye és a bemeneti adatok mérete alapján. Ezután optimalizálnia kell a modellt a kiválasztott példánytípushoz. Végül ki kell építenie és kezelnie kell az infrastruktúrát a terhelési tesztek futtatásához és a felhőkonfiguráció beállításához az optimális teljesítmény és költség érdekében. Mindez késleltetheti a modell bevezetését és a piacra kerülés idejét. Ezenkívül értékelnie kell a várakozási idő, az átviteli sebesség és a költségek közötti kompromisszumot az optimális telepítési konfiguráció kiválasztásához. SageMaker Inference Recommender automatikusan kiválasztja a megfelelő számítási példánytípust, példányszámot, tárolóparamétereket és modelloptimalizálást a következtetésekhez az átviteli sebesség maximalizálása, a késleltetés csökkentése és a költségek minimalizálása érdekében.

Valós idejű következtetés és késleltetés a SageMakerben

SageMaker valós idejű következtetés ideális olyan következtetési munkaterhelésekhez, ahol valós idejű, interaktív, alacsony késleltetésű követelmények vannak. Négy leggyakrabban használt mérőszám van a SageMaker következtetési végpontok következtetéskérés késésének figyelésére

• Tároló késleltetése – A kérés elküldéséhez, a válasz lekéréséhez a modell tárolójából, és a tárolóban a következtetés befejezéséhez szükséges idő. Ez a mérőszám az Amazon CloudWatch részeként érhető el Meghívási mérőszámok a SageMaker adta ki.
• Modell késleltetés – Az összes SageMaker tároló által eltöltött teljes idő egy következtetési csővezeték. Ez a mérőszám az Amazon CloudWatch részeként érhető el Meghívási mérőszámok a SageMaker adta ki.
• Rezsi késleltetés – Attól az időponttól mérve, amikor a SageMaker megkapja a kérést, addig, amíg választ nem ad vissza az ügyfélnek, levonva a modell késleltetését. Ez a mérőszám az Amazon CloudWatch részeként érhető el Meghívási mérőszámok a SageMaker adta ki.
• Végpontok közötti késleltetés – Attól az időponttól mérve, amikor az ügyfél elküldi a következtetési kérést, amíg vissza nem kapja a választ. Az ügyfelek ezt egyéni mérőszámként tehetik közzé az Amazon CloudWatch szolgáltatásban.

A következő diagram ezeket az összetevőket mutatja be.

A tároló késleltetése több tényezőtől függ; a legfontosabbak közé tartoznak a következők:

• Az alapul szolgáló protokoll (HTTP(ek)/gRPC) a következtetéskiszolgálóval való kommunikációhoz
• Új TLS-kapcsolatok létrehozásával kapcsolatos általános költségek
• A kérés/válasz hasznos teher deszerializálási ideje
• Az alapul szolgáló következtetési kiszolgáló által biztosított sorban állási és kötegelési szolgáltatások kérése
• A mögöttes következtetési szerver által biztosított ütemezési lehetőségek kérése
• A következtetési kiszolgáló mögöttes futásidejű teljesítménye
• Elő- és utófeldolgozási könyvtárak teljesítménye a modell-előrejelzési függvény meghívása előtt
• A mögöttes ML keretrendszer háttér teljesítménye
• Modell- és hardver-specifikus optimalizálás

Ebben a bejegyzésben elsősorban a konténer késleltetésének, valamint az általános átviteli sebesség és költség optimalizálására összpontosítunk. Konkrétan a SageMaker tárolóban futó Triton Inference Server teljesítményhangolását vizsgáljuk.

Használati eset áttekintése

Az NLP-modellek üzembe helyezése és méretezése éles környezetben meglehetősen nagy kihívást jelenthet. Az NLP modellek gyakran nagyon nagy méretűek, és több millió modellparamétert tartalmaznak. Optimális modellkonfigurációk szükségesek ahhoz, hogy megfeleljenek a termelési szintű NLP-alkalmazások szigorú teljesítmény- és méretezhetőségi követelményeinek.

Ebben a bejegyzésben összehasonlítunk egy NLP-használati esetet egy SageMaker valós idejű végpont segítségével, amely egy Triton Inference Server tárolón alapul, és teljesítmény-hangolási optimalizálásokat javasolunk az ML használati esetünkhöz. Nagyméretű, előre betanított transzformátor alapú Hugging Face-t használunk BERT nagy burkolat nélküli modell, amely mintegy 336 millió modellparaméterrel rendelkezik. A bináris osztályozási modellhez használt bemeneti mondat kitömött és csonkolt, legfeljebb 512 token bemeneti sorozathosszra. A következtetési terhelési teszt 500 hívást szimulál másodpercenként (maximum 30,000 XNUMX hívást percenként) és ModelLatency kevesebb, mint 0.5 másodperc (500 ezredmásodperc).

Az alábbi táblázat összefoglalja a benchmark konfigurációnkat.

NVIDIA Triton következtetés szerver

A Triton Inference Servert kifejezetten arra tervezték, hogy lehetővé tegye a modellek méretezhető, gyors és egyszerű üzembe helyezését a termelésben. A Triton számos fő mesterséges intelligencia keretrendszert támogat, köztük a TensorFlow, TensorRT, PyTorch, XGBoost és ONNX. A Python és C++ egyéni háttérrendszerrel a következtetési munkaterhelést is megvalósíthatja a testreszabottabb használati esetek érdekében.

A legfontosabb, hogy a Triton egyszerű, konfiguráción alapuló beállítást biztosít a modellek tárolásához, amely a teljesítményoptimalizálási funkciók gazdag készletét teszi lehetővé, amelyeket kis kódolási erőfeszítéssel használhat.

A Triton növeli a következtetési teljesítményt azáltal, hogy maximalizálja a hardver kihasználtságát különböző optimalizálási technikákkal (a leggyakrabban az egyidejű modellfutásokat és a dinamikus kötegelést használják). Az optimális modellkonfigurációk megtalálása a dinamikus kötegméretek és az egyidejű modellpéldányok számának különféle kombinációiból kulcsfontosságú ahhoz, hogy valós idejű következtetést lehessen levonni az alacsony költségű kiszolgáláson belül a Triton használatával.

Dinamikus kötegelés

Sok gyakorló hajlamos egymás után futtatni a következtetést, amikor a szervert több független kéréssel hívják meg. Bár könnyebben beállítható, általában nem a legjobb gyakorlat a GPU számítási teljesítményének kihasználása. Ennek megoldására a Triton a beépített optimalizálásokat kínálja dinamikus kötegelés ezeknek a független következtetési kéréseknek a szerveroldali kombinálására, hogy dinamikusan nagyobb kötegeket alkossanak az átviteli sebesség növelése érdekében. A következő diagram a Triton futásidejű architektúráját mutatja be.

Az előző architektúrában az összes kérés először a dinamikus kötegelőt éri el, mielőtt a tényleges modellütemező-sorokba lépne, hogy megvárja a következtetést. Beállíthatja a kívánt kötegméreteket a dinamikus kötegeléshez a preferált_kötegelt_méret beállításokat a modell konfigurációjában. (Ne feledje, hogy a formált tétel méretének kisebbnek kell lennie, mint a max_batch_size a modell támogatja.) Beállíthatja azt is max_queue_delay_microseconds a maximális késleltetési idő megadásához a kötegelőben, hogy a várakozási idő követelményei alapján más kérésekre is csatlakozzanak a köteghez.

A következő kódrészlet bemutatja, hogyan adhatja hozzá ezt a funkciót a modell konfigurációs fájljaihoz, hogy dinamikus kötegelést állítson be 16-os preferált kötegmérettel a tényleges következtetéshez. A jelenlegi beállításokkal a modellpéldány azonnal meghívásra kerül, ha az előnyben részesített 16-os kötegméret teljesül, vagy a 100 mikromásodperces késleltetési idő eltelik azóta, hogy az első kérés elérte a dinamikus kötegelőt.

dynamic_batching { preferred_batch_size: 16 max_queue_delay_microseconds: 100 }

Modellek egyidejű futtatása

A Triton egy másik alapvető optimalizálása a hardver kihasználtságának maximalizálására további késleltetési költségek nélkül párhuzamos modellvégrehajtás, amely lehetővé teszi több modell vagy ugyanazon modell több példányának párhuzamos futtatását. Ez a funkció lehetővé teszi a Triton számára, hogy egyidejűleg több következtetési kérést kezeljen, ami növeli a következtetés átviteli sebességét azáltal, hogy a hardveren egyébként üresjárati számítási teljesítményt használ.

A következő ábra bemutatja, hogyan konfigurálhat egyszerűen, néhány soros kódmódosítással a különböző modell-telepítési házirendeket. Például az A konfiguráció (balra) azt mutatja, hogy két modellpéldány azonos konfigurációját is sugározhatja bert-large-uncased minden elérhető GPU-ra. Ezzel szemben a B konfiguráció (középső) csak a GPU 0 esetében más konfigurációt mutat, anélkül, hogy a többi GPU-n módosítaná a házirendeket. Különböző modellek példányait is telepítheti egyetlen GPU-n, amint az a C konfigurációban (jobbra) látható.

A C konfigurációban a számítási példány két egyidejű kérést tud kezelni a DistilGPT-2 modellhez és hét egyidejű kérést a bert-large-uncased modell párhuzamosan. Ezekkel az optimalizálásokkal a hardver erőforrások jobban kihasználhatók a kiszolgálási folyamathoz, ezáltal javul az átviteli sebesség és a munkaterhelés költséghatékonysága.

TensorRT

NVIDIA TensorRT egy SDK a nagy teljesítményű mély tanulási következtetésekhez, amely zökkenőmentesen működik a Tritonnal. A TensorRT, amely minden nagyobb mély tanulási keretrendszert támogat, tartalmaz egy következtetés-optimalizálót és egy futási időt, amely alacsony késleltetést és nagy áteresztőképességet biztosít a következtetések futtatásához hatalmas adatmennyiséggel, hatékony optimalizálás révén.

A TensorRT úgy optimalizálja a grafikont, hogy a felesleges memória felszabadításával és annak hatékony újrafelhasználásával minimalizálja a memóriaterületet. Ezenkívül a TensorRT-összeállítás egyesíti a modellgráfon belüli ritka műveleteket, hogy nagyobb kernelt képezzen, hogy elkerülje a többszöri kis kernelindítások többletköltségét. A kernel automatikus hangolása segít a hardver teljes kihasználásában azáltal, hogy kiválasztja a legjobb algoritmust a cél GPU-n. A CUDA adatfolyamok lehetővé teszik a modellek párhuzamos futtatását, hogy maximalizálják a GPU kihasználtságát a legjobb teljesítmény érdekében. Végül, de nem utolsósorban, a kvantálási technika teljes mértékben ki tudja használni a Tensor magok vegyes pontosságú gyorsítását a modell FP32, TF32, FP16 és INT8 alatti futtatásához a legjobb következtetési teljesítmény elérése érdekében.

Triton a SageMaker tárhelyén

SageMaker hosting A szolgáltatások a SageMaker funkcióinak készletét jelentik, amelyek célja a modellek telepítésének és kiszolgálásának megkönnyítése. Számos lehetőséget kínál az ML-modellek könnyű üzembe helyezéséhez, automatikus méretezéséhez, figyeléséhez és optimalizálásához, a különböző felhasználási esetekre szabva. Ez azt jelenti, hogy a telepítéseket minden típusú használati mintára optimalizálhatja, a tartós és mindig elérhető kiszolgáló nélküli opciókkal az átmeneti, hosszú távú vagy kötegelt következtetési igényekig.

A SageMaker hosting ernyője alatt található a SageMaker következtetést leíró Deep Learning Container (DLC) készlet is, amelyek előre csomagolva a megfelelő kiszolgálómodell-szoftverrel a megfelelő támogatott ML keretrendszerhez tartoznak. Ez lehetővé teszi, hogy nagy következtetési teljesítményt érjen el modellkiszolgáló-beállítás nélkül, ami gyakran a modelltelepítés legösszetettebb technikai aspektusa, és általában nem része az adatkutatók készségeinek. A Triton következtetési szerver most van elérhető a SageMaker Deep Learning tárolókon (DLC).

A lehetőségek széles skálája, a modularitás és a különféle kiszolgálási keretrendszerek egyszerű használata teszi a SageMaker-t és a Tritont erőteljes párosításra.

SageMaker Inference Recommender a benchmarking teszteredményekhez

A SageMaker Inference Recommender programot használjuk kísérleteink futtatásához. A SageMaker Inference Recommender kétféle feladatot kínál: alapértelmezett és haladó, amint azt a következő ábra mutatja.

Az alapértelmezett feladat ajánlásokat ad a példánytípusokra, csak a modell és egy minta hasznos terhelése alapján. A példajavaslatokon kívül a szolgáltatás teljesítménynövelő futásidejű paramétereket is kínál. Az alapértelmezett feladat ajánlásai a példánykeresés szűkítésére szolgálnak. Egyes esetekben ez lehet a példánycsalád, másokban pedig az adott példánytípusok. Az alapértelmezett job eredményei ezután betáplálódnak a speciális jobba.

A fejlett feladat több vezérlőelemet kínál a teljesítmény további finomhangolásához. Ezek a vezérlők a valós környezeti és termelési követelményeket szimulálják. E vezérlőelemek közé tartozik a forgalmi minta, amelynek célja a referenciaértékek kérési mintázata. A forgalmi minta több fázisának használatával felhajtókat vagy egyenletes forgalmat állíthat be. Például egy InitialNumberOfUsers az 1 SpawnRate 1, és DurationInSeconds 600-ból 10 perces rámpaforgalmat eredményezhet 1 egyidejű felhasználóval az elején és 10 a végén. Ezenkívül a kezelőszerveken MaxInvocations és a ModelLatencyThresholds állítsa be a termelési küszöböt, így ha valamelyik küszöböt túllépik, a benchmarking leáll.

Végül, ajánlási mérőszámok tartalmazza az átviteli sebességet, a maximális átviteli késleltetést és a következtetésenkénti költséget, így ezek könnyen összehasonlíthatók.

A SageMaker Inference Recommender speciális feladattípusát használjuk kísérleteink futtatásához, hogy további irányítást szerezzünk a forgalmi minták felett, és finomhangoljuk a kiszolgáló tároló konfigurációját.

Kísérlet beállítása

A SageMaker Inference Recommender egyéni terhelési teszt funkcióját használjuk a használati esetünkben felvázolt NLP-profil összehasonlítására. Először a következő előfeltételeket határozzuk meg az NLP modellhez és az ML feladathoz. A SageMaker Inference Recommender ezeket az információkat használja fel arra, hogy következtetési Docker-képet vonjon le Amazon Elastic Container Registry (Amazon ECR), és regisztrálja a modellt a SageMaker modellnyilvántartásba.

A SageMaker Inference Recommender forgalmi minta-konfigurációi lehetővé teszik, hogy különböző fázisokat határozzunk meg az egyéni terhelési teszthez. A terhelési teszt két kezdeti felhasználóval indul, és minden percben két új felhasználót generál, összesen 25 percig (1500 másodpercig), amint azt a következő kód mutatja:

"TrafficPattern": { "TrafficType": "PHASES", "Phases": [ { "InitialNumberOfUsers": 2, "SpawnRate": 2, "DurationInSeconds": 1500 }, ],
}

Kísérletezzük ugyanazt a modellt két különböző állapotban terhelési teszteléssel. A PyTorch-alapú kísérletek a szabványos, változatlan PyTorch-modellt használják. A TensorRT-alapú kísérletekhez a PyTorch modellt előzőleg TensorRT motorrá konvertáljuk.

Ezen a két modellen a teljesítményoptimalizálási funkciók különböző kombinációit alkalmazzuk, amelyeket az alábbi táblázatban foglalunk össze.

Vizsgálati eredmények és megfigyelések

Terhelési teszteket végeztünk három példánytípuson ugyanazon a g4dn családon belül: ml.g4dn.xlarge, ml.g4dn.2xlarge és ml.g4dn.12xlarge. Minden g4dn-példánytípus hozzáfér az NVIDIA T4 Tensor Core GPU-khoz és a 2. generációs Intel Cascade Lake processzorokhoz. A példánytípusok megválasztásának logikája az volt, hogy legyen egy példány csak egy GPU-val, valamint egy több GPU-hoz való hozzáféréssel rendelkező példány – az ml.g4dn.12xlarge esetén négy. Ezenkívül azt akartuk tesztelni, hogy a példány vCPU-kapacitásának növelése egyetlen rendelkezésre álló GPU-val javítja-e a költség-teljesítmény arányt.

Először nézzük meg az egyéni optimalizálás gyorsítását. A következő grafikon azt mutatja, hogy a TensorRT optimalizálás 50%-kal csökkenti a modell késleltetését a PyTorch natívhoz képest az ml.g4dn.xlarge példányon. Ez a várakozási idő csökkenése több mint háromszorosára nő az ml.g4dn.12xlarge több GPU-s példányokon. Mindeközben a 30%-os áteresztőképesség-javulás mindkét esetben konzisztens, ami jobb költséghatékonyságot eredményez a TensorRT optimalizálás alkalmazása után.

A dinamikus kötegeléssel közel kétszeres átviteli javulást érhetünk el, ugyanazt a hardverarchitektúrát használva az ml.g2dn.xlarge, ml.g4dn.4xlarge és ml.g2dn.4xlarge összes kísérleti példányán, észrevehető késleltetésnövekedés nélkül.

Hasonlóképpen, a párhuzamos modellvégrehajtás lehetővé teszi számunkra, hogy körülbelül 3-4-szeres teljesítménynövekedést érjünk el az ml.g4dn.xlarge példány GPU-kihasználásának maximalizálásával, és körülbelül 2-szeres javulás mind az ml.g4dn.2xlarge példányon, mind a több GPU-s ml példányon. g4dn.12xlarge.. Ez az átviteli sebességnövekedés a késleltetési idő túlterhelése nélkül történik.

Még jobb, hogy ezeket az optimalizálásokat integrálhatjuk a legjobb teljesítmény elérése érdekében a hardvererőforrások legteljesebb kihasználásával. Az alábbi táblázat és grafikonok összefoglalják a kísérleteink során kapott eredményeket.

[1] A fenti táblázatban szereplő kezdeti példányszám az automatikus skálázási házirenddel együtt használandó példányok javasolt száma a munkaterheléshez szükséges átviteli sebesség és várakozási idő fenntartása érdekében.

[2] Az óránkénti költség a fenti táblázatban a példánytípus kezdeti példányszáma és ára alapján kerül kiszámításra.

Az eredmények többnyire azt a hatást igazolják, amelyet a különböző teljesítményoptimalizálási funkcióktól vártak:

• A TensorRT-összeállítás rendelkezik a legmegbízhatóbb hatással az összes példánytípusra. A percenkénti tranzakciók száma példányonként 30–35%-kal nőtt, a költségek következetes, körülbelül 25%-os csökkenése mellett a TensorRT motor teljesítményéhez képest az alapértelmezett PyTorch BERT (pt-base). A TensorRT motor megnövekedett teljesítményét a többi tesztelt teljesítmény-hangolási funkció egészíti ki és használja ki.
• Két modell betöltése minden GPU-ra (példánycsoport) szinte szigorúan megduplázta az összes mért mutatót. A percenkénti hívások száma körülbelül 80–90%-kal nőtt, ami 50%-os költségcsökkenést eredményezett, majdnem mintha két GPU-t használnánk. Valójában, amazonfelhőóra A g4dn.2xlarge-n végzett kísérleteink mérőszámai (mint például) megerősítik, hogy a CPU és a GPU kihasználtsága is megduplázódik, ha két modellből álló példánycsoportot konfigurálunk.

További teljesítmény- és költségoptimalizálási tippek

Az ebben a bejegyzésben bemutatott benchmark csak megkarcolta a lehetséges funkciók és technikák felszínét, amelyeket a Tritonnal a következtetési teljesítmény javítására használhat. Ezek az adat-előfeldolgozási technikáktól, például a bináris rakományok küldése a modellkiszolgálóra vagy a nagyobb kötegekkel rendelkező rakományok, a natív Triton-szolgáltatásokig, például a következőkig terjednek:

• Modell bemelegítés, amely megakadályozza a kezdeti, lassú következtetési kéréseket azáltal, hogy teljesen inicializálja a modellt az első következtetési kérelem beérkezése előtt.
• Válasz gyorsítótár, amely gyorsítótárazza az ismételt kéréseket.
• Modell összeállítás, amely lehetővé teszi egy vagy több modellből álló csővezeték létrehozását, valamint a bemeneti és kimeneti tenzorok összekapcsolását a modellek között. Ez lehetőséget ad arra, hogy az egyes kérések feldolgozási folyamatához elő- és utófeldolgozási lépéseket, vagy akár más modellekkel való következtetéseket adjunk.

Várjuk, hogy egy jövőbeni bejegyzésben teszteljük és összehasonlítjuk ezeket a technikákat és funkciókat, úgyhogy maradjon velünk!

Következtetés

Ebben a bejegyzésben megvizsgáltunk néhány olyan paramétert, amelyek segítségével maximalizálhatja a SageMaker valós idejű végpontja teljesítményét PyTorch BERT modellek Triton Inference Server szolgáltatással történő kiszolgálásához. A SageMaker Inference Recommender segítségével végeztük el a benchmarking teszteket a paraméterek finomhangolásához. Ezek a paraméterek lényegében a TensorRT-alapú modelloptimalizáláshoz kapcsolódnak, ami közel 50%-os válaszidő-javulást eredményez a nem optimalizált verzióhoz képest. Ezenkívül a modellek egyidejű futtatása és a Triton dinamikus kötegelése csaknem 70%-os átviteli sebességnövekedést eredményezett. Ezen paraméterek finomhangolása a következtetési költségek általános csökkentését is eredményezte.

A helyes értékek meghatározásának legjobb módja a kísérletezés. A teljesítményhangolás és -optimalizálás empirikus ismereteinek felépítéséhez azonban megfigyelheti a különböző Tritonnal kapcsolatos paraméterek kombinációit és azok teljesítményre gyakorolt ​​hatását az ML modelleken és a SageMaker ML példányokon.

A SageMaker olyan eszközöket biztosít, amelyekkel az ML életciklusának minden szakaszában eltávolítható a differenciálatlan nehéz teher, megkönnyítve ezzel a gyors kísérletezést és feltárást, amely a modellbevezetések teljes optimalizálásához szükséges.

A terhelési teszteléshez és üzembe helyezéshez használt notebook itt található GitHub. Frissítheti a Triton konfigurációit és a SageMaker Inference Recommender beállításait, hogy azok a legjobban illeszkedjenek az Ön használati esetéhez, így költséghatékony és legjobban teljesítő következtetési munkaterheléseket érhet el.

A szerzőkről

Vikram Elango AI/ML Specialist Solutions Architect az Amazon Web Servicesnél, Virginia államban, USA-ban. A Vikram a pénzügyi és biztosítási ágazat ügyfeleit tervezéssel, vezető szereppel segíti a gépi tanulási alkalmazások nagyszabású létrehozásában és üzembe helyezésében. Jelenleg a természetes nyelvi feldolgozásra, a felelős AI-re, a következtetések optimalizálására és az ML méretezésére összpontosít a vállalaton belül. Szabadidejében szeret utazni, kirándulni, főzni és kempingezni családjával.

João Moura AI/ML Specialist Solutions Architect az Amazon Web Servicesnél. Leginkább az NLP-használati esetekre összpontosít, és segít ügyfeleinek a Deep Learning modell képzésének és bevezetésének optimalizálásában. Emellett aktív támogatója az alacsony kódú ML megoldásoknak és az ML-re specializált hardvereknek.

Mohan Gandhi az AWS vezető szoftvermérnöke. Az elmúlt 9 évben az AWS-nél dolgozott, és különféle AWS-szolgáltatásokon dolgozott, mint például az EMR, az EFA és az RDS az Outposts-on. Jelenleg a SageMaker Inference Experience fejlesztésére összpontosít. Szabadidejében szeret túrázni és maratont futni.

Dhawal Patel az AWS vezető gépi tanulási építésze. Az elosztott számítástechnikával és a mesterséges intelligenciával kapcsolatos problémákon a nagyvállalatoktól a közepes méretű induló vállalkozásokig szervezetekkel dolgozott együtt. A mély tanulásra összpontosít, beleértve az NLP és a Computer Vision tartományokat. Segít az ügyfeleknek abban, hogy a SageMaker-en nagy teljesítményű modellkövetkeztetést érjenek el.

Santosh Bhavani az Amazon SageMaker Elastic Inference csapatának vezető műszaki termékmenedzsere. Arra összpontosít, hogy segítse a SageMaker-ügyfeleket a modellkövetkeztetés és a telepítés felgyorsításában. Szabadidejében szeret utazni, teniszezni, és sok Pu'er teát iszik.

Jiahong Liu az NVIDIA Cloud Service Provider csapatának megoldástervezője. Segíti az ügyfeleket a gépi tanulási és mesterséges intelligencia-megoldások elfogadásában, amelyek az NVIDIA gyorsított számítástechnikáját használják ki a képzési és következtetési kihívások megoldására. Szabadidejében szereti az origamit, a barkácsprojekteket és a kosárlabdát.

• Coinsmart. Európa legjobb Bitcoin- és kriptográfiai tőzsdéje.
• Platoblockchain. Web3 metaverzum intelligencia. Felerősített tudás. SZABAD HOZZÁFÉRÉS.
• CryptoHawk. Altcoin radar. Ingyenes próbaverzió.
• Source: https://aws.amazon.com/blogs/machine-learning/achieve-hyperscale-performance-for-model-serving-using-nvidia-triton-inference-server-on-amazon-sagemaker/