تصور کنید برای مدیریت یک خوشه عظیم GPU، به جای ارتشی از مهندسان DevOps و کوهی از فایل‌های YAML، تنها با یک دستور متنی تمام زیرساخت را کنترل کنید. آمازون وب سرویسز (AWS) با معرفی HyperPod InstantStart قصد دارد این رویای ساده‌سازی را به واقعیت تبدیل کند. این ابزار در واقع یک صفحه کنترل متن‌باز است که به کاربران اجازه می‌دهد زیرساخت‌های یادگیری ماشین (ML) خود را با استفاده از یک عامل هوش مصنوعی مستقر و مدیریت کنند.
برای اکثر توسعه‌دهندگان، فاصله بین داشتن یک اسکریپت PyTorch و داشتن یک خوشه آماده برای تولید، یک کابوس لجستیکی است. شما باید ارکستراسیون کوبرنتیز، بررسی سلامت GPUها و شبکه‌های پرسرعت را هماهنگ کنید. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی پیچیدگی‌های زیرساخت‌های مدل‌های بنیادی اشاره کردیم، این لایه‌ی عملیاتی معمولاً گلوگاه اصلی سرعت پیشرفت است. حالا تصور کنید به ترمینال بگویید: «یک خوشه با قابلیت بازیابی خودکار گره‌ها و ذخیره‌ساز S3 ایجاد کن» و سیستم تمام لوله‌کشی‌های فنی را انجام دهد.
به نقل از وبلاگ یادگیری ماشین AWS در تاریخ ۴ سپتامبر ۲۰۲۶، سامانه InstantStart این هدف را از طریق جفت کردن یک رابط وب با یک عامل (Agent) — شبیه به یک دستیار فنی که دستورات شما را به کدهای اجرایی تبدیل می‌کند — محقق کرده است. این رویکرد یادآور تلاش‌های مشابه در اکوسیستم‌های دیگر است، مانند چارچوب عامل مایکروسافت که با هدف حذف پیچیدگی‌های استقرار برای توسعه‌دهندگان طراحی شده است. این عامل از ابزارهای پروتکل زمینه مدل (MCP) برای برنامه‌ریزی و اجرای عملیات چندمرحله‌ای استفاده می‌کند. نکته کلیدی این است که این عامل در مسیر داده‌های آموزشی قرار نمی‌گیرد؛ یعنی مدیریت منابع را بدون کند کردن عملیات واقعی هوش مصنوعی انجام می‌دهد.
معماری و ساختار مدیریتی
سامانه InstantStart به صورت یک کانتینر مدیریتی خارج از مسیر داده (out-of-band) در حساب کاربری AWS اجرا می‌شود. این ابزار با فراخوانی APIهای سرویس‌های AWS و APIهای کوبرنتیز با محیط تعامل دارد. از آنجا که خارج از مسیر داده عمل می‌کند، هیچ تداخلی با درخواست‌های استنتاج (Inference) — لحظه‌ای که مدل واقعاً جواب تولید می‌کند، مثل خودِ آشپزی نه دوره‌ی آموزش آشپز — یا کارهای آموزشی ایجاد نمی‌کند.
هر منبعی که این سیستم ایجاد می‌کند، یک شیء استاندارد AWS یا کوبرنتیز است. این یعنی تمام زیرساخت‌ها از طریق AWS CLI و kubectl کاملاً قابل بازرسی هستند. سیستم از یک بک‌اند واحد استفاده می‌کند که سه رابط مختلف را پشتیبانی می‌کند: یک رابط کاربری وب، یک REST API و ابزارهای MCP که توسط عامل استفاده می‌شوند.
مکانیزم ارکستراسیون
این سامانه مانند پلی میان Amazon EKS و Amazon SageMaker HyperPod عمل می‌کند. وقتی کاربر درخواستی را ارسال می‌کند — چه از طریق فرم وب و چه با یک جمله طبیعی به عامل hypd-inst-agent (که برای Kiro CLI ساخته شده است) — عامل مراحل حیاتی زیر را ترتیب می‌دهد:
- ایجاد صفحه کنترل EKS (که طبق اعلام AWS حدود ۸ تا ۱۲ دقیقه زمان می‌برد).
- انتخاب خوشه فعال و تطبیق وابستگی‌ها.
- ایجاد خوشه HyperPod و پیکربندی ذخیره‌ساز.
برای جلوگیری از تغییرات پیش‌بینی‌نشده یا نامنظم توسط عامل، AWS ابزارهای MCP را طوری طراحی کرده که به جای استفاده از SDKهای عمومی یا AWS CLI، مستقیماً از REST APIهای صفحه کنترل استفاده کنند. این کار باعث می‌شود هر قانون اعتبارسنجی که در بک‌اند اضافه شود، همزمان هم رابط وب و هم عامل هوش مصنوعی را محافظت کند و از خطاهای پیکربندی جلوگیری نماید.
منطق عامل و جریان کاری
رفتار عامل توسط «مهارت‌ها» (Skills) هدایت می‌شود که در واقع دفترچه‌های راهنمای Markdown هستند و در مخزن پروژه نسخه‌بندی شده‌اند. این ساختار ماژولار برای مدیریت قابلیت‌های گسترده، مشابه معماری DeepSeek Harness است که از پلاگین‌ها برای مقیاس‌دهی عامل‌های AI استفاده می‌کند. این مهارت‌ها سه قانون جریان کاری خاص را اجرا می‌کنند:
- نظارت بر وضعیت نهایی (Terminal State Polling): عامل به جای گزارش ساده‌ی «درخواست ارسال شد»، عملیات طولانی را تا رسیدن به وضعیت نهایی رصد می‌کند و سپس نتیجه را اعلام می‌کند.
- پرس‌وجوی تصمیم‌محور: عامل فقط برای تصمیمات سطح بالا (مثل منطقه در دسترس یا Availability Zone، نوع نمونه یا Instance Type و نوع ظرفیت) از کاربر سوال می‌کند. جزئیات فنی پیچیده مثل جداول مسیریابی (Route Tables)، گروه‌های امنیتی (Security Groups) و CIDRهای زیرشبکه را به طور خودکار مدیریت می‌کند.
- بازرسی پیش‌نیاز: عامل ابتدا خوشه‌های موجود را لیست کرده و مناطق معتبر و انواع نمونه‌های در دسترس را استعلام می‌کند و سپس گزینه‌ها را به کاربر پیشنهاد می‌دهد.
قابلیت‌های مدیریت GPU
تمرکز InstantStart بر «وضعیت تطبیق‌یافته» (Reconciled State) است؛ یعنی مدام بررسی می‌کند که خوشه با پیکربندی مورد نظر مطابقت داشته باشد. این سیستم بازیابی خودکار گره‌ها را فعال می‌کند که در آن HyperPod گره‌های معیوب را بر اساس گزارش‌های عامل‌های نظارتی ری‌بوت یا جایگزین می‌کند. این بررسی‌ها شامل تست‌های سلامت پایه و تست‌های عمیق (Deep Health Checks) است که اتصال واحد پردازش گرافیکی (GPU) و EFA (Elastic Fabric Adapter) را پیش از پذیرش هرگونه workload فشار می‌دهد تا از پایداری آموزش اطمینان حاصل شود.
جزئیات زیرساختی
- تأمین محاسبات: صفحه کنترل از یک تابع واحد برای ایجاد زیرشبکه‌های محاسباتی با اندازه /۲۰ استفاده می‌کند تا فضای کافی برای ناوگان‌های بزرگ شتاب‌دهنده فراهم شود.
- گروه‌های نمونه: هنگام افزودن یک گروه نمونه، نوع ظرفیت، حالت رابط شبکه و جایگذاری زیرشبکه در یک عملیات واحد در زمان ایجاد تعیین می‌شوند. نوع ظرفیت و حالت رابط EFA-only برای تمام طول عمر آن گروه ثابت می‌مانند.
- مقیاس‌دهی خودکار: پلتفرم از یک مقیاس‌دهنده مدیریت‌شده مبتنی بر Karpenter استفاده می‌کند. این قابلیت اجازه می‌دهد گره‌ها از گروه‌های نمونه HyperPod که از صفر مقیاس شده‌اند، بالا بیایند. البته AWS اشاره کرده که این نسخه از Karpenter فقط گروه‌های HyperPod را مدیریت می‌کند و برای ظرفیت‌های عمومی EC2 کاربرد ندارد.
- ویژگی‌های پیشرفته: پنلی مجزا برای فعال‌سازی اپراتورهای آموزش، استنتاج، مقیاس‌دهی خودکار مدیریت‌شده و ذخیره‌سازی لایه‌ای مدیریت‌شده (Managed Tiered Checkpointing) وجود دارد. فعال کردن ذخیره‌سازی لایه‌ای به طور خودکار زنجیره‌ای از شناسایی‌ها شامل یک حساب سرویس کوبرنتیز، یک نقش و سیاست IAM، یک رابطه اعتماد OpenID Connect و یک binding annotation را ایجاد می‌کند.
برای جلوگیری از خطاهای پیکرباری، سیستم از قرارداد «تفاضل صریح» (Explicit-Diff) استفاده می‌کند. رابط تنها فیلدهایی را ارسال می‌کند که کاربر واقعاً تغییر داده است و اگر وضعیت درخواستی با وضعیت فعلی خوشه یکی باشد، بک‌اند هیچ عملیاتی (no-op) انجام نمی‌دهد.
مسیرهای آموزش و استنتاج
کاربران دو مسیر اصلی برای آموزش دارند. اول، اپراتور آموزش HyperPod که به عنوان افزونه EKS نصب می‌شود و قابلیت‌هایی مثل بازیابی خطا در سطح پردازش، تشخیص داده‌های پرت (Outlier Detection) و تشخیص توقف‌های ناگهانی (Hang-job Detection) از طریق نظارت بر الگوهای لاگ را فراهم می‌کند. کارهای آموزشی به عنوان منابع HyperPodPyTorchJob با یک بودجه بازیابی (Recovery Budget) قابل مشاهده ارسال می‌شوند. دوم، KubeRay استاندارد که برای کارهای بومی Ray مثل یادگیری تقویتی طراحی شده است.
هر دو مسیر از لایه‌ی دستورالعمل (Recipe) برای فریم‌ورک‌هایی مثل LLaMA-Factory، MS-Swift و VERL پشتیبانی می‌کنند. در این ساختار، یک قرارداد داده مشترک وجود دارد که در آن یک باکت S3 یکسان هم در محیط توسعه و هم داخل پادها (Pods) متصل می‌شود. لاگ‌های عملیات از طریق WebSocket به مرورگر ارسال شده و معیارهایی مثل توان عملیاتی آموزش به MLflow مدیریت‌شده در SageMaker AI گزارش می‌شوند.
در بخش استنتاج نیز دو مسیر وجود دارد: یک مسیر مدیریت‌شده با اپراتور استنتاج HyperPod برای مسیریابی هوشمند و کشینگ لایه‌ای KV مدیریت‌شده، و یک مسیر خودمدیریتی که اجازه می‌دهد کانتینرهایی مثل vLLM یا SGLang به صورت استقرار استاندارد کوبرنتیز اجرا شوند. برای سرویس‌دهی SGLang با چندین نسخه (Multi-replica)، صفحه کنترل می‌تواند یک روتر SGLang با مسیریابی آگاه از کش (Cache-aware) مستقر کند و از KEDA (Kubernetes Event-driven Autoscaling) برای هدایت مقیاس‌دهی استفاده نماید.
مرزهای عملیاتی
سرور MCP در مجموع ۳۸ ابزار مجزا ارائه می‌دهد که همه چیز از دانلود مدل تا عملیات گره‌ها را پوشش می‌دهد. هر ابزار تغییردهنده (Mutating Tool) به یک ابزار وضعیت متصل است تا وضعیت تکمیل را تعیین کند و عملیات‌ها فاز خود را ذخیره می‌کنند تا از تکرار یک تغییر در صورت تلاش مجدد عامل جلوگیری شود.
برای حفظ امنیت، عامل یک مسیر تصاعدی سخت‌گیرانه برای خطاها دنبال می‌کند: ابتدا بررسی (Investigate)، سپس ری‌بوت (Reboot) و در نهایت جایگزینی (Replace). AWS تأکید می‌کند که عامل دسترسی‌های کاربر را گسترش نمی‌دهد، بلکه فقط رابط وسیع‌تری برای مرزهای موجود IAM و کوبرنتیز فراهم می‌کند.
استقرار با یک قالب CloudFormation آغاز می‌شود که محیط مدیریتی و یک باکت S3 مشترک را می‌سازد. رابط وب سپس روی پورت ۳۰۹۹ از طریق نشست‌های port-forwarding در AWS Systems Manager در دسترس قرار می‌گیرد.
این چرخش به سمت مدیریت عامل‌محور زیرساخت نشان می‌دهد که عصر «زیرساخت به عنوان کد» (IaC) در حال تبدیل شدن به «زیرساخت به عنوان گفتگو» است. AWS با انتزاع پیچیدگی‌های EKS و HyperPod، سد ورود تیم‌ها برای اجرای مدل‌های مقیاس-مرزی (Frontier-scale) را بدون نیاز به تخصص عمیق در کوبرنتیز پایین می‌آورد.
گام بعدی شما
- اگر قصد اجرای آموزش در مقیاس بزرگ را دارید، ابتدا سهمیه‌های (Quotas) استفاده از SageMaker HyperPod و رزروهای برنامه‌ی آموزش برای GPUهای رده‌بالا را بررسی کنید، زیرا AWS هشدار داده که این موارد باید پیش از استقرار اولین خوشه هماهنگ شوند.
- توجه داشته باشید که آموزش الاستیک در حال حاضر از Spot Instances، آموزش بدون نقطه بازرسی (Checkpointless) و ذخیره‌سازی لایه‌ای مدیریت‌شده پشتیبانی نمی‌کند.
- مستندات MCP را مطالعه کنید تا متوجه شوید چگونه می‌توانید ابزارهای سفارشی خود را به این عامل اضافه کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو