Ollama unter WSL2 oder nativ unter Windows: Welche Variante wählen? ?

#Die Herausforderung: zwei Ollama-Instanzen auf derselben Maschine

Seit Ollama ein natives Windows-Installationsprogramm anbietet, taucht die Frage „Ollama unter WSL2 oder nativ?“ immer wieder auf. Beide Ansätze führen genau denselben Daemon aus, lauschen standardmäßig auf http://localhost:11434 und stellen dieselben GGUF-Modelle bereit. Der Unterschied liegt woanders: darin, wie die GPU zugänglich gemacht wird, wo Ihre Dateien gespeichert sind und welches Tool-Ökosystem Sie ergänzend nutzen.

Zusammenfassend bietet der native Betrieb unter Windows Vorteile bei der einfachen Installation und der Desktop-Integration, während WSL2 besser zu einem Linux-/Entwicklungsworkflow passt und mit Werkzeugen kompatibel ist, die es nur unter Unix gibt. Keine der beiden Varianten ist grundsätzlich „besser“ — die richtige Wahl hängt davon ab, wofür Sie Ihre LLMs nutzen.

Ollama nativ unter Windows

Eine .exe-Datei, ein Symbol in der Systemleiste, der Daemon startet mit Windows. Keine Linux-Schicht zu verwalten.

Ollama unter WSL2

Eine Linux-Distribution (meist Ubuntu), in der Sie Ollama wie auf einem Server installieren. Ideal, wenn Ihr Stack bereits auf Linux basiert.

Gemeinsamkeit

Dieselbe API auf Port 11434, dieselben Modelle, dieselben Befehle. Ein Windows-Client kann übrigens mit einem WSL2-Server kommunizieren und umgekehrt.

#Voraussetzungen

Um die beiden ehrlich miteinander zu vergleichen, muss die GPU in jeder Umgebung korrekt unterstützt werden. Genau hier entstehen die meisten Enttäuschungen.

Windows 11 (oder eine aktuelle Version von Windows 10)

WSL2 mit GPU-Acceleration (WSLg) erfordert Windows 11 oder eine aktuelle Build Windows 10.

Aktueller GPU-Treiber unter Windows

Unter WSL2 macht der Windows-Treiber die GPU über /dev/dxg für Linux zugänglich. Installieren Sie den neuesten NVIDIA-Treiber (Game Ready oder Studio) oder AMD-Adrenalin-Treiber, KEINEN Linux-Treiber in der Distribution.

WSL2 aktiviert

Der Befehl „wsl --install“, ausgeführt in einer PowerShell mit Administratorrechten, installiert WSL2 und standardmäßig eine Ubuntu-Distribution.

Ausreichend VRAM

Die Richtwerte für Q4_K_M bleiben in beiden Umgebungen gleich: 7B ≈ 5 GB, 14B ≈ 9 GB, 32B ≈ 19 GB, 70B ≈ 40 GB. WSL2 ändert diesen Speicherbedarf nicht.

#Ollama sauber in WSL2 installieren

Die Installation in WSL2 ist identisch mit der auf einem Linux-Server: Das offizielle Skript erkennt die von WSLg bereitgestellte GPU und konfiguriert die Beschleunigung automatisch.

1. 01
   WSL2 aktivieren

   In einer als Administrator gestarteten PowerShell: „wsl --install“. Starten Sie neu, falls Sie dazu aufgefordert werden. Prüfen Sie anschließend mit „wsl -l -v“, ob Ihre Distribution tatsächlich unter VERSION 2 läuft.
2. 02
   Die Distribution aktualisieren

   Öffnen Sie Ubuntu und führen Sie dann „sudo apt update && sudo apt upgrade -y“ aus. Eine aktuelle Distribution vermeidet Überraschungen bei den GPU-Runtimes.
3. 03
   Ollama installieren

   Führen Sie das offizielle Skript aus: „curl -fsSL https://ollama.com/install.sh | sh“. Es erkennt NVIDIA (über CUDA, das durch WSLg bereitgestellt wird) oder AMD (ROCm) und meldet dies in den Logs.
4. 04
   GPU überprüfen

   Laden Sie ein kleines Modell und prüfen Sie anschließend „ollama ps“: Die Spalte PROCESSOR muss GPU anzeigen, nicht CPU. Wenn dort CPU steht, ist die Beschleunigung nicht aktiv.
5. 05
   Ein Modell testen

   „ollama run qwen3.5:9b“ und stellen Sie dann eine Frage. Dieses Modell aus dem Jahr 2026 (6,6 GB in Q4, 256k Kontext, Bildverarbeitung) ist die Standardwahl auf einer Karte mit 8 GB. Fügen Sie --verbose hinzu, um die tatsächlichen Tokens pro Sekunde anzuzeigen.

# Dans le terminal Ubuntu de WSL2
sudo apt update && sudo apt upgrade -y

# Installation officielle d'Ollama
curl -fsSL https://ollama.com/install.sh | sh

# Vérifier la prise en charge du GPU
ollama pull qwen3.5:9b
ollama run qwen3.5:9b --verbose

# Le processeur utilisé (GPU attendu)
ollama ps

#GPU-Leistung: nativ vs. WSL2, mit Zahlen belegt

Das ist DIE Frage, die den Anlass für diesen Leitfaden gibt. Die gute Nachricht: Bei der LLM-Inferenz auf NVIDIA-GPUs ist der Unterschied zwischen nativ ausgeführtem Ollama und Ollama unter WSL2 gering. Sobald das Modell in den VRAM geladen ist, finden die Berechnungen in beiden Fällen auf der GPU statt, und WSL2 verursacht bei der eigentlichen Token-Generierung nahezu keinen zusätzlichen Aufwand.

In der Praxis sind die Generierungsraten auf derselben Karte (zum Beispiel einer RTX 4070 mit 12 GB und einem 8B-Modell in Q4_K_M) sehr ähnlich — der Unterschied liegt typischerweise bei wenigen Prozent und geht oft in der Streuung der Messwerte unter. Etwas Zeit kann WSL2 beim anfänglichen Laden des Modells vom Datenträger kosten: Das Dateisystem von WSL2 ist auf seinem virtuellen ext4-Datenträger schnell, der Zugriff auf Dateien auf der Windows-Seite (über /mnt/c) ist dagegen deutlich langsamer.

Tokengenerierung (GPU)

Auf NVIDIA nahezu identisch bei nativer Ausführung und unter WSL2. Die GPU erledigt in beiden Fällen die Arbeit; die WSL2-Schicht ist für die Berechnung transparent.

Laden des Modells

Schnell, wenn die Modelle im nativen Linux-Dateisystem von WSL2 liegen. Langsam, wenn Ollama seine Blobs aus /mnt/c/... liest (Zugriff über die Brücke zu Windows).

Latenz des ersten Tokens

Vergleichbar, sofern das Modell bereits im VRAM-Cache liegt. Das erste Laden bei einem Kaltstart ist die kritische Phase.

CPU-Overhead

Für die Inferenz vernachlässigbar. WSL2 ist eine echte, schlanke virtuelle Maschine, keine Emulation; bei GPU-Lasten macht sich der Virtualisierungsaufwand nicht bemerkbar.

Fazit zur reinen Leistung: Wenn Sie eine NVIDIA-Grafikkarte haben, ist die Generierungsgeschwindigkeit NICHT ausschlaggebend für die Wahl zwischen nativem Betrieb und WSL2. Entscheiden Sie nach Ihrem Workflow. Die Leistung wird nur in zwei Fällen wieder zum Argument: bei der Speicherung der Modelle (unter WSL2 auf der Linux-Seite belassen) und bei der AMD-Unterstützung, auf die wir jetzt eingehen.

