انویدیا درهای هسته محاسباتی GPU را به روی Rust باز کرد؛ مسیرهای SIMT و Tile موازی پیش می‌روند
همزمان با پیوستن به هیئت مدیره بنیاد Rust، انویدیا با گشودن درهای خود به روی زبان برنامه‌نویسی Rust، قصد دارد خندق دفاعی CUDA را عمیق‌تر کند.
انویدیا در تاریخ ۸ سپتامبر (۱۷ شهریور) در وبلاگ فنی رسمی خود اعلام کرد که بخش‌های حیاتی برنامه‌نویسی GPU اکنون مستقیماً با استفاده از Rust قابل نوشتن هستند. اکوسیستم CUDA پیش از این از ابزارهای توسعه بالغ C++ و Python بهره می‌برد، اما هسته‌هایی که مستقیماً روی کارت گرافیک اجرا می‌شوند (kernel)، استثنا بودند. توسعه‌دهندگان می‌توانستند از Rust به این هسته‌ها فراخوانی کنند، اما قادر به نوشتن آن‌ها با Rust نبودند.
پشتیبانی از Rust در CUDA، این پازل ناتمام را تکمیل می‌کند.
روز بعد، در ۹ سپتامبر (۱۸ شهریور)، ربکا رامبول، مدیر اجرایی بنیاد Rust، در مراسم افتتاحیه RustConf 2026 در مونترال اعلام کرد که انویدیا و بنیاد سولانا به عضویت پلاتینیوم بنیاد درآمده‌اند. این عضویت با پرداخت سالانه ۳۲۵ هزار دلار، شامل یک کرسی در هیئت مدیره برای هر کدام می‌شود. این دو خبر در واقع یک پیام را منتقل می‌کنند: انویدیا قصد دارد خود را در حلقه تصمیم‌گیری هسته‌ای Rust جای دهد، نه اینکه صرفاً به عنوان یک کاربر باقی بماند.
لایه سیستم هوش مصنوعی، شامل موتورهای استنتاج، زیرساخت‌های استقرار، درایورها و محیط‌های اجرای عامل‌ها، به سرعت در حال مهاجرت به Rust هستند. دلیل این امر روشن است: Rust قادر است در زمان کامپایل (یعنی پیش از اجرای واقعی برنامه و در مرحله کامپایل، کامپایلر خطاهای مربوط به استفاده از حافظه را شناسایی می‌کند) دسته‌ای از اشکالات را شناسایی کند، بدون اینکه عملکرد را فدا کند.
درایور لینوکس انویدیا، Nova، با Rust نوشته شده است و هسته چارچوب استنتاج NVIDIA Dynamo نیز بر پایه Rust بنا شده است. اما هسته‌های برنامه‌نویسی GPU همواره آخرین قلمرو تسخیر نشده باقی مانده بود: توسعه‌دهندگان می‌توانستند از Rust به آن‌ها فراخوانی کنند، اما مجبور بودند آن‌ها را با CUDA C++ یا زبان‌های دیگر بنویسند.
پشتیبانی از Rust در CUDA، این شکاف را پر می‌کند. این اختلاف زبانی بین لایه سیستم و هسته‌های محاسباتی، خود نوعی بدهی فنی پنهان است: هر چقدر هم که لایه بالایی با Rust به دقت نوشته شود، به محض عبور از مرز و ورود به هسته برنامه، تضمین‌های اولیه از بین می‌روند و مشکلات اغلب تا زمان استقرار در محیط عملیاتی واقعی خود را نشان نمی‌دهند.
انویدیا در این مرحله دو مسیر را پیش گرفته است که با دو مدل برنامه‌نویسی موجود در CUDA مطابقت دارد. مسیر اول، cuda-oxide است که با SIMT (Single Instruction, Multiple Threads – به زبان ساده، توسعه‌دهنده فقط مشخص می‌کند که “یک رشته چه کاری باید انجام دهد” و GPU به طور خودکار هزاران رشته را برای انجام همان کار ایجاد می‌کند) مطابقت دارد. این رایج‌ترین روش برای توسعه‌دهندگان CUDA C++ است. cuda-oxide کل این فرآیند را به کامپایلر Rust منتقل می‌کند و تا PTX (زبان اسمبلی سطح پایین که GPU قادر به درک آن است) کامپایل می‌شود.
مسیر دوم، cutile-rs است که با Tile (بلوک – به زبان ساده، یک مدل برنامه‌نویسی جدیدتر است که در آن توسعه‌دهنده فقط مشخص می‌کند “یک بلوک کامل از داده‌ها چه کاری باید انجام دهد” و کامپایلر خود تصمیم می‌گیرد که چگونه آن را برای اجرا به سخت‌افزار تقسیم کند) مطابقت دارد. انویدیا در وبلاگ خود توصیه می‌کند که توسعه‌دهندگان اولویت را به Tile بدهند، زیرا تشخیص تفاوت‌های معماری به کامپایلر سپرده می‌شود؛ تنها در صورتی که واقعاً نیاز به مدیریت دستی رشته‌ها و حافظه مشترک باشد، باید به SIMT بازگشت.
هر دو مسیر بر یک اصل شرط‌بندی می‌کنند: استفاده از قوانین مالکیت Rust برای جلوگیری از شرایط رقابتی (race conditions – اشکالاتی که در آن‌ها چندین رشته به طور همزمان سعی در خواندن و نوشتن یک بخش از حافظه دارند و با تغییر ترتیب، داده‌ها اشتباه می‌شوند) در زمان کامپایل. انویدیا در وبلاگ خود نشان می‌دهد که اگر یک بافر خروجی مشترک هم به عنوان ورودی و هم به عنوان خروجی به طور همزمان ارسال شود، cuda-oxide مستقیماً با شکست کامپایل مواجه می‌شود؛ cutile-rs حتی سخت‌گیرانه‌تر عمل می‌کند و مالکیت داده‌ها را در طول کل مرز فراخوانی هسته دنبال می‌کند، نه فقط در لحظه فراخوانی.
این نوع اشکالات در گذشته اغلب تا زمان آنلاین شدن برنامه و افزایش ترافیک به ندرت رخ می‌دادند، اما اکنون در همان لحظه نوشتن کد شناسایی می‌شوند.
با این حال، انویدیا خود اذعان دارد که هیچ‌کدام از این دو پروژه هنوز برای استقرار در محیط رسمی آماده نیستند. cuda-oxide در حال حاضر در مرحله آلفای اولیه قرار دارد و برای کامپایل نیاز به ابزارهای توسعه nightly (نسخه‌های آزمایشی کامپایلر Rust که روزانه توسط تیم رسمی Rust به‌روزرسانی می‌شوند، قابلیت‌های جدیدتری دارند اما تضمین سازگاری ندارند) با نسخه‌های ثابت دارد و حافظه مشترک هنوز باید با استفاده از unsafe (سینتکس ناامن که مکانیزم‌های حفاظتی کامپایلر را موقتاً غیرفعال می‌کند و مسئولیت صحت را به توسعه‌دهنده واگذار می‌کند) مدیریت شود.
cutile-rs پیشرفت سریع‌تری داشته و می‌تواند روی نسخه استاندارد Rust اجرا شود و نیازی به ابزارهای nightly ندارد. این پروژه قبلاً توسط موتور استنتاج Grout از Hugging Face و پروژه mistral.rs به کار گرفته شده است؛ اما انویدیا صراحتاً اعلام کرده است که رابط‌های API همچنان در حال تغییر هستند و پوشش‌دهی هنوز کامل نیست. به عبارت دیگر، هر دو مسیر در حال حاضر در مرحله‌ای قرار دارند که “کار می‌کنند، اما عجله‌ای برای سرمایه‌گذاری روی آن‌ها نیست.”
با کنار هم قرار دادن این دو خبر، استراتژی انویدیا کاملاً قابل درک است. CUDA عمیق‌ترین خندق دفاعی انویدیا محسوب می‌شود. در سال‌های اخیر، AMD با ROCm، گوگل با TPU و پشته نرم‌افزاری خود، و بسیاری از شرکت‌های ابری با طراحی تراشه‌های اختصاصی، همگی در تلاش بوده‌اند تا از CUDA عبور کنند. هدف همه آن‌ها این بود که با دور زدن CUDA، قدرت قیمت‌گذاری و نفوذ انویدیا را کاهش دهند.
در ابتدا این نگرانی وجود داشت که با اجبار CUDA به باز شدن به روی اکوسیستم‌های دیگر، مزیت قفل‌شدگی انویدیا تضعیف شود؛ اما رویکرد انویدیا در این مورد کاملاً برعکس است. این شرکت CUDA را در جای خود رها نکرده تا مورد حمله رقبا قرار گیرد، بلکه به طور فعالانه آستانه استفاده را به زبانی که مهندسان سیستم با آن آشنا هستند، کاهش داده است. با این کار، توسعه‌دهندگان Rust نیز به داخل دیوارهای CUDA کشیده می‌شوند. زبان تغییر کرده است، اما بلیط ورود همچنان توسط انویدیا صادر می‌شود و کسانی که به دنبال دلیلی برای خروج بودند، اکنون دلیل کمتری برای این کار دارند.
