۲.۱۱ برابر. این عدد، میزان افزایش سرعتی است که CUDA Agent به دست آورده است؛ یک سامانهٔ عاملمحور (Agentic) مبتنی بر یادگیری تقویتی (Reinforcement Learning) که توسط ByteDance Seed و Tsinghua AIR توسعه یافته تا کرنلهای GPU را با دقتی فراتر از کامپایلرهای حرفهای بنویسد. این سیستم یکی از سختترین گلوگاههای زیرساخت هوش مصنوعی را هدف قرار داده است: مدلهای پیشرو اگرچه میتوانند کد CUDA صحیح بنویسند، اما معمولاً کرنلهایی تولید میکنند که در مقایسه با بهینهسازیهای خودکار کامپایلرها، کند هستند.
زمینه و تأثیرات صنعتی
این پیشرفت در زمانی رخ میدهد که صنعت با هزینههای بالای استنتاج (Inference) و تأخیر در مسیرهای بحرانی (Critical Paths) برای کرنلهای ادغامشده (Fused Kernels) دستوپنجه نرم میکند. برای توسعهدهندگان در حوزههای رانندگی خودکار، معاملات الگوریتمی و تصویربرداری پزشکی، تفاوت بین یک کامپایلر استاندارد و یک کرنل دستنویس و بهینه، اغلب تعیینکنندهٔ این است که آیا یک مدل قابلیت استقرار در زمان واقعی (Real-time) را دارد یا خیر.
سایر کاربردهای کلیدی این سیستم شامل زیرساختهای هوش مصنوعی، سرویسهای استنتاج، ابرهای GPU و سیستمهای توصیهگر است. این سامانه بهویژه برای ادغام توالیهای اپراتوری که torch.compile در مدیریت آنها ضعف دارد، بسیار مفید است و میتواند هزینه هر توکن را کاهش داده و کرنلها را برای نسلهای مختلف GPU بازتنظیم کند. این تلاشها در راستای بهینهسازی زیرساختهای PyTorch صورت میگیرد، مشابه رویکردهایی که برای کاهش زمان توقف آموزش مدلهای زبانی بزرگ در گرههای جایگزین به کار گرفته شده است.
به گزارش مقاله منتشر شده در arXiv، این سیستم بر پایه مدل Seed1.6 بنا شده است؛ یک مدل ترکیب خبرهها (Mixture-of-Experts) اختصاصی با ۲۳۰ میلیارد پارامتر کل و ۲۳ میلیارد پارامتر فعال. این مدل بخشی از استراتژی گستردهتر بایتدنس برای توسعه مدلهای عظیم است، در حالی که گزارش شده این شرکت در حال آموزش مدلی با ۱۰ تریلیون پارامتر برای رقابت با آنتروپیک است. پژوهشگران برای پر کردن شکاف عملکرد، مدل را در یک محیط ایزوله (Sandbox) با دسترسی محدود قرار دادند که مجهز به ابزارهای پروفایلینگ و بررسی صحت کد بود.

جزئیات فنی و آموزش
CUDA Agent با استفاده از بهینهسازی سیاست تقریبی (PPO) برای ۱۵۰ گام و با یک پنجرهٔ زمینه (Context Window) عظیم ۱۳۱,۰۷۲ توکنی آموزش دیده است. چرخهٔ عملکرد این عامل مشابه ابزار OpenHands است و از الگوی ریاکت (ReAct) به همراه مجموعهای از ابزارها نظیر Bash, Read/Write, Edit/MultiEdit, Glob, Grep, NotebookEdit, BashOutput و KillBash استفاده میکند.
برای آموزش مدل، تیم پژوهشی مجموعه داده CUDA-Agent-Ops-6K را سنتز کرد. آنها اپراتورهای مرجع را از کتابخانههای torch و transformers استخراج کرده و تا پنج کلاس اپراتور torch را برای ایجاد لایههای ادغامشده (Fused) ترکیب کردند. برای تضمین کیفیت، آنها اپراتورهایی را فیلتر کردند که قطعی (Deterministic) بودند، خروجیهای غیرثابت تولید میکردند و زمان اجرای آنها در حالت eager بین ۱ تا ۱۰۰ میلیثانیه بود. هر نمونهای که شباهت AST آن با تکالیف موجود در KernelBench بیش از ۰.۹ بود، حذف شد. مجموعه داده نهایی شامل ۶,۰۰۰ نمونه است که ۸۳.۷۷٪ آنها ترکیبی از دو اپراتور هستند.
نتایج بهدستآمده در محک KernelBench بسیار چشمگیر است:
- نرخ پذیرش: ۹۸.۸٪ از تکالیف بهطور صحیح تکمیل شدند.
- عملکرد: ۹۶.۸٪ از کرنلهای تولیدشده سریعتر از torch.compile بودند.
- افزایش سرعت: میانگین هندسی سرعت ۲.۱۱ برابر بیشتر از کامپایلر بود.
- پیچیدگی: در توالیهای اپراتوری سطح ۲، نرخ پیشی گرفتن از کامپایلر به ۱۰۰٪ با سرعت ۲.۸۰ برابر رسید.
- مزیت رقابتی: در سختترین بخش (سطح ۳)، نرخ موفقیت ۹۰٪ بود که حدود ۴۰ واحد از Claude Opus 4.5 (۵۰٪) و Gemini 3 Pro (۵۲٪) جلوتر است.

