NVIDIA otwiera programowanie GPU w Rust. Dwie ścieżki

Kod liczący na karcie graficznej da się teraz napisać w Ruście i skompilować wprost do PTX, czyli do wirtualnego zestawu instrukcji, który sterownik NVIDII tłumaczy na kod binarny dla konkretnej architektury układu. Z Rusta dało się sięgać po kartę już wcześniej, ale w wielu rozwiązaniach sam kernel nadal powstawał w innym języku. Producent udostępnił dwa niezależne projekty, oba otwarte na licencji Apache 2.0. Programowanie GPU w Rust dostaje więc narzędzia od samej NVIDII, choć żaden z tych projektów nie jest jeszcze gotowy na produkcję.

Czym jest CUDA Rust i od kiedy można tego użyć

Pod nazwą CUDA Rust kryją się dwa osobne projekty, ogłoszone 8 września 2026 na blogu deweloperskim NVIDII przez Sriego Koundinyana, Meliha Elibola i Jonathana Bentza. Oba służą do pisania kerneli, czyli funkcji wykonywanych równolegle przez tysiące wątków karty graficznej.

Pierwszy nazywa się cuda-oxide i obsługuje klasyczny model CUDA. Drugi to cutile-rs i idzie nowszą drogą, opartą na kafelkach danych. Kod obu leży publicznie w repozytoriach NVlabs na GitHubie, na licencji Apache 2.0.

Trzy rzeczy są wspólne i to one najszybciej rozstrzygają, czy w ogóle warto próbować. Oba projekty działają tylko na Linuksie, testowane były na Ubuntu 24.04. Oba wymagają karty o zdolności obliczeniowej 8.0 lub wyższej, czyli generacji Ampere i nowszych. I oba ich autorzy opisują jako oprogramowanie wczesne, z niepełnymi funkcjami i zmieniającym się API.

Jeden wątek albo jeden kafelek danych

Różnica między ścieżkami sprowadza się do tego, co opisujesz w kodzie.

W modelu SIMT piszesz, co robi jeden wątek, a potem uruchamiasz ich tysiące naraz. Tak działa CUDA C++ od lat i tak działa cuda-oxide. Rozkład pracy na wątki i układ danych w pamięci masz na głowie.

W modelu kafelkowym opisujesz, co dzieje się z jednym kafelkiem danych, a odwzorowanie na wątki i rozmieszczenie w pamięci bierze na siebie kompilator. NVIDIA udostępniała ten model wcześniej w CUDA C++ i w Pythonie, a teraz dokłada Rusta. Kod wygląda przez to bliżej matematyki niż sprzętu:

#[cutile::module]
mod kernel {
    use cutile::core::*;

    #[cutile::entry()]
    fn add<const B: i32>(
        z: &mut Tensor<f32, { [B] }>,
        x: &Tensor<f32, { [-1] }>,
        y: &Tensor<f32, { [-1] }>,
    ) {
        let tx = x.load_like(z);
        let ty = y.load_like(z);
        z.store(tx + ty);
    }
}

Przykład pochodzi z dokumentacji cutile-rs i dodaje do siebie dwa tensory. Nie ma w nim ani identyfikatora wątku, ani ręcznego liczenia przesunięć w pamięci.

cuda-oxide wymaga nocnej wersji Rusta i jest wczesną alfą

cuda-oxide to własna końcówka kompilatora Rusta, wpięta w rustc. Kernele oznacza się makrami #[kernel] i #[cuda_module]. Domknięcia razem z przechwyconymi wartościami kompilator sam rozkłada na postać wykonywalną na karcie. Budowę obsługuje podkomenda cargo oxide z poleceniami run, build, test, debug i sanitize.

Lista wymagań jest długa i to jest tu główna informacja praktyczna:

• nocna wersja Rusta przypięta do konkretnej daty, z komponentami rust-src, rustc-dev i llvm-tools
• CUDA Toolkit w wersji 13.0 lub nowszej, z nagłówkami cuRAND
• sterownik R580 lub nowszy
• Clang z nagłówkami libclang, w instrukcji podany jako clang-21
• Linux, testowany na Ubuntu 24.04

Osobny LLVM jest opcjonalny i README wymienia go poza listą wymagań. Kompilacja sięga najpierw po llc z przypiętego łańcucha narzędzi Rusta. Dopiero potem szuka systemowego llc w wersji 23, 22 albo 21. Liczy się wersja używanego llc, niezależnie od tego, skąd pochodzi. Prostsze kernele mogą zadziałać i na starszym, ale Hopper i Blackwell wymagają wersji 21 lub nowszej.

Warto tu zajrzeć do repozytorium, a nie do ogłoszenia. Wpis blogowy z 8 września podaje wymagania łagodniejsze: CUDA w wersji 12.x lub nowszej i wcześniejszą wersję nocną Rusta. Plik README podaje wartości wyższe. To on opisuje stan, który zastanie ktoś próbujący dziś zbudować projekt.

Autorzy nazywają cuda-oxide wczesną alfą. Repozytorium dodaje, że należy się spodziewać błędów, niepełnych funkcji i łamania API.

cutile-rs działa na stabilnym Ruście i ma już użytkowników

