Hogyan csökkentette a Veriff 80%-kal a telepítési időt az Amazon SageMaker többmodell végpontjaival | Amazon webszolgáltatások

Veriff személyazonosság-ellenőrzési platform partnere innovatív növekedés-vezérelt szervezetek számára, beleértve a pénzügyi szolgáltatások, a FinTech, a kriptográfia, a játék, a mobilitás és az online piacterek úttörőit. Fejlett technológiát kínálnak, amely ötvözi a mesterséges intelligencia által hajtott automatizálást az emberi visszajelzésekkel, mély betekintéssel és szakértelemmel.

A Veriff olyan jól bevált infrastruktúrát biztosít, amely lehetővé teszi ügyfelei számára, hogy megbízzanak felhasználóik kilétében és személyes tulajdonságaiban az ügyfélútjuk minden fontos pillanatában. A Veriffben olyan ügyfelek bíznak meg, mint a Bolt, a Deel, a Monese, a Starship, a Super Awesome, a Trustpilot és a Wise.

AI-alapú megoldásként a Veriffnek több tucat gépi tanulási (ML) modellt kell létrehoznia és futtatnia költséghatékony módon. Ezek a modellek a könnyű faalapú modellektől a mély tanulási számítógépes látásmodellekig terjednek, amelyeknek GPU-kon kell futniuk az alacsony késleltetés elérése és a felhasználói élmény javítása érdekében. A Veriff jelenleg is több terméket ad kínálatához, egy hiperszemélyre szabott megoldást célozva meg ügyfelei számára. A különböző modellek különböző ügyfelek számára történő kiszolgálása növeli a méretezhető modellszolgáltatási megoldás szükségességét.

Ebben a bejegyzésben bemutatjuk, hogyan szabványosította a Veriff a modell-telepítési munkafolyamatát Amazon SageMaker, csökkentve a költségeket és a fejlesztési időt.

Infrastruktúra és fejlesztési kihívások

A Veriff háttérarchitektúrája mikroszolgáltatási mintán alapul, és a szolgáltatások különböző, AWS-infrastruktúrán tárolt Kubernetes-fürtökön futnak. Ezt a megközelítést kezdetben minden vállalati szolgáltatásnál alkalmazták, beleértve a drága számítógépes látásmódos ML modelleket futtató mikroszolgáltatásokat is.

E modellek némelyikét GPU-példányokon kellett telepíteni. A GPU-val támogatott példánytípusok viszonylag magasabb költségének tudatában a Veriff kifejlesztett a egyedi megoldás a Kubernetesen, hogy megosszák egy adott GPU erőforrásait a különböző szolgáltatásreplikák között. Egyetlen GPU általában elegendő VRAM-mal rendelkezik ahhoz, hogy több Veriff számítógépes látásmodelljét tárolja a memóriában.

Bár a megoldás csökkentette a GPU-költségeket, azzal a megkötéssel is járt, hogy az adatkutatóknak előre jelezniük kellett, mennyi GPU-memóriát igényel a modell. Ezenkívül a DevOps-t a GPU-példányok manuális kiépítése terhelte a keresleti mintáknak megfelelően. Ez működési többletköltséget és a példányok túlzott kiépítését okozta, ami szuboptimális költségprofilt eredményezett.

A GPU-kiépítésen kívül ez a beállítás azt is megkövetelte az adattudósoktól, hogy minden modellhez készítsenek egy REST API burkolóanyagot, amelyre szükség volt ahhoz, hogy általános interfészt biztosítsanak a többi vállalati szolgáltatás számára, és beágyazza a modelladatok elő- és utófeldolgozását. Ezekhez az API-khoz gyártási szintű kódra volt szükség, ami kihívást jelentett az adatkutatók számára a modellek előállításában.

A Veriff adattudományi platform csapata alternatív módszereket keresett ehhez a megközelítéshez. A fő cél az volt, hogy egyszerűbb telepítési folyamatok biztosításával támogassák a vállalat adattudósait a kutatásról a termelésre való jobb átmenetben. A másodlagos cél a GPU-példányok kiépítésének működési költségeinek csökkentése volt.

Megoldás áttekintése

A Veriffnek új megoldásra volt szüksége, amely két problémát oldott meg:

• Könnyedén építhet REST API burkolókat az ML modellek köré
• Engedélyezze a kiépített GPU-példánykapacitás optimális kezelését, és ha lehetséges, automatikusan

Végül az ML platform csapata egyetértett a használat mellett Sagemaker többmodell végpontjai (MME). Ezt a döntést az MME NVIDIA-támogatása indokolta Triton következtetési szerver (egy ML-központú szerver, amely megkönnyíti a modellek REST API-kba történő becsomagolását; a Veriff is kísérletezett már a Tritonnal), valamint a GPU-példányok automatikus skálázásának natív kezelésére való képessége egyszerű automatikus skálázási házirendekkel.

Két MME-t hoztak létre a Veriffnél, egyet színpadra, egyet pedig produkcióra. Ez a megközelítés lehetővé teszi számukra, hogy tesztelési lépéseket állomásoztatási környezetben hajtsanak végre anélkül, hogy ez befolyásolná a termelési modelleket.

