CUDA unter WSL2 auf RTX-PRO-Workstations: Treiber, Docker, vLLM und ihre Grenzen

Was unter WSL2 auf einer RTX-PRO-Workstation läuft

CUDA unter WSL2 funktioniert auf Workstation-Karten der NVIDIA RTX PRO Blackwell-Familie wie der RTX PRO 6000 Blackwell Workstation Edition, der RTX PRO 6000 Max-Q und der RTX PRO 5000: Der NVIDIA-Treiber wird unter Windows installiert, das CUDA-Toolkit in der Linux-Distribution, und danach laufen PyTorch, GPU-Container und vLLM auf der Karte. Die wichtigste Grenze, die NVIDIAs Leitfaden dokumentiert, betrifft den Speicher: Die virtuelle Maschine von WSL erhält standardmäßig die Hälfte des Windows-Arbeitsspeichers, Pinned Memory ist eingeschränkt und Unified Memory unvollständig. WSL2 passt für einen Entwickler mit einem Modell je Karte; ein gemeinsamer Dienst des Teams, MIG oder ein Modell über mehrere Karten gehören auf eine Linux-Workstation oder einen gemeinsamen Server.

Dieser Leitfaden richtet sich an IT-Abteilungen, die Windows-Workstations betreiben und ihren Entwicklern Linux-KI-Werkzeuge ohne Dual Boot bereitstellen wollen. Jede Aussage stammt aus NVIDIAs CUDA on WSL User Guide (CUDA 13.4, zuletzt aktualisiert am 12. Oktober 2026), der WSL-Dokumentation sowie den Dokumentationen von Docker und vLLM, alle gelesen am 25. Oktober 2026. Versionen ändern sich, lesen Sie die Quellen vor einem Rollout also erneut. Ob auf einen GPU-Server Windows Server oder Linux gehört, ist eine eigene Frage; sie beantwortet unser Vergleich Windows Server oder Linux für den GPU-Server.

Welche Karten und welches Treibermodell

WSL2 erreicht die GPU über den Windows-Treiber, deshalb entscheidet das Windows-Treibermodell der Karte, ob es funktioniert. NVIDIAs Leitfaden sagt, die GPU-Beschleunigung in WSL 2 sei auf Pascal und neueren Architekturen für GeForce- und Quadro-Produkte „in WDDM mode“ verfügbar und auf Quadro-GPUs im TCC-Modus sowie auf Tesla-GPUs „not available … yet“. Alle RTX-PRO-Blackwell-Karten sind mehrere Generationen jünger als Pascal. Eine Workstation-Karte, die die Monitore ansteuert, läuft in WDDM, dem Treibermodell für Grafik und Anzeige, und genau für diesen Fall ist WSL2 gebaut.

Die Server Edition ist anders. NVIDIAs Windows-Treiberhinweise für Rechenzentrums-GPUs vom Oktober 2026 nennen TCC als Standardmodus der RTX PRO 6000 Blackwell Server Edition, und diese Karte gehört ohnehin in einen Rack-Server mit Linux. Eine reine Rechenkarte ohne Monitor in einer Workstation mit mehreren GPUs kann in einem anderen Modus laufen; prüfen Sie das mit nvidia-smi -q. Unser Leitfaden zu WDDM, TCC und MCDM erklärt die Modi und wie MCDM reine Rechenkarten unter Windows 11 für WSL2 sichtbar macht.

NVIDIA-Datenblätter und Produktseiten wie in unseren Workstation-Artikeln (Speicher, Leistungsaufnahme der Karte). Nutzbarer Speicher nach unserer Nutzer-pro-Karte-Regel: 0,9 × der vom Treiber gemeldete Speicher, minus 3 GiB je Karte; der Treiber meldet 95,6 GiB bei einer 96-GB-Karte, kleinere Karten nach Kapazität skaliert.

Die Spalte „nutzbar“ gilt in WSL2 wie unter Linux: Gewichte und KV-Cache der laufenden Unterhaltungen müssen hineinpassen. Unser Leitfaden, wie viele Nutzer eine RTX PRO 6000 bedient, leitet die Regel her.

