معیار و بهینه سازی استقرار نقطه پایانی در Amazon SageMaker JumpStart | خدمات وب آمازون

هنگام استقرار یک مدل زبان بزرگ (LLM)، تمرین‌کنندگان یادگیری ماشین (ML) معمولاً به دو اندازه‌گیری برای عملکرد ارائه مدل اهمیت می‌دهند: تأخیر، که با زمان لازم برای تولید یک توکن مشخص می‌شود، و توان عملیاتی، که با تعداد توکن‌های تولید شده تعریف می‌شود. در هر ثانیه اگرچه یک درخواست واحد به نقطه پایانی مستقر شده، توان عملیاتی تقریباً برابر با معکوس تأخیر مدل را نشان می‌دهد، اما وقتی چندین درخواست همزمان به طور همزمان به نقطه پایانی ارسال می‌شوند، لزوماً اینطور نیست. با توجه به تکنیک‌های سرویس‌دهی مدل، مانند دسته‌بندی پیوسته درخواست‌های همزمان سمت مشتری، تأخیر و توان عملیاتی ارتباط پیچیده‌ای دارند که به طور قابل‌توجهی بر اساس معماری مدل، پیکربندی‌های سرویس، سخت‌افزار نوع نمونه، تعداد درخواست‌های همزمان و تغییرات در بارهای ورودی متفاوت است. به عنوان تعداد نشانه های ورودی و نشانه های خروجی.

این پست این روابط را از طریق یک معیار جامع از LLM های موجود در Amazon SageMaker JumpStart، از جمله انواع Llama 2، Falcon و Mistral بررسی می کند. با SageMaker JumpStart، پزشکان ML می‌توانند از میان مجموعه گسترده‌ای از مدل‌های پایه عمومی در دسترس را برای استقرار در موارد اختصاصی انتخاب کنند. آمازون SageMaker نمونه هایی در محیط ایزوله از شبکه ما اصول نظری در مورد اینکه چگونه مشخصات شتاب دهنده بر معیار LLM تأثیر می گذارد ارائه می دهیم. ما همچنین تأثیر استقرار چندین نمونه در پشت یک نقطه پایانی واحد را نشان می‌دهیم. در نهایت، ما توصیه‌های عملی را برای تنظیم فرآیند استقرار SageMaker JumpStart به منظور هماهنگی با الزامات شما در مورد تأخیر، توان عملیاتی، هزینه و محدودیت‌های موجود در انواع نمونه ارائه می‌کنیم. همه نتایج محک زدن و همچنین توصیه ها بر اساس یک روش همه کاره است دفتر یادداشت که بتوانید با مورد استفاده خود سازگار شوید.

بنچمارک نقطه پایانی مستقر شده است

شکل زیر کمترین مقدار تاخیر (سمت چپ) و بالاترین توان عملیاتی (راست) را برای پیکربندی‌های استقرار در انواع مدل‌ها و انواع نمونه نشان می‌دهد. نکته مهم این است که هر یک از این استقرارهای مدل از تنظیمات پیش‌فرض استفاده می‌کنند که توسط SageMaker JumpStart با توجه به شناسه مدل و نوع نمونه مورد نظر برای استقرار ارائه شده است.

این مقادیر تأخیر و خروجی مربوط به بارهای با 256 توکن ورودی و 256 توکن خروجی است. پیکربندی کمترین تأخیر، ارائه مدل به یک درخواست همزمان را محدود می‌کند و بالاترین پیکربندی توان عملیاتی، تعداد ممکن درخواست‌های همزمان را به حداکثر می‌رساند. همانطور که در بنچمارک خود می بینیم، افزایش درخواست های همزمان به طور یکنواخت باعث افزایش توان عملیاتی با کاهش بهبود برای درخواست های همزمان بزرگ می شود. علاوه بر این، مدل ها به طور کامل در نمونه پشتیبانی شده خرد می شوند. برای مثال، از آنجایی که نمونه ml.g5.48xlarge دارای 8 پردازنده گرافیکی است، تمام مدل‌های SageMaker JumpStart که از این نمونه استفاده می‌کنند، با استفاده از موازی‌سازی تانسور در هر هشت شتاب‌دهنده موجود، خرد می‌شوند.

