16 juli 2026
Serverhall med GPU-hårdvara i närbild, kablage i bakgrunden

cuTile Rust låter dig skriva GPU-kod utan att slänga borrow-checkern

cuTile Rust är ett projekt från NVIDIA som gör att du kan skriva GPU-kernels i Rust utan att förlora minnessäkerheten på vägen. Buggar där två delar av programmet skriver till samma minne samtidigt, så kallade data races, fångas redan vid `cargo build` istället för att smälla i produktion. Projektet släpptes under Apache 2.0-licens och beskrivs i ett papper på arXiv från 14 juni 2026.

Det låter kanske smalt men problemet det löser har irriterat GPU-programmerare i över ett decennium.

Rusts säkerhet slutade gälla när den nådde grafikkortet

När du skriver vanlig Rust-kod vakar borrow-checkern över minnet åt dig. Den ser till att bara en del av programmet får skriva till en viss minnesplats i taget och den gör det vid kompilering, utan prestandaförlust. Det är hela poängen med språket.

Men så fort koden lämnade processorn och skulle köra på grafikkortet försvann det skyddet. Referenser kollapsade till råa pekare. Aliasing och synkronisering blev något utvecklaren fick hålla reda på för hand, i huvudet, med samma felmarginal som i C. En felplacerad skrivning och du fick en tyst korruption som var nästan omöjlig att felsöka.

Det är den gränsen cuTile Rust bär över ägarskapet. Inte bara i host-koden på processorsidan, utan hela vägen in i själva GPU-kerneln.

Partitionering istället för lås är hur säkerheten fungerar

Trixet är att dela upp minnet i bitar som inte kan överlappa och låta typsystemet bevisa det. Innan en kernel startar partitioneras den muterbara output-tensorn i disjunkta slices. Varje tile-program får sedan en exklusiv `&mut`-vy av precis sin bit, medan indata kommer in som vanliga `&`-referenser.

Eftersom partitionerna inte kan överlappa är varje kernel data-race-fri av konstruktion. Det finns inget runtime-lås som ska tas och släppas, ingen mutex som kan ge deadlock. Säkerheten ligger i hur koden är typad, inte i något som händer medan programmet kör.

Det ger två konkreta effekter:

  • Aliasing-buggar avvisas vid `cargo build`. Försöker du få två samtidiga skrivare mot samma minne kompilerar koden helt enkelt inte.
  • Bounds-checks försvinner vid runtime. Märkta partitionsindex och begränsade iteratorer bevisar redan vid kompilering att du håller dig innanför gränserna, så kontrollerna behövs inte medan koden kör.

Kernlarna körs semantiskt som om de vore enkeltrådade, vilket gör dem betydligt lättare att resonera kring. Du slipper hålla synkroniseringsinvarianter i huvudet.

Prestandan tappar inte mot handoptimerad kod

Den vanliga invändningen mot säkerhetsabstraktioner är att de kostar prestanda. Här gör de det knappt.

På ett B200-kort nådde en tät f16 GEMM-operation 2,07 PFlop/s vid M=N=K=8192. Det motsvarar 92 procent av kortets teoretiska toppprestanda och 96 procent av vad cuBLAS levererar, NVIDIAs eget handoptimerade bibliotek. Element-wise-operationer nådde 7 TB/s.

Poängen är inte siffrorna i sig, utan att idiomatisk och minnessäker Rust-kod hamnar så nära vendor-bibliotekens prestanda att skillnaden knappt är mätbar. Du behöver alltså inte välja mellan säker kod och snabb kod.

Ovanpå cuTile Rust finns Grout, en LLM-inferensmotor byggd på tekniken. Den genererade 171 tokens per sekund för Qwen3-4B på ett RTX 5090 och 82 tokens per sekund för Qwen3-32B på ett B200. På batch-1-avkodning ligger den i nivå med etablerade motorer som vLLM och SGLang.

Vad du behöver för att köra det

Kraven är tydliga och ganska nya. Det här är inget du kör på ett äldre gaming-kort.

Komponent Krav
GPU Compute capability sm_80+ (A100, H100, B200)
CUDA Version 13.3 eller senare
Rust 1.89 eller senare
Drivrutin Version 610 eller senare