#Der Fall AMD: ROCm unter WSL2

Bei AMD-GPUs ist die Lage anders und differenzierter. Ollama nutzt ROCm zur Beschleunigung auf kompatiblen Radeon-Karten. Unter Windows war ROCm jedoch lange ein Minenfeld, und WSL2 hat die Lage verändert – je nach Grafikkarte nicht immer zum Vorteil.

AMD nativ unter Windows

Ollama enthält eine ROCm-Bibliothek für Windows. Auf den offiziell unterstützten Grafikkarten (neuere RX 7000, einige RX 6000) funktioniert die Beschleunigung ohne WSL2. Dies ist oft der einfachste Weg für einen AMD-Desktop.

AMD unter WSL2

ROCm ist für WSL2 verfügbar, aber es werden weniger GPUs unterstützt und die Einrichtung ist anspruchsvoller. Das kann nötig sein, wenn Sie Linux-Werkzeuge nutzen möchten, bringt für sich genommen aber keinen Geschwindigkeitsvorteil.

Nicht unterstützte Karten

Viele ältere Radeon-Karten oder APUs stehen nicht auf der offiziellen ROCm-Liste. Bei diesen kann Ollama in beiden Umgebungen auf die CPU zurückfallen.

HSA-Workaround

Mit der Variable HSA_OVERRIDE_GFX_VERSION lässt sich manchmal die Erkennung einer GPU erzwingen, die einem unterstützten Modell ähnelt. Nur für erfahrene Nutzer, ohne Garantie.

# La carte AMD est-elle vue par ROCm dans WSL2 ?
rocminfo | grep -i 'Name\|gfx'

# Forcer une version gfx proche (avancé, sans garantie)
# Exemple pour cibler gfx1030 sur une carte non listée :
HSA_OVERRIDE_GFX_VERSION=10.3.0 ollama serve

#Dateizugriff und VS Code-Integration

Neben der Leistung ist oft der Dateizugriff ausschlaggebend. Beide Dateisysteme (Windows NTFS und Linux ext4 unter WSL2) sind jeweils vom anderen System aus zugänglich, allerdings kostet der Zugriff über diese Brücke Leistung, und die Pfadkonventionen unterscheiden sich.

Von WSL2 zu Windows

Ihre Windows-Laufwerke sind unter /mnt/c, /mnt/d usw. eingebunden. Das ist praktisch, um einen Dokumentenordner zu lesen, aber bei intensiven Zugriffen langsam (Laden großer Modelle, RAG-Indexierung).

Von Windows zu WSL2

Das Linux-Dateisystem ist im Explorer über den Netzwerkpfad \\wsl$\Ubuntu\ zugänglich. Das ist praktisch, um eine Datei abzulegen; vermeiden Sie jedoch, Windows-Tools dort intensiv arbeiten zu lassen.

Goldene Regel

Belassen Sie die Dateien jeder Arbeitslast im jeweiligen nativen Dateisystem. Linux-Entwicklungsprojekt → in WSL2. Office-Dokumente → auf der Windows-Seite. So vermeiden Sie die langsame Brücke zwischen den Dateisystemen.

In VS Code ist die WSL-Integration hervorragend und spricht für die Entwicklung klar für WSL2. Die offizielle Erweiterung „WSL“ öffnet ein Projekt direkt in der Distribution: Der VS-Code-Server läuft unter Linux, das integrierte Terminal ist eine Linux-Shell, und Ihr Code zum Aufrufen der Ollama-API wird in derselben Umgebung wie der Daemon ausgeführt.

import requests

# Même endpoint quel que soit l'environnement
resp = requests.post(
    "http://localhost:11434/api/generate",
    json={
        "model": "qwen3.5:9b",
        "prompt": "Explique WSL2 en une phrase.",
        "stream": False,
    },
    timeout=120,
)
print(resp.json()["response"])

#Welche Konfiguration empfiehlt sich für Ihren Einsatzzweck?

