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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

به تکنیک‌های بهینه‌سازی مثل کارت‌های Pokémon نگاه نکنید؛ هدف جمع‌آوری همه آن‌ها نیست. هدف، به‌کارگیری تکنیکی است که مهم‌ترین محدودیت را برطرف کند و در عین حال الزامات کسب‌وکار برنامه را حفظ کند.

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

برای تغییر آماده شوید، نه برای بنچمارک امروز

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

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

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

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

سازمان‌ها بیش‌ازپیش به بسیاری از مدل‌های یکسان دسترسی دارند. تمایز پایدار از توانایی سازمان در تبدیل این هوشمندی به دستاوردهای کسب‌وکار ناشی می‌شود.

مدل هوشمندی را فراهم می‌کند؛ چارچوب سروینگ تعیین می‌کند آیا سازمان می‌تواند دستاوردها را به‌شکلی قابل‌اعتماد، مقرون‌به‌صرفه و در مقیاس گسترده ارائه کند یا نه.

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