Ollama WSL2 : installation complète sous Windows 11

Introduction

Ollama fonctionne désormais nativement sous Windows, mais installer Ollama WSL2 reste un choix pertinent dès que vous voulez garder un environnement Linux cohérent avec votre code Python, Docker, VS Code Remote ou vos scripts de déploiement. Ce guide est utile si vous développez ou testez un agent IA sous Windows et que vous ciblez ensuite un déploiement Linux, ou si votre stack (CrewAI, LangChain, LlamaIndex) est plus simple à faire tourner dans Ubuntu que sous Windows. Il est à éviter pour un usage purement desktop : dans ce cas, l’application Windows officielle est plus directe. Une installation mal alignée se paie en GPU non détecté, en port 11434 inaccessible depuis Windows, ou en service qui redémarre mal.

Résumé rapide

Question	Réponse courte
Ollama WSL2 ou application Windows native ?	WSL2 pour un workflow Linux/Docker cohérent ; natif pour la simplicité desktop
Quelle distro ?	Ubuntu 22.04 LTS ou 24.04 LTS, WSL2 par défaut sous Windows 11
Comment activer le GPU ?	Pilote NVIDIA Windows ≥ 535, aucun driver Linux supplémentaire dans WSL
Quel modèle tester en premier ?	Un modèle léger récent (3B) depuis la bibliothèque Ollama officielle
Comment appeler Ollama depuis Windows ?	http://localhost:11434 si le forwarding fonctionne, sinon IP WSL via hostname -I

Préparer WSL2 et activer le GPU

L’application officielle Ollama pour Windows est désormais l’option la plus directe : installation en un clic, support natif des GPU NVIDIA et AMD, et interface desktop. WSL2 reste pertinent pour les builders qui veulent rester dans un environnement Linux cohérent avec leur production. Si vous ne développez pas et que vous voulez seulement discuter avec un LLM local, restez sur l’application Windows native. Si votre code, vos outils ou votre cible de production est Linux, WSL2 aligne l’OS de dev avec l’OS cible ; pour l’orchestration multi-agents, les frameworks comme CrewAI ou LlamaIndex s’attendent à un runtime POSIX et bénéficient directement de cet alignement.

Critère	Application Windows native	Ollama dans WSL2
Simplicité d’installation	Élevée (installeur graphique)	Moyenne, PowerShell + commandes Linux
Outils Linux / Python / Docker	Limité (WSL requis quand même)	Natif dans Ubuntu
Support GPU	NVIDIA et AMD officiels	NVIDIA via pilote Windows exposé
Chemins de fichiers	Windows (C:\…)	Linux (~/…), performances I/O meilleures
Maintenance / mises à jour	Ollama auto-update	apt + script Ollama
Cas d’usage typique	Chat local ponctuel, Open WebUI	Agent IA, CI locale, déploiement ensuite sur Linux

Prérequis : Windows 11 (recommandé) ou Windows 10 21H2+, accès administrateur local, virtualisation activée dans le BIOS/UEFI. Depuis une PowerShell administrateur :

wsl --install
wsl --update
wsl --list --online
wsl --install -d Ubuntu-24.04
wsl -l -v

Redémarrez si demandé, créez votre utilisateur Linux à la première ouverture d’Ubuntu. Mettez ensuite le système à jour et gardez vos projets dans le système de fichiers Linux (~/projets/...), pas dans /mnt/c/..., pour de bien meilleures performances I/O.

Côté GPU, le pilote Windows compatible WSL (version ≥ 535 recommandée, ≥ 460 minimum) est la seule source : n’installez jamais de driver Linux NVIDIA dans WSL, sinon le pilote Windows ne peut plus piloter le GPU. Vérification côté Linux :

nvidia-smi
/usr/lib/wsl/lib/nvidia-smi  # si absent du PATH

Vous devez voir votre carte GPU, la version du driver et CUDA Version. Si rien ne s’affiche : mettez à jour le pilote Windows, redémarrez, lancez wsl --shutdown côté PowerShell puis rouvrez Ubuntu. Pour les GPU AMD, le support WSL2 dépend du pilote Adrenalin récent et du runtime ROCm ; vérifiez via rocminfo ou les logs Ollama. Sans GPU compatible, Ollama fonctionne en CPU sur la RAM système : comptez au moins 8 Go de RAM pour un 3B, 16 Go pour un 7B–8B confortable.

Installer Ollama, tester l’API et résoudre les erreurs

Installation via le script officiel Ollama, alignée avec la documentation Linux à jour :

curl -fsSL https://ollama.com/install.sh | sh
ollama --version