SageMaker MME-k

A SageMaker egy teljesen felügyelt szolgáltatás, amely lehetővé teszi a fejlesztők és adatkutatók számára az ML modellek gyors felépítését, betanítását és üzembe helyezését. A SageMaker MME-k méretezhető és költséghatékony megoldást kínálnak nagyszámú modell telepítéséhez valós idejű következtetésekhez. Az MME-k megosztott kiszolgálótárolót és erőforrásflottát használnak, amelyek gyorsított példányokat, például GPU-kat használhatnak az összes modell tárolására. Ez csökkenti az üzemeltetési költségeket a végpontok kihasználtságának maximalizálásával az egymodell végpontok használatához képest. Csökkenti a telepítési többletköltséget is, mivel a SageMaker kezeli a modellek be- és kirakodását a memóriában, és a végpont forgalmi mintái alapján méretezi azokat. Ezenkívül az összes SageMaker valós idejű végpont a modellek kezeléséhez és figyeléséhez szükséges beépített képességekkel rendelkezik, mint pl. árnyékváltozatok, automatikus méretezés, és natív integrációval amazonfelhőóra (további információért lásd CloudWatch metrikák többmodell végpont-telepítésekhez).

Egyedi Triton együttes modellek

Számos oka volt annak, hogy a Veriff a Triton Inference Server használata mellett döntött, a főbbek a következők:

• Lehetővé teszi az adattudósok számára, hogy modellekből REST API-kat építsenek a modelltermékfájlok szabványos könyvtárformátumba rendezésével (kód nélküli megoldás).
• Kompatibilis az összes főbb AI keretrendszerrel (PyTorch, Tensorflow, XGBoost és még sok más)
• ML-specifikus alacsony szintű és szerveroptimalizálásokat biztosít, mint pl dinamikus kötegelés kérésekből

A Triton használata lehetővé teszi az adattudósok számára a modellek egyszerű üzembe helyezését, mivel csak formázott modelltárolókat kell létrehozniuk ahelyett, hogy kódot írnának a REST API-k létrehozásához (a Triton is támogatja Python modellek ha egyéni következtetési logika szükséges). Ez csökkenti a modell üzembe helyezési idejét, és több idejük marad az adatkutatóknak, hogy a bevezetés helyett a modellek építésére összpontosítsanak.

A Triton másik fontos tulajdonsága, hogy lehetővé teszi az építkezést modellegyüttesek, amelyek összeláncolt modellcsoportok. Ezeket az együtteseket úgy lehet futtatni, mintha egyetlen Triton modell lennének. A Veriff jelenleg ezt a funkciót használja az előfeldolgozási és utófeldolgozási logikák minden egyes ML-modellhez Python-modellek használatával történő üzembe helyezésére (ahogy korábban említettük), biztosítva, hogy a bemeneti adatok vagy a modell kimenete ne legyen eltérés a modellek éles üzemben történő használatakor.

A következőképpen néz ki egy tipikus Triton modell tároló ehhez a munkaterheléshez:

A model.py fájl elő- és utófeldolgozási kódot tartalmaz. A betanított modell súlyok a screen_detection_inferencer könyvtár, modell verzió alatt 1 (A modell ebben a példában ONNX formátumú, de lehet TensorFlow, PyTorch vagy más formátum is). Az együttes modell definíciója a screen_detection_pipeline könyvtár, ahol a lépések közötti bemenetek és kimenetek egy konfigurációs fájlban vannak leképezve.

A Python-modellek futtatásához szükséges további függőségek részletezése a requirements.txt fájlt, és conda-ba kell csomagolni egy Conda környezet létrehozásához (python_env.tar.gz). További információkért lásd: Python futási környezet és könyvtárak kezelése. Ezenkívül a Python-lépések konfigurációs fájljainak rá kell mutatniuk python_env.tar.gz használatával EXECUTION_ENV_PATH Irányelv.

A modell mappát ezután TAR tömöríteni kell, és át kell nevezni a használatával model_version.txt. Végül az eredmény <model_name>_<model_version>.tar.gz fájl másolásra kerül a Amazon egyszerű tárolási szolgáltatás (Amazon S3) vödör csatlakoztatva az MME-hez, lehetővé téve a SageMakernek a modell észlelését és kiszolgálását.

Modellverzió és folyamatos telepítés

Amint az előző részből kiderült, a Triton modelltároló felépítése egyszerű. A telepítéshez szükséges összes lépés végrehajtása azonban fárasztó és hibás, ha manuálisan futtatja. Ennek kiküszöbölésére a Veriff egy monorepót épített, amely tartalmazza az összes MME-ben telepítendő modellt, ahol az adattudósok Gitflow-szerű megközelítésben működnek együtt. Ez a monorepo a következő tulajdonságokkal rendelkezik:

