بهبود عملکرد مدل های فالکون با Amazon SageMaker | خدمات وب آمازون

چارچوب و پیکربندی بهینه برای میزبانی مدل‌های زبان بزرگ (LLM) برای برنامه‌های کاربردی هوش مصنوعی مولد متن چیست؟ علیرغم فراوانی گزینه‌ها برای ارائه به LLM، پاسخ به این سوال به دلیل اندازه مدل‌ها، معماری مدل‌های مختلف، الزامات عملکرد برنامه‌ها و موارد دیگر دشوار است. را آمازون SageMaker ظرف استنتاج مدل بزرگ (LMI). ارائه خدمات به LLM ها را با گرد هم آوردن مجموعه ای از چارچوب ها و تکنیک های مختلف که استقرار LLM ها را بهینه می کنند، آسان می کند. ظرف LMI دارای یک پشته خدمت قدرتمند به نام است سرویس DJL که برای LLM زمینه ای آگنوستیک است. این پارامترهای پیکربندی در سطح سیستم را فراهم می کند که می تواند برای استخراج بهترین عملکرد زیرساخت میزبانی برای یک LLM معین تنظیم شود. همچنین از بهینه‌سازی‌های اخیر مانند دسته‌بندی پیوسته، که به‌عنوان دسته‌بندی تکراری یا دسته‌ای چرخشی نیز شناخته می‌شود، پشتیبانی می‌کند، که پیشرفت‌های قابل‌توجهی در توان عملیاتی ایجاد می‌کند.

در اوایل پست، ما نشان دادیم که چگونه می توانید از کانتینر LMI برای استقرار مدل های خانواده فالکون در SageMaker استفاده کنید. در این پست، نحوه بهبود توان عملیاتی و تأخیر سرویس Falcon-40B با تکنیک‌هایی مانند بچینگ پیوسته را نشان می‌دهیم. ما همچنین درک بصری پارامترهای پیکربندی ارائه شده توسط ظرف SageMaker LMI را ارائه می دهیم که می تواند به شما کمک کند بهترین پیکربندی را برای برنامه دنیای واقعی خود پیدا کنید.

مبانی استنتاج مولد متن برای LLM

بیایید ابتدا به چند اصل اساسی در مورد نحوه انجام استنتاج برای LLM برای تولید متن نگاه کنیم.

پاس رو به جلو، فعال‌سازی‌ها و حافظه پنهان KV

با توجه به یک دنباله ورودی از نشانه ها، آنها در a اجرا می شوند forward pass در تمام لایه های LLM (مانند فالکون) برای تولید توکن بعدی. آ forward pass به فرآیند انتقال داده های ورودی از طریق شبکه عصبی برای تولید خروجی اشاره دارد. در مورد تولید متن، پاس رو به جلو شامل وارد کردن یک دانه یا زمینه اولیه به مدل زبان و تولید کاراکتر یا نشانه بعدی در دنباله است. برای تولید یک دنباله از متن، این فرآیند اغلب به صورت تکراری انجام می شود، به این معنی که برای هر مرحله یا موقعیت در دنباله خروجی تکرار می شود. در هر تکرار، مدل کاراکتر یا نشانه بعدی را تولید می کند که بخشی از متن تولید شده می شود و این روند تا زمانی ادامه می یابد که طول متن مورد نظر تولید شود.

تولید متن با مدل های زبانی مانند Falcon یا GPT هستند autoregressive. این به این معنی است که مدل در یک زمان یک توکن تولید می کند در حالی که روی توکن های تولید شده قبلی شرطی می شود. به عبارت دیگر، در هر تکرار، مدل متن تولید شده قبلی را به عنوان ورودی می گیرد و نشانه بعدی را بر اساس آن زمینه پیش بینی می کند. همانطور که در vLLM: سرویس دهی آسان، سریع و ارزان LLM با PagedAttentionدر این فرآیند رمزگشایی اتورگرسیو، تمام نشانه‌های ورودی به LLM تانسورهای کلید و ارزش خود را تولید می‌کنند و این تانسورها در حافظه GPU نگهداری می‌شوند تا توکن‌های بعدی تولید شوند. این تانسورهای کلید و مقدار ذخیره شده در حافظه پنهان اغلب به عنوان تانسور نامیده می شوند KV cache.

مراحل پیش پر کردن و رمزگشایی

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

مرحله پیش پر کردن شامل موارد زیر است:

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

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

