چگونه Modal سرعت ایجاد محیط‌های ایزوله را به مقیاس میلیونی برد؟

یک درخواست زیرساختی ساده حالا می‌تواند یک میلیون محیط ایزوله را در کمتر از ۶۰ ثانیه فعال کند. مدال (Modal) در ۱۶ ژوئیه ۲۰۲۶ اعلام کرد که پلتفرم هسته خود را به‌طور کامل بازسازی کرده تا سقف‌های مقیاس‌پذیری را که گریبان‌گیر ارکستراسیون‌های سنتی است، از بین ببرد.

بسیاری از عامل‌های هوش مصنوعی (AI Agent) — شبیه دستیارهای شخصی که می‌توانند به جای شما کارهای پیچیده را مدیریت کنند — برای مدیریت تپه‌های ترافیکی به مقیاس عظیم و نرخ ایجاد هم‌زمان بالایی نیاز دارند. چه در یادگیری تقویتی (Reinforcement Learning) باشد — که می‌تواند نیازمند اجرای میلیون‌ها سندباکس به صورت هم‌زمان و ایجاد موج‌هایی از صدها هزار محیط در شروع استقرارها باشد — و چه در عامل‌های پس‌زمینه، تقاضا برای محیط‌های ایزوله یا سندباکس‌ها (Sandboxes) سریع‌تر از توان زیرساخت‌های موجود رشد می‌کند. این نیاز به محیط‌های ایزوله سریع، در تقابل با رویکردهای متفاوتی قرار دارد؛ برای مثال در برخی سناریوها حذف محیط‌های ابری باعث کاهش تأخیر اجرای عامل‌های تک‌کاربره شده است. در حال حاضر، مدال روزانه میلیون‌ها سندباکس را اجرا کرده و برای هر مشتری تا ۵۰ هزار مورد هم‌زمان را پشتیبانی می‌کند.

همان‌طور که در بررسی‌های پیشین ما درباره‌ی چالش‌های مقیاس‌پذیری در مدل‌های عامل‌محور اشاره کردیم، زیرساخت‌های سنتی مانند کوبرنتیز (Kubernetes) در این مقیاس شکست می‌خورند چون بر «سازگاری قوی» (Strong Consistency) تکیه دارند. در این سیستم‌ها، الگوریتم‌های زمان‌بندی با افزایش تعداد گره‌ها و پادها، دچار گلوگاه‌های متوالی می‌شوند و عملکرد آن‌ها به شدت کاهش می‌یابد.

محدودیت‌های ارکستراسیون سنتی

به نقل از مستندات فنی مدال، در کوبرنتیز، الگوریتم زمان‌بندی در بدترین حالت دارای پیچیدگی O(n x p) برای n گره و p پاد است و فرآیند زمان‌بندی به‌صورت پیش‌فرض متوالی (Serialized) است. در این جریان، پادهای جدید توسط سرور API در etcd — یک ذخیره‌ساز بادوام با سازگاری قوی — نوشته می‌شوند. زمان‌بند کوبرنتیز این پادها را رصد کرده و آن‌ها را به گره‌ها اختصاص می‌دهد که این کار از طریق یک فراخوانی به سرور API انجام می‌شود و باز هم منجر به نوشتن در etcd می‌شود. تنها پس از پردازش این عملیات نوشتن است که یک گره می‌تواند پاد را استارت بزند.

هر پاد در طول چرخه حیاتش باعث چندین عملیات نوشتن در etcd می‌شود. این موضوع در زمان نرخ بالای چرخش (Churn) پادها یا نرخ‌های بالای ایجاد، مشکلاتی جدی ایجاد می‌کند؛ به‌خصوص که etcd به‌صورت بومی در فضای کلیدها (Keyspace) قابل تکه‌بندی (Shardable) نیست. علاوه بر این، هر گره باید برای اعلام زنده بودن، در هر بازه ضربان قلب (Heartbeat) حداقل یک‌بار در etcd بنویسد. این یعنی بار نوشتن پایه در etcd با پیچیدگی O(nodes) است که کاملاً مستقل از تعداد پادهای ایجاد شده است.

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

گلوگاه‌های سازگاری

معماری اولیه مدال نیز با موانع مشابهی روبرو بود. این سیستم به هماهنگی جهانی و عملیات نوشتن با پیچیدگی O(sandboxes) در یک پایگاه داده Postgres متکی بود که تکه‌بندی بهینه آن بسیار دشوار است.

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

نرخ بالای چرخش (Churn) همچنین باعث ایجاد انباشت‌های عظیم رویداد در جریان‌های کاری بادوام (Durable Workflows) می‌شد. مدال برای هر سندباکسی که به پایان می‌رسد، یک جریان کاری بادوام اجرا می‌کند؛ در مقیاس بالا، این موضوع به یک نقطه ضعف تبدیل شد. تیم متوجه شد که RPCها (فراخوانی‌های روی procedimento از راه دور) به‌صورت خطی — O(sandboxes) — مقیاس می‌شدند و باعث جهش‌های بار غیرمنتظره در سراسر سیستم می‌شدند. علاوه بر این، تعداد زیاد گره‌های مورد نیاز برای اجرای تعداد بالای سندباکس‌ها، مشکلاتی در مدیریت گره‌ها و مقیاس‌پذیری خودکار (Autoscaling) ایجاد کرد. در نهایت، این نتیجه حاصل شد که قرار دادن یک نمونه Postgres تکه‌بندی‌نشده در مسیر بحرانی تمام مراحل ایجاد و زمان‌بندی سندباکس‌ها، ایده‌ی بدی بوده است.

مهندسی معماری «مقیاس بی‌نهایت»

برای حل این مشکل، مدال تصمیم گرفت سیستم را از صفر بازسازی کند. فلسفه اصلی تغییر کرد: پذیرفتن عدم سازگاری جهانی در exchange با مقیاس‌پذیری و عملکرد در مسیر بحرانی (Critical Path). آن‌ها تصمیم گرفتند هر چیزی که باری معادل O(sandboxes) یا O(nodes) دارد، باید به‌صورت پیش‌فرض افقی مقیاس‌پذیر باشد و مسیر ایجاد سندباکس باید تا حد ممکن ساده باشد.

به جای یک زمان‌بند متوالی واحد، سیستم جدید از ناوگانی از سرورهای زمان‌بندی استفاده می‌کند. این سرورها درخواست‌های ایجاد را به‌طور هم‌زمان و با استفاده از داده‌های کش‌شده سریع در حافظه (In-memory) مدیریت می‌کنند. این تغییر، زمان‌بندی را از یک ارکستراسیون سنتی به چیزی شبیه به «توزیع‌کننده بار» (Load Balancer) تبدیل می‌کند.

دیگر هیچ ذخیره‌ساز مرکزی بادوامی به عنوان منبع حقیقت برای وضعیت ورکرها وجود ندارد؛ بلکه هر ورکر خودش منبع حقیقت است.

مکانیزم فنی جدید: توزیع وضعیت ورکر

• انتشار وضعیت: ورکرها وضعیت خود را به‌صورت دوره‌ای در یک استریم Redis منتشر می‌کنند.
• مصرف غیرهم‌زمان: سرورهای زمان‌بندی این وضعیت‌ها را به‌صورت غیرهم‌زمان مصرف می‌کنند تا بر اساس آن‌ها تصمیم‌گیری کنند.
• RPC مستقیم: سرور پس از انتخاب ورکر، مستقیماً از طریق RPC برای درخواست ایجاد سندباکس با آن تماس می‌گیرد.
• تأیید منابع: ورکر در صورت داشتن منابع آزاد، درخواست را می‌پذیرد و در غیر این صورت آن را رد می‌کند.

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

برای بهینه‌سازی بیشتر، مدال تمام RPCهایی که با تعداد سندباکس‌ها رابطه خطی داشتند (O(sandboxes))، به جز عملیات اولیه ایجاد، حذف کرد. طبق اصول «طراحی داده‌محور» (Data-oriented design)، ورکرها اکنون پیام‌های کنترلی چندین سندباکس را در قالب یک RPC واحد دسته‌بندی (Batch) می‌کنند. این یعنی مسیر ایجاد اکنون تنها به دو جهش شبکه‌ای و یک عملیات ارزان CPU نیاز دارد. در این مدل هیچ نقطه شکست واحدی وجود ندارد و سقف عملی برای مقیاس کلی تعریف نشده است.

غلبه بر تداخلات سطح هسته (Kernel)

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

پس از بازگشت به نیویورک، تیم باید تمام ویژگی‌های سندباکس و تمام ابزارهای مشاهده‌پذیری (Observability) را روی سیستم جدید پیاده می‌کرد. این کار همچنین مستلزم تغییر در پشته مدیریت ورکر و زمان اجرای کانتینر (Container Runtime) بود.

