طراحی یک مهار سرویس هوش مصنوعی که برای دوام ساخته شده است

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

این یک تغییر مهم است. در چند سال گذشته، بیشتر گفتگوهای هوش مصنوعی بر قابلیت مدل متمرکز شده است: مدل های بزرگتر، استدلال بهتر، پنجره های زمینه بزرگتر، امتیازهای معیار بالاتر. این پیشرفت ها فوق العاده بوده است. اما همانطور که هوش مصنوعی از آزمایش به سمت تولید حرکت می کند، سوال پیش روی رهبران شرکت تغییر کرده است - دیگر این نیست که "مدل چه کاری می تواند انجام دهد؟" - اکنون این است که "آیا می توانیم این اطلاعات را به طور قابل اعتماد، اقتصادی و در مقیاس ارائه کنیم؟"

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

برای مدیران فنی، این تغییر می‌کند که سرمایه‌گذاری در هوش مصنوعی به کجا باید انجام شود - و آنچه باید از معماری پشتیبانی کننده آن درخواست کنند.

با حجم کار شروع کنید نه مدل

هیچ مدل جهانی یا معماری هوش مصنوعی «بهترین» وجود ندارد. تنها راه حل مناسب برای مشکل کسب و کار وجود دارد.

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

حجم کار محدودیت ها را مشخص می کند. محدودیت ها باید معماری را تعیین کنند.

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

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

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

سیستم را مهندسی کنید، نه مدل را

زمانی که هوش مصنوعی به تولید برسد، تصمیمات مهندسی به ظاهر جدا شده بر یکدیگر تأثیر می گذارد. معماری سرویس بر استفاده از حافظه تأثیر می گذارد. مدیریت حافظه بر همزمانی تأثیر می گذارد. همزمانی دسته بندی و زمان بندی را شکل می دهد و زمان بندی بر استفاده و تأخیر GPU تأثیر می گذارد.

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

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

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

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

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

برای تغییر بسازید، نه معیار امروز

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

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

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

محققان EXL این چالش‌های تولید را با عمق بیشتری در سری EXL Engineering the Harness بررسی کرده‌اند. این بررسی می‌کند که چگونه معماری سرویس، مدیریت حافظه، زمان‌بندی، و بهینه‌سازی استنتاج با هم کار می‌کنند تا هوش مصنوعی سازمانی را کارآمدتر، مقیاس‌پذیرتر و از نظر اقتصادی پایدارتر کنند.

شرکت ها به طور فزاینده ای به بسیاری از مدل های مشابه دسترسی دارند. تمایز پایدار ناشی از این است که سازمان چقدر این هوش را به نتایج تجاری تبدیل می کند.

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

این محتوا توسط EXL تولید شده است. این توسط هیات تحریریه MIT Technology Review نوشته نشده است.