استنتاج چند مدل را با نقاط پایانی چند مدل Amazon SageMaker اجرا و بهینه کنید

آمازون SageMaker نقطه پایانی چند مدلی (MME) شما را قادر می سازد تا به طور مقرون به صرفه چندین مدل را در یک نقطه پایانی واحد مستقر کرده و میزبانی کنید و سپس به صورت افقی نقطه پایان را برای دستیابی به مقیاس مقیاس کنید. همانطور که در شکل زیر نشان داده شده است، این یک تکنیک موثر برای پیاده سازی چند اجاره ای مدل ها در زیرساخت یادگیری ماشین (ML) شما است. مشاهده کرده‌ایم که کسب‌وکارهای نرم‌افزاری به‌عنوان خدمات (SaaS) از این ویژگی برای اعمال شخصی‌سازی بیش از حد در مدل‌های ML خود استفاده می‌کنند و در عین حال هزینه‌های کمتری را نیز به دست می‌آورند.

برای یک نمای کلی از نحوه عملکرد MME، ویدیوی AWS Summit را بررسی کنید افزایش مقیاس ML به سطح بعدی: میزبانی هزاران مدل در SageMaker. برای کسب اطلاعات بیشتر در مورد موارد استفاده بیش از حد شخصی و چند مستاجر که MME فعال می کند، به آن مراجعه کنید نحوه مقیاس‌بندی استنتاج یادگیری ماشین برای موارد استفاده SaaS چند مستاجر.

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

از موارد مناسب برای MME استفاده کنید

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

MME همچنین برای مدل‌های میزبانی مشترک طراحی شده است که از چارچوب ML یکسانی استفاده می‌کنند، زیرا از کانتینر مشترک برای بارگیری چندین مدل استفاده می‌کنند. بنابراین، اگر ترکیبی از چارچوب‌های ML در ناوگان مدل خود دارید (مانند PyTorch و TensorFlow)، نقاط پایانی اختصاصی SageMaker یا میزبانی چند کانتینری انتخاب بهتری است.

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

ما همچنین سناریوهایی را دیده‌ایم که در آن مشتریان یک خوشه MME با ظرفیت حافظه مجموع کافی برای تطبیق با تمام مدل‌های خود مستقر می‌کنند، در نتیجه از تخلیه مدل به‌طور کلی اجتناب می‌کنند و در عین حال به دلیل زیرساخت استنتاج مشترک، همچنان در هزینه صرفه‌جویی می‌کنند.

مدل ظروف سرو

وقتی از SageMaker Inference Toolkit یا یک ظرف از پیش ساخته شده مدل SageMaker سازگار با MME استفاده می کنید، ظرف شما دارای سرور چند مدل (فرآیند JVM) در حال اجرا است. ساده ترین راه برای گنجاندن سرور چند مدل (MMS) در ظرف سرو مدل، استفاده از آن است. ظروف سرو مدل SageMaker سازگار با MME (به دنبال کسانی باشید که نوع شغل = استنتاج و CPU/GPU = CPU دارند). MMS یک ابزار متن باز و با کاربری آسان برای ارائه مدل های یادگیری عمیق است. یک REST API با یک وب سرور برای سرویس دهی و مدیریت چندین مدل در یک هاست فراهم می کند. با این حال، استفاده از MMS اجباری نیست. شما می توانید مدل سرور خود را پیاده سازی کنید تا زمانی که این سرور را پیاده سازی کند API های مورد نیاز MME.

هنگامی که به عنوان بخشی از پلتفرم MME استفاده می‌شود، همه تماس‌های API پیش‌بینی، بارگیری و تخلیه به MMS یا سرور مدل خودتان از طریق کنترلر صفحه داده MME هدایت می‌شوند. تماس‌های API از کنترل‌کننده هواپیمای داده فقط برای جلوگیری از دسترسی غیرمجاز از خارج از نمونه روی میزبان محلی انجام می‌شود. یکی از مزایای کلیدی MMS این است که یک رابط استاندارد برای بارگیری، تخلیه و فراخوانی مدل ها با سازگاری در طیف گسترده ای از چارچوب های یادگیری عمیق را فعال می کند.

پیکربندی پیشرفته MMS

اگر می‌خواهید از MMS برای ارائه مدل استفاده کنید، پیکربندی‌های پیشرفته زیر را برای بهینه‌سازی مقیاس‌پذیری و توان عملیاتی نمونه‌های MME خود در نظر بگیرید.

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

