#L'enjeu : deux Ollama sur une même machine

Depuis qu'Ollama propose un installeur Windows natif, la question « ollama wsl2 ou natif ? » revient sans cesse. Les deux approches font tourner exactement le même daemon, écoutent par défaut sur http://localhost:11434 et servent les mêmes modèles GGUF. La différence se joue ailleurs : dans la façon dont le GPU est exposé, dans l'endroit où vivent vos fichiers, et dans l'écosystème d'outils que vous utilisez autour.

En résumé, le natif Windows gagne en simplicité d'installation et en intégration desktop, tandis que WSL2 gagne en cohérence avec un workflow Linux/dev et en compatibilité avec les outils qui n'existent que côté Unix. Aucun des deux n'est « meilleur » dans l'absolu — le bon choix dépend de ce que vous faites de vos LLM.

Ollama natif Windows: Un .exe, une icône dans la barre système, le daemon démarre avec Windows. Zéro couche Linux à gérer.
Ollama sous WSL2: Une distribution Linux (Ubuntu le plus souvent) dans laquelle vous installez Ollama comme sur un serveur. Idéal si votre stack est déjà Linux.
Point commun: Même API sur le port 11434, mêmes modèles, mêmes commandes. On peut d'ailleurs faire dialoguer un client Windows avec un serveur WSL2 et inversement.

Ne faites pas tourner les deux en même temps

Un Ollama natif et un Ollama WSL2 veulent tous deux le port 11434. Si les deux tournent, vous aurez des conflits déroutants (« address already in use » ou requêtes qui partent vers le mauvais daemon). Choisissez-en un, ou changez le port de l'autre via OLLAMA_HOST.

#Prérequis

Pour comparer honnêtement les deux, il faut que le GPU soit correctement pris en charge dans chaque environnement. C'est là que la plupart des déceptions naissent.

Windows 11 (ou 10 récent): WSL2 avec accélération GPU (WSLg) suppose Windows 11 ou une build Windows 10 récente à jour.
Pilote GPU à jour côté Windows: Sous WSL2, c'est le pilote Windows qui expose le GPU à Linux via /dev/dxg. Installez le pilote NVIDIA (Game Ready ou Studio) ou AMD Adrenalin le plus récent, PAS un pilote Linux dans la distro.
WSL2 activé: La commande « wsl --install » depuis un PowerShell administrateur installe WSL2 et une Ubuntu par défaut.
VRAM suffisante: Les repères Q4_K_M restent identiques dans les deux mondes : 7B ≈ 5 Go, 14B ≈ 9 Go, 32B ≈ 19 Go, 70B ≈ 40 Go. WSL2 ne change pas ces besoins.

Piège classique : le pilote Linux qui casse tout

Sous WSL2, n'installez JAMAIS un pilote GPU Linux (le .run NVIDIA, ou les paquets mesa/amdgpu). Le GPU est déjà exposé par le pilote Windows. Installer un pilote Linux par-dessus casse l'accélération. On installe uniquement le CUDA toolkit ou les runtimes ROCm côté user-space, pas le kernel driver.

#Installer proprement Ollama dans WSL2

L'installation dans WSL2 est identique à celle sur un serveur Linux : le script officiel détecte le GPU exposé par WSLg et configure l'accélération automatiquement.

01
Activer WSL2
Dans un PowerShell administrateur : « wsl --install ». Redémarrez si demandé. Vérifiez ensuite avec « wsl -l -v » que votre distribution est bien en VERSION 2.
02
Mettre à jour la distribution
Ouvrez Ubuntu, puis « sudo apt update && sudo apt upgrade -y ». Une distro à jour évite des surprises avec les runtimes GPU.
03
Installer Ollama
Lancez le script officiel : « curl -fsSL https://ollama.com/install.sh | sh ». Il détecte NVIDIA (via CUDA exposé par WSLg) ou AMD (ROCm) et l'annonce dans les logs.
04
Vérifier le GPU
Chargez un petit modèle puis regardez « ollama ps » : la colonne PROCESSOR doit indiquer GPU, pas CPU. Si c'est CPU, l'accélération n'est pas active.
05
Tester un modèle
« ollama run llama3.1:8b » puis posez une question. Ajoutez --verbose pour voir les tokens/seconde réels.

WSL2 (Ubuntu) — installation

# 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 llama3.1:8b
ollama run llama3.1:8b --verbose

# Le processeur utilisé (GPU attendu)
ollama ps

→

Vérifier que le GPU est bien vu par WSL2

