Achieve Hyperscale Performance For Model Serving Using NVIDIA Triton Inference Server On Amazon SageMaker

بازنشر افلاطون

دنبال: 0

کاربردهای یادگیری ماشین (ML) برای استقرار پیچیده هستند و اغلب به چندین مدل ML برای ارائه یک درخواست استنتاج نیاز دارند. یک درخواست معمولی ممکن است در چندین مدل با مراحلی مانند پیش پردازش، تبدیل داده ها، منطق انتخاب مدل، تجمیع مدل، و پس پردازش جریان داشته باشد. این منجر به تکامل الگوهای طراحی رایج مانند خطوط لوله استنتاج سریال، مجموعه‌ها (جمع پراکنده)، و گردش‌های کاری منطق تجاری شده است که منجر به تحقق کل گردش کاری درخواست به عنوان یک گراف غیر چرخه جهت دار (DAG) شده است. با این حال، با پیچیده تر شدن گردش کار، این امر منجر به افزایش زمان پاسخ کلی یا تأخیر این برنامه ها می شود که به نوبه خود بر تجربه کلی کاربر تأثیر می گذارد. علاوه بر این، اگر این مؤلفه‌ها در نمونه‌های مختلف میزبانی شوند، تأخیر اضافی شبکه بین این نمونه‌ها تأخیر کلی را افزایش می‌دهد. نمونه ای از مورد استفاده محبوب ML را برای دستیار مجازی در پشتیبانی مشتری در نظر بگیرید. یک درخواست معمولی ممکن است چندین مرحله شامل تشخیص گفتار، پردازش زبان طبیعی (NLP)، ردیابی وضعیت گفتگو، خط مشی گفتگو، تولید متن و در نهایت متن به گفتار را طی کند. علاوه بر این، برای شخصی‌تر کردن تعامل با کاربر، می‌توانید از مدل‌های NLP مبتنی بر ترانسفورماتور مانند نسخه‌های مختلف استفاده کنید. برت, بارتو GPT. نتیجه نهایی زمان پاسخگویی طولانی برای این مجموعه‌های مدل و تجربه مشتری ضعیف است.

یک الگوی متداول برای کاهش زمان پاسخگویی بدون به خطر انداختن توان کلی، میزبانی این مدل‌ها در همان نمونه همراه با منطق تجاری سبک وزن است که در آن تعبیه شده است. این مدل‌ها را می‌توان به‌منظور ایجاد انزوا برای فرآیندهای در حال اجرا و پایین نگه داشتن تأخیر، در ظرف‌های منفرد یا چندگانه در یک نمونه کپسوله کرد. علاوه بر این، تأخیر کلی به منطق برنامه استنتاج، بهینه‌سازی مدل، زیرساخت‌های زیربنایی (شامل محاسبات، ذخیره‌سازی و شبکه) و سرور وب زیربنایی که درخواست‌های استنتاج می‌گیرد بستگی دارد. سرور استنتاج تریتون NVIDIA یک نرم افزار ارائه استنتاج منبع باز با ویژگی هایی برای به حداکثر رساندن توان عملیاتی و استفاده از سخت افزار با تأخیر استنتاج بسیار کم (تک رقمی) است. پشتیبانی گسترده ای از چارچوب های ML (از جمله TensorFlow، PyTorch، ONNX، XGBoost، و NVIDIA TensorRT) و زیرساخت های پشتیبان، از جمله GPU، CPU و استنتاج AWS. علاوه بر این، سرور استنتاج تریتون با آن یکپارچه شده است آمازون SageMaker، یک سرویس ML سرتاسر مدیریت شده، که گزینه های استنتاج بلادرنگ از جمله ارائه می دهد تنها و چند مدل میزبانی. این گزینه‌های استنتاج شامل میزبانی چندین مدل در یک ظرف پشت a است نقطه پایانی واحد، و میزبانی چند مدل با ظروف متعدد پشت یک نقطه پایانی واحد