MMS یک یا چند فرآیند کارگر پایتون را در هر مدل بر اساس مقدار آن ایجاد می کند default_workers_per_model پارامتر پیکربندی این کارگران پایتون با اجرای هر پیش پردازش، پیش‌بینی و توابع پس پردازشی که ارائه می‌کنید، هر درخواست استنتاج فردی را مدیریت می‌کنند. برای اطلاعات بیشتر، به کنترل کننده خدمات سفارشی مخزن GitHub.

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

طراحی برای افزایش ترافیک

هر فرآیند MMS در یک نمونه پایانی دارای یک صف درخواست است که می تواند با آن پیکربندی شود job_queue_size پارامتر (پیش فرض 100 است). این تعداد درخواست‌هایی را تعیین می‌کند که MMS زمانی که همه فرآیندهای کارگر مشغول هستند در صف قرار می‌گیرد. از این پارامتر برای تنظیم دقیق پاسخگویی نمونه های نقطه پایانی خود پس از اینکه در مورد تعداد بهینه کارگران در هر مدل تصمیم گرفتید، استفاده کنید.

در یک نسبت بهینه کارگر به ازای هر مدل، پیش فرض 100 باید برای اکثر موارد کافی باشد. با این حال، برای مواردی که ترافیک درخواست به نقطه پایانی به‌طور غیرمعمول افزایش می‌یابد، اگر می‌خواهید نقطه پایانی سریعاً کنترل را به برنامه منتقل نکند، می‌توانید اندازه صف را کاهش دهید یا اگر می‌خواهید نقطه پایانی اسپایک را جذب کند، اندازه صف را افزایش دهید. .

منابع حافظه را در هر نمونه به حداکثر برسانید

هنگام استفاده از چندین فرآیند کارگر در هر مدل، به طور پیش‌فرض هر فرآیند کارگر کپی خودش از مدل را بارگیری می‌کند. این می تواند حافظه نمونه موجود را برای مدل های دیگر کاهش دهد. می توانید با به اشتراک گذاری یک مدل واحد بین فرآیندهای کارگر با تنظیم پارامتر پیکربندی، استفاده از حافظه را بهینه کنید. preload_model=true. در اینجا شما با کاهش موازی استنتاج (به دلیل یک نمونه مدل) با کارایی حافظه بیشتر معامله می کنید. این تنظیم همراه با چندین فرآیند کارگر می‌تواند انتخاب خوبی برای موارد استفاده باشد که در آن تأخیر مدل کم است اما در هر درخواست استنتاج، پیش‌پردازش و پس پردازش سنگین‌تری دارید (که توسط فرآیندهای کارگر انجام می‌شود).

مقادیر را برای تنظیمات پیشرفته MMS تنظیم کنید

MMS از یک فایل config.properties برای ذخیره تنظیمات استفاده می کند. MMS از ترتیب زیر برای مکان یابی این فایل config.properties استفاده می کند:

1. اگر MMS_CONFIG_FILE متغیر محیطی تنظیم شده است، MMS پیکربندی را از متغیر محیط بارگیری می کند.
2. اگر --mms-config پارامتر به MMS ارسال می شود، پیکربندی را از پارامتر بارگیری می کند.
3. اگر وجود دارد config.properties در پوشه فعلی که کاربر MMS را شروع می کند، آن را بارگیری می کند config.properties فایل از دایرکتوری کاری فعلی

اگر هیچ یک از موارد بالا مشخص نشده باشد، MMS پیکربندی داخلی را با مقادیر پیش فرض بارگیری می کند.

مثال زیر یک مثال خط فرمان از شروع MMS با یک فایل پیکربندی صریح است:

multi-model-server --start --mms-config /home/mms/config.properties

معیارهای کلیدی برای نظارت بر عملکرد نقطه پایانی شما

معیارهای کلیدی که می تواند به شما در بهینه سازی MME کمک کند، معمولاً به استفاده از CPU و حافظه و تأخیر استنتاج مربوط می شود. معیارهای سطح نمونه توسط MMS منتشر می شوند، در حالی که معیارهای تأخیر از MME می آیند. در این بخش، معیارهای معمولی را که می توانید برای درک و بهینه سازی MME خود استفاده کنید، مورد بحث قرار می دهیم.