Démarrage du service. Sous WSL2 moderne (Ubuntu 22.04+ avec systemd activé), systemctl fonctionne ; sinon, lancez ollama serve manuellement. Vérifiez l’état effectif, ne supposez pas qu’il tourne :

systemctl status ollama 2>/dev/null || pgrep -af 'ollama serve'

Si systemctl renvoie “Failed to connect to bus”, activez systemd dans /etc/wsl.conf :

[boot]
systemd=true

Puis wsl --shutdown côté Windows, rouvrez Ubuntu et réessayez. Téléchargez ensuite un modèle léger et récent, vérifié le jour de la rédaction sur la bibliothèque Ollama. Évitez les noms ou versions historiques non contrôlés :

ollama pull llama3.2:3b
ollama run llama3.2:3b "Réponds simplement OK"

Trois vérifications successives : modèle en mémoire, GPU utilisé, API accessible depuis Windows.

ollama ps
ollama run llama3.2:3b "Donne-moi la capitale de la France en un mot"

ollama ps affiche la taille du modèle et le pourcentage de VRAM utilisée. Si la ligne size vram n’apparaît pas, Ollama tourne en CPU : vérifiez le pilote Windows et nvidia-smi. Côté API locale :

curl http://localhost:11434/api/version
curl http://localhost:11434/api/generate -d '{
  "model": "llama3.2:3b",
  "prompt": "Réponds OK",
  "stream": false
}'

Le forwarding localhost entre Windows et WSL2 fonctionne depuis Windows 10 21H2 / Windows 11 avec la dernière mise à jour du kernel WSL. Si localhost:11434 ne répond pas depuis PowerShell, obtenez l’IP WSL via hostname -I et utilisez-la en attendant. Pour un accès réseau explicite, OLLAMA_HOST=0.0.0.0 est à manier avec un pare-feu, un réseau privé et une authentification — ne l’activez jamais sans ces trois verrous.

Erreurs fréquentes et leur diagnostic.

Symptôme	Cause probable	Correctif
localhost:11434 inaccessible depuis Windows	Forwarding WSL désactivé ou WSL non démarré	wsl --update, wsl --shutdown, tester l’IP WSL
GPU non détecté, Ollama en CPU	Pilote Windows trop ancien, driver Linux installé par erreur	Mettre à jour le pilote Windows, désinstaller le driver Linux WSL
systemctl renvoie “no bus”	systemd non activé dans WSL	Activer systemd=true dans /etc/wsl.conf, wsl --shutdown
Modèle “out of memory”	RAM/VRAM insuffisante pour le modèle	Choisir un modèle plus léger, fermer les autres charges
Port 11434 occupé	Autre service ou instance Ollama	lsof -iTCP:11434 -sTCP:LISTEN, ajuster OLLAMA_HOST
Modèles qui saturent le disque C:	Stockage par défaut dans ~/.ollama	Définir OLLAMA_MODELS=/mnt/d/ollama, déplacer le cache existant

Stockage : les modèles se trouvent par défaut dans ~/.ollama/models. Pour un disque dédié ou un second disque Windows monté en /mnt/d, définissez OLLAMA_MODELS=/mnt/d/ollama dans /etc/environment ou dans l’override systemd (systemctl edit ollama → Environment=...), puis systemctl daemon-reload && systemctl restart ollama. VS Code Remote WSL monte directement les fichiers Linux et permet d’éditer votre projet dans ~/... sans copier dans /mnt/c. Mini-checklist de fin d’installation : WSL2 actif, nvidia-smi opérationnel, modèle chargé, curl localhost:11434/api/version qui répond, appel depuis PowerShell réussi.

Exemple concret

Contexte. Vous développez un agent de qualification de leads sur votre laptop Windows 11 (GPU NVIDIA RTX 3060, 16 Go de RAM), avec Python 3.11 et CrewAI. Vous ciblez ensuite un déploiement sur un VPS Linux et vous voulez garder un workflow Linux cohérent du dev à la cible.

Parcours choisi. Installer WSL2 avec Ubuntu 24.04, activer le pilote NVIDIA Windows récent, vérifier nvidia-smi dans WSL, installer Ollama via le script officiel, charger llama3.2:3b, valider http://localhost:11434/api/generate depuis PowerShell, et brancher CrewAI en pointant base_url sur localhost.

Réalisation. Étape 1 : wsl --install -d Ubuntu-24.04, puis Ubuntu et apt update. Étape 2 : pilote NVIDIA ≥ 535 installé côté Windows, nvidia-smi dans WSL renvoie la RTX 3060. Étape 3 : curl -fsSL https://ollama.com/install.sh | sh, ollama --version, ollama pull llama3.2:3b. Étape 4 : ollama run llama3.2:3b "OK" répond en moins d’une seconde. Étape 5 : curl http://localhost:11434/api/version depuis PowerShell renvoie la version. Étape 6 : branchement CrewAI avec OpenAI(base_url="http://localhost:11434/v1", api_key="ollama").