Druga ścieżka ma zauważalnie niższy próg wejścia. cutile-rs wymaga stabilnego Rusta w wersji 1.89 lub nowszej oraz Linuksa. Nie potrzebuje ani nocnej wersji kompilatora, ani własnego LLVM-a. Pakiet leży na crates.io pod nazwą cutile.

Wymagana wersja CUDA zależy od generacji karty i układa się wbrew intuicji. Ampere i Ada (sm_8x) potrzebują wersji 13.2, Blackwell (sm_100+) również 13.2, a Hopper (sm_90) dopiero 13.3. NVIDIA zaleca 13.3 wszystkim, bo pakowanie FP4 i mnożenie macierzy ze skalowaniem blokowym działają tylko od tej wersji. Karty poniżej sm_80 nie są obsługiwane w ogóle.

Poza NVIDIĄ używa go już Hugging Face w silniku wnioskowania Grout, obsługującym modele Qwen 3, oraz projekt mistral.rs. To drugie zastosowanie znamy wyłącznie z ogłoszenia producenta. Warto przy okazji odnotować, że Hugging Face od sierpnia należy do NVIDII, więc nie jest to całkiem niezależny głos z rynku.

Między tymi dwoma opisami jest napięcie, którego nie warto wygładzać. Ogłoszenie chwali się użyciem poza firmą, a README tego samego projektu ostrzega przed błędami i zmianami API. Obie rzeczy mogą być prawdziwe naraz, ale wybierając cutile-rs do czegokolwiek poważnego, bierzesz na siebie przepisywanie kodu przy kolejnych wydaniach.

Dlaczego akurat Rust i co z CUDA C++

Uzasadnienie podaje sama NVIDIA i nie trzeba go zgadywać z dyskusji pod ogłoszeniem. Warstwa systemowa wokół AI, czyli silniki wnioskowania, infrastruktura serwująca modele, sterowniki i środowiska uruchomieniowe agentów, powstaje coraz częściej w Ruście. Firma pisze wprost, że język ten wyłapuje całe klasy błędów już na etapie kompilacji, bez oddawania wydajności.

Rust jest zresztą u niej obecny od dawna. W Ruście napisany jest sterownik Nova dla Linuksa, na rdzeniu w Ruście stoi NVIDIA Dynamo, a biblioteka NVTX ma wiązania do tego języka. Dokładanie do tego kerneli domyka listę.

CUDA C++ nigdzie się nie wybiera. NVIDIA nazywa CUDA C++ i CUDA Python dojrzałymi łańcuchami narzędzi klasy korporacyjnej i zapowiada rozwijanie CUDA Rust do 2027 roku i dalej. Nowe projekty dokładają trzecią możliwość obok tamtych dwóch. Współpraca między tymi trzema językami jest na razie planem, a nie działającą funkcją, więc dziś wybór ścieżki nadal coś przesądza.

Sam język ma zresztą u siebie własną dyskusję o tym, co wolno wpuścić do repozytorium. Pisaliśmy o tym przy okazji stanowiska projektu Rust wobec kodu generowanego przez modele.

Co to zmienia, jeśli dziś piszesz w CUDA C++ albo w Ruście

Dla osoby utrzymującej produkcyjny kod w CUDA C++ nie zmienia się dziś nic. Żaden z tych projektów nie jest gotowy do zastąpienia czegokolwiek, a producent sam to mówi.

Dla osoby, która pisze w Ruście i chciała dotąd sięgnąć po kartę, realnym punktem wejścia jest cutile-rs. Stabilny kompilator i brak konieczności konfigurowania własnego LLVM-a wyraźnie obniżają próg wejścia wobec cuda-oxide. cuda-oxide zostaw na później, chyba że interesuje cię sam kompilator.

Trzy rzeczy potrafią zamknąć temat, zanim się zacznie. Windows odpada, bo obsługiwany jest wyłącznie Linux. Karta poniżej zdolności obliczeniowej 8.0 odpada tak samo. I nie ma żadnych opublikowanych liczb porównujących wydajność z CUDA C++, więc decyzji o szybkości na razie nie da się podjąć na danych.

Podsumowanie

Ogłoszenie z 8 września zamyka pytanie o wsparcie producenta dla Rusta na kartach graficznych. Otwiera za to dwa mniejsze: którą ścieżkę wybrać i kiedy. Na dziś wybór jest prosty, bo tylko jedna z nich stoi na stabilnym kompilatorze. cutile-rs uruchomisz na zwykłym Ruście 1.89, na Linuksie i na karcie od generacji Ampere wzwyż. Wersja CUDA to 13.2 albo 13.3, zależnie od układu. cuda-oxide wymaga nocnego kompilatora przypiętego do konkretnej daty, CUDA 13.0 i Clanga z nagłówkami libclang. Obie ścieżki są wczesne i obie będą łamać API. Do niczego, co ma działać za pół roku bez opieki, jeszcze się nie nadają. Kto chce je poznać, niech zacznie od repozytoriów NVlabs, a nie od ogłoszenia, bo wymagania w obu miejscach się różnią.

Mateusz Wojdalski

Specjalista SEO i content marketingu w Devstock. Zajmuję się strategią treści, automatyzacją procesów marketingowych i wdrożeniami AI w codziennej pracy. Badam nowe narzędzia, adaptuję je do realnych zadań i piszę o tym, co faktycznie działa.