GKE Agent Sandbox عمومی شد؛ آغاز محیط تا ۴۵ برابر سریع‌تر است

گوگل کلاد در اعلام عرضهٔ ۲۹ سپتامبر ۲۰۲۶، نسخهٔ بهینه‌شدهٔ GKE Agent Sandbox برای یادگیری تقویتی، SDK هماهنگ‌سازی آن و اتصال به ابزارهای این حوزه را عمومی کرد و برای زمان رسیدن به نخستین فرمان، بهبودی تا ۴۵ برابر گزارش داد. در توصیف خلاصهٔ همان آزمون، آماده شدن محیط ۱ تا ۹ ثانیه طول کشید؛ در مقایسه با ۴۵ تا ۸۵ ثانیه برای پادهای معمول Kubernetes. عدد ۴۵ برابر به طولانی‌ترین انتظار اندازه‌گیری‌شده مربوط است، نه سرعت معمول همهٔ درخواست‌ها.

گزارش ComputeLabs نیز عرضهٔ عمومی نسخهٔ مخصوص یادگیری تقویتی و زمان ۱ تا ۹ ثانیه تا نخستین فرمان را ثبت کرده است. این زمان برای آموزش و ارزیابی عامل‌هایی اهمیت دارد که باید کد تولیدشده را بارها، و گاهی به‌طور هم‌زمان، در محیط‌های جداگانه اجرا کنند. اگر یک دسته از اجراها منتظر کندترین محیط بماند، دیر آماده شدن همان محیط می‌تواند شتاب‌دهنده‌های مشغول آموزش را معطل کند.

عدد ۴۵ برابر از کدام بخش آزمون می‌آید؟

معیار مقایسه «زمان تا نخستین فرمان» است: فاصلهٔ درخواست یک محیط تا زمانی که اجرای فرمان عامل در آن ممکن می‌شود. در جدول تفصیلی آزمون، میانگین این زمان برای پادهای معمول Kubernetes از ۴۴ تا ۸۵ ثانیه و برای پیکربندی مبتنی بر Agent Sandbox RL SDK از ۱٫۱ تا ۸٫۸ ثانیه بود. توصیف کوتاه‌ترِ ۴۵ تا ۸۵ ثانیه در برابر ۱ تا ۹ ثانیه، همین نتیجه را با اعداد گرد شده بیان می‌کند؛ نسبت میانگین‌ها در گزارش حدود ۱۰ برابر توصیف شده است.

ردیف دیگری از همان جدول، طولانی‌ترین انتظار هر اجرا را نشان می‌دهد. در آن ردیف، بیشینهٔ زمان برای روش پایه ۷٫۵ دقیقه، یا ۴۵۰ ثانیه، و برای پیکربندی جدید کمتر از ۱۰ ثانیه بود. تقسیم ۴۵۰ بر ۱۰ منشأ ادعای بهبود ۴۵ برابری است؛ چون مقدار جدید کمتر از ۱۰ ثانیه گزارش شده، این نسبت یک بیان محافظه‌کارانه از کاهش بدترین زمان انتظار در آزمون است. تفاوت این ردیف با میانگین مهم است: در اجرای دسته‌ای، یک محیط بسیار دیرآماده می‌تواند پایان کل دسته را عقب بیندازد.

آزمون روی استخری از محیط‌های gVisor در کلاستری با ۱۰ گره انجام شد. پیکربندی، GKE Image Streaming، کنترلر Agent Sandbox و گردانندهٔ SDK درون کلاستر را در کنار استخر محیط‌های آماده به کار گرفت. بارکاری‌ها شامل ۵۰۰ تصویر برای SWE-bench و ۴٬۵۷۸ تصویر برای مجموعهٔ R2E بودند؛ شمار وظایف هم‌زمان از ۵۰۰ تا ۱۸٬۳۱۲ رسید. بنابراین نتیجهٔ سرعت به این ترکیب و شرایط آزمون تعلق دارد و نمی‌توان آن را اثر مستقل gVisor یا یک قابلیت منفرد دیگر دانست.

استخر آماده چگونه زمان انتظار را جابه‌جا می‌کند؟

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

