How To Scale Machine Learning Inference For Multi-tenant SaaS Use Cases

Újra kiadta Platón

Követő: 0

Ezt a bejegyzést Sowmya Manusanival, a Zendesk Sr. Staff Machine Learning Engineerével közösen írták

Zendesk egy SaaS-cég, amely támogatási, értékesítési és ügyfél-elköteleződési szoftvereket készít mindenki számára, az egyszerűség alapja. Világszerte több mint 170,000 XNUMX vállalatot tesz lehetővé, hogy hatékonyan szolgálja ki több száz millió ügyfelét. A Zendcaesk gépi tanulási csapata felelős azért, hogy az ügyfélélményt nyújtó csapatokat a legjobb teljesítményük elérése érdekében javítsa. Az adatok és az emberek erejét kombinálva a Zendesk intelligens termékeket kínál, amelyek a kézi munka automatizálásával termelékenyebbé teszik ügyfeleit.

A Zendesk 2015 óta gyárt ML termékeket, beleértve Válasz Bot, Elégedettség-előrejelzés, Tartalmi jelek, Javasolt makrók, és még sok más. Az elmúlt néhány évben, a mély tanulással, különösen az NLP-ben, sok lehetőséget láttak a munkafolyamatok automatizálására és az ügynökök támogatására ügyfeleik Zendesk megoldásaival való támogatásában. A Zendesk jelenleg a TensorFlow-t és a PyTorch-ot használja a mély tanulási modellek felépítéséhez.

Az olyan ügyfelek, mint a Zendesk, az Amazon Web Services (AWS) szolgáltatáson keresztül sikeres, nagyszabású szoftvereket építettek ki szolgáltatásként (SaaS). A SaaS sikeres üzleti modelljének kulcsfontosságú mozgatórugója a több bérlés alkalmazásának képessége az alkalmazásban és az infrastruktúrában. Ez költség- és működési hatékonyságot tesz lehetővé, mivel az alkalmazást csak egyszer kell elkészíteni, de többször használható, és az infrastruktúra megosztható. Látjuk, hogy sok ügyfél biztonságos, költséghatékony, több bérlős rendszert épít AWS-re a verem minden rétegében, a számításoktól, tárolástól, adatbázistól egészen a hálózatépítésig, és most azt látjuk, hogy az ügyfeleknek alkalmazniuk kell ezt a gépi tanulásban (ML). ).

Nehéz kompromisszum létrehozása a modell újrafelhasználása és a hiper-személyre szabás között

A SaaS-vállalkozások többbérleti szerződése általában azt jelenti, hogy egyetlen alkalmazást több felhasználó (SaaS-ügyfelek) használ fel újra. Ez költséghatékonyságot eredményez, és csökkenti a működési költségeket. A gépi tanulási modelleket azonban időnként nagyfokú specifikusságra (hiperszemélyre szabottan) kell személyre szabni a pontos előrejelzések készítéséhez. Ez azt jelenti, hogy az „egyszer építeni, többször használni” SaaS-paradigma nem mindig alkalmazható az ML-re, ha a modellek meghatározottak. Vegyük például az ügyfélszolgálati platformok használati esetét. A felhasználók által a támogatási jegyben feltüntetett nyelv attól függően változik, hogy utazási részesedésről („túl sokáig tartott az utazás”) vagy ruhavásárlási problémáról („elszíneződés mosáskor”) van-e szó. Ebben a használati esetben a legjobb helyreállítási művelet előrejelzésének pontosságának javítása szükségessé teheti egy természetes nyelvi feldolgozási (NLP) modell betanítását egy üzleti tartományra vagy iparági vertikumra jellemző adatkészletre. A Zendesk pontosan ezzel a kihívással néz szembe, amikor az ML-t próbálja kihasználni megoldásaiban. Több ezer nagymértékben testreszabott ML-modellt kellett létrehozniuk, mindegyiket egy-egy ügyfélre szabva. A több ezer modell bevezetésével kapcsolatos kihívás költséghatékony megoldása érdekében a Zendesk az Amazon SageMakerhez fordult.

Ebben a bejegyzésben bemutatjuk, hogyan használhatod a következő néhány új funkciót Amazon SageMaker, egy teljesen felügyelt gépi tanulási szolgáltatás, több bérlős ML következtetési képesség kiépítéséhez. Megosztunk egy valós példát is arra vonatkozóan, hogy a Zendesk sikeresen elérte ugyanazt az eredményt azáltal, hogy boldog médiumot telepített az ML modelljeikben a hiper-személyre szabás támogatása és az infrastruktúra költséghatékony, megosztott használata között a SageMaker többmodell végpontjaival ( MME).

SageMaker többmodell végpontok

A SageMaker többmodelles végpontjai lehetővé teszik több modell telepítését egyetlen következtetési végpont mögé, amely egy vagy több példányt tartalmazhat. Minden példányt több modell betöltésére és kiszolgálására terveztek, egészen a memória- és CPU-kapacitásig. Ezzel az architektúrával a SaaS-üzletág megtörheti a több modell üzemeltetésének lineárisan növekvő költségeit, és elérheti az infrastruktúra újrafelhasználását, amely összhangban van az alkalmazásveremben máshol alkalmazott többbérleti modellel.

A következő diagram egy SageMaker többmodell végpont architektúráját mutatja be.

A SageMaker többmodell végpontja dinamikusan tölti be a modelleket innen Amazon egyszerű tárolási szolgáltatás (Amazon S3) meghívásakor, ahelyett, hogy a végpont első létrehozásakor letöltené az összes modellt. Ennek eredményeként egy modell kezdeti meghívása magasabb következtetési késleltetést láthat, mint a későbbi következtetések, amelyek alacsony késleltetéssel fejeződnek be. Ha a modell meghívásakor már be van töltve a tárolóba, akkor a letöltési lépés kimarad, és a modell alacsony késleltetéssel adja vissza a következtetéseket. Tegyük fel például, hogy van egy modellje, amelyet naponta csak néhány alkalommal használnak. Igény szerint automatikusan betöltődik, miközben a gyakran használt modellek megmaradnak a memóriában, és következetesen alacsony késleltetéssel hívódnak meg.

Nézzük meg közelebbről, hogyan használta a Zendesk a SageMaker MME-t a költséghatékony, nagy léptékű ML-telepítés eléréséhez a Javasolt makrók ML funkciójával.

Miért épített a Zendesk hiperszemélyre szabott modelleket?

A Zendesk ügyfelei világszerte elterjedtek különböző iparági vertikumokban, eltérő támogatási jegy szemantikával. Ezért ügyfeleik legjobb kiszolgálása érdekében gyakran személyre szabott modelleket kell készíteniük, amelyek az ügyfél-specifikus támogatási jegyek adataira vannak kiképezve, hogy helyesen azonosítsák a szándékot, a makrókat és egyebeket.

2021 októberében kiadtak egy új NLP ML-funkciót, a Javasolt makrókat, amely makrókat (előre meghatározott műveleteket) ajánl több ezer ügyfél-specifikus modell-előrejelzés alapján. A Zendesk ML csapata egy TensorFlow alapú NLP osztályozó modellt épített, amelyet a jegytartalom és a makrók ügyfelenkénti korábbi történetéből oktattak. Ezekkel a modellekkel a makró előrejelzése javasolt, amikor egy ügyintéző megtekinti a jegyet (amint az a következő képernyőképen látható), ami segít az ügynöknek az ügyfelek gyors kiszolgálásában. Mivel a makrók az ügyfelekre jellemzőek, a Zendesknek ügyfélspecifikus modellekre van szüksége a pontos előrejelzések kiszolgálásához.

A Zendesk Javasolt makrók burkolata alatt

A javasolt makrók NLP-alapú neurális hálók, amelyek körülbelül 7–15 MB méretűek. A fő kihívás az ilyen modellek ezrei gyártásba helyezése költséghatékony, megbízható és méretezhető megoldásokkal.

Mindegyik modellnek más-más forgalmi mintázata van, legalább két kéréssel másodpercenként, és a csúcsértéke másodpercenként több száz, és naponta több millió előrejelzést szolgál ki, körülbelül 100 ezredmásodperces modell késleltetéssel, ha a modell elérhető a memóriában. A SageMaker-végpontok több AWS-régióban vannak üzembe helyezve, és végpontonként percenként több ezer kérést szolgálnak ki.

Azáltal, hogy több modellt egyetlen végponton tud tárolni, a SageMaker segített a Zendesknek csökkenteni az üzembe helyezési többletköltségeket, és költséghatékony megoldást hozott létre, összehasonlítva azzal, hogy ügyfelenként egyetlen modelles végpontot telepített. A kompromisszum itt a modellenkénti menedzsment kevésbé szabályozható; azonban ez az a terület, ahol a Zendesk együttműködik az AWS-szel a többmodelles végpontok fejlesztése érdekében.