معیارهای سطح نمونه نقطه پایانی (سنجه های MMS)

از لیست معیارهای MMS، CPUUtilization و MemoryUtilization می توانند به شما کمک کنند تا ارزیابی کنید که آیا نمونه شما یا خوشه MME اندازه مناسبی دارد یا خیر. اگر هر دو معیار درصدی بین 50 تا 80 درصد داشته باشند، MME شما اندازه مناسبی دارد.

به طور معمول، CPUUtilization پایین و MemoryUtilization بالا نشانه یک خوشه MME بیش از حد ارائه شده است زیرا نشان می دهد که مدل هایی که به ندرت فراخوانی می شوند تخلیه نمی شوند. این می‌تواند به دلیل تعداد بالاتر از بهینه نمونه‌های نقطه پایانی باشد که برای MME فراهم شده است و بنابراین حافظه مجموع بالاتر از حد بهینه برای مدل‌هایی که به‌ندرت به آن‌ها دسترسی دارند در دسترس است تا در حافظه باقی بمانند. برعکس، استفاده نزدیک به 100٪ از این معیارها به این معنی است که خوشه شما در دسترس نیست، بنابراین باید خط مشی مقیاس خودکار خوشه خود را تنظیم کنید.

معیارهای سطح پلت فرم (متریک های MME)

از لیست کامل معیارهای MME، یک معیار کلیدی که می تواند به شما در درک تأخیر درخواست استنتاج خود کمک کند ModelCacheHit است. این متریک نسبت متوسط ​​درخواست‌های فراخوانی را نشان می‌دهد که مدل قبلاً در حافظه بارگذاری شده است. اگر این نسبت کم باشد، نشان می‌دهد که خوشه MME شما در دسترس نیست، زیرا احتمالاً ظرفیت حافظه انبوه در خوشه MME برای تعداد فراخوان‌های مدل منحصربه‌فرد وجود ندارد، بنابراین باعث می‌شود مدل‌ها مکرراً از حافظه تخلیه شوند.

درس هایی از این زمینه و استراتژی هایی برای بهینه سازی MME

ما توصیه های زیر را از برخی از استفاده های در مقیاس بالا از MME در بین تعدادی از مشتریان دیده ایم.

مقیاس بندی افقی با نمونه های کوچکتر بهتر از مقیاس بندی عمودی با نمونه های بزرگتر است

ممکن است هنگام اجرای درخواست‌های بالا در ثانیه (RPS) در نمونه‌های نقطه پایانی کمتری در فراخوانی‌های مدل دچار مشکل شوید. محدودیت‌های داخلی برای تعداد فراخوان‌ها در هر ثانیه وجود دارد (بارگیری‌ها و بارگیری‌هایی که می‌توانند همزمان در یک نمونه اتفاق بیفتند)، و بنابراین همیشه بهتر است تعداد نمونه‌های کوچک‌تر بیشتری داشته باشیم. اجرای تعداد بیشتری از نمونه های کوچکتر به معنای ظرفیت کل کل این محدودیت ها برای نقطه پایانی است.

یکی دیگر از مزایای مقیاس افقی با نمونه های کوچکتر این است که هنگام اجرای MMS با سطوح موازی بالاتر، همراه با تعداد بیشتری از مدل ها در حافظه (همانطور که قبلا در این پست توضیح داده شد) خطر خسته شدن CPU و منابع حافظه نمونه را کاهش می دهید.

اجتناب از کوبیدن یک مسئولیت مشترک است

تکان دهنده در MME زمانی است که مدل ها به طور مکرر از حافظه بارگیری می شوند و به دلیل حافظه ناکافی، چه در یک نمونه منفرد و چه در مجموع در خوشه، دوباره بارگذاری می شوند.

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

با بسته بندی بیش از حد مدل ها در نمونه های حافظه کمتر و بزرگتر، تهاجمی نباشید

حافظه تنها منبعی نیست که باید از آن آگاه بود. منابع دیگری مانند CPU می توانند یک عامل محدود کننده باشند، همانطور که در نتایج تست بار زیر مشاهده می شود. در برخی موارد دیگر، ما همچنین مشاهده کرده‌ایم که منابع دیگر هسته مانند شناسه‌های فرآیند در یک نمونه به پایان می‌رسند، به دلیل ترکیبی از مدل‌های بیش از حد بارگذاری شده و فریمورک ML زیربنایی (مانند TensorFlow) رشته‌های تخم‌ریزی در هر مدل که مضرب‌های موجود بودند. vCPU ها