Eine Workstation in der dokumentierten Reihenfolge einrichten

NVIDIAs Leitfaden gibt die Reihenfolge vor. Jeder Schritt stammt daraus, sofern keine andere Quelle genannt ist.

1. Windows-Treiber. Installieren Sie NVIDIAs RTX/Quadro-Anzeigetreiber für Windows. Der Leitfaden ist eindeutig: „This is the only driver you need to install. Do not install any Linux display driver in WSL.“ Ab Treiber R495 steht CUDA in WSL 2 zur Verfügung.
2. WSL und Kernel. Führen Sie wsl.exe --install und danach wsl.exe --update für den aktuellen WSL-Kernel aus. NVIDIA nennt Kernel 4.19.121 als Minimum und empfiehlt 5.10.16.3 oder neuer. Die Standarddistribution ist Ubuntu.
3. CUDA-Toolkit in WSL. Nehmen Sie das WSL-Ubuntu-Paket von NVIDIAs Download-Seite, das laut Leitfaden den NVIDIA-Linux-GPU-Treiber nicht enthält. Wer aus dem Ubuntu-Repository installiert, nimmt nur das Toolkit-Metapaket; die Metapakete cuda, cuda-12-x und cuda-drivers soll man unter WSL 2 nicht wählen, weil sie einen Linux-Treiber mitbringen, der den von WSL bereitgestellten überschreibt. Der Leitfaden nennt noch Paketnamen mit 12-x, obwohl er CUDA 13.4 beschreibt; passen Sie den Namen an die installierte Version an.
4. Karte prüfen. nvidia-smi liegt unter /usr/lib/wsl/lib/. Laut Leitfaden unterstützt NVML, die Bibliothek dahinter, „not all the queries yet“.
5. Framework. PyTorch oder vLLM installieren Sie in der Distribution wie unter Linux. RTX-PRO-Blackwell-Karten haben Compute Capability 12.0, was CUDA 12.8 oder neuer voraussetzt, wie unser Artikel zur Software-Unterstützung von Blackwell RTX darlegt.

Die WSL-Dokumentation ergänzt eine Regel, die bei Modellen mit Dutzenden GB zählt: Für die beste Geschwindigkeit sollen Dateien im WSL-Dateisystem liegen, wenn man in einer Linux-Kommandozeile arbeitet. Legen Sie den Hugging-Face-Cache und die Modellverzeichnisse also in die Distribution, nicht unter /mnt/c.

GPU-Container: Docker Desktop oder Docker Engine in WSL

Es gibt zwei dokumentierte Wege, Containern die Karte zugänglich zu machen.

Docker Desktop. Docker schreibt auf seiner GPU-Seite (aktualisiert am 30. September 2026), Docker Desktop für Windows unterstütze „NVIDIA GPU Paravirtualization (GPU-PV) on NVIDIA GPUs“, mit dem WSL-2-Backend, einem aktuellen Windows 10 oder Windows 11, aktuellen NVIDIA-Treibern und dem neuesten WSL-Kernel. Der Test lautet docker run --rm -it --gpus=all nvcr.io/nvidia/k8s/cuda-sample:nbody nbody -gpu -benchmark, und Docker weist darauf hin, dass die CUDA-Beispiele nicht für Leistungsmessungen gedacht sind. Seit Docker Desktop 4.54 betreibt Docker Model Runner laut Dockers Ankündigung vom Dezember 2025 auch vLLM unter Windows über WSL2, für GPUs ab Compute Capability 8.0.

Docker Engine in der Distribution. NVIDIAs WSL-Leitfaden unterstützt das NVIDIA Container Toolkit in WSL und nennt dessen Mindestversionen. Die Installationsanleitung des Toolkits selbst (Version 1.20.1, aktualisiert am 18. September 2026) erwähnt WSL nicht, und ihre erste Voraussetzung lautet, den NVIDIA-GPU-Treiber für die Linux-Distribution zu installieren: Diesen Schritt lassen Sie in WSL aus, weil dort der Windows-Treiber die Karte bedient, und folgen dem Rest, einschließlich sudo nvidia-ctk runtime configure --runtime=docker. Scheitern Container mit nvidia-container-cli : initialization error, rät NVIDIAs Leitfaden, Windows-Build, WSL 2, Treiber und Toolkit zu prüfen und den Docker-Daemon neu zu starten.