در نوامبر 2021 اعلام کردیم ادغام سرور استنتاج Triton در SageMaker. AWS همکاری نزدیکی با NVIDIA داشت تا به شما امکان دهد بهترین های هر دو دنیا را داشته باشید و استقرار مدل با Triton در AWS را آسان تر کنید.

در این پست، ما به بهترین روش‌ها برای استقرار مدل‌های ترانسفورماتور در مقیاس بر روی GPU با استفاده از Triton Inference Server در SageMaker نگاه می‌کنیم. ابتدا، با خلاصه‌ای از مفاهیم کلیدی در مورد تأخیر در SageMaker و مروری بر دستورالعمل‌های تنظیم عملکرد شروع می‌کنیم. در ادامه، مروری بر تریتون و ویژگی‌های آن و همچنین کد نمونه برای استقرار در SageMaker ارائه می‌کنیم. در نهایت با استفاده از تست بارگذاری را انجام می دهیم SageMaker Inference Recommender و خلاصه بینش و نتیجه گیری از آزمایش بار یک مدل ترانسفورماتور محبوب ارائه شده توسط Hugging Face.

می توانید بررسی کنید دفتر یادداشت ما برای استقرار مدل‌ها و انجام آزمایش‌های بار به تنهایی با استفاده از کد موجود استفاده می‌کردیم GitHub.

تنظیم و بهینه سازی عملکرد برای ارائه مدل در SageMaker

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

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

استنتاج بلادرنگ و تأخیر در SageMaker

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

تأخیر کانتینر - مدت زمان ارسال درخواست، واکشی پاسخ از ظرف مدل و استنتاج کامل در ظرف. این معیار در آمازون CloudWatch به عنوان بخشی از در دسترس است معیارهای فراخوانی منتشر شده توسط SageMaker.
تأخیر مدل - کل زمان صرف شده توسط تمام ظروف SageMaker در یک خط لوله استنتاج. این معیار در آمازون CloudWatch به عنوان بخشی از در دسترس است معیارهای فراخوانی منتشر شده توسط SageMaker.
تأخیر سربار – از زمانی که SageMaker درخواست را دریافت می‌کند تا زمانی که پاسخی را به مشتری برمی‌گرداند، منهای تأخیر مدل اندازه‌گیری می‌شود. این معیار در آمازون CloudWatch به عنوان بخشی از در دسترس است معیارهای فراخوانی منتشر شده توسط SageMaker.
تأخیر انتها به انتها - از زمانی که مشتری درخواست استنتاج را ارسال می کند تا زمانی که پاسخ را دریافت می کند اندازه گیری می شود. مشتریان می توانند این را به عنوان یک معیار سفارشی در آمازون CloudWatch منتشر کنند.

نمودار زیر این اجزا را نشان می دهد.

تأخیر کانتینر به عوامل مختلفی بستگی دارد. موارد زیر از مهمترین آنها هستند:

پروتکل اصلی (HTTP(s)/gRPC) که برای ارتباط با سرور استنتاج استفاده می شود
سربار مربوط به ایجاد اتصالات TLS جدید
زمان سریال‌زدایی محموله درخواست/پاسخ
ویژگی های صف و دسته بندی ارائه شده توسط سرور استنتاج زیربنایی را درخواست کنید
درخواست قابلیت های زمان بندی ارائه شده توسط سرور استنتاج زیربنایی
عملکرد زیربنایی زمان اجرا سرور استنتاج
عملکرد کتابخانه های پیش پردازش و پس پردازش قبل از فراخوانی تابع پیش بینی مدل
عملکرد پشتیبان چارچوب ML زیربنایی
بهینه سازی های خاص مدل و سخت افزار

در این پست، ما عمدتاً بر روی بهینه‌سازی تأخیر کانتینر همراه با توان و هزینه کلی تمرکز می‌کنیم. به طور خاص، ما تنظیم عملکرد Triton Inference Server را که در داخل یک ظرف SageMaker اجرا می شود، بررسی می کنیم.

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

استقرار و مقیاس بندی مدل های NLP در یک مجموعه تولید می تواند بسیار چالش برانگیز باشد. مدل های NLP اغلب از نظر اندازه بسیار بزرگ هستند و حاوی میلیون ها پارامتر مدل هستند. پیکربندی‌های مدل بهینه برای برآورده کردن الزامات عملکرد دقیق و مقیاس‌پذیری برنامه‌های NLP درجه تولید مورد نیاز است.

در این پست، ما یک مورد استفاده از NLP را با استفاده از یک نقطه پایانی بلادرنگ SageMaker بر اساس ظرف سرور استنتاج Triton مقایسه می‌کنیم و بهینه‌سازی‌های تنظیم عملکرد را برای مورد استفاده ML خود توصیه می‌کنیم. ما از یک صورت بزرگ و از قبل آموزش دیده مبتنی بر ترانسفورماتور استفاده می کنیم BERT بزرگ بدون قاب مدلی که حدود 336 میلیون پارامتر مدل دارد. جمله ورودی مورد استفاده برای مدل طبقه‌بندی باینری به حداکثر طول دنباله ورودی 512 توکن اضافه شده و کوتاه شده است. تست بار استنتاج 500 فراخوان در ثانیه (30,000 حداکثر فراخوان در دقیقه) را شبیه سازی می کند و ModelLatency کمتر از 0.5 ثانیه (500 میلی ثانیه).

جدول زیر پیکربندی معیار ما را خلاصه می کند.

نام مدل	در آغوش کشیدن صورت `bert-large-uncased`
مدل اندازه	1.25 GB
نیاز تاخیر	0.5 ثانیه (500 میلی ثانیه)
فراخوان در ثانیه	500 درخواست (30,000 در دقیقه)
طول توالی ورودی	512 نشانه
وظیفه ML	طبقه بندی باینری

سرور استنتاج تریتون NVIDIA

سرور استنتاج تریتون به طور خاص طراحی شده است تا امکان استقرار مقیاس پذیر، سریع و آسان مدل ها را در تولید فراهم کند. تریتون از انواع چارچوب های اصلی هوش مصنوعی، از جمله TensorFlow، TensorRT، PyTorch، XGBoost و ONNX پشتیبانی می کند. با باطن سفارشی Python و C++، می‌توانید بار کاری استنتاج خود را برای موارد استفاده سفارشی‌تر پیاده‌سازی کنید.

مهمتر از همه، تریتون یک راه‌اندازی ساده مبتنی بر پیکربندی برای میزبانی مدل‌های شما ارائه می‌کند، که مجموعه‌ای غنی از ویژگی‌های بهینه‌سازی عملکرد را نشان می‌دهد که می‌توانید با تلاش کمی برای کدنویسی استفاده کنید.

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

دسته بندی پویا

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

در معماری قبلی، تمام درخواست‌ها قبل از ورود به صف‌های زمان‌بندی مدل واقعی، ابتدا به دسته پویا می‌رسند تا منتظر استنتاج شوند. شما می توانید اندازه های دسته دلخواه خود را برای دسته بندی پویا با استفاده از ترجیح_بچ_اندازه تنظیمات در پیکربندی مدل (توجه داشته باشید که اندازه دسته تشکیل شده باید کمتر از مقدار باشد حداکثر_اندازه_دسته مدل پشتیبانی می کند.) همچنین می توانید پیکربندی کنید max_queue_delay_microseconds برای تعیین حداکثر زمان تأخیر در batcher برای منتظر ماندن سایر درخواست‌ها برای پیوستن به دسته براساس الزامات تأخیر شما.

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

dynamic_batching { preferred_batch_size: 16 max_queue_delay_microseconds: 100 }

اجرای مدل ها به صورت همزمان

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

شکل زیر نشان می دهد که چگونه می توانید به راحتی سیاست های استقرار مدل های مختلف را تنها با چند خط تغییر کد پیکربندی کنید. برای مثال، پیکربندی A (سمت چپ) نشان می‌دهد که می‌توانید پیکربندی یکسانی از دو نمونه مدل را پخش کنید. bert-large-uncased به تمام GPU های موجود در مقابل، پیکربندی B (وسط) پیکربندی متفاوتی را فقط برای GPU 0 نشان می‌دهد، بدون اینکه سیاست‌های مربوط به GPUهای دیگر را تغییر دهد. همانطور که در پیکربندی C (راست) نشان داده شده است، می‌توانید نمونه‌هایی از مدل‌های مختلف را بر روی یک GPU منفرد مستقر کنید.

در پیکربندی C، نمونه محاسباتی می‌تواند دو درخواست همزمان برای مدل DistilGPT-2 و هفت درخواست همزمان برای مدل را انجام دهد. bert-large-uncased مدل به صورت موازی با این بهینه‌سازی‌ها، می‌توان از منابع سخت‌افزاری برای فرآیند سرویس‌دهی بهتر استفاده کرد، در نتیجه توان عملیاتی را بهبود بخشید و کارایی بهتری را برای حجم کاری شما فراهم کرد.

تنفر

NVIDIA TensorRT یک SDK برای استنتاج یادگیری عمیق با کارایی بالا است که به طور یکپارچه با Triton کار می کند. TensorRT، که از هر چارچوب یادگیری عمیق اصلی پشتیبانی می‌کند، شامل یک بهینه‌ساز استنتاج و زمان اجرا است که تأخیر کم و توان عملیاتی بالا را برای اجرای استنتاج‌ها با حجم عظیم داده از طریق بهینه‌سازی‌های قدرتمند ارائه می‌دهد.

TensorRT نمودار را برای به حداقل رساندن ردپای حافظه با آزاد کردن حافظه غیر ضروری و استفاده مجدد کارآمد از آن بهینه می کند. علاوه بر این، کامپایل TensorRT عملیات پراکنده در نمودار مدل را با هم ترکیب می کند تا یک هسته بزرگتر را تشکیل دهد تا از سربار راه اندازی چندین هسته کوچک جلوگیری کند. تنظیم خودکار هسته به شما کمک می کند تا با انتخاب بهترین الگوریتم در GPU مورد نظر خود از سخت افزار به طور کامل استفاده کنید. جریان‌های CUDA به مدل‌ها امکان می‌دهند تا به صورت موازی اجرا شوند تا استفاده از GPU شما برای بهترین عملکرد به حداکثر برسد. آخرین اما نه کم‌اهمیت، تکنیک کوانتیزاسیون می‌تواند به طور کامل از شتاب با دقت ترکیبی هسته‌های Tensor برای اجرای مدل در FP32، TF32، FP16 و INT8 برای دستیابی به بهترین عملکرد استنتاج استفاده کند.

تریتون در میزبانی SageMaker

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

در زیر چتر میزبانی SageMaker نیز مجموعه ای از ظروف یادگیری عمیق استنتاج SageMaker (DLC) قرار دارد که با نرم افزار سرور مدل مناسب برای چارچوب ML پشتیبانی شده مربوطه خود بسته بندی شده اند. این به شما امکان می‌دهد بدون راه‌اندازی سرور مدل به عملکرد استنتاج بالایی برسید، که اغلب پیچیده‌ترین جنبه فنی استقرار مدل است و به طور کلی، بخشی از مجموعه مهارت یک دانشمند داده نیست. سرور استنتاج تریتون اکنون است در دسترس در SageMaker Deep Learning Containers (DLC).

این گستردگی گزینه‌ها، ماژولار بودن و سهولت استفاده از فریمورک‌های مختلف سرویس دهی، SageMaker و Triton را به یک بازی قدرتمند تبدیل کرده است.

SageMaker Inference Recommender برای مقایسه نتایج آزمون

ما از SageMaker Inference Recommender برای اجرای آزمایش های خود استفاده می کنیم. SageMaker Inference Recommender دو نوع کار را ارائه می دهد: پیش فرض و پیشرفته، همانطور که در نمودار زیر نشان داده شده است.

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

