«بدون افت کیفیت»؛ دستاورد InstinctFlash در سخت‌افزارهای لبه

۳۳.۷۸ برابر. این عدد، جهشی خیره‌کننده در سرعت استنتاج مدل‌های رباتیک روی سخت‌افزارهای لبه است که اکنون به لطف InstinctFlash ممکن شده است. این محیط اجرای (Runtime) با کارایی بالا که در ۱۵ سپتامبر ۲۰۲۶ منتشر شد، اجازه می‌دهد سیاست‌های پیچیده رباتیک روی دستگاه‌هایی مثل Jetson Thor بدون قربانی کردن دقت، به‌صورت آنی اجرا شوند.

هوش مصنوعی رباتیک همیشه با «شکاف تأخیر» دست‌وپنجه نرم کرده است؛ یعنی همان فاصله زمانی بین حس کردن محیط و اجرای یک حرکت فیزیکی. مدل‌های بزرگ استدلال بهتری دارند، اما معمولاً برای نیازهای میلی‌ثانیه‌ای ربات‌ها بیش از حد کند هستند. InstinctFlash مانند یک پل عمل می‌کند و مسیر تبدیل وزن‌های مدل به اجرای سخت‌افزاری را بهینه می‌کند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی بهینه‌سازی مدل‌های لبه اشاره کردیم، کاهش تأخیر کلید تبدیل مدل‌های آزمایشگاهی به محصولات تجاری است.

جهش در عملکرد

به نقل از مخزن گیت‌هاب این پروژه، بیشترین دستاوردها روی پلتفرم Jetson Thor مشاهده شده است. مدل LingBot-VA هنگام انتقال از پروفایل توان ۲۵ ولت/۵۰ آمپر به ۲ ولت/۴ آمپر با استفاده از دقت FP8 و مراحل نمونه‌گیری بهینه، به شتاب ۳۳.۷۸ برابری رسید. طبق گزارش‌های منتشر شده در ۱۵ سپتامبر ۲۰۲۶، در تست‌های ربات واقعی هیچ افت کیفیتی در اجرای تسک‌ها دیده نشده است.

سایر بنچمارک‌های قابل توجه برای Prediction p50 روی Jetson Thor عبارت‌اند از:

• pi0.5: شتاب ۷.۸۸ برابری (کاهش از ۴۰۸.۵۸ میلی‌ثانیه به ۵۱.۸۵ میلی‌ثانیه) با استفاده از دقت FP8.
• LingBot-VA: شتاب ۵.۳۶ برابری در حالت ۲۵ ولت/۵۰ آمپر (از ۱۵۵۰۶.۳۲ میلی‌ثانیه به ۲۸۹۱.۷۴ میلی‌ثانیه) و شتاب ۴.۵۱ برابری در حالت ۲ ولت/۴ آمپر (از ۲۰۷۱.۲۹ میلی‌ثانیه به ۴۵۹.۱۰ میلی‌ثانیه).
• Cosmos3 Edge: شتاب ۳.۲۴ برابری (از ۳۳۹۳.۷۸ میلی‌ثانیه به ۱۰۴۸.۰۱ میلی‌ثانیه) با استفاده از UniPC4 و CFG3.
• LingBot-VLA-4B: شتاب ۲.۸۲ برابری (از ۶۲۴.۲۲ میلی‌ثانیه به ۲۲۱.۵۳ میلی‌ثانیه) از طریق FP8.
• LingBot-VLA-V2-6B: شتاب ۱.۸۶ برابری (از ۷۳۴.۵۶ میلی‌ثانیه به ۳۹۴.۱۱ میلی‌ثانیه) از طریق FP8.
• Cosmos3 Nano: شتاب ۲.۱۳ برابری (از ۱۰۱۸۴.۶۸ میلی‌ثانیه به ۴۷۷۲.۳۸ میلی‌ثانیه) با استفاده از UniPC4 و CFG3.
• DreamZero: شتاب ۱.۹۸ برابری (از ۲۳۵۶۳.۰۸ میلی‌ثانیه به ۱۱۸۹۹.۴۲ میلی‌ثانیه) با استفاده از DROID FP8، ۱۶ گام و کش پویا (Dynamic Cache).
• GR00T N1.7: شتاب ۱.۱۹ برابری (از ۱۳۹.۵۰ میلی‌ثانیه به ۱۱۷.۳۰ میلی‌ثانیه) با استفاده از BITEXACT.

معماری بهینه‌سازی لایه‌ای

InstinctFlash برای رسیدن به این سرعت از یک ترفند ساده استفاده نمی‌کند، بلکه یک معماری شش‌لایه را به کار گرفته است تا هر میلی‌ثانیه از توان سخت‌افزار را استخراج کند. این سیستم به جای دنبال کردن یک اولویت سخت‌گیرانه، ابتدا اندازه‌گیری می‌کند که زمان دقیقاً کجا تلف می‌شود و سپس بهینه‌سازی را از همان نقطه آغاز می‌کند:

• لایه ۱ (مدل): تغییر در آنچه محاسبه می‌شود. این لایه شامل distillation (تقطیر مدل) — مثل خلاصه‌سازی یک کتاب قطور به یک دفترچه راهنمای سریع بدون حذف نکات کلیدی — کاهش گام‌ها و فشرده‌سازی نقاط بازرسی (Checkpoint) از طریق ابزارهایی مانند InstinctCompress و instinct-pdd است.
• لایه ۲ (گراف): تغییر در زمان صدور دستورات. این بخش شامل استخراج prefill، کپچر کردن CUDA-graph و برنامه‌ریزی حافظه است.
• لایه ۳ (کش): تغییر در آنچه دوباره محاسبه می‌شود. این لایه استفاده مجدد از KV، توجه متقاطع (cross-attention) و کش‌های اپیزودیک را بهینه می‌کند.
• لایه ۴ (توجه): تغییر در نحوه ترکیب توکن‌ها. در اینجا FlashAttention، توجه ترکیبی (hybrid) و توجه خطی (linear) پیاده‌سازی شده‌اند. این بهینه‌سازی‌ها در مدیریت کانتکست‌های طولانی مشابه رویکردهای پیشرفته در مدل‌های Grok 4.6 و Muse Spark است که بر لبه‌های پردازشی تمرکز دارند.
• لایه ۵ (کرنل): تغییر در نحوه نوشتن کرنل‌ها. این لایه شامل دیسپچ بک‌اِند، چیدمان (layout) و ادغام (fusion) کرنل‌ها است.
• لایه ۶ (سخت‌افزار): تغییر در محیط اجرا. هدف‌گذاری روی FP8/INT8، TensorRT و دستگاه‌های لبه کلاس Jetson است.

تفاوت کلیدی این است که لایه ۱ وزن‌ها را تغییر داده و یک نقطه بازرسی در مخازن همراه تولید می‌کند، در حالی که لایه‌های ۲ تا ۶ نحوه اجرای آن وزن‌ها را تغییر داده و یک «طرح اجرا» (Plan) را در محیط Runtime ایجاد می‌کنند.

پشتیبانی گسترده از سخت‌افزار و مدل‌ها

بر اساس مستندات، این چارچوب تا سپتامبر ۲۰۲۶ سازگاری خود را به‌سرعت گسترش داده است. پشتیبانی از RTX 4090 در ۱۶ سپتامبر و پشتیبانی از RTX 5090 در ۱۷ سپتامبر اضافه شد. این یعنی توسعه‌دهندگان می‌توانند روی ورک‌استیشن‌های خود با همان Runtime API که روی دستگاه لبه Jetson Thor استفاده می‌شود، مدل‌ها را مستقر کنند.

این محیط اجرا از ۸ خانواده اصلی مدل‌های رباتیک پشتیبانی می‌کند. هر خانواده از یک پروفایل نصب اختصاصی برای تضمین سازگاری با نسخه‌های خاص پایتون استفاده می‌کند:

• پایتون ۳.۱۳: توسط Cosmos3 Edge و Cosmos3 Nano استفاده می‌شود.
• پایتون ۳.۱۲: توسط LingBot-VA، LingBot-VLA-4B، LingBot-VLA-V2-6B، pi0.5، GR00T و DreamZero استفاده می‌شود.

برای نسخه‌های استاندارد، شناسه‌های Hub خاصی ارائه شده است؛ مانند robbyant/lingbot-va-posttrain-robotwin برای LingBot-VA، robbyant/lingbot-vla-4b-posttrain-robotwin برای LingBot-VLA-4B، robbyant/lingbot-vla-v2-6b-robotwin برای LingBot-VLA-V2-6B، lerobot/pi05_base یا lerobot/pi05_libero_finetuned_v044 برای pi0.5، nvidia/GR00T-N1.7-3B برای GR00T، nvidia/Cosmos3-Edge-Policy-DROID یا nvidia/Cosmos3-Nano-Policy-DROID برای Cosmos3 و GEAR-Dreams/DreamZero-DROID برای DreamZero.

ساده‌سازی فرآیند استقرار

استقرار یک نقطه بازرسی (Checkpoint) تنظیم‌شده اکنون به یک دستور ساده تبدیل شده است: instinctflash serve /path/to/your/checkpoint. هسته این سیستم (پایتون ۳.۱۰ به بالا) بدون نیاز به PyTorch یا GPU، نقاط بازرسی را بررسی کرده و برنامه‌ریزی می‌کند. سیستم خانواده مدل را شناسایی کرده و یک فایل instinctflash.json کوچک بر اساس آنچه مدل ثابت می‌کند می‌سازد؛ این سیستم هرگز اطلاعات گم‌شده را حدس نمی‌زند.

پس از ایجاد این اعلان (declaration)، دایرکتوری را می‌توان در پایتون از طریق Runtime.from_pretrained("/path/to/your/checkpoint") بارگذاری کرد. برای ربات‌های مبتنی بر شبکه، این چارچوب محیط اجرا را پشت یک پروتکل msgpack-over-websocket قرار می‌دهد. این امر آن را به‌طور بومی با اکوسیستم openpi-client سازگار می‌کند. کلاینت‌های موجود در سمت ربات می‌توانند بدون تغییر و با استفاده از WebsocketClientPolicy روی پورت ۸۰۰۰ متصل شوند.

پرامپت (Prompt) در داخل مشاهده (observation) حمل می‌شود و کلاینت‌ها می‌توانند با ارسال {"reset": True, ...} یک اپیزود جدید را آغاز کنند. برای مدل LingBot-VA، کاربران باید هنگام تغییر یک تکه اکشن پیش‌بینی شده توسط کنترلر، مقدار executed_action=... را پاس دهند تا اطمینان حاصل شود که پیش‌بینی بعدی از اکشن‌هایی که واقعاً اجرا شده‌اند استفاده می‌کند.

کنترل پیشرفته و اعتبارسنجی

توسعه‌دهندگان می‌توانند موازنه بین ایمنی و سرعت را با استفاده از سیاست‌های دقت (Precision Policies) تنظیم کنند:

• BITEXACT: سقف تبدیل پیش‌فرض برای دقت بومی (Native).
• NUMERIC: از طریق tier_ceiling="numeric" فعال می‌شود و اجازه تغییرات عددی و ادغام BF16 مشترک را می‌دهد.
• FP8: به‌طور صریح از طریق precision="fp8" یا فلگ --fp8 در خط فرمان فعال می‌شود.
• Behavioral: برای استفاده از کش گام‌های پویا (Dynamic Step Cache) در مدل DreamZero الزامی است.

برای جلوگیری از افت عملکرد (Regression)، ابزار دستور instinctflash validate <dir> را شامل می‌شود. این دستور تایید می‌کند که یک نقطه بازرسی قابل انتشار است. هنگامی که پارامترهای --validate.teacher_outcomes/، .student_outcomes/ یا .margin ارائه شوند، یک گواهی «عدم افت کیفیت» (non-inferiority) در بسته مدل ثبت می‌شود.