• Használatával kezelhető Nadrág.
• A kódminőségi eszközök, például a Black és a MyPy a Pants használatával kerülnek alkalmazásra.
• Minden modellhez egységtesztek vannak definiálva, amelyek azt ellenőrzik, hogy a modell kimenete az adott modell bemenetre várt kimenet.
• A modellsúlyok a modelltárak mellett tárolódnak. Ezek a súlyok lehetnek nagy bináris fájlok, így DVC bővítmény verziószámú módon szinkronizálja őket a Git-tel.

Ez a monorepo folyamatos integrációs (CI) eszközzel van integrálva. A repóhoz vagy új modellhez való minden új push esetén a következő lépések futnak le:

1. Menjen át a kód minőségi ellenőrzésén.
2. Töltse le a modell súlyait.
3. Építsd meg a Conda környezetet.
4. Pörgessen fel egy Triton szervert a Conda környezettel, és használja fel az egységtesztekben meghatározott kérések feldolgozására.
5. A végső modell TAR fájl elkészítése (<model_name>_<model_version>.tar.gz).

Ezek a lépések biztosítják, hogy a modellek a telepítéshez szükséges minőséggel rendelkezzenek, így a repo ághoz történő minden egyes leküldéskor az eredményül kapott TAR-fájl (egy másik CI-lépésben) átmásolódik az átmeneti S3 tárolóba. Amikor a leküldések megtörténnek a fő ágban, a modellfájl átmásolásra kerül a termelési S3 tárolóba. A következő ábra ezt a CI/CD rendszert mutatja be.

Költség- és telepítési sebesség-előnyök

Az MME-k használata lehetővé teszi a Veriff számára, hogy monorepo megközelítést alkalmazzon a modellek éles üzembe helyezéséhez. Összefoglalva, a Veriff új modell-telepítési munkafolyamata a következő lépésekből áll:

1. Hozzon létre egy ágat a monorepóban az új modellel vagy modellverzióval.
2. Egységtesztek meghatározása és futtatása egy fejlesztőgépen.
3. Nyomja meg az ágat, amikor a modell készen áll az átmeneti környezetben való tesztelésre.
4. Ha a modell készen áll a termelésben való használatra, egyesítse az ágat a fővel.

Ezzel az új megoldással a modell bevezetése a Veriffnél a fejlesztési folyamat egyértelmű része. Az új modellek fejlesztési ideje 10 napról átlagosan 2 napra csökkent.

A SageMaker felügyelt infrastruktúra-kiépítési és automatikus skálázási funkciói a Veriffnek további előnyöket kínáltak. Használták a InvocationsPerInstance A CloudWatch mérőszáma a forgalmi minták szerint skálázható, így költségmegtakarítás érhető el a megbízhatóság feláldozása nélkül. A metrika küszöbértékének meghatározásához terhelési tesztet hajtottak végre az állomásoztatási végponton, hogy megtalálják a legjobb kompromisszumot a várakozási idő és a költség között.

Miután hét éles modellt telepített az MME-kbe, és elemezte a ráfordításokat, a Veriff 75%-os költségcsökkenésről számolt be a GPU-modellben az eredeti Kubernetes-alapú megoldáshoz képest. A működési költségek is csökkentek, mivel a példányok manuális kiépítésének terhe lekerült a vállalat DevOps mérnökeiről.

Következtetés

Ebben a bejegyzésben áttekintettük, hogy a Veriff miért választotta a Sagemaker MME-ket a Kubernetesen végzett önmenedzselt modelltelepítés helyett. A SageMaker átveszi a differenciálatlan nehézemelést, lehetővé téve a Veriff számára, hogy csökkentse a modellfejlesztési időt, növelje a mérnöki hatékonyságot, és drámai módon csökkentse a valós idejű következtetések költségeit, miközben fenntartja az üzleti szempontból kritikus műveletekhez szükséges teljesítményt. Végül bemutattuk a Veriff egyszerű, de hatékony modelltelepítési CI/CD folyamatát és modellverziós mechanizmusát, amely referencia implementációként használható a legjobb szoftverfejlesztési gyakorlatok és a SageMaker MME-k kombinálásához. Kódmintákat találhat a SageMaker MME-k használatával több modell hosztolásához GitHub.

---

A szerzőkről

Ricard Borràs Senior Machine Learning a Veriffnél, ahol ő vezeti az MLOps erőfeszítéseit a vállalatnál. Segít az adattudósoknak gyorsabb és jobb AI/ML termékek létrehozásában azáltal, hogy Data Science Platformot épít a vállalatnál, és számos nyílt forráskódú megoldást kombinál AWS-szolgáltatásokkal.

João Moura AI/ML Specialist Solutions Architect a spanyolországi székhelyű AWS-nél. Segíti az ügyfeleket a mélytanulási modell nagyszabású képzésében és a következtetések optimalizálásában, valamint szélesebb körben a nagyszabású ML platformok AWS-en való felépítésében.

Miguel Ferreira Sr. Solutions Architectként dolgozik az AWS-nél Helsinkiben, Finnországban. Az AI/ML egész életen át érdekelt, és több ügyfelének is segített az Amazon SageMaker integrációjában az ML munkafolyamataiba.

• 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/how-veriff-decreased-deployment-time-by-80-using-amazon-sagemaker-multi-model-endpoints/