مستندات مفهومی GKE Agent Sandbox برای تحویل محیط از warm pool زمان کمتر از یک ثانیه را ذکر می‌کند و نسخهٔ 1.35.2-gke.1269000 یا جدیدتر را برای پشتیبانی کامل از قابلیت‌ها، از جمله snapshot، لازم می‌داند. تحویل یک پاد از پیش آماده با «زمان تا نخستین فرمان» در آزمون یادگیری تقویتی یک اندازه‌گیری واحد نیست: اولی تخصیص محیط آماده را می‌سنجد و دومی تا قابل اجرا شدن فرمان در بارکاری آزمون ادامه دارد. به همین دلیل، زمان زیرثانیه‌ای warm pool را نباید به‌جای بازهٔ ۱ تا ۹ ثانیه‌ای نتیجهٔ آزمون گذاشت.

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

ایزولاسیون و نسخهٔ کلاستر چه نقشی دارند؟

GKE Agent Sandbox برای اجرای کد نامطمئن تولیدشده توسط عامل در محیطی ایزوله طراحی شده است. در معماری آن، SandboxTemplate مشخصات محیط را تعریف می‌کند، SandboxClaim درخواست آن را ثبت می‌کند و کنترلر درخواست را به یک محیط موجود یا محیطی که باید ساخته شود وصل می‌کند. gVisor محیط اجرای امنیت‌محور اصلی در این کاربرد است. سیاست پیش‌فرض شبکه نیز دسترسی را رد می‌کند و ارتباطات مجاز باید در پیکربندی محیط تعریف شوند.

نسخهٔ کلاستر تنها یکی از شرط‌های فنی است. کنترلر Agent Sandbox باید نصب و پیکربندی شده باشد و گره‌هایی که پادهای ایزوله را می‌پذیرند باید با محیط اجرا سازگار باشند. حداقل نسخه‌ای که سند مفهومی برای پشتیبانی کامل ذکر می‌کند، به‌تنهایی همهٔ شرایط فعال‌سازی هر نسل از API را مشخص نمی‌کند. همان سند هشدار می‌دهد که بعضی قابلیت‌های زیرین، از جمله Pod snapshots، ممکن است در مرحلهٔ پیش‌نمایش باشند یا دسترسی منطقه‌ای محدودی داشته باشند.

این تمایز برای آموزش عامل‌ها اثر مستقیم دارد. ایزولاسیون، اجرای کدی را که عامل تولید کرده از دیگر بخش‌های کلاستر جدا می‌کند؛ استخر آماده، تأخیر تحویل محیط را کم می‌کند؛ و snapshot در صورت دسترسی، به نگهداری یا بازیابی وضعیت محیط مربوط است. عمومی شدن بستهٔ بهینه‌شده برای یادگیری تقویتی به معنای یکسان بودن دسترسی به همهٔ قابلیت‌های مکمل در هر کلاستر نیست.

SDK تازه در اجرای دسته‌ای چه تغییری می‌دهد؟

Agent Sandbox RL SDK یک رابط ناهم‌زمان Python و راهبردهای قابل تنظیم برای استخر آماده فراهم می‌کند و اتصال‌هایی برای Gymnasium، NVIDIA NeMo Gym و OpenHands دارد. نقش آن هماهنگ کردن درخواست محیط‌ها در چرخه‌ای است که مدل عمل تولید می‌کند، کد در محیط ایزوله اجرا می‌شود و نتیجه به فرایند آموزش یا ارزیابی برمی‌گردد. این هماهنگی هنگام ورود ناگهانی شمار زیادی درخواست مهم می‌شود، زیرا صف زمان‌بندی و آماده‌سازی تصویر می‌تواند زمان کل دسته را افزایش دهد.

در بخش دیگری از آزمون منتشرشده، راهبرد بازیافت پاد به‌جای حذف و ساخت دوبارهٔ آن، شمار پادهای ساخته‌شده را از ۱۸٬۳۱۲ به ۵٬۸۶۹ رساند؛ کاهشی حدود ۳٫۱ برابر در رفت‌وآمد چرخهٔ عمر پادها. پاد میان اجراها باقی می‌ماند و محیط کاری آن برای وظیفهٔ بعدی بازنشانی می‌شود. این نتیجه نیز به همان بارکاری و پیکربندی آزمون مربوط است، اما نشان می‌دهد چرا زمان آغاز فقط مسئلهٔ سرعت یک پاد نیست: در مقیاس اجرای هم‌زمان، شمار درخواست‌هایی که به بخش کنترل Kubernetes می‌رسد نیز بر انتظار دسته اثر می‌گذارد.

بیشتر بخوانید:

• Paddle یا Lemon Squeezy؛ کارمزد برابر، زمان تسویه متفاوت
• Passkey یا اپ احراز هویت؛ فقط یکی در برابر فیشینگ طراحی شده است
• نمونه‌کار AI بسازید؛ سه پروژهٔ روشن از ده مخزن مبهم بهتر است