کار پیشرفته کنترل های بیشتری را برای تنظیم دقیق عملکرد ارائه می دهد. این کنترل ها محیط واقعی و نیازمندی های تولید را شبیه سازی می کنند. از جمله این کنترل ها الگوی ترافیک است که هدف آن مرحله بندی الگوی درخواست برای معیارها است. می توانید با استفاده از فازهای متعدد الگوی ترافیک، رمپ یا ترافیک ثابت را تنظیم کنید. به عنوان مثال، یک InitialNumberOfUsers از 1 میزان تخم ریزی از 1 و مدت زمان در ثانیه از 600 ممکن است منجر به ترافیک رمپ 10 دقیقه ای با 1 کاربر همزمان در ابتدا و 10 در پایان شود. علاوه بر این، روی کنترل ها، MaxInvocations و ModelLatency Thresholds آستانه تولید را تعیین کنید، بنابراین زمانی که یکی از آستانه ها فراتر رفت، معیارگذاری متوقف می شود.

در نهایت، معیارهای توصیه شامل توان عملیاتی، تاخیر در حداکثر توان عملیاتی، و هزینه هر استنتاج، بنابراین مقایسه آنها آسان است.

ما از نوع کار پیشرفته SageMaker Inference Recommender برای اجرای آزمایش‌های خود برای به دست آوردن کنترل بیشتر بر الگوهای ترافیک و تنظیم دقیق پیکربندی ظرف سرو استفاده می‌کنیم.

تنظیم آزمایش

ما از ویژگی تست بار سفارشی SageMaker Inference Recommender برای محک زدن نمایه NLP که در مورد استفاده ما مشخص شده است استفاده می کنیم. ابتدا پیش نیازهای زیر را در رابطه با مدل NLP و وظیفه ML تعریف می کنیم. SageMaker Inference Recommender از این اطلاعات برای استخراج تصویر داکر استنتاج از آن استفاده می کند رجیستری ظروف الاستیک آمازون (Amazon ECR) و مدل را در رجیستری مدل SageMaker ثبت کنید.

دامنه	`NATURAL_LANGUAGE_PROCESSING`
کار	`FILL_MASK`
چارچوب	PYTORCH: 1.6.0
مدل	`bert-large-uncased`

پیکربندی الگوی ترافیک در SageMaker Inference Recommender به ما امکان می دهد فازهای مختلفی را برای تست بار سفارشی تعریف کنیم. تست بارگذاری با دو کاربر اولیه شروع می شود و در هر دقیقه دو کاربر جدید به مدت 25 دقیقه (1500 ثانیه) ایجاد می شود، همانطور که در کد زیر نشان داده شده است:

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

ما با آزمایش بار یک مدل را در دو حالت مختلف آزمایش می کنیم. آزمایش‌های مبتنی بر PyTorch از مدل استاندارد و بدون تغییر PyTorch استفاده می‌کنند. برای آزمایش‌های مبتنی بر TensorRT، ما مدل PyTorch را از قبل به یک موتور TensorRT تبدیل می‌کنیم.

ما ترکیب های مختلفی از ویژگی های بهینه سازی عملکرد را در این دو مدل اعمال می کنیم که در جدول زیر خلاصه شده است.

نام پیکربندی	توضیحات پیکربندی	پیکربندی مدل
`pt-base`	خط پایه PyTorch	مدل پایه PyTorch، بدون تغییر
`pt-db`	PyTorch با دسته بندی پویا	`dynamic_batching` `{}`
`pt-ig`	PyTorch با چندین نمونه مدل	`instance_group [` `{` `count: 2` `kind: KIND_GPU` `}` `]`
`pt-ig-db`	PyTorch با نمونه های مدل متعدد و دسته بندی پویا	`dynamic_batching` `{},` `instance_group [` `{` `count: 2` `kind: KIND_GPU` `}` `]`
`trt-base`	خط پایه TensorRT	مدل PyTorch با TensoRT کامپایل شده است `trtexec` سودمندی
`trt-db`	TensorRT با دسته بندی پویا	`dynamic_batching` `{}`
`trt-ig`	TensorRT با چندین نمونه مدل	`instance_group [` `{` `count: 2` `kind: KIND_GPU` `}` `]`
`trt-ig-db`	TensorRT با نمونه های مدل متعدد و دسته بندی پویا	`dynamic_batching` `{},` `instance_group [` `{` `count: 2` `kind: KIND_GPU` `}` `]`