Att lägsta nivån är sm_80 betyder att konsumentkort av äldre snitt faller utanför. Det här riktar sig mot datacenter-GPU:er och de senaste toppmodellerna, inte mot laptopen. Vill du grotta i vad korten faktiskt gör bakom kulisserna har vi samlat en rad gratis verktyg för dator och nätverk som funkar oavsett hårdvara.

Begränsningarna du bör känna till

Det här är tidig kod och det märks. Innan du planerar ett projekt runt det bör du väga in flera saker.

NVIDIA-only. Det finns ingen portabilitet till AMD eller andra GPU-leverantörer. Binder du dig till cuTile Rust binder du dig till NVIDIAs ekosystem, precis som med CUDA i övrigt.

Grout är smalt. Inferensmotorn stöder bara Qwen3-modeller lagrade som safetensors. Ingen spekulativ avkodning, ingen multi-GPU-exekvering. Benchmark-siffrorna finns i pappret, inte i själva koden och repositoryt har få commits och inga taggade releaser.

Makron är under utveckling. API-brytningar är att vänta. Bygger du något idag får du räkna med att skriva om delar när projektet mognar.

Ordet ”tiling” är för övrigt inte nytt i sammanhanget. Redan runt 2010 pratade CUDA-utvecklare om tiling för att tuna block-geometri, sådant som 4×8- eller 32×4-formade block. Det 2026-arbetet tillför är en helt annan sak, en programmeringsmodell där kernels skrivs över tiles med partitionerad mutabilitet och där säkerheten är inbyggd i typerna.

Varför det spelar roll för Rust och GPU

cuTile Rust är intressant för att det visar att Rusts kärnlöfte kan sträckas ut till en domän där det tidigare gav upp. GPU-programmering har varit ett av de sista fästena för handhållen minneshantering och att kunna få kompilatorn att avvisa data races där också är ett genuint steg framåt.

För svenska utvecklare som redan jobbar med maskininlärning eller tunga beräkningar betyder det ett alternativ som inte tvingar fram valet mellan säkerhet och fart. Att sedan låsningen till NVIDIA kvarstår är en reell nackdel och tidiga API-brytningar gör det olämpligt för produktion just nu.

Men riktningen är rätt. Om NVIDIA fortsätter satsa och Rusts egen NVPTX-backend mognar parallellt, kan säker GPU-kod bli standard snarare än undantag inom några år. Det tekniska underlaget finns beskrivet i pappret på arXiv för den som vill gräva djupare.

FAQ

Fungerar cuTile Rust på AMD-grafikkort?

Nej. Projektet är helt bundet till NVIDIA och stöder inga andra GPU-leverantörer.

Kan jag köra det på mitt vanliga gaming-grafikkort?

Bara om det når compute capability sm_80 eller högre. Kraven pekar mot datacenter-kort som A100, H100 och B200 samt de senaste toppmodellerna och du behöver dessutom CUDA 13.3+, Rust 1.89+ och drivrutin 610 eller nyare. Äldre konsumentkort faller utanför.

Vad är skillnaden mot att bara använda CUDA direkt?

CUDA tvingar dig att hantera aliasing och synkronisering för hand, med samma risk för tysta minnesbuggar som i C. cuTile Rust bär i stället Rusts ägarskap in i kerneln, så att data races fångas redan vid kompilering i stället för att uppstå medan koden kör.

Är projektet färdigt att använda i produktion?

Nej. Makron är under utveckling, API-brytningar väntas och den tillhörande inferensmotorn Grout har få commits och inga taggade releaser. Betrakta det som tidig och lovande kod, inte som en stabil plattform.

Fredrik Albinsson
Chefredaktör & expert på digitala tjänster

Fredrik Albinsson är chefredaktör för PC Concept och har varit med sedan sajten grundades. Med över 15 års erfarenhet inom IT och teknikjournalistik leder han redaktionens arbete och sätter riktningen för innehållet. Han bevakar framför allt utvecklingen inom digitala tjänster och appar.

Lämna ett svar

Din e-postadress kommer inte publiceras. Obligatoriska fält är märkta *