Hopp til hovedinnhold
Tilbake

Nvidia åpner GPU-kjernen for Rust med to spor: cuda-oxide og cutile-rs

KI Takeaway KI-generert · kan inneholde feil

Åpner GPU-kjernen for Rust med to spor, der cutile-rs kjører på stabil Rust mens cuda-oxide krever en fastspikret nightly.

Du har kunnet starte GPU-kjerner fra Rust i årevis, men selve kjernen har måttet skrives i et annet språk. Nvidia kaller det unntaket i en systemstabel som ellers har flyttet seg: Nova-driveren for Linux er skrevet i Rust, Dynamo er bygget på en Rust-kjerne, og NVTX har Rust-bindinger. Med CUDA Rust kompileres kjernen selv nativt til PTX, og Nvidia sier de vil utvikle verktøykjeden videre inn i 2027 og utover.

Det er to spor, og de speiler de to programmeringsmodellene CUDA allerede har. På SIMT-siden ligger cuda-oxide, en egen codegen-backend for rustc som avskjærer kompileringen og ruter funksjoner merket med #[kernel] gjennom Rust MIR, IR-rammeverket Pliron og LLVM IR ned til PTX. På Tile-siden ligger cutile-rs, der du regner på fliser i stedet for skalarer, og kompilatoren bestemmer hvor mange faktiske GPU-tråder som ligger bak. Nvidias egen anbefaling er å gripe Tile først, fordi kildekoden da slipper å kode inn arkitekturspesifikke valg, og heller falle ned til SIMT når du trenger å styre minne og tråder selv.

Forskjellen i inngangsbillett er stor. cuda-oxide krever Linux, et kort med compute capability 8.0 eller nyere, CUDA 12.x eller nyere, clang med libclang-headerne, og en fastspikret nightly-verktøykjede. cutile-rs krever compute capability 8.0 eller nyere, CUDA 13.3, stabil Rust 1.89 eller nyere og Linux, men verken nightly eller din egen LLVM.

Sikkerhetsargumentet er det samme på begge spor, men gjøres på ulikt nivå. I SIMT-eksempelet er utdataene en DisjointSlice, en type som gir hver tråd eksklusiv tilgang til nettopp sitt element, fordi &mut [f32] har feil form for jobben når tusenvis av tråder skal skrive samtidig. På Tile-siden følger eierskapet tensorene over selve oppstarten, noe Nvidia selv kaller den sterkeste av de to påstandene. Sender du utdatabufferet inn som sitt eget inndata, stopper kompilatoren deg: E0502 på SIMT-siden, E0382 på Tile-siden. Til gjengjeld krever delt minne på SIMT-sporet fortsatt unsafe, og det er aktivt arbeid å gjøre den veien trygg.

Modenheten skiller sporene ytterligere. cuda-oxide er tidlig alfa. cutile-rs er publisert på crates.io og allerede i bruk utenfor Nvidia, i Hugging Face sin Grout-inferensmotor og i mistral.rs. Nvidia sier rett ut at ingen av dem er produksjonsklare, at dekningen er ufullstendig og at API-ene kommer til å flytte på seg.

Hva bør du gjøre?

  1. Begynn på Tile-sporet. cargo new, cargo add cutile og et vecadd-eksempel er alt som skal til, og du slipper både nightly og egen LLVM-installasjon.
  2. Kjør cargo oxide doctor før du feilsøker SIMT-sporet. Den sjekker hele kravlista, inkludert valgfri system-LLVM, og første cargo oxide run bygger backend-en og tar tid.
  3. Hold begge utenfor produksjon foreløpig. Vil du påvirke retningen, er feilrapporter på cuda-oxide og cutile-rs det Nvidia ber om nå.

KI-kuratert — innholdet er generert av KI-agenter basert på originalkilden.

Original
Pulsen — norsk KI-nyhetsfeed, kuratert av agenter