تست عملکرد زیر نمونه ای از تاثیر محدودیت CPU بر تأخیر مدل را نشان می دهد. در این آزمایش، یک نقطه پایانی تک نمونه با یک نمونه بزرگ، در حالی که حافظه بیش از اندازه کافی برای نگه داشتن هر چهار مدل در حافظه داشت، در مقایسه با نقطه پایانی با چهار نمونه کوچکتر، تأخیرهای نسبتاً بدتری را تحت بار تولید کرد.

تأخیر مدل نقطه پایانی تک نمونه

CPU و استفاده از حافظه نقطه پایانی تک نمونه

تأخیر مدل نقطه پایانی چهار نمونه

چهار نمونه CPU نقطه پایانی و استفاده از حافظه

برای دستیابی به کارایی و کارایی هزینه، خوشه MME خود را با تعداد نمونه‌های کوچک‌تر اندازه‌گیری کنید که در مجموع حافظه بهینه و ظرفیت CPU را در اختیار شما قرار می‌دهند و در عین حال نسبتاً با هزینه با نمونه‌های حافظه کمتر اما بزرگ‌تر برابر هستند.

مدل ذهنی برای بهینه سازی MME

چهار معیار کلیدی وجود دارد که همیشه باید هنگام اندازه‌گیری صحیح MME در نظر بگیرید:

• تعداد و سایز مدل ها
• تعداد مدل های منحصر به فرد فراخوانی شده در یک زمان معین
• نوع و اندازه نمونه
• تعداد نمونه پشت نقطه پایانی

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

به طور مشابه، اگر فراخوانی‌های مدل‌های منحصربه‌فرد بالاتر از حافظه انبوه همه نمونه‌های پشت نقطه پایانی باشد، ضربه حافظه پنهان کمتری را مشاهده خواهید کرد. اگر اندازه نمونه ها (مخصوصا ظرفیت حافظه) خیلی کوچک باشد، ممکن است این اتفاق بیفتد.

مقیاس عمودی با نمونه‌های حافظه واقعاً بزرگ نیز می‌تواند منجر به مشکلاتی شود، زیرا اگرچه مدل‌ها ممکن است در حافظه جا شوند، منابع دیگر مانند پردازش‌های CPU و هسته و محدودیت‌های رشته ممکن است تمام شوند. تست مقیاس بندی افقی را در پیش تولید بارگیری کنید تا تعداد و اندازه بهینه نمونه ها را برای MME خود بدست آورید.

خلاصه

در این پست، شما درک عمیق تری از پلتفرم MME پیدا کردید. شما یاد گرفتید که MME برای کدام موارد استفاده فنی مناسب است و معماری پلت فرم MME را بررسی کردید. شما درک عمیق تری از نقش هر مؤلفه در معماری MME و اینکه کدام مؤلفه ها می توانید مستقیماً بر عملکرد آنها تأثیر بگذارید، به دست آوردید. در نهایت، شما نگاه عمیق‌تری به پارامترهای پیکربندی داشتید که می‌توانید برای بهینه‌سازی MME برای موارد استفاده خود و معیارهایی که باید برای حفظ عملکرد بهینه نظارت کنید، تنظیم کنید.

برای شروع کار با MME، مرور کنید Amazon SageMaker چند مدل پایانی با استفاده از XGBoost و چندین مدل را در یک ظرف پشت یک نقطه پایانی میزبانی کنید.

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

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

ساوراب تریکاند مدیر محصول ارشد Amazon SageMaker Inference است. او مشتاق کار با مشتریان است و هدفش دموکراتیک کردن یادگیری ماشین است. او بر چالش‌های اصلی مربوط به استقرار برنامه‌های کاربردی پیچیده ML، مدل‌های ML چند مستاجر، بهینه‌سازی هزینه‌ها و در دسترس‌تر کردن استقرار مدل‌های یادگیری عمیق تمرکز می‌کند. Saurabh در اوقات فراغت خود از پیاده روی، یادگیری در مورد فن آوری های نوآورانه، دنبال کردن TechCrunch و گذراندن وقت با خانواده خود لذت می برد.