CUDA Rust schließt die Lücke zum GPU-Kernel
NVIDIA erweitert CUDA um native Unterstützung für GPU-Kernel in Rust. Entwickler müssen damit den rechenintensiven Device-Code nicht mehr separat in CUDA C++ oder Python schreiben. Host- und Device-Code können in denselben Rust-Dateien liegen und mit den üblichen Cargo-Befehlen gebaut werden.
Die am 8. September 2026 angekündigte Initiative besteht aus zwei parallelen Ansätzen. cuda-oxide richtet sich an hardwarenahe SIMT-Programmierung, bei der einzelne Threads und Speicherzugriffe kontrolliert werden. cutile-rs abstrahiert diese Details über Datenblöcke, sogenannte Tiles, deren Verteilung auf die GPU der Compiler übernimmt.
NVIDIA will beide Ansätze bis 2027 und darüber hinaus weiterentwickeln. Rust kommt im Unternehmen bereits beim Nova-Linux-Treiber, im Kern von Dynamo und bei den NVTX-Bindings zum Einsatz.
Zwei Wege für unterschiedliche Anforderungen
cuda-oxide ist ein eigenes Codegen-Backend für den Rust-Compiler. Es leitet markierte Kernel über Rust MIR, das Pliron-IR-Framework und LLVM weiter und erzeugt daraus PTX. PTX ist NVIDIAs Zwischendarstellung für Programme, die anschließend auf der GPU ausgeführt werden.
Der Ansatz folgt dem SIMT-Modell, kurz für Single Instruction, Multiple Threads. Dabei wird definiert, was ein einzelner Thread ausführt. Das bietet viel Kontrolle über Threads, Speicher und Hardware, verlangt aber auch entsprechendes CUDA-Wissen.
cutile-rs arbeitet dagegen mit größeren Datenbereichen. Der Compiler entscheidet, wie diese Tiles auf Threads, Speicher und die jeweilige GPU-Architektur verteilt werden. Die Übersetzung erfolgt per JIT-Kompilierung, also zur Laufzeit, über NVIDIAs CUDA Tile IR.
| Merkmal | cuda-oxide | cutile-rs |
|---|---|---|
| Programmiermodell | SIMT mit direkter Thread-Kontrolle | Tile-basiert mit Compiler-Abstraktion |
| Rust-Version | Gepinnte Nightly-Toolchain | Stable Rust ab 1.89 |
| CUDA-Voraussetzung | CUDA Toolkit 12.x oder neuer | CUDA 13.3 |
| Weitere Voraussetzungen | Linux, Clang und libclang | Linux, kein eigenes LLVM erforderlich |
| GPU | Compute Capability 8.0 oder neuer | Compute Capability 8.0 oder neuer |
| Reifegrad | Frühes Alpha-Stadium | Auf crates.io verfügbar |
cutile-rs wird bereits in der Grout-Inferenz-Engine von Hugging Face und in mistral.rs eingesetzt. cuda-oxide ist deutlich experimenteller. Einen Termin für eine stabile Version nennt NVIDIA bislang nicht.
Speichersicherheit reicht bis zum Kernel
Der zentrale Vorteil von Rust ist die Prüfung vieler Speicherfehler während der Kompilierung. Beide CUDA-Ansätze übertragen dieses Prinzip auf GPU-Code, nutzen dafür aber unterschiedliche Mechanismen.
cuda-oxide arbeitet unter anderem mit DisjointSlice und sogenannten Launch Contracts. DisjointSlice stellt sicher, dass jeder Thread nur exklusiven Zugriff auf den für ihn vorgesehenen Speicherbereich erhält. Launch Contracts prüfen, ob die Startkonfiguration eines Kernels zu den im Code festgelegten Bedingungen passt.
cutile-rs nutzt Tensor-Partitionierung und Rusts Ownership-Modell. Dadurch soll bereits beim Übersetzen ausgeschlossen werden, dass mehrere Programmteile unkontrolliert denselben veränderbaren Speicherbereich verwenden.
Die Wahl von Rust soll künftig nicht vom CUDA-Ökosystem für C++ und Python isolieren.
NVIDIA plant dafür Interoperabilität zwischen CUDA Rust, CUDA C++ und CUDA Python. Wie diese Zusammenarbeit technisch im Detail umgesetzt wird, bleibt noch offen.
Was CUDA Rust für Unternehmen verändert
Für Unternehmen mit Rust-basierten Backends, Datenplattformen oder Inferenzdiensten entfällt ein bisher typischer Medienbruch. GPU-Kernel lassen sich in derselben Sprache entwickeln wie der übrige Systemcode. Das kann gemeinsame Prüfwerkzeuge, einheitliche Build-Prozesse und die interne Wartung erleichtern.
Die Entwicklung passt zur breiteren Verbreitung von Rust in geschäftskritischer Infrastruktur. Auch Microsoft behandelt Rust inzwischen als interne Tier-1-Sprache. Für Teams im DACH-Raum ist besonders die Kombination aus hoher Leistung, Typsicherheit und kontrollierbaren Speicherzugriffen relevant.
Belastbare Aussagen zur Geschwindigkeit gegenüber handoptimiertem CUDA C++ sind allerdings noch nicht möglich. NVIDIA nennt keine direkten Vergleichswerte. Die technische Bewertung sollte deshalb anhand eigener Kernel, realer Modelle und der vorgesehenen Hardware erfolgen.
Mehr Eigenentwicklung, aber weiterhin CUDA-Bindung
CUDA Rust kann den Aufbau eigener Inferenz-, Datenverarbeitungs- und Rendering-Systeme auf lokalen GPUs vereinfachen. Zusammen mit günstigen Open-Weights-Modellen als Alternative zu geschlossenen APIs entsteht damit eine weitere Option, laufende Cloud- und Inferenzkosten zu kontrollieren.
Für Self-Hosting bedeutet das dennoch keine vollständige Unabhängigkeit. Der Anwendungscode kann offen und in Rust geschrieben sein, benötigt aber weiterhin NVIDIAs proprietäre CUDA-Plattform, passende Treiber und GPUs ab Compute Capability 8.0. Die Abhängigkeit verschiebt sich damit vom Software-Abo zur Hardware- und Plattformebene.
Alternativen auf anderer Hardware bleiben deshalb strategisch relevant. Lokale Systeme wie die AMD Threadripper Halo Workstation für KI-Workloads zeigen, dass Unternehmen bei Infrastrukturentscheidungen auch Speicherbedarf, Treiberunterstützung und Herstellerbindung gemeinsam bewerten müssen.
CUDA Rust senkt somit eine wichtige technische Hürde für eigene GPU-Software. Ob daraus auch wirtschaftliche Vorteile entstehen, hängt von Entwicklungsaufwand, Auslastung, Hardwarekosten und dem Reifegrad der Werkzeuge ab. Vor allem cuda-oxide ist derzeit noch keine Grundlage, die ohne zusätzliche Prüfung für produktive Systeme eingeplant werden sollte.