مرحله رمزگشایی شامل موارد زیر است:

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

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

به مراجعه یک سیستم سرویس دهی توزیع شده برای مدل های مولد مبتنی بر ترانسفورماتور برای توضیح دقیق فرآیند

بهینه سازی توان عملیاتی با استفاده از دسته بندی پویا

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

• max_batch_delay = 100 - حداکثر تاخیر برای تجمع دسته ای در میلی ثانیه. مقدار پیش فرض 100 میلی ثانیه است.
• دسته_اندازه = 32 - اندازه دسته پویا. پیش فرض 1 است.

این اساساً نشان می‌دهد که DJLServing درخواست‌ها را در یک زمان ۱۰۰ میلی‌ثانیه در صف قرار می‌دهد یا اگر تعداد درخواست‌هایی که در صف قرار می‌گیرند به اندازه batch_size مشخص‌شده باشد، دسته برای استنتاج به باطن برنامه‌ریزی می‌شود. این به عنوان شناخته شده است dynamic batching. پویا است زیرا بسته به تعداد درخواست‌هایی که در آن مدت زمان اضافه شده است، اندازه دسته ممکن است در بین دسته‌ها تغییر کند. با این حال، از آنجایی که درخواست‌ها ممکن است ویژگی‌های متفاوتی داشته باشند (برای مثال، برخی از درخواست‌ها ممکن است به شکل 20 توکن ورودی و 500 نشانه خروجی باشند، در حالی که برخی دیگر ممکن است معکوس شوند، با 500 نشانه ورودی اما تنها 20 نشانه برای خروجی)، برخی از درخواست‌ها ممکن است پردازش سریعتر از سایرین در همان دسته انجام می شود. این می‌تواند منجر به استفاده ناکافی از GPU شود، در حالی که منتظر تمام درخواست‌های حین پرواز در دسته برای تکمیل مرحله رمزگشایی آن است، حتی اگر درخواست‌های اضافی در انتظار پردازش در صف باشد. نمودار زیر این فرآیند را نشان می دهد.

بهینه سازی توان با استفاده از بچینگ پیوسته

با continuous batching، همچنین به عنوان شناخته شده است iterative or rolling بچینگ، ما از تفاوت های بین مراحل پیش پر کردن و رمزگشایی استفاده می کنیم. برای فعال کردن بچینگ پیوسته، DJServing پیکربندی‌های اضافی زیر را طبق serving.properties ارائه می‌کند:

• موتور=MPI - ما شما را تشویق می کنیم که از موتور MPI برای بچینگ پیوسته استفاده کنید.
• option.rolling_batch=auto یا lmi-dist - توصیه می کنیم از خودکار استفاده کنید زیرا به طور خودکار مناسب ترین الگوریتم دسته ای نورد را همراه با سایر بهینه سازی ها در آینده انتخاب می کند.
• option.max_rolling_batch_size=32 - این تعداد درخواست های همزمان را محدود می کند. پیش فرض 32 است.

با دسته‌بندی پیوسته، پشته سرویس (DJLServing) منتظر تمام درخواست‌های حین پرواز در یک دسته برای تکمیل مرحله رمزگشایی خود نمی‌ماند. در عوض، در وقفه های منطقی (در پایان یک تکرار در مرحله رمزگشایی)، درخواست های اضافی را می کشد که در صف منتظر هستند در حالی که دسته فعلی هنوز در حال پردازش است (از این رو نام دسته نورد). این بررسی را برای درخواست های معلق در پایان هر تکرار مرحله رمزگشایی انجام می دهد. به یاد داشته باشید، برای هر درخواست، باید مرحله پیش پر کردن و سپس مرحله رمزگشایی متوالی را اجرا کنیم. از آنجایی که می‌توانیم تمام نشانه‌ها را از اعلان اولیه یک درخواست به صورت موازی برای مرحله پیش‌پر کردن آن پردازش کنیم، هر زمان که یک درخواست جدید وارد شود، مرحله رمزگشایی درخواست‌های حین پرواز دسته را موقتاً متوقف می‌کنیم—به طور موقت حافظه پنهان KV آن را ذخیره می‌کنیم. و فعال سازی در حافظه و اجرای مرحله prefill درخواست های جدید.

اندازه این کش را می توان با گزینه زیر پیکربندی کرد:

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

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

کنار هم قرار دادن همه اینها: چگونه در مورد استفاده از حافظه GPU فکر کنیم