Docker auf GPU-Servern ohne Kubernetes behandelt unser Leitfaden zur GPU-Zuweisung in Docker; auf der Workstation gilt dieselbe --gpus-Syntax mit einer Grenze aus NVIDIAs Leitfaden: Mit Docker 19.03 funktioniert nur --gpus all, keine Auswahl nach Index.

vLLM unter WSL2

Die Installationsanleitung von vLLM sagt „vLLM does not support Windows natively“ und nennt WSL mit einer Linux-Distribution als Weg unter Windows. Dort lässt sich vLLM wie unter Linux installieren und betreiben; drei Punkte sollten Sie dabei kennen.

Pinned Memory ist standardmäßig aus. Der CUDA-Plattformcode von vLLM, wie er in der aktuellen API-Dokumentation veröffentlicht ist, erkennt WSL. Auf WSL2-Kerneln ab 4.19.121 ist Pinned Memory „supported but disabled by default“, und die Variable VLLM_WSL2_ENABLE_PIN_MEMORY=1 schaltet es ein; auf älteren Kerneln schaltet vLLM es ab und protokolliert, dass dies die Leistung verlangsamen kann. Pinned (page-locked) Memory beschleunigt Kopien zwischen Arbeitsspeicher und Karte, setzen Sie die Variable also auf einem aktuellen Kernel.

CPU-Offload ist riskant. Für --cpu-offload-gb zusammen mit CUDA Graphs warnt derselbe Code, Windows (WDDM) setze standardmäßig eine harte, systemweite Grenze von „roughly 50%“ des physischen Arbeitsspeichers für Pinned Memory über alle Prozesse, und zu viel page-locked Speicher könne den Host unbedienbar machen. Wählen Sie auf der Workstation lieber ein Modell, das auf die Karte passt, statt auszulagern.

Nicht jede Funktion ist dort erprobt. Im Juni 2026 meldete ein Nutzer im vLLM-Forum, dass der Sleep Mode unter WSL2 auf Windows 10 mit vLLM 0.23.0 als nicht unterstützt abgelehnt wurde; die Maintainer antworteten im Thread nicht. Testen Sie Funktionen jenseits des reinen Servings auf Ihrem Build, bevor Sie sich darauf verlassen.

Was ein Entwickler auf einer Karte betreiben kann, nach unserer Nutzer-pro-Karte-Regel:

Gewichte als Summe der Safetensors-Dateien auf Hugging Face (gpt-oss-20b, gpt-oss-120b; Repository Qwen3.8-27B-FP8 mit 30,9 GB), gelesen am 25. Oktober 2026. Cache je Unterhaltung mit 32K Token und 16-Bit-KV-Cache aus der jeweiligen config.json: gpt-oss-20b 0,75 GiB, gpt-oss-120b 1,125 GiB, Qwen3.8-27B 2,0 GiB auf seinen 16 Full-Attention-Schichten plus höchstens 0,14 GiB Zustand der Linear-Attention-Schichten. Unsere Schätzung, keine Messung.

Die Tabelle rechnet alle Modelle mit einem 16-Bit-KV-Cache. Mit einem FP8-KV-Cache, wie ihn unsere übrigen Berechnungen für Qwen3.8-27B verwenden, belegt eine Unterhaltung mit 32K Token bei Qwen3.8-27B 1,14 GiB, und die Zahl steigt nach unserer Schätzung auf 9 bei der RTX PRO 5000 48 GB, 28 bei der 72-GB-Karte und 47 bei einer 96-GB-Karte.

Alle drei Modelle stehen laut ihren LICENSE-Dateien unter Apache 2.0. Unser Kaufberater für KI-Workstations zeigt, welche Karten und Tower wir für diese Arbeit bauen.