نتایج آزمایش و مشاهدات

ما آزمایش‌های بار را برای سه نوع نمونه در یک خانواده g4dn انجام دادیم: ml.g4dn.xlarge، ml.g4dn.2xlarge و ml.g4dn.12xlarge. همه انواع نمونه g4dn به پردازنده‌های گرافیکی NVIDIA T4 Tensor Core و پردازنده‌های نسل دوم اینتل Cascade Lake دسترسی دارند. منطق پشت انتخاب انواع نمونه‌ها این بود که هم نمونه‌ای با تنها یک GPU در دسترس داشته باشیم و هم نمونه‌ای با دسترسی به چندین GPU—چهار در مورد ml.g2dn.4xlarge. علاوه بر این، ما می‌خواستیم آزمایش کنیم که آیا افزایش ظرفیت vCPU در نمونه با تنها یک GPU موجود باعث بهبود نسبت هزینه به عملکرد می‌شود یا خیر.

اجازه دهید ابتدا به سرعت بهینه سازی فردی بپردازیم. نمودار زیر نشان می‌دهد که بهینه‌سازی TensorRT کاهش 50 درصدی تأخیر مدل را در مقایسه با نسخه اصلی PyTorch در نمونه ml.g4dn.xlarge ارائه می‌کند. این کاهش تأخیر در نمونه‌های چند GPU ml.g4dn.12xlarge به بیش از سه برابر افزایش می‌یابد. در همین حال، بهبود 30 درصدی توان عملیاتی در هر دو مورد سازگار است و پس از اعمال بهینه‌سازی TensorRT، مقرون به صرفه‌تر است.

با دسته‌بندی پویا، می‌توانیم با استفاده از همان معماری سخت‌افزاری در تمام آزمایش‌ها مانند ml.g2dn.xlarge، ml.g4dn.4xlarge و ml.g2dn.4xlarge، بدون افزایش تأخیر محسوس، نزدیک به 12 برابر افزایش توان عملیاتی داشته باشیم.

به طور مشابه، اجرای مدل همزمان ما را قادر می‌سازد تا با به حداکثر رساندن استفاده از GPU در نمونه ml.g3dn.xlarge و حدود 4 برابر بهبود در نمونه ml.g4dn.2xlarge و نمونه چند GPU میلی‌لیتری، حدود 4 تا 2 برابر در توان عملیاتی بهبود پیدا کنیم. g4dn.12xlarge.. این افزایش توان عملیاتی بدون هیچ سرباری در تأخیر انجام می شود.

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

