CUDA Toolkit 13.4: Windows on Arm, Rubin-Preview und MPS V3

CUDA 13.4: Windows on Arm, Rubin-Preview und MPS V3

NVIDIA hat das CUDA Toolkit 13.4 veröffentlicht. Die Version führt drei wesentliche Neuerungen ein: erstmals native Unterstützung für Windows on Arm, eine frühe Entwickler-Unterstützung für die kommende Rubin-GPU-Architektur als Preview sowie eine modernisierte Steuerungsschicht für den Multi-Process Server (MPS) in Version 3. Bisher war CUDA auf Arm-Plattformen nur unter Linux verfügbar; mit dieser Version erweitert NVIDIA die Unterstützung auf Windows on Arm. Die Rubin-Architektur mit Compute Capability 107 wird als Preview unterstützt, damit Entwickler bereits vor der allgemeinen Verfügbarkeit mit der Portierung beginnen können. MPS V3 führt eine scriptable CLI, benannte Server-Instanzen, Namespaces, TOML-Konfiguration, SM-Partitionssteuerung und cgroup-integrierte GPU-Speicherlimits ein. Diese Funktionen sind für die GPU-Ressourcenverwaltung wichtig, weil sie eine präzise Zuweisung von Rechenkapazität und Speicher in gemeinsam genutzten Umgebungen ermöglichen: Die scriptable CLI und TOML-Konfiguration erlauben die Automatisierung der MPS-Verwaltung in CI/CD-Pipelines oder Orchestrierungssystemen, benannte Server-Instanzen und Namespaces helfen dabei, gleichzeitige Workloads verschiedener Teams oder Projekte sauber zu trennen, und SM-Partitionssteuerung sowie cgroup-integrierte Speicherlimits verhindern, dass ein einzelner Prozess die gesamte GPU blockiert. Zusätzlich erweitert das Toolkit CUDA Python und CCCL sowie die Nsight-Entwicklertools und Kern-Mathematikbibliotheken. Die offizielle GA-Version ist 13.4.1 und ersetzt die zuvor veröffentlichte Developer Preview 13.4.0. Die dritte Ziffer ist eine Build-Nummer und kennzeichnet kein Update-Release. Der NVIDIA-Treiber ist seit CUDA 13.1 unter Windows und seit CUDA 13.4 unter Linux nicht mehr im Toolkit gebündelt, sondern muss separat heruntergeladen werden.

Windows on Arm: Erstmals offizielles CUDA-Toolkit

Die Windows-on-Arm-Unterstützung ist eine zentrale Neuerung. CUDA-Anwendungen liefen auf Arm-Prozessoren bislang nur unter Linux, etwa auf Jetson-Systemen oder Arm64-SBSA-Plattformen. Mit CUDA 13.4 gibt es erstmals ein offizielles CUDA-Toolkit für Windows on Arm. Entwickler haben zwei Build-Pfade: Sie können nativ auf einem Windows-on-Arm-System kompilieren oder auf einem herkömmlichen x86-64-Windows-Rechner per Cross-Compilation Arm64-Binaries erzeugen. Der native Build-Pfad bietet den Vorteil, dass Entwickler ihre Anwendungen direkt auf der Zielplattform testen und plattformspezifische Probleme wie Speicherarchitektur oder Treiberverhalten sofort erkennen können. Die Cross-Compilation-Strategie ist dagegen für Teams relevant, die ihre bestehende x86-64-Entwicklungsumgebung nicht sofort ersetzen wollen: Sie können weiterhin auf ihren gewohnten Workstations mit AMD- oder Intel-Prozessoren arbeiten und trotzdem Arm64-Builds erzeugen, ohne zusätzliche Hardware anzuschaffen. Das Paket enthält den CUDA-Compiler NVCC, Laufzeitkomponenten, Importbibliotheken, mathematische Bibliotheken sowie die Profiling-Werkzeuge Nsight Compute und Nsight Systems. Für Windows on Arm stellt NVIDIA einen separaten Entwicklertreiber aus der R616-Serie bereit, etwa Version 616.00. Für die erste Portierung ist keine RTX-Spark-Hardware erforderlich: Laut NVIDIA genügt eine bestehende Windows-on-Arm-Plattform, um Abhängigkeiten zu prüfen, inkompatible Bibliotheken zu identifizieren und eine native Arm64-Version zu erstellen. NVIDIA empfiehlt, sowohl reine Arm64-Builds als auch Arm64EC zu testen, wobei Arm64EC die Kombination nativer Arm-Komponenten mit vorhandenen x64-Bibliotheken in derselben Anwendung ermöglicht. Als Beispiel-Hardware nennt Microsoft die Surface RTX Spark Dev Box, die eine NVIDIA-Blackwell-RTX-GPU mit einer Grace-CPU und bis zu 128 GB unified Memory kombiniert. Sie ist als lokales KI-Entwicklungssystem positioniert und wird mit Windows 11 Pro, WSL-2-GPU-Zugriff, CUDA-Unterstützung, VS Code, GitHub Copilot, Git, Python, Node.js und PowerShell 7 ausgeliefert. Die Dev Box ist in Konfigurationen mit bis zu 6.144 CUDA-Kernen, einer 20-Kern-Grace-CPU und 1 Petaflop FP4-KI-Leistung erhältlich. Microsoft gibt an, dass das System Modelle mit mehr als 120 Milliarden Parametern ausführen kann.

