تصور کنید برای راه اندازی یک ربات، مجبور باشید بین سه محیط محاسباتی مختلف جابه‌جا شوید و هر بار کدهای واسط پیچیده‌ای را بازنویسی کنید. مدیریت سه محیط مجزا و زمان‌بندهای (Schedulers) پراکنده، اصطکاکی بزرگ در مسیر توسعه بود. انویدیا با متن‌باز کردن OSMO (اسمو)، این اصطکاک را از بین برده است. OSMO یک ارکستراتور بومی کوبرنتیز است که به تیم‌ها اجازه می‌دهد کل خط لولهٔ هوش مصنوعی فیزیکی — از آموزش تا اعتبارسنجی در دنیای واقعی — را تنها در یک فایل YAML تعریف کنند.
توسعهٔ هوش مصنوعی فیزیکی معمولاً با «مشکل سه کامپیوتر» روبروست. آموزش مدل‌ها روی خوشه‌های عظیم H100 یا GB200 رخ می‌دهد، شبیه‌سازی روی ورک‌استیشن‌های RTX اجرا می‌شود و تست نهایی روی سخت‌افزارهای لبه مثل Jetson AGX Thor انجام می‌گیرد. طبق مستندات انویدیا، این لایه‌ها پیش از این به ابزارهای مجزا و اسکریپت‌های سفارشی برای جابه‌جایی داده‌ها بین یکدیگر نیاز داشتند که منجر به ایجاد بدهی فنی (Technical Debt) قابل‌توجهی می‌شد.
تحلیل مشکل سه کامپیوتر
انویدیا هوش مصنوعی فیزیکی را به عنوان مبارزه‌ای در سه سطح متمایز تعریف می‌کند. سطح اول، آموزش است که در GPUهای مرکز داده اتفاق می‌افتد. سطح دوم، شبیه‌سازی، فیزیک و رندرینگ حسگرها است که روی سخت‌افزارهای کلاس ورک‌استیشن RTX اجرا می‌شود. در نهایت، سطح سوم استقرار و تست‌های سخت‌افزار-در-حلقه (HIL) است که روی دستگاه‌های لبه و معمولاً در محیط‌های محلی (On-premises) انجام می‌گیرد.
همان‌طور که در تحلیل‌های قبلی ما درباره‌ی زیرساخت‌های محاسباتی انویدیا اشاره کردیم، هدف این شرکت تبدیل سخت‌افزار به یک پلتفرم نرم‌افزاری یکپارچه است. OSMO این هدف را با تبدیل هر سه لایه به «بک‌اندهای» یک پنل کنترل واحد محقق می‌کند. در این سیستم، هر محیط یک خوشه کوبرنتیز (Kubernetes) — شبیه به یک مدیر ترافیک که تصمیم می‌گیرد هر کانتینر نرم‌افزاری در کدام سرور اجرا شود — است که از طریق رابط خط فرمان (CLI) ثبت می‌شود. توسعه‌دهندگان به‌جای نام بردن از خوشه‌های خاص، نام یک پلتفرم (مثلاً gb200 یا rtx-pro-6000 یا jetson-agx-thor) را می‌نویسند و OSMO وظیفه را به استخر (Pool) مناسب هدایت می‌کند.
قابلیت‌های فنی و گردش کار
بر اساس بررسی مستندات فنی، این سیستم از رویکرد «زنجیره داده» (Data-chained) برای خودکارسازی خط لوله استفاده می‌کند. یک گردش کار معمولی شامل سه وظیفه متوالی است:
- اجرای یک شبیه‌سازی با کانتینر Isaac Sim روی یک
rtx-pro-6000. - یک جلسه آموزش سیاست (Policy Training) با استفاده از کانتینر PyTorch روی خوشه
gb200با ۸ پردازنده گرافیکی، که خروجی شبیه‌سازی را به عنوان ورودی می‌گیرد. - یک مرحله ارزیابی با اجرای اپلیکیشن ROS روی دستگاه Jetson AGX Thor، که سیاست آموزش‌دیده را مصرف کرده و نتایج را در یک مجموعه‌داده نام‌گذاری شده می‌نویسد.
این ابزار به‌طور پیش‌فرض از NVIDIA KAI Scheduler استفاده می‌کند. در به‌روزرسانی ژوئن ۲۰۲۶ (نسخه ۶.۳.۱) و آپدیت‌های پیشین، چندین مکانیزم حیاتی معرفی شده است:
- توپولوژی NVLink: در نسخه ۶.۲.۸، جای‌گذاری وظایف چند-GPU بر اساس آگاهی از توپولوژی NVLink بهینه شد تا ارتباط بین کارت‌ها سریع‌تر شود.
- مدیریت زمان انتظار: در نسخه ۶.۳.۰، پارامترهای
exec_timeoutوqueue_timeoutبرای هر گروه مجزا شدند. این یعنی توقف یک گروه شبیه‌سازی دیگر باعث مرگ گروه‌های آموزش موازی نمی‌شود. - کنترل وظایف: راهنمای کاربر اکنون از گروه‌های وظایف سریال و موازی، قالب‌بندی Jinja برای گردش‌های کاری پارامتریک و سیاست‌های تلاش مجدد (Retry Policies) پشتیبانی می‌کند.
- سطوح اولویت: وظایف در سه سطح بالا (HIGH)، نرمال (NORMAL) و پایین (LOW) تعریف می‌شوند که قابلیت پیش‌دستی (Preemption) و قرض گرفتن GPU از استخرهای دیگر را فراهم می‌کند.
زیرساخت و امنیت
استقرار OSMO از طریق لایسنس Apache-2.0 و Helm Charts موجود در NGC تسهیل شده است. این پلتفرم از استقرار چند-ارائده‌ای در Azure AKS، AWS EKS، GKE، محیط‌های محلی یا خوشه‌های ایزوله (Air-gapped) پشتیبانی می‌کند. این رویکرد متن‌باز به توسعه‌دهندگان کمک می‌کند تا از وابستگی مطلق به یک ارائه‌دهنده خاص رها شوند، موضوعی که در تحلیل ما پیرامون نبرد زیرساخت‌های متن‌باز در برابر مدل‌های بسته به تفصیل بررسی شده است. در نسخه ۶.۳.۰، اسکریپت deploy-k8s.sh اضافه شد که OSMO را روی Azure AKS، AWS EKS یا microk8s مستقر کرده و اتصالات ذخیره‌سازی را برای MinIO، Azure Blob، AWS S3 یا S3های شخصی برقرار می‌کند.
در حوزه امنیت، نسخه ۶.۲.۸ یک Sidecar برای احراز هویت RBAC و ادغام با OAuth2 proxy با قابلیت ورود از طریق کد دستگاه (Device-code login) اضافه کرد. در نسخه ۶.۳.۰، این سیستم با پایان دادن TLS در درگاه Envoy و استفاده از هویت کاری ابری (Azure Workload Identity و AWS IRSA/Pod Identity) ارتقا یافت تا دیگر نیازی به نصب کلیدهای ذخیره‌سازی به عنوان Kubernetes Secrets نباشد. همچنین در نسخه ۶.۳.۱، نقش پیش‌فرض osmo-user به استخر پیش‌فرض محدود شد تا امنیت دسترسی‌ها افزایش یابد.
به‌روزرسانی‌های اخیر در نسخه ۶.۳.۰، CLI مستقل مجموعه‌داده‌ها و API /datasets (که قرار است در نسخه ۶.۴ حذف شوند) را با خروجی‌های مدیریت‌شده توسط گردش کار جایگزین کرد. این رویکرد جدید برای مجموعه‌داده‌های با آدرس‌دهی محتوایی (Content-addressable) همراه با حذف داده‌های تکراری (Deduplication)، می‌تواند نیاز به فضای ذخیره‌سازی را بین ۱۰ تا ۱۰۰ برابر کاهش دهد. برای سازمان‌هایی که به دنبال بهینه‌سازی هزینه‌ها هستند، انتخاب بین استقرار محلی و ابری می‌تواند تأثیر مستقیمی بر هزینه‌های بلندمدت استنتاج مدل‌ها داشته باشد.
یکپارچگی با عامل‌های هوشمند
به گزارش انویدیا در کنفرانس GTC ۲۰۲۶، OSMO اکنون با عامل‌های کدنویس مثل Claude Code، OpenAI Codex و Cursor یکپارچه شده است. این یعنی عامل‌های هوش مصنوعی (AI Agents) — شبیه به دستیاران برنامه‌نویسی که می‌توانند به‌طور مستقل کد بزنند و خطاها را رفع کنند — حالا می‌توانند از طریق یک راهنمای استقرار MCP و یک دایرکتوری مهارت‌های اختصاصی، خط لوله‌های OSMO را به‌طور خودکار ارسال، نظارت و عیب‌یابی کنند.
این چرخش، توسعه هوش مصنوعی فیزیکی را از مدیریت دستی زیرساخت به سمت یک چرخه حیات «نرم‌افزار-محور» می‌برد. انویدیا با انتزاع لایه سخت‌افزار، مانع انتقال از محیط شبیه‌سازی به ربات واقعی را از بین برده است تا تیم‌ها بدون بازنویسی منطق استقرار، مدل خود را منتقل کنند. این رویکرد در پروژه‌هایی مثل GR00T، Isaac Lab، Isaac Sim و Isaac ROS به‌طور عملی آزمایش شده است و شرکت‌هایی مانند Skild AI نیز از این استراتژی‌های انویدیا برای تسریع استقرار ربات‌های هوشمند خود بهره می‌برند.
برای توسعه‌دهندگان، این به معنای حذف «کدهای چسب» (Glue Code) است که پیش از این بخش بزرگی از مهندسی رباتیک را اشغال می‌کرد. قابلیت‌های جدیدی مثل osmo workflow rsync download (که در نسخه ۶.۳.۰ با یک نوار پیشرفت زنده اضافه شد) و امکان اتصال مستقیم (Exec) به گنه‌های GPU از طریق VS Code، Jupyter یا SSH، چرخه توسعه تعاملی را بسیار سریع‌تر کرده است.
گام بعدی شما
- اگر روی رباتیک کار می‌کنید، از Quickstart محلی OSMO که کل پنل کنترل را با استفاده از KIND روی ورک‌استیشن اجرا می‌کند، برای تست استفاده کنید.
- ساختار فایل‌های YAML خود را برای تعریف وظایف موازی و سریال بازبینی کنید تا از حداکثر توان GPUها استفاده کنید.
- ادغام OSMO با Cursor را امتحان کنید تا مدیریت زیرساخت را به عامل‌های کدنویس بسپارید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.
گفتگو