ابزار instinctflash eval نیز تأخیر، توافق در اکشن‌ها و موفقیت در تسک‌های شبیه‌ساز را به‌طور مجزا بررسی می‌کند. این ابزار اجازه می‌دهد آزمایش‌های جفت‌شده در LIBERO و RoboTwin انجام شود تا اطمینان حاصل شود که افزایش سرعت، رفتار واقعی ربات را خراب نکرده است. ارزیابی گسترش‌یافته V2، شواهد تأخیر و کیفیت را به پروفایل‌های اجرای خاص متصل کرده و بودجه‌های کنترلی صریح را بررسی می‌کند.

نصب و راه‌اندازی

نصب با کلون کردن مخزن و ایجاد محیط مجازی با python3 -m venv .venv-core و uv==0.12.5 آغاز می‌شود. کاربران RTX 4090 از اسکریپت bootstrap_vendor.py برای نصب مدل‌های خاص (مثلاً pi05) با ریشه هدف و مسیر ptxas (مانند /usr/local/cuda/bin/ptxas) استفاده می‌کنند. برای Jetson Thor، از فلگ --target jetson_thor برای فعال کردن ساخت بک‌اند CUDA مخصوص Thor استفاده می‌شود.

چندین فلگ CLI به عیب‌یابی و تست کمک می‌کنند:

• --serve.dry_run: بررسی پیش‌پرواز دستگاه، اعلان و طرح اجرا را بدون بارگذاری وزن‌ها انجام می‌دهد.
• --serve.smoke: مدل را بارگذاری کرده، یک اکشن تولید می‌کند و خارج می‌شود.
• --serve.seed: اجرای بومی را برای مقایسه‌های جفت‌شده Seed می‌کند (در حالت FP8 رد می‌شود).
• --serve.viz: مشاهدات، اکشن‌ها و تأخیر را به یک Rerun viewer استریم می‌کند.

نقشه راه و کارهای آینده

InstinctFlash با چندین هدف کلیدی به تکامل خود ادامه می‌دهد:

• تقطیر (Distillation): پیاده‌سازی تقطیر چند-گامی تنها زمانی که بهینه‌سازی‌های بومی نتوانند بودجه کنترل لبه اعلام شده را برآورده کنند.
• موتور لبه (Edge Engine): آوردن سرویس‌دهی بومی و FP8 برای LingBot-VA به Jetson Thor با بررسی‌های کامل WebSocket.
• ارتقای توجه: توسعه یک بازوی توجه سریع‌تر در سطح NUMERIC برای مدل‌های کلاس pi05 و توجه ترکیبی/خطی برای مدل‌های جهانی با کانتکست طولانی.
• گسترش Thor: نصب پین‌شده و بررسی‌های CLI/WebSocket برای Cosmos3 و DreamZero روی Thor.
• بهینه‌سازی: تکمیل کپچر بومی Thor برای LingBot-VLA-V2 و پروفایل‌بندی اشباع برای LingBot-VA.

این تغییر در این حوزه نشان می‌دهد که گلوگاه رباتیک اکنون از معماری مدل به سمت بهره‌وری سرویس‌دهی (Serving Efficiency) تغییر کرده است. با نگاه به محیط اجرا به عنوان یک پشته لایه‌ای، توسعه‌دهندگان اکنون می‌توانند «بودجه‌های کنترلی» خاص — یعنی حداکثر تأخیر مجاز برای پایدار ماندن یک ربات — را هدف قرار دهند.

گام بعدی شما

• اگر روی مدل‌های VLA کار می‌کنید، از دستور --serve.dry_run برای بررسی سازگاری سخت‌افزار قبل از بارگذاری وزن‌ها استفاده کنید.
• برای مانیتورینگ آنی تأخیر و اکشن‌ها، خروجی را به Rerun viewer متصل کنید (--serve.viz).
• در صورت استفاده از مدل‌های LingBot، حتماً مقدار executed_action را پاس دهید تا پیش‌بینی‌های بعدی بر اساس واقعیت باشند.

اما گلوگاه رباتیک اکنون از معماری مدل به سمت بهره‌وری سرویس‌دهی تغییر کرده است — برای درک بیشتر این تغییر، تحلیل ما درباره تراشه‌های نسل جدید انویدیا را بخوانید.