چگونه Veriff با استفاده از نقاط پایانی چند مدل آمازون SageMaker زمان استقرار را 80٪ کاهش داد | خدمات وب آمازون

راستی یک شریک پلتفرم تأیید هویت برای سازمان‌های نوآورانه مبتنی بر رشد، از جمله پیشگامان خدمات مالی، فین‌تک، ارزهای دیجیتال، بازی، تحرک و بازارهای آنلاین است. آنها فناوری پیشرفته ای را ارائه می دهند که اتوماسیون مبتنی بر هوش مصنوعی را با بازخورد انسانی، بینش عمیق و تخصص ترکیب می کند.

Veriff یک زیرساخت اثبات شده ارائه می دهد که مشتریان خود را قادر می سازد تا به هویت و ویژگی های شخصی کاربران خود در تمام لحظات مربوطه در سفر مشتری خود اعتماد داشته باشند. Veriff مورد اعتماد مشتریانی مانند Bolt، Deel، Monese، Starship، Super Awesome، Trustpilot و Wise است.

به عنوان یک راه حل مبتنی بر هوش مصنوعی، Veriff باید ده ها مدل یادگیری ماشینی (ML) را به روشی مقرون به صرفه ایجاد و اجرا کند. این مدل‌ها از مدل‌های سبک‌وزن مبتنی بر درخت تا مدل‌های بینایی کامپیوتری با یادگیری عمیق را شامل می‌شوند که برای دستیابی به تأخیر کم و بهبود تجربه کاربر، باید روی پردازنده‌های گرافیکی اجرا شوند. Veriff همچنین در حال حاضر محصولات بیشتری را به محصولات خود اضافه می کند و راه حلی فوق شخصی را برای مشتریان خود هدف قرار می دهد. ارائه مدل های مختلف برای مشتریان مختلف نیاز به یک راه حل ارائه مدل مقیاس پذیر را افزایش می دهد.

در این پست، ما به شما نشان می‌دهیم که چگونه Veriff گردش کار استقرار مدل خود را با استفاده از آن استاندارد کرد آمازون SageMaker، کاهش هزینه ها و زمان توسعه.

چالش های زیرساخت و توسعه

معماری باطن Veriff بر اساس یک الگوی میکروسرویس است، با سرویس‌هایی که روی خوشه‌های مختلف Kubernetes اجرا می‌شوند که روی زیرساخت AWS میزبانی می‌شوند. این رویکرد در ابتدا برای تمام خدمات شرکت، از جمله ریزسرویس‌هایی که مدل‌های ML بینایی کامپیوتری گران قیمت را اجرا می‌کنند، مورد استفاده قرار گرفت.

برخی از این مدل‌ها نیاز به استقرار در نمونه‌های GPU داشتند. Veriff با آگاهی از هزینه نسبتاً بالاتر انواع نمونه های مبتنی بر GPU، راه حل سفارشی در Kubernetes برای به اشتراک گذاشتن منابع یک GPU معین بین کپی های سرویس های مختلف. یک GPU به طور معمول دارای VRAM کافی برای نگهداری چندین مدل بینایی کامپیوتری Veriff در حافظه است.

اگرچه این راه حل هزینه های GPU را کاهش داد، اما همچنین با محدودیت هایی همراه بود که دانشمندان داده باید از قبل نشان دهند که مدل آنها به چه مقدار حافظه GPU نیاز دارد. علاوه بر این، DevOps با ارائه دستی نمونه های GPU در پاسخ به الگوهای تقاضا تحت فشار قرار گرفتند. این باعث سربار عملیاتی و تامین بیش از حد نمونه‌ها شد که منجر به نمایه هزینه‌های نامناسب شد.

جدای از ارائه GPU، این تنظیم همچنین به دانشمندان داده نیاز داشت تا برای هر مدل یک REST API Wrapper بسازند، که برای ارائه یک رابط عمومی برای سایر خدمات شرکت برای مصرف، و محصور کردن پیش پردازش و پس پردازش داده های مدل مورد نیاز بود. این APIها به کد درجه تولید نیاز داشتند که تولید مدل ها را برای دانشمندان داده چالش برانگیز می کرد.

تیم پلتفرم علم داده Veriff به دنبال راه های جایگزین برای این رویکرد بود. هدف اصلی حمایت از دانشمندان داده شرکت برای انتقال بهتر از تحقیق به تولید با ارائه خطوط لوله استقرار ساده تر بود. هدف ثانویه کاهش هزینه های عملیاتی تهیه نمونه های GPU بود.