Rubin-Preview und MPS V3: Neue Architektur und GPU-Steuerung

Die frühe Entwickler-Unterstützung für die Rubin-Architektur ist als Preview gekennzeichnet. Rubin trägt die Compute Capability 107. NVIDIA bezeichnet Rubin als Next-Generation-GPU-Architektur für das Zeitalter der agentischen KI – diese Einordnung ist eine Herstellerangabe von NVIDIA. Die Preview ermöglicht es Entwicklern, Anwendungen zu portieren, bevor die CUDA-Unterstützung für Rubin in einem künftigen Release allgemein verfügbar wird. MPS V3 modernisiert die Steuerungsschicht für den CUDA Multi-Process Server, der gemeinsam genutzte GPU-Ressourcen verwaltet. Die neue Version bietet eine scriptable CLI, benannte Server-Instanzen und Namespaces zur Organisation gleichzeitiger Workloads. Hinzu kommen TOML-Konfigurationsunterstützung, Steuerung von Streaming-Multiprocessor-Partitionen (SM-Partitionen) und cgroup-integrierte GPU-Speicherlimits. Diese Funktionen verbessern die Orchestrierung von GPU-Workloads, weil sie eine feingranulare Kontrolle über die Ressourcenzuweisung ermöglichen: Ein Orchestrierungssystem kann beispielsweise über die scriptable CLI automatisiert mehrere MPS-Instanzen mit unterschiedlichen SM-Partitionen starten, um einem Team eine feste Anzahl an Streaming-Multiprocessoren zuzuweisen, während ein anderes Team parallel eine andere Partition nutzt. Die cgroup-integrierten Speicherlimits verhindern, dass ein Prozess den gesamten GPU-Speicher belegt und andere Workloads verdrängt. Auch das Profiling-Werkzeug CUPTI wurde für Rubin erweitert: Es unterstützt die neue Architektur, bietet Fixed-Clock-Rate-APIs zum Sperren von GPU-Taktraten während der Profilerstellung, einen Cache-State-Reset für den Range Profiler sowie neue Felder sourceGraphId und sourceGraphNodeId. Der praktische Nutzen dieser CUPTI-Erweiterungen liegt in der Genauigkeit und Reproduzierbarkeit von Performance-Analysen: Die Fixed-Clock-Rate-APIs eliminieren Taktvariabilität, sodass Messungen nicht durch dynamisches Hoch- oder Heruntertakten der GPU verfälscht werden. Der Cache-State-Reset stellt sicher, dass jeder Profiling-Durchlauf mit einem leeren L2-Cache beginnt, was die Vergleichbarkeit verschiedener Läufe erhöht. Die neuen Felder sourceGraphId und sourceGraphNodeId helfen Entwicklern, Kernel-Aktivitäten eindeutig dem ursprünglichen CUDA-Graphen zuzuordnen, aus dem sie instanziiert wurden – das ist besonders bei komplexen Graphen mit vielen Knoten nützlich. Der Aktivitätsdatensatz CUpti_ActivityKernel12 wird durch CUpti_ActivityKernel13 ersetzt. Während aktiver CUPTI-Nutzung wird die Live-Migration virtueller GPUs blockiert, um die Genauigkeit von Tracing und Profiling zu gewährleisten. Zudem erlaubt CUPTI jetzt eine Filterung benutzerdefinierter Aktivitätsdatensätze pro Callback-ID.

