مدل‌های مخلوطی از خبرگان (Mixture-of-Experts) بی‌سروصدا اقتصاد هوش مصنوعی را بازنویسی می‌کنند

وقتی گوگل دیپ‌مایند (Google DeepMind) گزارش فنی Gemini 1.5 را منتشر کرد، یک جزئیات بسیاری از پژوهشگران را غافلگیر کرد: این مدل از معماری Mixture-of-Experts استفاده می‌کند که در هر استنتاج تنها کسری از پارامترهایش را فعال می‌کند. اندکی بعد، Mixtral 8x7B شرکت Mistral AI نشان داد که یک تیم نسبتاً کوچک می‌تواند مدلی رقابتی با معماری‌های متراکم بسیار بزرگتر را با کسری از هزینه محاسباتی منتشر کند. هر دو لحظه به یک تغییر ساختاری اشاره دارند: معماری‌های MoE از یک کنجکاوی تحقیقاتی به یک استاندارد تولیدی در حال تبدیل شدن هستند.

کاری که Mixture-of-Experts واقعاً انجام می‌دهد

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

Mixture-of-Experts این معادله را می‌شکند. معماری، لایه‌های پیشخور (feed-forward) مدل را به مجموعه‌ای از زیرشبکه‌های «خبره» تقسیم می‌کند — معمولاً بین ۸ تا ۶۴ عدد از آنها. سپس یک شبکه‌ی دروازه‌بانی سبک انتخاب می‌کند که کدام ۲ یا ۴ خبره برای هر تکن فعال شوند. بقیه بیکار می‌مانند.

نتیجه: یک مدل با ۴۶ میلیارد پارامتر کل ممکن است تنها ۱۲ میلیارد پارامتر را در هر تکن فعال کند. شما ظرفیت یک مدل ۴۶ میلیاردی — دانش گسترده و سطح استدلال آن — را با پرداخت هزینه استنتاج یک مدل ۱۲ میلیاردی به دست می‌آورید. این پیشنهاد اصلی اقتصادی معماری است.

معماری پشت اعداد

مکانیزم دروازه‌بانی جایی است که بیشتر پیچیدگی مهندسی در آن قرار دارد. پیاده‌سازی‌های اولیه MoE از «عدم توازن بار» رنج می‌بردند — برخی خبره‌ها بسیار بیشتر از بقیه مسیریابی می‌شدند و بیشتر پارامترها به طور مزمن کمتر استفاده می‌شدند. پیاده‌سازی‌های مدرن این مشکل را با استفاده از تلفات (losses) کمکی متعادل‌ساز بار در طول آموزش حل می‌کنند و باعث می‌شوند مسیریاب تکن‌ها را به طور یکنواخت‌تری بین خبره‌ها توزیع کند.

مدل Mixtral 8x7B از ۸ خبره در هر لایه با استراتژی مسیریابی «بازده ۲» (top-2) استفاده می‌کند: هر تکن دو خبره با بهترین تطابق را انتخاب کرده و خروجی‌های آنها از طریق مجموع وزنی ترکیب می‌شود. تعداد مؤثر پارامترها روی هر تکن حدود ۱۳ میلیارد است، در حالی که کل مدل ۴۶ میلیارد پارامتر دارد. عملکرد مدل در بیشتر بنچمارک‌ها به یک مدل متراکم ۳۰ تا ۴۰ میلیاردی نزدیک است.

مقاله Switch Transformer گوگل نشان داد که می‌توان یک مدل MoE را تا بیش از یک تریلیون پارامتر مقیاس‌دهی کرد و در عین حال محاسبات استنتاج را در سطوح قابل مدیریت نگه داشت. گمان می‌رود که GPT-4 از معماری MoE استفاده می‌کند، هرچند OpenAI هرگز جزئیات آن را تأیید نکرده است.

تغییرات در سطح زیرساخت

مزایای MoE در محاسبات با یک بده‌بستان واقعی همراه است: ردپای حافظه (memory footprint). شما باید همه خبره‌ها را در حافظه بارگذاری کنید، حتی اگر تنها چند عدد از آنها در هر تکن فعال شوند. یک مدل متراکم ۱۳ میلیاردی و یک مدل MoE 46 میلیاردی ممکن است از نظر FLOPs در هر تکن هزینه مشابهی داشته باشند، اما مدل MoE به حافظه GPU بسیار بیشتری برای میزبانی نیاز دارد.

این موضوع نیازمندی‌های سخت‌افزاری برای سرویس‌دهی به این مدل‌ها را شکل می‌دهد. مدل‌های متراکم به راحتی روی تعداد کمتری GPU جا می‌گیرند؛ مدل‌های MoE اغلب نیاز به توزیع خبره‌ها در چندین دستگاه دارند که سربار ارتباط بین دستگاه‌ها را به همراه دارد. برای استنتاج تک‌دستگاهی یا استقرار در لبه (edge)، مدل‌های متراکم همچنان برتری دارند. برای سرویس‌دهی API در مقیاس بزرگ که در آن درخواست‌های بسیاری را می‌توان دسته‌بندی (batch) کرد و خبره‌ها را در حافظه VRAM ذخیره نمود، معماری‌های MoE اغلب از نظر هزینه به ازای هر تکن برنده هستند.