می‌توانیم به چند نکته از این رقم اشاره کنیم. اول، همه مدل ها در همه نمونه ها پشتیبانی نمی شوند. برخی از مدل‌های کوچک‌تر، مانند Falcon 7B، از Sharding مدل پشتیبانی نمی‌کنند، در حالی که مدل‌های بزرگ‌تر نیاز به منابع محاسباتی بالاتری دارند. دوم، با افزایش شاردینگ، عملکرد معمولاً بهبود می‌یابد، اما ممکن است لزوماً برای مدل‌های کوچک بهبود نیابد. این به این دلیل است که مدل‌های کوچکی مانند 7B و 13B وقتی در شتاب‌دهنده‌های بیش از حد خرد می‌شوند، هزینه‌های ارتباطی قابل توجهی را متحمل می‌شوند. بعداً در این مورد عمیق تر بحث می کنیم. در نهایت، نمونه‌های ml.p4d.24xlarge به دلیل بهبود پهنای باند حافظه A100 نسبت به پردازنده‌های گرافیکی A10G، توان عملیاتی قابل‌توجهی بهتری دارند. همانطور که بعداً بحث خواهیم کرد، تصمیم برای استفاده از یک نوع نمونه خاص به نیازهای استقرار شما، از جمله تأخیر، توان عملیاتی و محدودیت‌های هزینه بستگی دارد.

چگونه می توانید این مقادیر پیکربندی کمترین تأخیر و بالاترین توان عملیاتی را بدست آورید؟ بیایید با ترسیم تاخیر در مقابل توان برای نقطه پایانی Llama 2 7B در یک نمونه ml.g5.12xlarge برای محموله ای با ۲۵۶ نشانه ورودی و ۲۵۶ نشانه خروجی، همانطور که در منحنی زیر مشاهده می شود، شروع کنیم. یک منحنی مشابه برای هر نقطه پایانی LLM مستقر شده وجود دارد.

با افزایش همزمانی، توان عملیاتی و تأخیر نیز به طور یکنواخت افزایش می یابد. بنابراین، کمترین نقطه تأخیر در مقدار درخواست همزمان 1 رخ می دهد و شما می توانید با افزایش درخواست های همزمان، توان عملیاتی سیستم را به طور مقرون به صرفه افزایش دهید. یک "زانو" متمایز در این منحنی وجود دارد، جایی که بدیهی است که افزایش توان عملیاتی مرتبط با همزمانی اضافی بر افزایش تاخیر مرتبط بیشتر نیست. محل دقیق این زانو به موارد خاص بستگی دارد. برخی از پزشکان ممکن است زانو را در نقطه ای تعریف کنند که از نیاز تاخیری از پیش تعیین شده فراتر رفته است (مثلاً 100 ms/token)، در حالی که برخی دیگر ممکن است از معیارهای تست بار و روش های تئوری صف مانند قانون نیمه تأخیر استفاده کنند، و دیگران ممکن است از آن استفاده کنند. مشخصات شتاب دهنده نظری

همچنین توجه داشته باشیم که حداکثر تعداد درخواست‌های همزمان محدود است. در شکل قبل، ردیابی خط با 192 درخواست همزمان به پایان می رسد. منبع این محدودیت محدودیت زمانی فراخوانی SageMaker است که در آن SageMaker یک پاسخ فراخوانی را پس از 60 ثانیه به پایان می رساند. این تنظیم مختص حساب است و برای یک نقطه پایانی فردی قابل تنظیم نیست. برای LLM ها، تولید تعداد زیادی توکن خروجی می تواند چند ثانیه یا حتی چند دقیقه طول بکشد. بنابراین، بارهای ورودی یا خروجی بزرگ می تواند باعث شکست درخواست های فراخوانی شود. علاوه بر این، اگر تعداد درخواست‌های همزمان بسیار زیاد باشد، بسیاری از درخواست‌ها زمان‌های صف زیادی را تجربه می‌کنند که باعث ایجاد محدودیت ۶۰ ثانیه‌ای می‌شود. برای هدف این مطالعه، ما از محدودیت زمانی برای تعریف حداکثر توان عملیاتی ممکن برای استقرار مدل استفاده می‌کنیم. نکته مهم، اگرچه یک نقطه پایانی SageMaker ممکن است تعداد زیادی درخواست همزمان را بدون مشاهده مهلت زمانی پاسخ فراخوانی انجام دهد، ممکن است بخواهید حداکثر درخواست‌های همزمان را با توجه به زانو در منحنی تأخیر-درآمد تعریف کنید. این احتمالاً نقطه‌ای است که در آن شروع به بررسی مقیاس‌بندی افقی می‌کنید، که در آن یک نقطه پایانی نمونه‌های متعددی را با کپی‌های مدل ارائه می‌کند و درخواست‌های ورودی را بین کپی‌ها توازن می‌کند تا از درخواست‌های همزمان بیشتر پشتیبانی کند.