Wir liefern RTX-PRO-Workstation-Karten und bauen Workstations auf Bestellung; schicken Sie uns die Modelle Ihrer Entwickler, und unser Team antwortet mit einer Karten- und Speicheraufteilung, die unter WSL2 dazu passt.

Speicher: die virtuelle Maschine von WSL, Pinned Memory und Caches

WSL2 ist eine schlanke virtuelle Maschine, und die WSL-Dokumentation (aktualisiert am 16. Oktober 2026) setzt ihren Speicher standardmäßig auf „50% of total memory on Windows“, die Prozessoren auf die Zahl der logischen Prozessoren unter Windows und den Swap auf 25 Prozent der Speichergröße. Alles in der Distribution teilt sich diese Grenze: Python-Prozesse, Container, Modell-Downloads und der Page Cache der Modelldateien. Auf einer Workstation mit 256 GB Arbeitsspeicher erhält die Distribution 128 GB, solange Sie den Wert nicht erhöhen.

Die Einstellung steht in %UserProfile%\.wslconfig unter [wsl2], zum Beispiel memory=192GB. Die Datei existiert standardmäßig nicht. WSL übernimmt Änderungen erst, wenn die virtuelle Maschine angehalten ist, laut Dokumentation etwa 8 Sekunden nach dem Schließen der letzten Shell; wsl --shutdown hält alle laufenden Distributionen auf einmal an. Die experimentelle Einstellung autoMemoryReclaim, standardmäßig dropCache, gibt Cache-Speicher an Windows zurück.

NVIDIAs Leitfaden ergänzt die Grenzen auf der GPU-Seite:

• „Full Managed Memory Support is not available on Windows native“, und WSL 2 wird ihn „for the foreseeable future“ nicht unterstützen. Software, die GPU-Speicher überbucht, verhält sich anders: RAPIDS cudf.pandas etwa ist unter WSL2 auf den physischen Speicher der Karte begrenzt, wie unser Leitfaden zur RAPIDS-Workstation erklärt.
• „Concurrent CPU/GPU access is not supported“ für Managed Memory.
• Pinned Memory steht Anwendungen nur begrenzt zur Verfügung, und manche Deep-Learning-Trainings überschreiten die Grenze und scheitern.

Für Inferenz mit vLLM, das Gewichte und Cache im GPU-Speicher hält, spielen diese Grenzen selten eine Rolle. Bei Fine-Tuning und Data Science dagegen schon: Scheitert ein Trainingslauf unter WSL2, wiederholen Sie ihn zuerst unter Linux, bevor Sie an anderer Stelle etwas ändern.

Mehrere GPUs in einer WSL2-Workstation

NVIDIAs Leitfaden äußert sich zu Multi-GPU-Arbeit in WSL2 nur mit zwei Einträgen: NCCL 2.12 oder neuer steht in seiner Support-Tabelle, und RAPIDS ab 22.04 hat „Experimental Support for single GPU“. Der einzige veröffentlichte Aufbau mit vier Karten, den wir fanden, ein Bericht im vLLM-Forum vom April 2026 mit vier RTX PRO 6000 (Edition nicht angegeben), lief unter WSL2 mit abgeschalteten Peer-to-Peer-Transfers über NCCL_P2P_DISABLE=1. Er beschreibt, welche GPU-Kernel nicht starteten, und taugt nicht als Referenz für die Geschwindigkeit.

Daraus folgt die praktische Regel: In WSL2 läuft ein Modell je Karte. Zwei RTX PRO 6000 Max-Q in einer Workstation können zwei Modelle bedienen, oder das Modell eines Entwicklers und die Experimente eines anderen, jedes mit CUDA_VISIBLE_DEVICES an seine Karte gebunden. Ein Modell, das zwei oder vier Karten mit Tensor-Parallelität braucht, gehört auf eine Linux-Maschine, wo die Multi-GPU-Pfade von vLLM dokumentiert und getestet sind.