بررسی اجمالی راه حل

Veriff به یک راه حل جدید نیاز داشت که دو مشکل را حل کرد:

• به ساختن پوشش های REST API در اطراف مدل های ML به راحتی اجازه دهید
• امکان مدیریت ظرفیت نمونه GPU ارائه شده به صورت بهینه و در صورت امکان به صورت خودکار

در نهایت، تیم پلتفرم ML در تصمیم گیری برای استفاده همگرا شدند نقاط پایانی چند مدل Sagemaker (MME). این تصمیم ناشی از پشتیبانی MME از NVIDIA است سرور استنتاج تریتون (یک سرور متمرکز بر ML که بسته بندی مدل ها به عنوان REST API را آسان می کند؛ Veriff همچنین قبلاً با Triton آزمایش می کرد)، و همچنین توانایی آن برای مدیریت مقیاس خودکار نمونه های GPU از طریق سیاست های مقیاس خودکار ساده.

دو MME در Veriff ایجاد شد، یکی برای صحنه سازی و دیگری برای تولید. این رویکرد به آنها اجازه می دهد تا مراحل آزمایش را در یک محیط مرحله بندی بدون تأثیر بر مدل های تولید اجرا کنند.

SageMaker MMEs

SageMaker یک سرویس کاملاً مدیریت شده است که به توسعه دهندگان و دانشمندان داده توانایی ساخت، آموزش و استقرار سریع مدل های ML را می دهد. SageMaker MME یک راه حل مقیاس پذیر و مقرون به صرفه برای استقرار تعداد زیادی مدل برای استنتاج بلادرنگ ارائه می دهد. MMEها از یک کانتینر سرویس مشترک و ناوگانی از منابع استفاده می‌کنند که می‌توانند از نمونه‌های تسریع‌شده مانند GPU برای میزبانی همه مدل‌های شما استفاده کنند. این امر با به حداکثر رساندن استفاده از نقطه پایانی در مقایسه با استفاده از نقاط پایانی تک مدل، هزینه های میزبانی را کاهش می دهد. همچنین سربار استقرار را کاهش می دهد زیرا SageMaker بارگیری و تخلیه مدل ها را در حافظه مدیریت می کند و آنها را بر اساس الگوهای ترافیک نقطه پایانی مقیاس می کند. علاوه بر این، تمام نقاط پایانی بلادرنگ SageMaker از قابلیت‌های داخلی برای مدیریت و نظارت بر مدل‌ها، مانند انواع سایه, مقیاس بندی خودکارو ادغام بومی با CloudWatch آمازون (برای اطلاعات بیشتر مراجعه کنید معیارهای CloudWatch برای استقرار نقطه پایانی چند مدلی).

مدل های سفارشی مجموعه تریتون

دلایل مختلفی وجود داشت که چرا Veriff تصمیم گرفت از سرور استنتاج تریتون استفاده کند که مهمترین آنها عبارتند از:

• این به دانشمندان داده اجازه می‌دهد تا با مرتب کردن فایل‌های مصنوع مدل در قالب فهرست استاندارد (بدون راه‌حل کد)، APIهای REST را از مدل‌ها بسازند.
• با تمام چارچوب‌های اصلی هوش مصنوعی (PyTorch، Tensorflow، XGBoost و غیره) سازگار است.
• بهینه‌سازی‌های سطح پایین و سرور مخصوص ML مانند دسته بندی پویا از درخواست ها

استفاده از Triton به دانشمندان داده اجازه می‌دهد تا مدل‌ها را به آسانی پیاده‌سازی کنند، زیرا آنها به جای نوشتن کد برای ساختن APIهای REST، فقط نیاز به ساخت مخازن مدل‌های قالب‌بندی شده دارند (تریتون همچنین از آن پشتیبانی می‌کند. مدل های پایتون اگر منطق استنتاج سفارشی مورد نیاز است). این امر زمان استقرار مدل را کاهش می دهد و به دانشمندان داده زمان بیشتری برای تمرکز بر ساخت مدل ها به جای استقرار آنها می دهد.

یکی دیگر از ویژگی های مهم تریتون این است که به شما امکان ساخت می دهد مجموعه های مدل، که گروه هایی از مدل ها هستند که به هم زنجیر شده اند. این مجموعه‌ها را می‌توان طوری اجرا کرد که انگار یک مدل تریتون هستند. Veriff در حال حاضر از این ویژگی برای استقرار منطق پیش‌پردازش و پس پردازش با هر مدل ML با استفاده از مدل‌های پایتون (همانطور که قبلاً ذکر شد) استفاده می‌کند و اطمینان حاصل می‌کند که هنگام استفاده از مدل‌ها در تولید، هیچ ناهماهنگی در داده‌های ورودی یا خروجی مدل وجود ندارد.