با برداشتن این یک قدم جلوتر، جدول زیر حاوی نتایج محک زدن برای پیکربندی‌های مختلف برای مدل Llama 2 7B، از جمله تعداد مختلف نشانه‌های ورودی و خروجی، انواع نمونه‌ها و تعداد درخواست‌های همزمان است. توجه داشته باشید که شکل قبل فقط یک سطر از این جدول را ترسیم می کند.

ما برخی از الگوهای اضافی را در این داده ها مشاهده می کنیم. با افزایش اندازه زمینه، تاخیر افزایش می یابد و توان عملیاتی کاهش می یابد. به عنوان مثال، در ml.g5.2xlarge با همزمانی 1، توان عملیاتی 30 توکن در ثانیه است که تعداد کل توکن ها 512 باشد، در مقابل 20 توکن در ثانیه اگر تعداد کل توکن ها 4,096 باشد. این به این دلیل است که پردازش ورودی بزرگتر به زمان بیشتری نیاز دارد. همچنین می‌توانیم ببینیم که افزایش قابلیت GPU و اشتراک‌گذاری بر حداکثر توان عملیاتی و حداکثر درخواست‌های همزمان پشتیبانی شده تأثیر می‌گذارد. جدول نشان می دهد که Llama 2 7B دارای مقادیر حداکثر توان عملیاتی متفاوتی برای انواع نمونه های مختلف است و این مقادیر حداکثر توان عملیاتی در مقادیر مختلف درخواست های همزمان رخ می دهد. این ویژگی‌ها باعث می‌شود یک پزشک ML هزینه یک نمونه را نسبت به نمونه دیگر توجیه کند. برای مثال، با توجه به نیاز به تأخیر کم، پزشک ممکن است یک نمونه ml.g5.12xlarge (4 پردازنده گرافیکی A10G) را نسبت به یک نمونه ml.g5.2xlarge (1 GPU A10G) انتخاب کند. اگر نیاز به توان عملیاتی بالا داده شود، استفاده از یک نمونه ml.p4d.24xlarge (8 پردازنده گرافیکی A100) با اشتراک گذاری کامل تنها در صورت همزمانی بالا قابل توجیه است. با این حال، توجه داشته باشید که بارگذاری چندین مؤلفه استنتاج یک مدل 7B در یک نمونه ml.p4d.24xlarge اغلب مفید است. چنین پشتیبانی چند مدلی بعداً در این پست مورد بحث قرار می گیرد.

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

درک مشخصات شتاب دهنده

انتخاب سخت افزار مناسب برای استنتاج LLM به شدت به موارد استفاده خاص، اهداف تجربه کاربر و LLM انتخاب شده بستگی دارد. این بخش تلاش می‌کند تا درک درستی از زانو در منحنی تأخیر - توان با توجه به اصول سطح بالا بر اساس مشخصات شتاب‌دهنده ایجاد کند. این اصول به تنهایی برای تصمیم گیری کافی نیستند: معیارهای واقعی ضروری هستند. عبارت دستگاه در اینجا برای در بر گرفتن تمام شتاب دهنده های سخت افزاری ML استفاده می شود. ما ادعا می کنیم که زانو در منحنی تاخیر-عملکرد توسط یکی از دو عامل هدایت می شود:

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

ما معمولاً ترجیح می‌دهیم توسط عامل دوم محدود شویم، زیرا این بدان معناست که منابع شتاب‌دهنده اشباع شده‌اند. اساساً شما منابعی را که برای آن هزینه کرده اید به حداکثر می رسانید. بیایید این ادعا را با جزئیات بیشتری بررسی کنیم.

حافظه پنهان KV و حافظه دستگاه