نتیجه عملی: مدل‌های MoE برای سرویس‌دهی ابری در مقیاس بهینه شده‌اند، نه برای اجرای محلی روی سخت‌افزار مصرفی. یک مدل MoE 46 میلیاردی حتی در حالت کوانتیزه (quantized) به بیش از ۲۴ گیگابایت VRAM نیاز دارد، در حالی که یک مدل متراکم با عملکرد مشابه ممکن است در ۱۶ گیگابایت جا بگیرد.

چرا این موضوع شکل‌دهی به سازندگان مدل‌های مرزی را تغییر می‌دهد

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

به همین دلیل است که Mistral — تیمی با کمتر از ۲۰ پژوهشگر در زمان انتشار Mixtral — توانست مدلی تولید کند که با Llama 2 70B شرکت متا رقابت کرد. معماری به آنها اهرم (leverage) داد: پارامترهای بیشتر، هزینه آموزش کمتر، هزینه سرویس‌دهی کمتر به ازای هر تکن. این نیاز سرمایه‌ای برای ساخت مدل‌های مرزی رقابتی را کاهش داد.

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

پرسش‌های باز

تحقیق روی MoE هنوز به نتایج نهایی نرسیده است. مکانیزم مسیریابی همچنان یک حوزه فعال است: مسیریابی پراکنده یادگیری‌شده، ادغام خبره‌ها و تعداد پویای خبره‌ها همگی تحت بررسی هستند. کار قابل توجهی روی این موضوع انجام می‌شود که آیا مدل‌های MoE به اندازه مدل‌های متراکم با تعداد پارامتر فعال یکسان تعمیم می‌یابند، به ویژه در کارهایی که نیاز به یکپارچه‌سازی دانش در حوزه‌های مختلف در یک گذر پیشرو (forward pass) دارند.

استدلال زمینه‌بلند (Long-context reasoning) حوزه دیگری است که مورد بررسی قرار می‌گیرد. اگر تکن‌های یک سند طولانی به خبره‌های مختلف مسیریابی شوند، مدل ممکن است نتواند زمینه منسجم را به تمیزی یک مدل متراکم که در آن همه پارامترها همه چیز را با هم پردازش می‌کنند، حفظ کند. پژوهشگران در حال آزمایش معماری‌های مختلف توجه-به-علاوه-خبره (attention-plus-expert) برای مقابله با این مشکل هستند.

بازده سرویس‌دهی در اندازه‌های دسته کوچک (batch sizes) همچنان یک ضعف است. اگر شما یک برنامه تک‌کاربره با هم‌روندی کم اجرا می‌کنید، مزایای دسته‌بندی که MoE را در مقیاس مقرون‌به‌صرفه می‌کند از بین می‌روند — و شما با سربار کامل حافظه و بدون صرفه‌جویی در محاسبات استهلاکی مواجه هستید.

آنچه باید دنبال کنید

روند MoE در هر دو مدل متن‌باز (open) و بسته در حال شتاب است. انتظار داشته باشید که آزمایشگاه‌های بیشتری معماری‌های MoE را به عنوان قالب اصلی انتشار خود عرضه کنند، ابزارهای بیشتری برای کوانتیزاسیون آگاه از خبره (expert-aware quantization) که جریمه حافظه را کاهش می‌دهد، و تحقیقات بیشتری روی الگوریتم‌های مسیریابی که تعمیم را بدون قربانی کردن کارایی بهبود می‌بخشند.

برای توسعه‌دهندگانی که روی این مدل‌ها از طریق API می‌سازند، معماری تا حد زیادی نامرئی است — یک مدل MoE همان طور که یک مدل متراکم پاسخ می‌دهد، پاسخ می‌دهد. اما برای تیم‌هایی که ارزیابی می‌کنند آیا خودشان میزبانی کنند یا Fine-tuning انجام دهند، بده‌بستان حافظه-محاسبه برای برنامه‌ریزی سخت‌افزاری مرکزی است. یک مدل MoE 46 میلیاردی و یک مدل متراکم ۱۳ میلیاردی ممکن است در هر استنتاج هزینه مشابهی داشته باشند، اما نیازمندی‌های میزبانی بسیار متفاوتی دارند.

MoE یک راه‌حل جادویی نیست. اما این واضح‌ترین مثال در سال‌های اخیر از یک نوآوری معماری است که واقعاً مرز کارایی را جابجا کرد — و تغییر داد که کدام تیم‌ها می‌توانند به طور واقع‌گرایانه در ساخت مدل‌های بزرگ توانمند رقابت کنند.