A SageMaker egyik multimodell funkciója a modellek lusta betöltése, vagyis a modellek az első meghívásra kerülnek a memóriába. Ez a memóriahasználat optimalizálását szolgálja; azonban az első terhelésnél megugrik a válaszidő, ami hidegindítási problémának tekinthető. A javasolt makrók számára ez kihívást jelentett; A Zendesk azonban túljutott ezen azáltal, hogy a SageMaker végpont-kiépítésen felül egy előbetöltési funkciót implementált, hogy a modelleket az éles forgalom kiszolgálása előtt betöltse a memóriába. Másodszor, az MME kiüríti a ritkán használt modelleket a memóriából, így annak érdekében, hogy az összes modellen egyenletesen alacsony késleltetést érjen el, és elkerülje, hogy a „zajos szomszédok” hatással legyenek a többi kevésbé aktív modellre, a Zendesk együttműködik az AWS-szel, hogy új funkciókat adjon hozzá, amelyekről a bejegyzés későbbi részében lesz szó. explicitebb modellenkénti menedzsment. Ezen túlmenően átmeneti megoldásként a Zendesk megfelelő méretűre szabta az MME flottát, hogy minimalizálja a túl sok modell kirakodását. Ezzel a Zendesk alacsony késleltetéssel, körülbelül 100 ezredmásodperccel tud előrejelzéseket kiszolgálni minden ügyfelének, és így is 90%-os költségmegtakarítást ér el a dedikált végpontokhoz képest.

Az MME megfelelő méretezésénél a Zendesk a terhelési tesztelés során azt figyelte meg, hogy az MME mögött nagyobb számú kisebb példány (vízszintes skálázás torzítása) jobb választás, mint kevesebb nagyobb memóriapéldány (függőleges méretezés). A Zendesk megfigyelte, hogy a túl sok modell (az esetükben 500 TensorFlow modellen túl) tárolása egyetlen nagy memóriapéldányra nem működik jól, mert a memória nem az egyetlen erőforrás egy példányon, amely szűk keresztmetszetet jelenthet. Pontosabban azt figyelték meg, hogy a TensorFlow modellenként több szálat (az összes példány vCPU-t) hozott létre, így több mint 3 modell betöltése egyetlen példányra a kernelszintű korlátok megsértését okozta az egy példányon létrehozható szálak maximális számában. Egy másik probléma a kevesebb, nagyobb példányok használatával kapcsolatban akkor fordult elő, amikor a Zendesk szabályozást tapasztalt (biztonsági mechanizmusként) néhány példányon az MME mögött, mivel az egyedi modell másodpercenkénti hívási sebessége meghaladta a Több modell szerver (MMS) az egyetlen példányon biztonságosan kezelhető anélkül, hogy a példány elbarnulna. Ez egy másik probléma volt, amelyet több és kisebb példány használatával sikerült megoldani.

A megfigyelhetőség szempontjából, ami minden termelési alkalmazás döntő összetevője, amazonfelhőóra Az olyan mérőszámok, mint a meghívások, a CPU, a memória kihasználtsága és a több modellre jellemző mérőszámok, mint például a memóriába betöltött modellek, a modell betöltési ideje, a modell betöltési várakozási ideje és a modell gyorsítótár találatai, tájékoztató jellegűek. Pontosabban, a modell késleltetésének lebontása segített a Zendesknek megérteni a hidegindítási problémát és annak hatását.

Az MME automatikus skálázás burkolata alatt

Az egyes többmodell-végpontok mögött modellek tárolási példányai találhatók, amint azt a következő ábra mutatja. Ezek a példányok több modellt töltenek be a memóriába és a memóriából a modellek forgalmi mintái alapján.

A SageMaker továbbra is a modellhez tartozó következtetési kérelmeket arra a példányra irányítja, ahol a modell már be van töltve, így a kérések a gyorsítótárazott modellmásolatból kerülnek kiszolgálásra (lásd a következő diagramot, amely az első előrejelzési kérés és a gyorsítótárazott előrejelzési kérelem kérési útvonalát mutatja pálya). Ha azonban a modell sok hívási kérelmet kap, és a többmodell végponthoz további példányok is tartoznak, a SageMaker egyes kéréseket egy másik példányhoz irányít a növekedéshez. A SageMaker automatizált modellméretezésének előnyeinek kihasználásához győződjön meg arról, hogy rendelkezik példány automatikus skálázás beállítása további példánykapacitás biztosítására. Állítsa be a végpont-szintű skálázási szabályzatot egyéni paraméterekkel vagy percenkénti hívásokkal (ajánlott), hogy további példányokat adjon a végpontflottához.

Az MME-nek leginkább megfelelő esetek