توصیه می شود مدل خود را بارگیری کنید تا ببینید کدام پیکربندی برای مورد استفاده تجاری شما مقرون به صرفه است. برای ایجاد یک درک، اجازه دهید ردپای حافظه GPU ها را هنگام بارگیری مدل و هنگامی که درخواست های متوالی در یک دسته پردازشی پردازش می شوند، تجسم کنیم. برای این پست، بیایید فرض کنیم که مدل Falcon-40B را روی یکی از نمونه‌های نمونه G5 که با پردازنده‌های گرافیکی NVIDIA A10G، هر کدام با 24 گیگابایت حافظه، نصب شده‌اند، بارگذاری می‌کنیم. توجه داشته باشید که درک مشابهی برای انواع نمونه‌های p3، p4 و p5 که با سری‌های گرافیکی V100، A100 و H100 ارائه می‌شوند، قابل اعمال است.

در زیر نمای کلی از بدست آوردن مقدار تقریبی کل حافظه مورد نیاز برای سرویس Falcon-40B آمده است:

• اندازه مدل = تعداد پارامترهای مدل (40 میلیارد برای Falcon-40B) x 4 بایت در هر پارامتر (برای FP32) = 160 گیگابایت
• کل حافظه تقریبی مورد نیاز برای بارگیری Falcon-40B برای استنتاج = اندازه مدل (=160 گیگابایت) + حافظه پنهان KV (حافظه پنهان) (=*20 گیگابایت) + سربار حافظه اضافی توسط ML Frameworks (تقریباً 2 گیگابایت)

برای Falcon-40B، اگر مدل را با کمی کردن مدل به نوع داده bfloat16 (2 بایت) فشرده کنیم، اندازه مدل تقریباً 80 گیگابایت می شود. همانطور که می بینید، این حافظه هنوز بزرگتر از حافظه پشتیبانی شده توسط یک دستگاه شتاب دهنده است، بنابراین ما باید یک تکنیک پارتیشن بندی مدل (شاردینگ) را با یک روش خاص اتخاذ کنیم. موازی تانسور (TP) مدل را در چندین دستگاه شتاب دهنده نزدیک می کند و خرد می کند. بیایید فرض کنیم که g5.24xlarge را انتخاب کرده ایم که دارای 4 دستگاه GPU A10G است. اگر DJLServing (serving.properties) را با موارد زیر پیکربندی کنیم، می‌توان انتظار داشت که وزن مدل 80 گیگابایتی به طور مساوی در تمام 4 GPU تقسیم شود:

با tensor_parallel_degree با تنظیم روی 4، حدود 20 گیگابایت از حافظه 24 گیگابایتی GPU (تقریباً 84٪) حتی قبل از پردازش یک درخواست استفاده می شود. 16% باقیمانده از GPU برای کش KV برای درخواست های دریافتی استفاده می شود. این امکان وجود دارد که برای سناریوی کسب و کار شما و نیازهای تاخیر و توان عملیاتی آن، 2 تا 3 گیگابایت حافظه باقیمانده بیش از اندازه کافی باشد. در غیر این صورت، می توانید اندازه نمونه را به g5.48xlarge که دارای 8 پردازنده گرافیکی است و از tensor_parallel_degree روی 8 استفاده می کند، افزایش دهید. در چنین حالتی، تنها تقریباً 10 گیگابایت از حافظه 24 گیگابایتی موجود هر GPU برای وزن مدل استفاده می شود. حدود 60 درصد از GPU باقیمانده برای فعال سازی ها و حافظه نهان KV. به طور شهودی، می‌توانیم ببینیم که این پیکربندی ممکن است به ما اجازه دهد تا توان عملیاتی بالاتری داشته باشیم. علاوه بر این، به دلیل اینکه اکنون بافر بزرگتری داریم، می‌توانیم آن را افزایش دهیم max_rolling_batch_prefill_tokens و max_rolling_batch_size پارامترهایی برای بهینه سازی بیشتر توان عملیاتی این دو پارامتر با هم، تخصیص پیش‌پرداخت‌های فعال‌سازی و حافظه پنهان KV را برای مدل کنترل می‌کنند. با فرض اینکه شما بافر کافی برای حافظه نهان KV در حافظه GPU دارید، یک عدد بزرگتر برای این دو پارامتر به یک توان عملیاتی بزرگتر مربوط می شود.

دسته بندی مداوم با PagedAttention