Auch MIG liegt außerhalb von WSL2. NVIDIAs MIG-Voraussetzungen für RTX PRO 6000 und RTX PRO 5000 nennen Linux und einen Treiber ab 575.51.03, während WSL einen Linux-GPU-Treiber in der Distribution untersagt; die Aufteilung einer Karte in isolierte Instanzen, wie sie unser Leitfaden zu MIG-Profilen zeigt, erfolgt auf einem Linux-Host.

WSL2 auf viele Workstations ausrollen

Die WSL-Dokumentation für Unternehmen nennt die Mindestversionen: Windows 10 22H2 oder Windows 11 22H2 und WSL 2.0.9 oder neuer, geprüft mit wsl --version. Ab Windows 11 22H2 mit WSL 2.0.9 gelten die Regeln der Windows-Firewall automatisch auch für WSL. Den Zugang zu WSL und seine wichtigsten Sicherheitseinstellungen steuern Sie über Intune oder Windows-Richtlinien.

Für ein Standard-Image bauen Sie eine Distribution mit CUDA-Toolkit, Python und Ihren Framework-Versionen, exportieren sie mit wsl --export und verteilen sie mit wsl --import, wie die Dokumentation es beschreibt. Drei Dinge führt sie als nicht unterstützt, und Ihr Prozess muss sie abdecken: Aktualisierung und Patching der Linux-Distributionen mit Windows-Werkzeugen, die Aktualisierung der Distributionsinhalte durch Windows Update und die Kontrolle des Root-Zugriffs in den Distributionen. Die Linux-Seite jeder Workstation braucht also eine eigene Patch-Routine.

Halten Sie den Treiberzweig in der ganzen Flotte einheitlich. Der Windows-Treiber bedient CUDA in jeder Distribution, ein Treiber-Update ändert also, worauf alle laufen; unser Artikel zu NVIDIA-Treiberzweigen und CUDA-Versionen erklärt, wie man einen Zweig festlegt. Für WSL2 selbst rollen Sie wsl --update zusammen mit dem Treiber aus, weil NVIDIAs Leitfaden Leistungs- und Funktionskorrekturen an die Version des WSL-Kernels bindet.

Wann eine Linux-Workstation oder ein gemeinsamer Server besser ist

NVIDIA CUDA on WSL User Guide (12. Oktober 2026), NVIDIAs MIG-Voraussetzungen, CUDA-Plattformcode von vLLM; gelesen am 25. Oktober 2026.

Die letzte Zeile entscheidet am meisten. Ein Modell auf der WSL2-Workstation eines Entwicklers fällt aus, sobald diese Person den Rechner herunterfährt oder Windows ein Update installiert. Sobald Kollegen sich darauf verlassen, ziehen Sie es auf einen Server um, wie unser Artikel von Ollama auf dem PC zum KI-Server des Unternehmens beschreibt; die Entwickler behalten WSL2 für eigene Experimente und rufen die API des Servers auf. Die Einstiegskonfiguration auf unserer Seite KI-Server, mit zwei RTX PRO 6000 Server Edition, zwei AMD-EPYC-Prozessoren und 384 GB DDR5-ECC-Speicher, läuft unter Linux und nimmt nach unserer Schätzung etwa 1,8 kW an der Steckdose auf.

Was wir liefern

Wir liefern die RTX PRO 6000 Workstation Edition und Max-Q, die RTX PRO 5000 mit 48 oder 72 GB, die RTX PRO 4500 und die RTX PRO 4000 als Karten mit Herstellergarantie und bauen Workstations und Server auf Bestellung, vor der Lieferung montiert und getestet, mit Betriebssystem und Treibern auf Wunsch vorinstalliert. Mengen und Lieferzeit werden mit dem Angebot schriftlich bestätigt, mit einem EU-Vertrag und einer Rechnung. Wenn Ihre Entwickler eine Workstation für WSL2 oder einen Linux-Server neben ihren Windows-Rechnern brauchen, beschreiben Sie die Modelle und die Zahl der Entwickler, und unser Team schlägt die Karten für beides vor.

FAQ