یک مشکل بحرانی ظاهر شد: زمان‌بندهای جدید کانتینرها را چنان سریع به ورکرها می‌فرستادند که تعداد زیادی از کانتینرهایی که هم‌زمان استارت می‌زدند، برای دسترسی به قفل rtnl در هسته لینوکس رقابت می‌کردند. این قفل هنگام تنظیم قوانین شبکه‌سازی کانتینر استفاده می‌شود. این تداخل باعث می‌شد برخی کانتینرها ده‌ها ثانیه طول بکشند تا فعال شوند و در صورت بمباران درخواست‌ها، ورکرها عملاً «منفجر» شوند. مدال با تغییر روش تنظیم شبکه کانتینر مخصوص سندباکس‌ها، این مشکل را حل کرد.

نتایج بنچمارک

بر اساس گزارش modal.com، سیستم جدید میانگین زمان راه‌اندازی — یعنی تأخیر از اولین تلاش کلاینت برای ایجاد تا زمانی که سندباکس بتواند کد کاربر را اجرا کند — را به کمتر از نیم ثانیه رسانده است.

مشاهدات کلیدی عملکرد عبارتند از:

• ظرفیت انفجاری عظیم: ایجاد ۱ میلیون سندباکس در کمتر از یک دقیقه. در این آزمایش، گلوگاه اصلی خودِ ابزار بنچمارک بود، نه پلتفرم. این توانایی در مقیاس‌دهی، زیرساختی مشابه برای آموزش مدل‌های عظیم فراهم می‌کند؛ همان‌طور که در سازوکار آموزش مدل‌های Moes در prime-rl شاهد مدیریت منابع در مقیاس بسیار بالا هستیم.
• کاهش تأخیر: تأخیر زمان‌بندی به ده‌ها میلی‌ثانیه کاهش یافته است.
• ثبات در مقیاس: زمان رسیدن به وضعیت تعامل‌پذیری (Time-to-interactivity) برای هر سندباکس، با افزایش مقیاس، افت محسوسی نکرد و پایین باقی ماند.
• مقیاس‌پذیری افقی: هیچ هماهنگی مرکزی در مسیر زمان‌بندی وجود ندارد، به این معنی که مقیاس تنها به ظرفیت فیزیکی موجود محدود است.

تیم اشاره کرد که «دم بلند» (Long Tail) تأخیر هنوز بیشتر از حد مطلوب است. آن‌ها این موضوع را به تداخلات هسته و شبکه (از جمله قفل rtnl ذکر شده) هنگام استارت زدن تعداد زیاد سندباکس روی یک ورکر واحد نسبت می‌دهند. آن‌ها در حال حاضر در حال بهینه‌سازی مسیر استارت‌آپ کانتینر برای کاهش این تأخیرهای دم‌بلند هستند.

مقیاس‌دهی استریم وضعیت

تنها گلوگاه احتمالی باقی‌مانده در آینده نزدیک، استفاده از یک استریم Redis واحد برای تمام وضعیت‌های ورکرها است. با این حال، تست‌های بار نشان می‌دهد که این روش برای بیش از ۱۰۰ هزار ورکر قابل اتکا است. از آنجایی که سیستم به ترتیب (Ordering) استریم وابسته نیست، مدال می‌تواند در صورت عبور از این حد، به‌راحتی استریم‌های بیشتری اضافه کند.

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

گام بعدی شما

• توسعه‌دهندگان می‌توانند اکنون با یک تغییر ساده در کد، در نسخه بتا (Beta) به این سیستم جدید منتقل شوند.
• اگر گردش‌های کاری عامل‌محور شما نیاز به ظرفیت انفجاری (Burst Capacity) بالا دارد، قابلیت مقیاس‌پذیری به میلیون‌ها نمونه در چند ثانیه تبدیل به یک مزیت رقابتی حیاتی است؛ لذا استقرار مدل‌های توزیع‌شده را روی این زیرساخت تست کنید. در این مسیر، مقایسه کنترل مستقیم بر استنتاج LLM در مقابل مدیریت‌شده می‌تواند در انتخاب استراتژی استقرار به شما کمک کند.
• بررسی کنید که آیا سیستم‌های فعلی شما برای رسیدن به مقیاس میلیون‌ها نمونه، همچنان بر سازگاری قوی (Strong Consistency) تکیه دارند یا خیر.

اما تأثیر این سرعت روی هزینه‌های استنتاج در مقیاس عظیم، داستان دیگری است — به تحلیل ما درباره بهینه‌سازی هزینه‌های GPU مراجعه کنید.