مکانیسم‌های استاندارد توجه ترانسفورماتور توجه را برای هر توکن جدید در برابر تمام نشانه‌های قبلی محاسبه می‌کنند. اکثر سرورهای مدرن ML کلیدهای توجه و مقادیر را در حافظه دستگاه (DRAM) ذخیره می کنند تا از محاسبه مجدد در هر مرحله جلوگیری کنند. به این می گویند این حافظه پنهان KV، و با اندازه دسته و طول توالی رشد می کند. این تعریف می‌کند که چه تعداد از درخواست‌های کاربر را می‌توان به صورت موازی ارائه کرد و اگر رژیم محدود محاسبه در سناریوی دومی که قبلا ذکر شد، با توجه به DRAM موجود، هنوز برآورده نشده باشد، زانو را در منحنی تأخیر-درآمد تعیین می‌کند. فرمول زیر یک تقریب تقریبی برای حداکثر اندازه کش KV است.

در این فرمول، B اندازه دسته و N تعداد شتاب دهنده ها است. برای مثال، مدل Llama 2 7B در FP16 (2 بایت/پارامتر) که روی یک پردازنده گرافیکی A10G (24 گیگابایت DRAM) ارائه می‌شود، تقریباً 14 گیگابایت مصرف می‌کند و 10 گیگابایت برای حافظه نهان KV باقی می‌ماند. با وصل کردن طول متن کامل مدل (N = 4096) و پارامترهای باقیمانده (n_layers=32، n_kv_attention_heads=32، و d_attention_head=128)، این عبارت نشان می‌دهد که ما به دلیل محدودیت‌های DRAM به اندازه دسته‌ای از چهار کاربر به صورت موازی محدود شده‌ایم. . اگر معیارهای مربوطه را در جدول قبلی مشاهده کنید، این یک تقریب خوب برای زانوی مشاهده شده در این منحنی تاخیر-عملکرد است. روش هایی مانند توجه پرس و جو گروهی (GQA) می تواند اندازه کش KV را کاهش دهد، در مورد GQA با همان عامل تعداد هدهای KV را کاهش می دهد.

شدت حسابی و پهنای باند حافظه دستگاه

رشد قدرت محاسباتی شتاب دهنده های ML از پهنای باند حافظه آنها پیشی گرفته است، به این معنی که آنها می توانند محاسبات بیشتری را روی هر بایت داده در مدت زمانی که برای دسترسی به آن بایت نیاز است انجام دهند.

La شدت حسابییا نسبت عملیات محاسباتی به دسترسی‌های حافظه، برای یک عملیات تعیین می‌کند که آیا با پهنای باند حافظه یا ظرفیت محاسباتی روی سخت‌افزار انتخاب‌شده محدود است یا خیر. به عنوان مثال، یک پردازنده گرافیکی A10G (خانواده نوع نمونه g5) با 70 TFLOPS FP16 و 600 گیگابایت بر ثانیه پهنای باند می تواند تقریباً 116 عملیات در هر بایت را محاسبه کند. یک پردازنده گرافیکی A100 (خانواده نوع نمونه p4d) می تواند تقریباً 208 عملیات در بایت را محاسبه کند. اگر شدت محاسباتی برای یک مدل ترانسفورماتور کمتر از آن مقدار باشد، محدود به حافظه است. اگر بالاتر باشد، محدود به محاسبه است. مکانیسم توجه برای Llama 2 7B به 62 عملیات در بایت برای اندازه دسته 1 نیاز دارد (برای توضیح، رجوع کنید به راهنمای استنباط و عملکرد LLM) یعنی محدود به حافظه است. هنگامی که مکانیسم توجه محدود به حافظه است، FLOPS های گران قیمت استفاده نمی شوند.

دو راه برای استفاده بهتر از شتاب دهنده و افزایش شدت حسابی وجود دارد: کاهش دسترسی های حافظه مورد نیاز برای عملیات (این چیزی است که فلش توجه تمرکز می کند) یا اندازه دسته را افزایش می دهد. با این حال، اگر DRAM ما برای نگهداری حافظه نهان KV مربوطه بسیار کوچک است، ممکن است نتوانیم اندازه دسته خود را به اندازه کافی افزایش دهیم تا به یک رژیم محاسباتی برسیم. یک تقریب خام از اندازه بحرانی بچ B* که رژیم‌های محاسباتی را از رژیم‌های محدود به حافظه برای استنتاج رمزگشای استاندارد GPT جدا می‌کند، با عبارت زیر توصیف می‌شود، که در آن A_mb پهنای باند حافظه شتاب‌دهنده، A_f FLOPS شتاب‌دهنده، و N عدد است. از شتاب دهنده ها این اندازه بحرانی دسته ای را می توان با یافتن جایی که زمان دسترسی به حافظه برابر با زمان محاسبه است به دست آورد. رجوع شود به این پست وبلاگ برای درک معادله 2 و مفروضات آن با جزئیات بیشتر.