PagedAttention یک الگوریتم بهینه‌سازی جدید است که توسط UC Berkeley ایجاد شده است که با تخصیص حافظه در صفحات یا بلوک‌های با اندازه ثابت، فرآیند دسته‌بندی پیوسته را با اجازه دادن به حافظه نهان توجه (کش KV) غیر پیوسته بهبود می‌بخشد. این الهام گرفته از حافظه مجازی و مفاهیم صفحه بندی مورد استفاده توسط سیستم عامل ها است.

همانطور که در vLLM در کاغذ، حافظه پنهان توجه هر دنباله از نشانه ها به بلوک ها تقسیم می شود و از طریق یک جدول بلوک به بلوک های فیزیکی نگاشت می شود. در طول محاسبه توجه، یک هسته PagedAttention می تواند از جدول بلوک ها برای واکشی موثر بلوک ها از حافظه فیزیکی استفاده کند. این منجر به کاهش قابل توجه اتلاف حافظه می شود و به اندازه دسته بزرگتر، افزایش استفاده از GPU و توان عملیاتی بالاتر اجازه می دهد.

مقایسه عملکرد

برای اطمینان از تست بار موثر پیکربندی استقرار خود، توصیه می‌شود با در نظر گرفتن سناریوی تجاری و تعریف واضح ویژگی‌های ورودی و خروجی برای برنامه مبتنی بر LLM شروع کنید. برای مثال، اگر روی یک مورد استفاده از خلاصه‌سازی مرکز تماس کار می‌کنید، ورودی می‌تواند شامل متن بزرگ‌تر باشد، مانند رونوشت چت 500 توکنی بین یک نماینده خدمات مشتری و یک مشتری، اما خروجی ممکن است نسبتا کوچک‌تر باشد، حدود 100 نشانه‌هایی که خلاصه‌ای از رونوشت را نشان می‌دهند. از سوی دیگر، اگر روی یک سناریوی تولید کد کار می‌کنید، ورودی می‌تواند به اندازه 15 توکن کوتاه باشد، مانند «یک پیاده‌سازی کارآمد در پایتون بنویسید برای توصیف همه منابع EC2، از جمله صفحه‌بندی»، اما خروجی می‌تواند بسیار زیاد باشد. بزرگتر، به 500 توکن می رسد. همچنین مهم است که در نظر بگیرید که آیا دستیابی به تاخیر کمتر یا به حداکثر رساندن توان عملیاتی اولویت اصلی برای سناریوی خاص شما است.

پس از به دست آوردن درک جامع از سناریوی کسب و کار، می توانید پیکربندی بهینه برای محیط میزبانی خود را تجزیه و تحلیل و تعیین کنید. در این زمینه، محیط میزبانی شامل عناصر کلیدی مختلفی از جمله نوع نمونه و سایر پارامترهای پیکربندی مانند تانسور_موازی_درجه, max_rolling_batch_size, max_rolling_batch_prefill_tokens، و بیشتر. هدف ما شناسایی مؤثرترین راه‌اندازی برای پشتیبانی از زمان پاسخ، توان عملیاتی و کیفیت خروجی مدل است.

در تجزیه و تحلیل خود، ما عملکرد را برای نشان دادن مزایای بچینگ پیوسته نسبت به بچینگ پویا سنتی محک زدیم. ما از پیکربندی‌هایی که در جدول زیر توضیح داده شده است در serving.properties برای دسته‌بندی پویا و دسته‌بندی تکراری، با استفاده از یک ظرف LMI در SageMaker استفاده کردیم.

دسته بندی پویا	بچینگ پیوسته	دسته بندی پیوسته با PagedAttention
موتور = پایتون option.model_id=tiiuae/falcon-40b option.tensor_parallel_degree=8 option.dtype=fp16 دسته_اندازه=4 max_batch_delay=100 option.trust_remote_code = درست است	موتور = MPI option.model_id = {{s3_url}} option.trust_remote_code = درست است option.tensor_parallel_degree = 8 option.max_rolling_batch_size = 32 option.rolling_batch = خودکار option.dtype = fp16 option.max_rolling_batch_prefill_tokens = 1024 option.paged_attention = نادرست	موتور = MPI option.model_id = {{s3_url}} option.trust_remote_code = درست است option.tensor_parallel_degree = 8 option.max_rolling_batch_size = 32 option.rolling_batch = خودکار option.dtype = fp16 option.max_rolling_batch_prefill_tokens = 1024 option.paged_attention = درست است