مخزن مدل تریتون معمولی برای این حجم کاری به شکل زیر است:

La model.py فایل حاوی کدهای پیش پردازش و پس پردازش است. وزنه های مدل آموزش دیده در screen_detection_inferencer دایرکتوری، نسخه تحت مدل 1 (مدل در این مثال با فرمت ONNX است، اما می تواند قالب TensorFlow، PyTorch یا موارد دیگر باشد). تعریف مدل مجموعه در screen_detection_pipeline دایرکتوری، که در آن ورودی ها و خروجی های بین مراحل در یک فایل پیکربندی نگاشت می شوند.

وابستگی های اضافی مورد نیاز برای اجرای مدل های پایتون در a requirements.txt فایل، و برای ساخت محیط کوندا باید بسته بندی شود (python_env.tar.gz). برای اطلاعات بیشتر مراجعه کنید مدیریت زمان اجرا و کتابخانه های پایتون. همچنین، فایل های پیکربندی برای مراحل پایتون باید به آن اشاره کنید python_env.tar.gz با استفاده از EXECUTION_ENV_PATH بخشنامه.

سپس پوشه مدل باید با استفاده از TAR فشرده شود و نام آن تغییر یابد model_version.txt. در نهایت، نتیجه <model_name>_<model_version>.tar.gz فایل به کپی می شود سرویس ذخیره سازی ساده آمازون سطل (Amazon S3) متصل به MME، به SageMaker اجازه می دهد مدل را شناسایی و ارائه دهد.

نسخه سازی مدل و استقرار مداوم

همانطور که در بخش قبل مشخص شد، ساخت یک مخزن مدل تریتون ساده است. با این حال، اجرای تمام مراحل لازم برای استقرار آن، اگر به صورت دستی اجرا شود، خسته کننده و مستعد خطا است. برای غلبه بر این مشکل، Veriff یک monorepo شامل تمام مدل‌ها برای استقرار در MMEs ساخت، جایی که دانشمندان داده در یک رویکرد Gitflow مانند همکاری می‌کنند. این monorepo دارای ویژگی های زیر است:

• با استفاده از آن مدیریت می شود شلوار.
• ابزارهای کیفیت کد مانند Black و MyPy با استفاده از Pants استفاده می شوند.
• تست های واحد برای هر مدل تعریف شده است، که بررسی می کند که خروجی مدل، خروجی مورد انتظار برای ورودی مدل معین باشد.
• وزن مدل در کنار مخازن مدل ذخیره می شود. این وزن ها می توانند فایل های باینری بزرگ باشند، بنابراین دی وی سی برای همگام سازی آنها با Git به صورت نسخه شده استفاده می شود.

این monorepo با یک ابزار ادغام پیوسته (CI) یکپارچه شده است. برای هر فشار جدید به مخزن یا مدل جدید، مراحل زیر اجرا می شود:

1. بررسی کیفیت کد را پاس کنید.
2. دانلود مدل وزنه ها.
3. محیط کوندا را بسازید.
4. یک سرور Triton را با استفاده از محیط Conda بچرخانید و از آن برای پردازش درخواست های تعریف شده در تست های واحد استفاده کنید.
5. ساخت فایل TAR مدل نهایی (<model_name>_<model_version>.tar.gz).

این مراحل اطمینان حاصل می‌کنند که مدل‌ها کیفیت مورد نیاز برای استقرار را دارند، بنابراین برای هر فشار به یک شاخه مخزن، فایل TAR حاصل (در یک مرحله CI دیگر) در سطل مرحله‌بندی S3 کپی می‌شود. هنگامی که فشارها در شاخه اصلی انجام می شود، فایل مدل در سطل S3 تولیدی کپی می شود. نمودار زیر این سیستم CI/CD را نشان می دهد.

هزینه و مزایای سرعت استقرار

استفاده از MME به Veriff اجازه می دهد تا از یک رویکرد monorepo برای استقرار مدل ها در تولید استفاده کند. به طور خلاصه، گردش کار استقرار مدل جدید Veriff شامل مراحل زیر است:

1. با مدل یا نسخه مدل جدید یک شعبه در monorepo ایجاد کنید.
2. تست های واحد را در یک ماشین توسعه تعریف و اجرا کنید.
3. هنگامی که مدل آماده آزمایش در محیط مرحله است، شاخه را فشار دهید.
4. هنگامی که مدل برای استفاده در تولید آماده شد، شاخه را به اصلی ادغام کنید.

با وجود این راه حل جدید، استقرار یک مدل در Veriff بخشی ساده از فرآیند توسعه است. زمان توسعه مدل جدید از 10 روز به میانگین 2 روز کاهش یافته است.

تدارک زیرساخت مدیریت شده و ویژگی‌های مقیاس خودکار SageMaker مزایای بیشتری را برای Veriff به ارمغان آورد. آنها استفاده کردند InvocationsPerInstance متریک CloudWatch برای مقیاس بندی بر اساس الگوهای ترافیک، صرفه جویی در هزینه ها بدون به خطر انداختن قابلیت اطمینان. برای تعریف مقدار آستانه برای متریک، آنها آزمایش بار را در نقطه پایانی مرحله بندی انجام دادند تا بهترین مبادله بین تاخیر و هزینه را پیدا کنند.

پس از استقرار هفت مدل تولیدی در MME و تجزیه و تحلیل هزینه‌ها، Veriff کاهش 75 درصدی هزینه در مدل GPU را در مقایسه با راه‌حل اصلی مبتنی بر Kubernetes گزارش کرد. هزینه های عملیاتی نیز کاهش یافت، زیرا بار تهیه نمونه ها به صورت دستی از دوش مهندسان DevOps شرکت برداشته شد.

نتیجه

در این پست بررسی کردیم که چرا Veriff Sagemaker MMEs را به جای استقرار مدل خود مدیریت در Kubernetes انتخاب کرد. SageMaker بارهای سنگین غیرمتمایز را بر عهده می گیرد و به Veriff اجازه می دهد زمان توسعه مدل را کاهش دهد، کارایی مهندسی را افزایش دهد و هزینه استنتاج بلادرنگ را به طور چشمگیری کاهش دهد و در عین حال عملکرد مورد نیاز برای عملیات حیاتی تجاری خود را حفظ کند. در نهایت، خط لوله CI/CD استقرار مدل ساده و در عین حال مؤثر Veriff و مکانیزم نسخه‌سازی مدل را به نمایش گذاشتیم که می‌تواند به عنوان یک پیاده‌سازی مرجع برای ترکیب بهترین شیوه‌های توسعه نرم‌افزار و SageMaker MME استفاده شود. با استفاده از SageMaker MME می‌توانید نمونه کدهای میزبانی چندین مدل را پیدا کنید GitHub.

---

درباره نویسنده

ریکارد بوراس یک کارشناس ارشد یادگیری ماشین در Veriff است، جایی که او تلاش‌های MLOps را در شرکت رهبری می‌کند. او به دانشمندان داده کمک می کند تا با ساختن یک پلتفرم علم داده در شرکت، و ترکیب چندین راه حل منبع باز با خدمات AWS، محصولات AI/ML سریعتر و بهتری بسازند.

ژائو مورا یک معمار راه حل های تخصصی AI/ML در AWS، مستقر در اسپانیا است. او به مشتریان کمک می‌کند تا با آموزش مدل‌های یادگیری عمیق در مقیاس بزرگ و بهینه‌سازی استنتاج، و به‌طور گسترده‌تر، پلتفرم‌های ML در مقیاس بزرگ را در AWS بسازند.

میگل فریرا به عنوان یک معمار Sr. Solutions در AWS مستقر در هلسینکی فنلاند کار می کند. AI/ML مورد علاقه مادام العمر بوده است و او به چندین مشتری کمک کرده است تا Amazon SageMaker را در جریان کاری ML خود ادغام کنند.

• محتوای مبتنی بر SEO و توزیع روابط عمومی. امروز تقویت شوید.
• PlatoData.Network Vertical Generative Ai. به خودت قدرت بده دسترسی به اینجا.
• PlatoAiStream. هوش وب 3 دانش تقویت شده دسترسی به اینجا.
• PlatoESG. کربن ، CleanTech، انرژی، محیط، خورشیدی، مدیریت پسماند دسترسی به اینجا.
• PlatoHealth. هوش بیوتکنولوژی و آزمایشات بالینی. دسترسی به اینجا.
• منبع: https://aws.amazon.com/blogs/machine-learning/how-veriff-decreased-deployment-time-by-80-using-amazon-sagemaker-multi-model-endpoints/