Hier ist die Zusammenfassung mit konkreten Handlungsempfehlungen. Orientieren Sie Ihre Wahl an Ihrem hauptsächlichen Nutzungsprofil statt an minimalen Unterschieden bei den Tokens pro Sekunde.

Desktop-Nutzung / Nutzung durch Privatnutzer (NVIDIA)

Ollama nativ unter Windows. Installation mit einem Klick, Start bei der Anmeldung, keine Linux-Schicht zu warten. Ideal mit LM Studio oder Open WebUI als Benutzeroberfläche.

Linux-Entwickler / Unix-Stack

Ollama unter WSL2. Ihre Werkzeuge (Bash-Skripte, Docker, Python-venv) stehen Ihnen in derselben Umgebung wie der Daemon zur Verfügung, mit einer hervorragenden VS-Code-Integration.

AMD-GPU für den Verbrauchermarkt

Testen Sie zuerst die native Windows-Version: Sie lässt sich oft am einfachsten mit dem mitgelieferten ROCm betreiben. Wechseln Sie nur zu WSL2, wenn Ihr Workflow dies erfordert und Ihre Grafikkarte unterstützt wird.

Server / Netzwerkfreigabe

WSL2 kommt einer klassischen Bereitstellung auf einem Linux-Server nahe und erleichtert die Reproduzierbarkeit (dieselben Befehle wie im Produktivbetrieb). Denken Sie an OLLAMA_HOST, um den Dienst im Netzwerk zugänglich zu machen.

#Fehlerbehebung

„ollama ps“ zeigt CPU anstatt GPU

Unter WSL2 prüfen Sie, ob „nvidia-smi“ antwortet. Falls nicht, aktualisieren Sie den Treiber auf der Windows-Seite und installieren Sie keinen Linux-Treiber in der Distribution.

Sehr langsames Laden des Modells

Ihre Modelle sind wahrscheinlich unter /mnt/c gespeichert. Verschieben Sie sie in das Linux-Dateisystem (~/.ollama), um die ursprüngliche Geschwindigkeit wiederherzustellen.

„address already in use“ auf 11434

Eine native Ollama-Instanz UND eine Ollama-Instanz unter WSL2 laufen gleichzeitig. Beenden Sie eine davon oder ändern Sie den Port der anderen mit OLLAMA_HOST=127.0.0.1:11435.

AMD-GPU wird ignoriert

Die Karte steht nicht auf der ROCm-Kompatibilitätsliste. Prüfen Sie die Kompatibilität, versuchen Sie gegebenenfalls HSA_OVERRIDE_GFX_VERSION oder weichen Sie auf den nativen Betrieb unter Windows aus.

Der Windows-Client erreicht den WSL2-Daemon nicht

Verwenden Sie http://localhost:11434 (die WSL2-Weiterleitung übernimmt die Verbindung) und stellen Sie sicher, dass nur ein Daemon auf diesem Port lauscht.

# Faire écouter l'Ollama WSL2 sur un autre port
OLLAMA_HOST=127.0.0.1:11435 ollama serve

# Puis interroger ce daemon précisément
curl http://localhost:11435/api/tags

#Weiterführende Informationen

Sobald Sie Ihre Umgebung gewählt haben, helfen Ihnen diese Anleitungen, das Beste daraus zu machen:

Ollama auf Windows 11 installieren

Die Schritt-für-Schritt-Anleitung für den nativen Installer, als Ergänzung zu diesem Vergleich, wenn Sie sich für die Windows-Variante entscheiden.

Ollama-Fehlerbehebung: GPU nicht erkannt, langsamer Betrieb, Speicherfehler

Weiterführende Informationen zu GPU-Problemen, sowohl beim nativen Betrieb als auch unter WSL2.

Quantisierung wählen (Q4, Q5, Q8, FP16)

Um den VRAM-Bedarf an Ihre Grafikkarte anzupassen, unabhängig von der Umgebung.