Pour NVIDIA, « nvidia-smi » doit fonctionner directement dans WSL2 sans avoir rien installé côté Linux — c'est le signe que WSLg expose bien la carte. S'il répond, Ollama saura l'utiliser.

#Perfs GPU : natif vs WSL2, chiffres à l'appui

C'est LA question qui motive ce guide. Bonne nouvelle : pour l'inférence LLM sur GPU NVIDIA, l'écart entre Ollama natif et WSL2 est faible. Une fois le modèle chargé en VRAM, le calcul se fait sur le GPU dans les deux cas, et WSL2 n'ajoute quasiment pas de surcoût sur la génération de tokens elle-même.

En pratique, sur une même carte (par exemple une RTX 4070 12 Go avec un 8B en Q4_K_M), on observe des débits de génération très proches — l'écart se situe typiquement dans une marge de quelques pour cent, souvent noyée dans la variance des mesures. Là où WSL2 peut coûter un peu, c'est sur le chargement initial du modèle depuis le disque : le système de fichiers de WSL2 est rapide sur son disque virtuel ext4, mais l'accès aux fichiers stockés côté Windows (via /mnt/c) est nettement plus lent.

Génération de tokens (GPU): Quasi identique natif vs WSL2 sur NVIDIA. Le GPU fait le travail dans les deux cas ; la couche WSL2 est transparente pour le calcul.
Chargement du modèle: Rapide si les modèles vivent dans le système de fichiers Linux natif de WSL2. Lent si Ollama lit ses blobs depuis /mnt/c/... (traversée du pont Windows).
Latence premier token: Comparable, à condition que le modèle soit déjà en cache VRAM. Le premier chargement à froid est l'étape sensible.
Overhead CPU: Négligeable pour l'inférence. WSL2 est une vraie VM légère, pas une émulation ; le coût de virtualisation ne se voit pas sur des charges GPU.

→

Gardez vos modèles côté Linux

Sous WSL2, laissez Ollama stocker ses modèles à leur emplacement par défaut (~/.ollama dans le système de fichiers ext4 de la distro). Ne pointez pas OLLAMA_MODELS vers un chemin /mnt/c/... : vous perdriez énormément en vitesse de chargement à cause de la traversée du pont de fichiers.

Conclusion sur les perfs pures : si vous avez une carte NVIDIA, le choix natif vs WSL2 ne se joue PAS sur la vitesse de génération. Choisissez selon votre workflow. La performance ne redevient un argument que dans deux cas : le stockage des modèles (à garder côté Linux sous WSL2) et le support AMD, qu'on aborde maintenant.

#Le cas AMD : ROCm sous WSL2

Sur GPU AMD, l'histoire est différente et plus nuancée. Ollama utilise ROCm pour accélérer sur les Radeon compatibles. Or ROCm a longtemps été un terrain miné sous Windows, et WSL2 a changé la donne — dans un sens pas toujours favorable selon votre carte.

AMD en natif Windows: Ollama embarque une bibliothèque ROCm pour Windows. Sur les cartes officiellement supportées (RX 7000 récentes, certaines RX 6000), l'accélération fonctionne sans WSL2. C'est souvent le chemin le plus simple pour un desktop AMD.
AMD sous WSL2: ROCm existe pour WSL2 mais la liste des GPU supportés est plus étroite et le setup plus délicat. Ça peut être nécessaire si vous voulez un outillage Linux, mais ce n'est pas plus rapide en soi.
Cartes non supportées: Beaucoup de Radeon plus anciennes ou d'APU ne sont pas dans la liste ROCm officielle. Sur ces cartes, Ollama peut retomber sur le CPU dans les deux environnements.
Contournement HSA: La variable HSA_OVERRIDE_GFX_VERSION permet parfois de forcer la reconnaissance d'un GPU proche d'un modèle supporté. À réserver aux utilisateurs avertis, sans garantie.

AMD : vérifiez la compatibilité AVANT de choisir

Ne partez pas du principe que votre Radeon sera accélérée sous WSL2. Consultez la liste des GPU ROCm supportés sur la documentation officielle AMD et Ollama. Pour une carte AMD grand public récente, l'installeur natif Windows d'Ollama est souvent la voie la moins douloureuse.

WSL2 — diagnostic AMD ROCm

# 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

#Accès aux fichiers et intégration VS Code

Au-delà des perfs, c'est souvent l'accès aux fichiers qui décide. Les deux systèmes de fichiers (Windows NTFS et Linux ext4 de WSL2) sont accessibles depuis l'autre, mais avec un coût de performance à la traversée du pont, et des conventions de chemins différentes.