این همان نسبت عملیات/بایتی است که قبلاً برای A10G محاسبه کرده بودیم، بنابراین اندازه دسته بحرانی در این GPU 116 است. یکی از راه‌های نزدیک شدن به این اندازه نظری و بحرانی دسته، افزایش شاردینگ مدل و تقسیم حافظه نهان در شتاب‌دهنده‌های بیشتر N است. این به طور موثر ظرفیت کش KV و همچنین اندازه دسته محدود به حافظه را افزایش می دهد.

یکی دیگر از مزایای اشتراک گذاری مدل، تقسیم پارامتر مدل و کار بارگذاری داده در N شتاب دهنده است. این نوع شاردینگ نوعی موازی سازی مدل است که به آن نیز گفته می شود موازی تانسور. به طور ساده، N برابر پهنای باند حافظه و توان محاسباتی در مجموع وجود دارد. با فرض اینکه هیچ گونه سرباری (ارتباطات، نرم افزار و غیره) وجود نداشته باشد، این امر باعث کاهش تأخیر رمزگشایی به ازای هر توکن به میزان N می شود، اگر به حافظه محدود شده باشیم، زیرا تأخیر رمزگشایی رمز در این رژیم به زمان بارگذاری مدل محدود می شود. وزن و کش با این حال، در زندگی واقعی، افزایش درجه اشتراک گذاری منجر به افزایش ارتباطات بین دستگاه ها برای اشتراک گذاری فعال سازی های میانی در هر لایه مدل می شود. این سرعت ارتباطی توسط پهنای باند اتصال دستگاه محدود می شود. تخمین دقیق تأثیر آن دشوار است (برای جزئیات، نگاه کنید به موازی سازی مدل) اما این می تواند در نهایت مانع از ایجاد مزایا شود یا عملکرد را بدتر کند - این به ویژه برای مدل های کوچکتر صادق است، زیرا انتقال داده های کوچکتر منجر به نرخ انتقال کمتر می شود.

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

یک پیکربندی استقرار نقطه پایانی را انتخاب کنید

بسیاری از LLM های توزیع شده توسط SageMaker JumpStart از آن استفاده می کنند متن-نسل-استنتاج (TGI) ظرف SageMaker برای سرویس مدل جدول زیر نحوه تنظیم انواع پارامترهای سرویس مدل را مورد بحث قرار می‌دهد تا بر سرویس‌دهی مدل تأثیر بگذارد که بر منحنی تأخیر-درآمد تأثیر می‌گذارد یا از نقطه پایانی در برابر درخواست‌هایی که نقطه پایانی را بیش از حد بارگذاری می‌کنند محافظت کند. اینها پارامترهای اولیه ای هستند که می توانید برای پیکربندی استقرار نقطه پایانی برای مورد استفاده خود استفاده کنید. مگر اینکه غیر از این مشخص شده باشد، از پیش فرض استفاده می کنیم پارامترهای بار تولید متن و متغیرهای محیطی TGI.

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

این امکان وجود دارد که تجزیه و تحلیل‌های معیار تأخیر LLM را به تأخیر پیش پر کردن، تأخیر رمزگشایی و تأخیر صف تفکیک کنید. زمان مصرف شده توسط هر یک از این مؤلفه ها اساساً ماهیت متفاوتی دارد: پیش پر کردن یک محاسبات یکباره است، رمزگشایی یک بار برای هر نشانه در دنباله خروجی رخ می دهد، و صف بندی شامل فرآیندهای دسته بندی سرور است. هنگامی که چندین درخواست همزمان در حال پردازش هستند، تفکیک تاخیرها از هر یک از این مؤلفه‌ها دشوار می‌شود، زیرا تأخیر تجربه شده توسط هر درخواست مشتری معین شامل تأخیرهای صف ناشی از نیاز به تکمیل درخواست‌های همزمان جدید و همچنین تأخیرهای صف ناشی از گنجاندن است. درخواست در فرآیندهای رمزگشایی دسته ای. به همین دلیل، این پست بر تأخیر پردازش انتها به انتها تمرکز دارد. زانو در منحنی تأخیر- توان عملیاتی در نقطه اشباع رخ می دهد که در آن زمان تأخیر صف شروع به افزایش قابل توجهی می کند. این پدیده برای هر سرور استنتاج مدل رخ می دهد و توسط مشخصات شتاب دهنده هدایت می شود.