نام پیکربندی	بهینه سازی مدل	پویا دسته بندی	پیکربندی گروه نمونه	نوع نمونه	vCPU ها	GPU ها	حافظه گرافیکی (گیگابایت)	تعداد نمونه اولیه[1]	فراخوان در هر دقیقه در هر نمونه	تأخیر مدل	هزینه هر ساعت[2]
pt-base	NA	نه	NA	ml.g4dn.xlarge	4	1	16	62	490	1500	45.6568
pt-db	NA	بله	NA	ml.g4dn.xlarge	4	1	16	57	529	1490	41.9748
pt-ig	NA	نه	2	ml.g4dn.xlarge	4	1	16	34	906	868	25.0376
pt-ig-db	NA	بله	2	ml.g4dn.xlarge	4	1	16	34	892	1158	25.0376
trt-base	تنفر	نه	NA	ml.g4dn.xlarge	4	1	16	47	643	742	34.6108
trt-db	تنفر	بله	NA	ml.g4dn.xlarge	4	1	16	28	1078	814	20.6192
trt-ig	تنفر	نه	2	ml.g4dn.xlarge	4	1	16	14	2202	1273	10.3096
trt-db-ig	تنفر	بله	2	ml.g4dn.xlarge	4	1	16	10	3192	783	7.364
pt-base	NA	نه	NA	ml.g4dn.2xlarge	8	1	32	56	544	1500	52.64
pt-db	NA	بله	NA	ml.g4dn.2xlarge	8	1	32	59	517	1500	55.46
pt-ig	NA	نه	2	ml.g4dn.2xlarge	8	1	32	29	1054	960	27.26
pt-ig-db	NA	بله	2	ml.g4dn.2xlarge	8	1	32	30	1017	992	28.2
trt-base	تنفر	نه	NA	ml.g4dn.2xlarge	8	1	32	42	718	1494	39.48
trt-db	تنفر	بله	NA	ml.g4dn.2xlarge	8	1	32	23	1335	499	21.62
trt-ig	تنفر	نه	2	ml.g4dn.2xlarge	8	1	32	23	1363	1017	21.62
trt-db-ig	تنفر	بله	2	ml.g4dn.2xlarge	8	1	32	22	1369	963	20.68
pt-base	NA	نه	NA	ml.g4dn.12xlarge	48	4	192	15	2138	906	73.35
pt-db	NA	بله	NA	ml.g4dn.12xlarge	48	4	192	15	2110	907	73.35
pt-ig	NA	نه	2	ml.g4dn.12xlarge	48	4	192	8	3862	651	39.12
pt-ig-db	NA	بله	2	ml.g4dn.12xlarge	48	4	192	8	3822	642	39.12
trt-base	تنفر	نه	NA	ml.g4dn.12xlarge	48	4	192	11	2892	279	53.79
trt-db	تنفر	بله	NA	ml.g4dn.12xlarge	48	4	192	6	5356	278	29.34
trt-ig	تنفر	نه	2	ml.g4dn.12xlarge	48	4	192	6	5210	328	29.34
trt-db-ig	تنفر	بله	2	ml.g4dn.12xlarge	48	4	192	6	5235	439	29.34

[1] تعداد نمونه‌های اولیه در جدول بالا، تعداد نمونه‌های توصیه‌شده برای استفاده با خط‌مشی مقیاس‌بندی خودکار برای حفظ توان عملیاتی و تأخیر مورد نیاز برای حجم کاری شما است.

[2] هزینه هر ساعت در جدول بالا بر اساس تعداد نمونه اولیه و قیمت برای نوع نمونه محاسبه می شود.

نتایج عمدتاً تأثیری را که از ویژگی های مختلف بهینه سازی عملکرد انتظار می رفت تأیید می کند:

کامپایل TensorRT مطمئن ترین تاثیر را در همه انواع نمونه دارد. تراکنش‌ها در دقیقه به ازای هر نمونه 30 تا 35 درصد افزایش یافته است که در مقایسه با عملکرد موتور TensorRT با پیش‌فرض PyTorch BERT، تقریباً 25 درصد کاهش هزینه دارد.pt-base). عملکرد افزایش یافته موتور TensorRT با سایر ویژگی های تنظیم عملکرد آزمایش شده ترکیب شده و مورد بهره برداری قرار می گیرد.
بارگیری دو مدل در هر GPU (گروه نمونه) تقریباً تمام معیارهای اندازه گیری شده را دو برابر کرد. فراخوانی‌ها در هر دقیقه در هر نمونه تقریباً 80 تا 90 درصد افزایش می‌یابد که باعث کاهش هزینه در محدوده 50 درصدی می‌شود، تقریباً مثل اینکه از دو GPU استفاده می‌کنیم. در حقیقت، CloudWatch آمازون معیارهای آزمایش‌های ما روی g4dn.2xlarge (به عنوان مثال) تأیید می‌کند که وقتی یک گروه نمونه از دو مدل را پیکربندی می‌کنیم، استفاده از CPU و GPU دو برابر می‌شود.

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

معیار ارائه شده در این پست فقط سطح ویژگی‌ها و تکنیک‌های احتمالی را نشان می‌دهد که می‌توانید با Triton برای بهبود عملکرد استنتاج استفاده کنید. اینها از تکنیک‌های پیش‌پردازش داده‌ها، مانند ارسال بارهای باینری به سرور مدل یا محموله‌هایی با دسته‌های بزرگ‌تر، تا ویژگی‌های بومی Triton، مانند موارد زیر را شامل می‌شود:

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