Résultat. Temps de réponse 3B : ~0,3 s/token sur la RTX 3060 (mesure indicative à valider sur votre setup). Modèles stockés dans ~/.ollama/models ; saturation disque évitée en pointant OLLAMA_MODELS sur un disque dédié. API locale joignable depuis Python et depuis PowerShell sans tunnel, tant que localhost est résolu correctement. Aucune exposition réseau : OLLAMA_HOST reste à 127.0.0.1 par défaut.

Bonnes pratiques

• Choisissez WSL2 pour un workflow Linux, Docker ou de déploiement Linux ; restez sur l’application Windows native pour un usage purement desktop.
• Ne jamais installer de driver Linux NVIDIA dans WSL : c’est le pilote Windows compatible WSL qui expose le GPU.
• Gardez vos sources et vos caches (OLLAMA_MODELS) dans le système de fichiers Linux (~/..., /mnt/d/...), pas dans /mnt/c/... : les I/O y sont plusieurs fois plus rapides.
• Vérifiez chaque commande sur une installation Windows 11 propre avant de généraliser, et datez vos sources (documentation Ollama, NVIDIA WSL, Microsoft Learn).
• Isolez vos configurations par profil ou par projet (OLLAMA_MODELS, OLLAMA_HOST) pour éviter qu’un test ne casse votre setup principal.
• Surveillez RAM/VRAM (ollama ps, journalctl -u ollama) avant de charger un modèle plus gros ; préférez un 7B Q4_K_M à un 13B si la marge est faible.
• Gardez OLLAMA_HOST=127.0.0.1 par défaut ; toute exposition réseau ajoute reverse proxy + TLS + authentification.

Questions fréquentes

Ollama fonctionne-t-il sous Windows sans WSL2 ?

Oui. Depuis 2024, Ollama fournit une application Windows officielle avec accélération NVIDIA et AMD. WSL2 reste pertinent uniquement si votre workflow cible Linux ou si vous utilisez Docker, Python Linux ou des outils spécifiques à un environnement POSIX.

Faut-il un GPU NVIDIA pour Ollama WSL2 ?

Non. Ollama fonctionne en CPU sur la RAM système, suffisant pour un 3B–7B ponctuel. Le GPU devient utile dès 7B en usage répété, 13B, ou quand la latence CPU bloque. Pour AMD, le support WSL2 dépend du pilote Adrenalin récent et du runtime ROCm correspondant.

Pourquoi systemd ne répond-il pas dans WSL2 ?

Parce que systemd n’est pas activé par défaut sur toutes les distros. Ajoutez [boot] systemd=true dans /etc/wsl.conf, exécutez wsl --shutdown côté PowerShell, rouvrez Ubuntu. À partir de là, systemctl status ollama fonctionne et le service persiste entre les sessions.

Comment accéder à l’API Ollama depuis Windows ?

D’abord tester http://localhost:11434/api/version depuis PowerShell : si ça répond, le forwarding WSL fonctionne et tout votre code Windows (Python, curl, Open WebUI) utilise localhost. Sinon, récupérez l’IP WSL via hostname -I et utilisez cette IP jusqu’au prochain reboot.

Comment déplacer le stockage des modèles sur un autre disque ?

Définissez OLLAMA_MODELS=/mnt/d/ollama dans /etc/environment ou dans systemctl edit ollama, puis redémarrez le service. Déplacez ensuite les fichiers existants depuis ~/.ollama/models. Vérifiez l’espace disque avant de charger un 70B (~40 Go).

Articles liés

Wsl2 n’est qu’une étape : le bon enchaînement après l’API locale qui répond est de connecter Ollama à un framework d’agents, puis de raisonner en local vs cloud et en coûts d’exploitation. Pour les builders Windows qui veulent un parcours Python complet, le guide agent IA Windows couvre l’installation de l’environnement sans dupliquer ce tutoriel Ollama. Pour l’orchestration multi-appels, repartez de workflows agentiques une fois l’API validée.

• Agent IA avec Ollama — modèles, API et branchement CrewAI/LangChain
• Agent IA local — choix du stack local vs cloud privé
• Agent IA sur Windows — environnement Python/WSL général
• Créer un agent IA avec Python — premier agent une fois l’API locale validée
• Workflows agentiques — orchestration après le setup local
• Coûts des agents IA — arbitrage matériel local, VPS et API cloud