الزامات متداول در حین استقرار شامل برآوردن حداقل توان مورد نیاز، حداکثر تأخیر مجاز، حداکثر هزینه در ساعت و حداکثر هزینه برای تولید 1 میلیون توکن است. شما باید این الزامات را بر روی بارهایی که درخواست‌های کاربر نهایی را نشان می‌دهند، مشروط کنید. طراحی برای برآورده کردن این الزامات باید عوامل زیادی را در نظر بگیرد، از جمله معماری مدل خاص، اندازه مدل، انواع نمونه‌ها و تعداد نمونه (مقیاس‌بندی افقی). در بخش‌های بعدی، ما بر روی استقرار نقاط پایانی برای به حداقل رساندن تأخیر، به حداکثر رساندن توان عملیاتی و به حداقل رساندن هزینه تمرکز می‌کنیم. این تحلیل 512 توکن کل و 256 توکن خروجی را در نظر می گیرد.

تأخیر را به حداقل برسانید

تأخیر یک نیاز مهم در بسیاری از موارد استفاده بلادرنگ است. در جدول زیر، حداقل تاخیر برای هر مدل و هر نوع نمونه را بررسی می کنیم. با تنظیم می توانید به حداقل تاخیر دست یابید MAX_CONCURRENT_REQUESTS = 1.

برای دستیابی به حداقل تأخیر برای یک مدل، می‌توانید از کد زیر و جایگزین کردن شناسه مدل و نوع نمونه مورد نظر خود استفاده کنید:

from sagemaker.jumpstart.model import JumpStartModel model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.12xlarge", env={ "MAX_CONCURRENT_REQUESTS": "1", "MAX_INPUT_TOKENS": "256", "MAX_TOTAL_TOKENS": "512", },
)
predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True

توجه داشته باشید که اعداد تاخیر بسته به تعداد توکن های ورودی و خروجی تغییر می کنند. با این حال، فرآیند استقرار به جز متغیرهای محیطی یکسان باقی می ماند MAX_INPUT_TOKENS و MAX_TOTAL_TOKENS. در اینجا، این متغیرهای محیطی برای کمک به تضمین الزامات تأخیر نقطه پایانی تنظیم شده‌اند، زیرا توالی‌های ورودی بزرگ‌تر ممکن است الزامات تأخیر را نقض کنند. توجه داشته باشید که SageMaker JumpStart در حال حاضر سایر متغیرهای محیطی بهینه را هنگام انتخاب نوع نمونه فراهم می کند. به عنوان مثال، با استفاده از ml.g5.12xlarge تنظیم می شود SM_NUM_GPUS به 4 در محیط مدل.

به حداکثر رساندن توان عملیاتی

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

برای دستیابی به حداکثر توان برای یک مدل، می توانید از کد زیر استفاده کنید:

from sagemaker.jumpstart.model import JumpStartModel model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.12xlarge", env={ "MAX_CONCURRENT_REQUESTS": "128", # For your application, identify it from the benchmarking table with the maximum feasible concurrent requests. "MAX_INPUT_TOKENS": "256", "MAX_TOTAL_TOKENS": "512", },
)
predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True

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

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

هزینه را به حداقل برسانید

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

گزینه دوم برای به حداقل رساندن هزینه شامل به حداقل رساندن هزینه تولید 1 میلیون توکن است. این یک تبدیل ساده از جدولی است که قبلاً در مورد آن صحبت کردیم تا توان عملیاتی را به حداکثر برسانیم، جایی که می توانید ابتدا زمان تولید 1 میلیون توکن (1e6 / توان عملیاتی / 3600) را بر حسب ساعت محاسبه کنید. سپس می توانید این زمان را ضرب کنید تا 1 میلیون توکن با قیمت هر ساعت نمونه مشخص شده SageMaker تولید کنید.

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

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

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

در اینجا، نقاط پایانی Llama 2 7B و 13B را روی نمونه‌های ml.p4d.24xlarge با درجه‌های موازی تانسور (TP) 1، 2، 4، و 8 قرار می‌دهیم. برای وضوح رفتار مدل، هر یک از این نقاط پایانی فقط یک مدل را بارگیری می‌کنند.

تحلیل‌های قبلی ما قبلاً مزایای توان عملیاتی قابل‌توجهی را در نمونه‌های ml.p4d.24xlarge نشان داده‌اند، که اغلب به عملکرد بهتر از نظر هزینه برای تولید 1 میلیون توکن در خانواده نمونه g5 تحت شرایط بار درخواست همزمان بالا منجر می‌شود. این تجزیه و تحلیل به وضوح نشان می دهد که شما باید مبادله بین تقسیم مدل و تکرار مدل را در یک نمونه واحد در نظر بگیرید. یعنی یک مدل کاملاً خرد شده معمولاً بهترین استفاده از منابع محاسباتی ml.p4d.24xlarge برای خانواده‌های مدل 7B و 13B نیست. در واقع، برای خانواده مدل 7B، بهترین توان عملیاتی را برای یک ماکت مدل با درجه موازی تانسور 4 به جای 8 به دست می آورید.

از اینجا، می‌توانید برون‌یابی کنید که بالاترین پیکربندی توان عملیاتی برای مدل 7B شامل یک درجه موازی تانسور 1 با هشت مدل تکراری است، و بالاترین پیکربندی توان عملیاتی برای مدل 13B احتمالاً یک درجه موازی تانسور 2 با چهار مدل تکراری است. برای کسب اطلاعات بیشتر در مورد چگونگی انجام این کار، مراجعه کنید با استفاده از آخرین ویژگی های Amazon SageMaker هزینه های استقرار مدل را به طور متوسط ​​50٪ کاهش دهید، که استفاده از نقاط پایانی مبتنی بر مولفه استنتاج را نشان می دهد. به دلیل تکنیک‌های متعادل‌سازی بار، مسیریابی سرور و اشتراک‌گذاری منابع CPU، ممکن است به طور کامل به بهبود توان عملیاتی دقیقاً برابر با تعداد کپی‌ها برابر با توان یک ماکت نرسید.

مقیاس بندی افقی

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

model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", instance_type="ml.g5.2xlarge",
)
predictor = model.deploy( accept_eula=False, # Change EULA acceptance to True initial_instance_count = 3,
)

جدول زیر افزایش توان عملیاتی را به عنوان ضریب تعداد نمونه ها برای مدل Llama 2 7B نشان می دهد.

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

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

با درخواست های همزمان نقطه پایانی را فراخوانی کنید

فرض کنید دسته بزرگی از پرس‌و‌جوها دارید که می‌خواهید از آن‌ها برای تولید پاسخ‌ها از یک مدل مستقر در شرایط توان عملیاتی بالا استفاده کنید. به عنوان مثال، در بلوک کد زیر، لیستی از 1,000 بار را گردآوری می کنیم که هر بار پیلود درخواست تولید 100 توکن را دارد. در کل، ما درخواست تولید 100,000 توکن را داریم.

payload = { "inputs": "I believe the meaning of life is to ", "parameters": {"max_new_tokens": 100, "details": True},
}
total_requests = 1000
payloads = [payload,] * total_requests

هنگام ارسال تعداد زیادی درخواست به SageMaker Runtime API، ممکن است با خطاهای throttling مواجه شوید. برای کاهش این مشکل، می‌توانید یک کلاینت زمان اجرا SageMaker سفارشی ایجاد کنید که تعداد تلاش‌های مجدد را افزایش می‌دهد. می توانید شی جلسه SageMaker به دست آمده را به هر یک از آنها ارائه دهید JumpStartModel سازنده یا sagemaker.predictor.retrieve_default اگر می‌خواهید یک پیش‌بینی‌کننده جدید را به یک نقطه پایانی که قبلاً مستقر شده است وصل کنید. در کد زیر، هنگام استقرار یک مدل Llama 2 با تنظیمات پیش‌فرض SageMaker JumpStart از این شی جلسه استفاده می‌کنیم:

import boto3
from botocore.config import Config
from sagemaker.session import Session
from sagemaker.jumpstart.model import JumpStartModel sagemaker_session = Session( sagemaker_runtime_client=boto3.client( "sagemaker-runtime", config=Config(connect_timeout=10, retries={"mode": "standard", "total_max_attempts": 20}), )
)
model = JumpStartModel( model_id="meta-textgeneration-llama-2-7b", model_version="3.*", sagemaker_session=sagemaker_session
)
predictor = model.deploy(accept_eula=False) # Change EULA acceptance to True

این نقطه پایانی مستقر شده است MAX_CONCURRENT_REQUESTS = 128 به صورت پیش فرض. در بلوک زیر، از کتابخانه آتی همزمان برای تکرار فراخوانی نقطه پایانی برای همه بارهای با 128 رشته کارگر استفاده می کنیم. حداکثر، نقطه پایانی 128 درخواست همزمان را پردازش می کند و هر زمان که یک درخواست پاسخی را برمی گرداند، مجری بلافاصله درخواست جدیدی را به نقطه پایانی ارسال می کند.

import time
from concurrent import futures concurrent_requests = 128 time_start = time.time()
with futures.ThreadPoolExecutor(max_workers=concurrent_requests) as executor: responses = list(executor.map(predictor.predict, payloads)) total_tokens = sum([response[0]["details"]["generated_tokens"] for response in responses])
token_throughput = total_tokens / (time.time() - time_start)

این منجر به تولید 100,000 توکن کل با توان عملیاتی 1255 توکن در ثانیه در یک نمونه ml.g5.2xlarge می شود. این کار تقریباً 80 ثانیه طول می کشد تا پردازش شود.

توجه داشته باشید که این مقدار توان به طور قابل توجهی با حداکثر توان برای Llama 2 7B در ml.g5.2xlarge در جداول قبلی این پست متفاوت است (486 توکن در ثانیه در 64 درخواست همزمان). این به این دلیل است که بار ورودی به جای 8 از 256 توکن استفاده می کند، تعداد توکن های خروجی به جای 100، 256 است، و تعداد توکن های کوچکتر اجازه 128 درخواست همزمان را می دهد. این آخرین یادآوری است که تمام اعداد تاخیر و توان عملیاتی وابسته به بار است! تغییر تعداد توکن‌های بار بر فرآیندهای دسته‌بندی در طول ارائه مدل تأثیر می‌گذارد، که به نوبه خود بر پیش‌پر کردن، رمزگشایی و زمان‌های صف برنامه شما تأثیر می‌گذارد.

نتیجه

در این پست، بنچمارک SageMaker JumpStart LLM از جمله Llama 2، Mistral و Falcon را ارائه کردیم. ما همچنین راهنمای بهینه‌سازی تأخیر، توان عملیاتی و هزینه را برای پیکربندی استقرار نقطه پایانی ارائه کردیم. می توانید با اجرای برنامه شروع کنید نوت بوک مرتبط مورد استفاده خود را محک بزنید.

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

 دکتر کایل اولریش یک دانشمند کاربردی با تیم آمازون SageMaker JumpStart است. علایق تحقیقاتی او شامل الگوریتم های یادگیری ماشین مقیاس پذیر، بینایی کامپیوتر، سری های زمانی، ناپارامتریک های بیزی و فرآیندهای گاوسی است. دکترای او از دانشگاه دوک است و مقالاتی در NeurIPS، Cell و Neuron منتشر کرده است.

Dr. ویوک مدان یک دانشمند کاربردی با تیم آمازون SageMaker JumpStart است. او دکترای خود را از دانشگاه ایلینویز در Urbana-Champaign گرفت و پژوهشگر پست دکترا در جورجیا تک بود. او یک محقق فعال در یادگیری ماشین و طراحی الگوریتم است و مقالاتی در کنفرانس های EMNLP، ICLR، COLT، FOCS و SODA منتشر کرده است.

دکتر آشیش ختان یک دانشمند ارشد کاربردی با Amazon SageMaker JumpStart است و به توسعه الگوریتم های یادگیری ماشین کمک می کند. او دکترای خود را از دانشگاه ایلینویز Urbana-Champaign گرفت. او یک محقق فعال در یادگیری ماشین و استنتاج آماری است و مقالات زیادی در کنفرانس های NeurIPS، ICML، ICLR، JMLR، ACL و EMNLP منتشر کرده است.

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

• محتوای مبتنی بر SEO و توزیع روابط عمومی. امروز تقویت شوید.
• PlatoData.Network Vertical Generative Ai. به خودت قدرت بده دسترسی به اینجا.
• PlatoAiStream. هوش وب 3 دانش تقویت شده دسترسی به اینجا.
• PlatoESG. کربن ، CleanTech، انرژی، محیط، خورشیدی، مدیریت پسماند دسترسی به اینجا.
• PlatoHealth. هوش بیوتکنولوژی و آزمایشات بالینی. دسترسی به اینجا.
• منبع: https://aws.amazon.com/blogs/machine-learning/benchmark-and-optimize-endpoint-deployment-in-amazon-sagemaker-jumpstart/