ما انتظار داریم این تکنیک ها و ویژگی ها را در یک پست آینده آزمایش و محک بزنیم، پس با ما همراه باشید!

نتیجه

در این پست، چند پارامتر را بررسی کردیم که می‌توانید برای به حداکثر رساندن عملکرد SageMaker بلادرنگ خود برای ارائه مدل‌های PyTorch BERT با سرور استنتاج Triton استفاده کنید. ما از SageMaker Inference Recommender برای انجام تست‌های معیار برای تنظیم دقیق این پارامترها استفاده کردیم. این پارامترها در اصل مربوط به بهینه‌سازی مدل مبتنی بر TensorRT هستند که منجر به بهبودی تقریباً 50 درصدی در زمان‌های پاسخ نسبت به نسخه غیربهینه‌شده می‌شود. علاوه بر این، اجرای همزمان مدل‌ها و استفاده از دسته‌بندی پویا تریتون منجر به افزایش تقریباً 70 درصدی در توان عملیاتی شد. تنظیم دقیق این پارامترها منجر به کاهش کلی هزینه استنتاج نیز شد.

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

SageMaker ابزارهایی را برای حذف وزنه برداری تمایز نیافته از هر مرحله از چرخه عمر ML فراهم می کند، در نتیجه آزمایش و کاوش سریع مورد نیاز برای بهینه سازی کامل استقرار مدل شما را تسهیل می کند.

می توانید نوت بوک مورد استفاده برای تست بار و استقرار را در آن پیدا کنید GitHub. می‌توانید پیکربندی‌های Triton و تنظیمات SageMaker Inference Recommender را به‌روزرسانی کنید تا به بهترین وجه مناسب مورد استفاده شما باشد تا به حجم کاری استنتاج مقرون‌به‌صرفه و با بهترین عملکرد برسید.

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

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

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

موهان گاندی مهندس ارشد نرم افزار در AWS است. او در 9 سال گذشته با AWS کار کرده و روی سرویس‌های مختلف AWS مانند EMR، EFA و RDS در Outposts کار کرده است. در حال حاضر، او بر روی بهبود تجربه استنتاج SageMaker متمرکز شده است. در اوقات فراغت خود از پیاده روی و دویدن در ماراتن لذت می برد.

داوال پاتل یک معمار اصلی یادگیری ماشین در AWS است. او با سازمان‌هایی از شرکت‌های بزرگ گرفته تا استارت‌آپ‌های متوسط در زمینه مشکلات مربوط به محاسبات توزیع‌شده و هوش مصنوعی کار کرده است. او بر روی یادگیری عمیق از جمله دامنه های NLP و Computer Vision تمرکز دارد. او به مشتریان کمک می کند تا به استنباط مدل با عملکرد بالا در SageMaker دست یابند.

سانتوش باوانی یک مدیر ارشد محصول فنی با تیم آمازون SageMaker Elastic Inference است. او بر کمک به مشتریان SageMaker در تسریع استنتاج و استقرار مدل تمرکز دارد. در اوقات فراغت خود از مسافرت کردن، بازی تنیس و نوشیدن مقدار زیادی چای پوئر لذت می برد.

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

تمبر زمان: ممکن است 2، 2022

تمبر زمان: ممکن است 12، 2023

بازنشر افلاطون

استقرار مدل دیاریزاسیون بلندگوی صورت در آغوش گرفته (PyAnnote) در Amazon SageMaker به عنوان نقطه پایانی ناهمزمان | خدمات وب آمازون

شناسایی بینش های کلیدی از اسناد متنی از طریق تنظیم دقیق و HPO با Amazon SageMaker JumpStart

تسریع PyTorch با DeepSpeed برای آموزش مدل های زبان بزرگ با نمونه های DL1 EC2 مبتنی بر اینتل Habana Gaudi | خدمات وب آمازون

درباره‌ ما

جستجوی عمودی و هوش مصنوعی

سکو

همیشه در ارتباط ماندن

حساب