مکانیسمهای پاداش و محدودیتها
برای جلوگیری از سوءاستفاده از پاداش (Reward Hacking) — وضعیتی که مدل برای فریب دادن پروفایلر بدون بهبود واقعی کد، میانبر میزند — پنج تدبیر اتخاذ شد:
- استفاده از اسکریپتهای تأیید و پروفایلینگ با دسترسی محدود (Permission-locked).
- مدیریت زمینهای (Context Managers) برای ممنوعیت بازگشت به توابع torch.nn.functional.
- بررسی صحت کد در برابر پنج ورودی تصادفی.
- پروفایلینگ همراه با همگامسازی دستگاه (Device Synchronization) و گرم کردن (Warm-up).
- حذف کامل ابزار جستوجوی وب.
تیم بهجای استفاده از نسبت خام سرعت برای پاداشها، از یک سیستم پاداش گسسته (r ∈ {−1, 1, 2, 3}) استفاده کرد. پاداش ۱- برای شکست در بررسی صحت داده میشد، در حالی که پاداش ۳ تنها زمانی اعطا میشد که کرنل هم از حالت eager و هم از torch.compile بیش از ۵٪ سریعتر باشد (با تلورانس atol=1e-2 و rtol=1e-2). این انتخاب خاص باعث شد نرخ پیشی گرفتن از کامپایلر ۳۶.۴ واحد نسبت به استفاده از نسبتهای خام بهبود یابد.
تحلیل عملکرد
مطالعات موردی نشان میدهد که سیستم قادر به یافتن بهینهسازیهای غیربدیهی است. در یک مورد، بازنویسی یک ضرب ماتریسی قطری (Diagonal Matmul) به مقیاسبندی ردیفی (Row-wise Scaling)، منجر به افزایش سرعت ۷۳.۳۱ برابری نسبت به torch.compile شد. در مورد دیگر، یک زنجیره از عملیات ضرب-تقسیم-جمع-مقیاس، پس از آنکه عامل ترتیب را تغییر داد و توالی را ادغام کرد، بهبود ۲۴.۰۴ برابری را تجربه کرد. همچنین یک ResNet BasicBlock که در آن BatchNorm در کانولوشن ادغام شده بود و از cudnnConvolutionBiasActivationForward استفاده میکرد، به افزایش سرعت ۳.۵۹ برابری دست یافت.
تحلیلهای حذف (Ablation studies) نشان میدهد که حذف چرخهٔ عامل، نرخ موفقیت را از ۹۶.۸٪ به ۱۴.۱٪ کاهش میدهد. علاوه بر این، ترکیب تنظیم دقیق ردکننده (RFT) و پیشآموزش مقدار (Value Pretraining) برای جلوگیری از فروپاشی پاداش و مسیرهای runaway ضروری بود و یک سقوط ۱۷ گامی را به ۱۵۰ گام پایدار تبدیل کرد. این تمرکز بر کاهش تأخیر در مدلهای MoE با روندهای اخیر همسو است، مانند کتابخانه Mixture-of-Kittens که توانست تأخیر آموزش مدلهای MoE را تا ۵.۸ برابر کاهش دهد.
از منظر فنی، این دستاورد معیار کدنویسی به کمک هوش مصنوعی را از «صحت» به «کارایی» تغییر میدهد. این موضوع ثابت میکند که یادگیری تقویتی میتواند برای معیارهای عملکردی سطح سختافزار که برای تنظیم دقیق نظارتشده (SFT) بسیار پیچیده هستند، بهینهسازی انجام دهد. با این حال، سد ورود همچنان بالاست؛ تنها محیط پروفایلینگ به ۱۲۸ عدد GPU NVIDIA H20 نیاز داشت که این امر بازتولید کامل سیستم را به آزمایشگاههای بزرگ و ارائهدهندگان ابری محدود میکند.
اگرچه وزنهای عامل آموزشدیده بسته باقی مانده است، اما پژوهشگران مجموعه داده CUDA-Agent-Ops-6K، مشخصات SKILL.md و دستورالعملهای پاداش را منتشر کردهاند. این امر به تیمهای متوسط اجازه میدهد تا این منطق را روی مدلهای وزنهای باز (Open Weights) پیاده کنند.
توسعهدهندگان باید رصد کنند که آیا این رویکرد عاملمحور برای تولید کرنل در نسخههای آینده PyTorch یا سایر چارچوبهای یادگیری عمیق ادغام خواهد شد تا مرحله «تنظیم دستی» (Hand-tuning) در استقرار مدلها خودکار شود.




گفتگو