این دو پیکربندی برای Falcon-40B با نوع داده FP16 مستقر در ml.g5.48xlarge در چند سناریو مختلف که کاربردهای دنیای واقعی را نشان می‌دهند، محک زده شدند:

• تعداد کمی از نشانه های ورودی با تعداد زیادی توکن در حال تولید - در این سناریو تعداد توکن های ورودی 32 عدد ثابت شد و 128 توکن جدید تولید شد.

استراتژی بچینگ	توان عملیاتی (توکن ها/ثانیه)	تأخیر p90 (ثانیه)
دسته بندی پویا	5.53	58.34
بچینگ پیوسته	56.04	4.74
دسته بندی پیوسته با PagedAttention	59.18	4.76

• یک ورودی بزرگ با تعداد کمی توکن در حال تولید – در اینجا، تعداد نشانه‌های ورودی را 256 مشخص می‌کنیم و از LLM می‌خواهیم ورودی را به 32 توکن خلاصه کند.

استراتژی بچینگ	توان عملیاتی (توکن ها/ثانیه)	تأخیر p90 (ثانیه)
دسته بندی پویا	19.96	59.31
بچینگ پیوسته	46.69	3.88
دسته بندی پیوسته با PagedAttention	44.75	2.67

می‌بینیم که دسته‌بندی پیوسته با PagedAttention در سناریوی 10 و 1 برابر در سناریوی 2.3 در مقایسه با استفاده از دسته‌بندی پویا در SageMaker هنگام استفاده از کانتینر LMI، بهبود توان عملیاتی را 2 برابر بیشتر می‌کند.

نتیجه

در این پست، نحوه استفاده LLMها از حافظه را بررسی کردیم و توضیح دادیم که چگونه دسته‌بندی پیوسته با استفاده از یک ظرف LMI در SageMaker، توان عملیاتی را بهبود می‌بخشد. ما مزایای بچینگ پیوسته برای Falcon-40B را با استفاده از ظرف LMI در SageMaker با نشان دادن نتایج معیار نشان دادیم. می توانید کد را در آن پیدا کنید GitHub repo.

---

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

ابهی شیوادیتیا یک معمار ارشد راه حل در AWS است که با سازمان های سازمانی استراتژیک جهانی برای تسهیل پذیرش خدمات AWS در زمینه هایی مانند هوش مصنوعی، محاسبات توزیع شده، شبکه و ذخیره سازی کار می کند. تخصص او در یادگیری عمیق در حوزه های پردازش زبان طبیعی (NLP) و بینایی کامپیوتر است. Abhi به مشتریان کمک می کند تا مدل های یادگیری ماشینی با کارایی بالا را در اکوسیستم AWS به کار گیرند.

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

پیناک پانیگراهی با مشتریان برای ایجاد راه حل های مبتنی بر یادگیری ماشین برای حل مشکلات استراتژیک کسب و کار در AWS کار می کند. زمانی که مشغول یادگیری ماشینی نباشد، می توان او را در حال پیاده روی، خواندن کتاب یا تماشای ورزش پیدا کرد.

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

چینگ لان مهندس توسعه نرم افزار در AWS است. او روی چندین محصول چالش برانگیز در آمازون کار کرده است، از جمله راه حل های استنتاج ML با کارایی بالا و سیستم ثبت گزارش با کارایی بالا. تیم Qing با موفقیت اولین مدل میلیارد پارامتر را در تبلیغات آمازون با تاخیر بسیار کم مورد نیاز راه اندازی کرد. Qing دانش عمیقی در مورد بهینه سازی زیرساخت و شتاب یادگیری عمیق دارد.

• محتوای مبتنی بر SEO و توزیع روابط عمومی. امروز تقویت شوید.
• PlatoData.Network Vertical Generative Ai. به خودت قدرت بده دسترسی به اینجا.
• PlatoAiStream. هوش وب 3 دانش تقویت شده دسترسی به اینجا.
• PlatoESG. کربن ، CleanTech، انرژی، محیط، خورشیدی، مدیریت پسماند دسترسی به اینجا.
• PlatoHealth. هوش بیوتکنولوژی و آزمایشات بالینی. دسترسی به اینجا.
• منبع: https://aws.amazon.com/blogs/machine-learning/improve-performance-of-falcon-models-with-amazon-sagemaker/