Depuis WSL2 vers Windows: Vos disques Windows sont montés sous /mnt/c, /mnt/d, etc. Pratique pour lire un dossier de documents, mais lent pour des accès intensifs (chargement de gros modèles, indexation RAG).
Depuis Windows vers WSL2: Le système de fichiers Linux est accessible via le chemin réseau \\wsl$\Ubuntu\ dans l'Explorateur. Utile pour déposer un fichier, mais évitez d'y faire travailler des outils Windows intensivement.
Règle d'or: Gardez chaque charge de travail dans son système de fichiers natif. Projet dev Linux → dans WSL2. Documents bureautiques → côté Windows. Vous évitez ainsi le pont lent.

Côté VS Code, l'intégration WSL est excellente et penche fortement en faveur de WSL2 pour un usage développeur. L'extension officielle « WSL » ouvre un projet directement dans la distro : le serveur VS Code tourne côté Linux, le terminal intégré est un shell Linux, et votre code d'appel à l'API Ollama s'exécute dans le même environnement que le daemon.

Appel API Ollama (identique natif/WSL2)

import requests

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

→

Client Windows, serveur WSL2 (ou l'inverse)

Grâce à la redirection localhost de WSL2, un programme lancé sous Windows peut appeler un Ollama qui tourne dans WSL2 sur http://localhost:11434, et réciproquement. Vous n'êtes donc pas obligé de tout mettre du même côté — utile pour un IDE Windows piloté par un daemon Linux.

#Quelle config recommandée selon votre usage

Voici la synthèse actionnable. Choisissez selon votre profil dominant plutôt que sur des micro-différences de tokens/seconde.

Usage desktop / grand public (NVIDIA): Ollama natif Windows. Installation en un clic, démarrage avec la session, aucune couche Linux à maintenir. Parfait avec LM Studio ou Open WebUI en interface.
Développeur Linux / stack Unix: Ollama sous WSL2. Vous retrouvez vos outils (scripts bash, Docker, Python venv) dans le même environnement que le daemon, avec une intégration VS Code exemplaire.
GPU AMD grand public: Testez d'abord le natif Windows : c'est souvent le plus simple à faire fonctionner via la ROCm embarquée. Passez à WSL2 seulement si votre workflow l'exige et que votre carte est supportée.
Serveur / partage réseau: WSL2 se rapproche d'un déploiement Linux serveur classique et facilite la reproductibilité (mêmes commandes qu'en prod). Pensez à OLLAMA_HOST pour l'exposer.

En un mot

GPU NVIDIA + usage desktop → natif. Workflow développeur Linux → WSL2. Les perfs de génération sont quasi identiques ; c'est l'écosystème autour qui doit trancher.

#Dépannage

« ollama ps » affiche CPU au lieu de GPU: Sous WSL2, vérifiez que « nvidia-smi » répond. Si non, mettez à jour le pilote côté Windows et n'installez aucun pilote Linux dans la distro.
Chargement de modèle très lent: Vos modèles sont probablement stockés sous /mnt/c. Déplacez-les dans le système de fichiers Linux (~/.ollama) pour retrouver la vitesse.
« address already in use » sur 11434: Un Ollama natif ET un Ollama WSL2 tournent en même temps. Arrêtez-en un, ou changez le port de l'autre avec OLLAMA_HOST=127.0.0.1:11435.
GPU AMD ignoré: Carte hors liste ROCm. Vérifiez la compatibilité, tentez éventuellement HSA_OVERRIDE_GFX_VERSION, ou repliez-vous sur le natif Windows.
Le client Windows ne joint pas le daemon WSL2: Utilisez http://localhost:11434 (la redirection WSL2 gère le pont) et assurez-vous qu'un seul daemon écoute sur ce port.

WSL2 — changer le port pour éviter un conflit

# 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

#Pour aller plus loin

Une fois votre environnement choisi, ces guides vous aideront à en tirer le meilleur :

Installer Ollama sur Windows 11: Le pas-à-pas de l'installeur natif, complémentaire de ce comparatif si vous partez sur la voie Windows.
Dépanner Ollama : GPU non détecté, lenteurs, erreurs mémoire: Pour aller plus loin sur les pannes GPU, valables en natif comme sous WSL2.
Choisir sa quantification (Q4, Q5, Q8, FP16): Pour caler la bonne empreinte VRAM selon votre carte, indépendamment de l'environnement.

Ce guide vous a aidé ?

Un retour, une erreur, une précision ? Faites-nous signe, ça améliore le guide pour tout le monde.

Suite logique

Guide · 3 min