Widersprüche: GA oder Preview, RTX Spark nötig oder nicht?

Bei der Einordnung von CUDA 13.4 gibt es zwei Widersprüche zwischen offiziellen Angaben und unabhängigen Berichten. Der erste betrifft den Status des Toolkits. Die offiziellen NVIDIA Release Notes bezeichnen CUDA Toolkit 13.4 als GA-Release, versioniert 13.4.1, das die 13.4.0 Developer Preview ersetzt. Unabhängige Berichte bezeichnen CUDA 13.4 dagegen als Developer Preview. Die Diskrepanz lässt sich vermutlich dadurch erklären, dass sich die unabhängigen Quellen auf die frühere 13.4.0 Developer Preview beziehen oder den Begriff "Preview" für die neuen Windows-on-Arm- und Rubin-Features verwenden, während die offizielle Dokumentation die GA-Version 13.4.1 meint. Es ist auch möglich, dass einzelne Funktionen weiterhin Preview-Charakter haben, obwohl das Gesamtpaket als GA veröffentlicht wurde. Der zweite Widerspruch betrifft die Notwendigkeit von RTX-Spark-Hardware für die Windows-on-Arm-CUDA-Entwicklung. Ein Bericht behauptet, RTX-Spark-Laptops und -Mini-PCs seien die einzigen Windows-on-Arm-Maschinen, auf denen der CUDA-Software-Stack ohne Workarounds läuft. NVIDIA selbst gibt dagegen an, dass Entwickler für die erste Portierung kein RTX-Spark-System benötigen; eine bestehende Windows-on-Arm-Plattform genüge, um Abhängigkeiten zu prüfen und eine native Arm64-Version zu erstellen. Diese Aussagen schließen sich nicht direkt aus, betonen aber unterschiedliche Phasen: Der Bericht spricht vom vollständigen Ausführen des Produktions-Software-Stacks wie PyTorch oder TensorRT, während NVIDIA die frühe Entwicklungs- und Portierungsphase beschreibt. Für die initiale Portierung reicht eine beliebige Windows-on-Arm-Maschine, für den produktiven Betrieb des gesamten CUDA-Stacks ohne Workarounds ist dagegen RTX-Spark-Hardware erforderlich.

Auswirkungen auf Portierung, Microsofts Dev Box und CUDA-Verbreitung

Die Neuerungen haben konkrete Auswirkungen auf Entwickler und das Windows-on-Arm-Ökosystem. Entwickler können CUDA-Anwendungen nun auf Windows on Arm portieren, was die Plattform für KI- und wissenschaftliche Anwendungen erweitert. Microsoft positioniert die Surface RTX Spark Dev Box als lokales KI-Entwicklungssystem für Modelloptimierung, Inferenz, Feintuning und dauerhafte Agenten-Workloads. Das System soll Modelle mit mehr als 120 Milliarden Parametern ausführen können. NVIDIA erweitert mit der Windows-on-Arm-Unterstützung die Verfügbarkeit von CUDA auf eine neue Plattform. Unabhängige Beobachter weisen darauf hin, dass NVIDIA damit seine proprietäre CUDA-Plattform auf eine Gerätekategorie ausdehnt, in der das Unternehmen bislang nicht vertreten war. AMD ROCm und Intel oneAPI bieten Alternativen, aber die Mehrheit der KI-Frameworks setzt standardmäßig auf CUDA. Für Entwickler bedeutet das: Wer CUDA-Anwendungen für Windows on Arm vorbereiten will, kann bereits jetzt mit der Portierung beginnen, ohne auf RTX-Spark-Hardware warten zu müssen.