A SageMaker többmodelles végpontjai kiválóan alkalmasak nagyszámú hasonló modell fogadására, amelyeket megosztott kiszolgálókonténeren keresztül is kiszolgálhat, és nem kell egyszerre hozzáférnie az összes modellhez. Az MME olyan modellekhez a legalkalmasabb, amelyek mérete és hívási késleltetése hasonló. A modell méretének némi eltérése elfogadható; Például a Zendesk modelljei 10 és 50 Mb között vannak, ami jól működik, de a 10-szeres, 50-szeres vagy 100-szoros méretváltozatok nem megfelelőek. A nagyobb modellek nagyobb számú be- és kirakodást okozhatnak a kisebb modelleknél, hogy elegendő memóriaterületet tudjunk biztosítani, ami a végponton megnövekedett késleltetést eredményezhet. A nagyobb modellek teljesítményjellemzőiben mutatkozó különbségek az erőforrásokat, például a CPU-t is egyenlőtlenül fogyaszthatják, ami hatással lehet a példány többi modelljére.

Az MME-t olyan modellek társhosztolására is tervezték, amelyek ugyanazt az ML keretrendszert használják, mivel a megosztott tárolót használják több modell betöltésére. Ezért, ha a modellflottában vegyes ML-keretrendszerek vannak (például PyTorch és TensorFlow), akkor a SageMaker dedikált végpontjai vagy a többtárolós hosting jobb választás. Végül, az MME alkalmas olyan alkalmazásokra, amelyek elviselik az alkalmankénti hidegindítási késleltetést, mivel a ritkán használt modellek tehermentesíthetők a gyakran meghívott modellek javára. Ha sok ritkán elérhető modellje van, egy többmodellből álló végpont hatékonyan tudja kiszolgálni ezt a forgalmat, és jelentős költségmegtakarítást tesz lehetővé.

Összegzésként

Ebből a bejegyzésből megtudhatta, hogy a SaaS és a több bérlés hogyan kapcsolódik az ML-hez, és hogyan teszik lehetővé a SageMaker többmodell végpontjai a több bérlést és a költséghatékonyságot az ML következtetésekhez. Megismerhette a Zendesk ügyfelenkénti ML-modellek többszörös bérelt felhasználását, és azt, hogy a SageMaker MME-ben több ezer ML-modellt tároltak a Javasolt makrók funkcióhoz, és 90%-os költségmegtakarítást értek el a következtetések során a dedikált végpontokhoz képest. A hiper-személyre szabott használati esetek több ezer ML modellt igényelhetnek, és az MME költséghatékony választás erre a felhasználási esetre. Továbbra is továbbfejlesztjük az MME-t, hogy lehetővé tegyük alacsony késleltetésű modellek tárolását, és részletesebb vezérlőkkel minden egyes személyre szabott modellhez. Az MME használatának megkezdéséhez lásd Több modellt is tárolhat egy tárolóban egy végpont mögött.

A szerzőkről

Syed Jaffry Sr. Solutions Architect az AWS-nél. Számos vállalattal dolgozik, a közepes méretű szervezetektől a nagyvállalatokig, a pénzügyi szolgáltatásoktól az ISV-kig, hogy segítsen nekik biztonságos, rugalmas, méretezhető és nagy teljesítményű alkalmazásokat felépíteni és működtetni a felhőben.

Sowmya Manusani a Zendesk vezető beosztású gépi tanulási mérnöke. Az NLP-alapú gépi tanulási funkciók gyártási folyamatán dolgozik, amelyek az ügynök termelékenységének javítására összpontosítanak több ezer Zendesk Enterprise-ügyfél számára. Tapasztalata van több ezer személyre szabott modell automatizált képzési folyamatainak felépítésében, valamint biztonságos, rugalmas, méretezhető és nagy teljesítményű alkalmazások segítségével történő kiszolgálásában. Szabadidejében szeret rejtvényeket fejteni és kipróbálni a festést.

Saurabh Trikande az Amazon SageMaker Inference vezető termékmenedzsere. Szenvedélye az ügyfelekkel való együttműködés és a gépi tanulás hozzáférhetőbbé tétele. Szabadidejében Saurabh szeret túrázni, innovatív technológiákat tanulni, követi a TechCrunch-ot és a családjával tölt időt.

Deepti Ragha az Amazon SageMaker csapat szoftverfejlesztő mérnöke. Jelenlegi munkája a gépi tanulási modellek hatékony tárolására szolgáló funkciók létrehozására összpontosít. Szabadidejében szeret utazni, túrázni és növényt termeszteni.