# Déplacer les modèles Ollama vers un autre disque sous Windows

Pour déplacer les modèles téléchargés par Ollama hors du disque C, configurez `OLLAMA_MODELS` pour le compte qui exécute Ollama. Déplacer l'application elle-même est une opération différente. Modifier la variable seule ne copie pas les modèles existants, donc conservez l'ancien stockage jusqu'à ce que le nouveau soit vérifié.

Ce guide concerne l'installation classique sur un bureau Windows. Une installation en service, en conteneur ou sous WSL peut s'exécuter sous un autre compte ou avec une autre configuration et doit être traitée par son propriétaire.

## Identifier le stockage actuel avant de le copier

La [documentation Windows](https://docs.ollama.com/windows) d'Ollama distingue les binaires de l'application, les journaux et les données de modèles. Le stockage par défaut se trouve sous `%USERPROFILE%\.ollama\models`. Un paramètre `OLLAMA_MODELS` antérieur peut pointer ailleurs.

Dans une fenêtre PowerShell nouvellement ouverte, examinez le paramètre au niveau utilisateur :

```
[Environment]::GetEnvironmentVariable("OLLAMA_MODELS", "User")
ollama list
```

Un paramètre vide signifie qu'il n'y a pas de substitution au niveau utilisateur, pas la preuve qu'un service ou un autre compte utilise la valeur par défaut. Notez la liste des modèles et inspectez le dossier utilisé par cette installation. Le stockage contient `blobs` et `manifests` ; conservez leur structure relative plutôt que de copier uniquement les fichiers les plus volumineux.

## Vérifier les deux points sur lesquels une copie de dossier peut se tromper

Avant de copier, confirmez l'espace libre de la destination et le chemin source exact. Une ancienne surcharge au niveau utilisateur, un autre compte Windows ou une seconde installation d'Ollama peuvent rendre le chemin par défaut trompeur. Notez la valeur existante de la variable, y compris son absence éventuelle, afin que le retour arrière restaure l'état d'origine.

À la destination, `blobs` et `manifests` doivent se trouver directement dans le dossier nommé par `OLLAMA_MODELS`. Si la variable pointe vers `D:\AI\Ollama\models`, les enfants attendus sont `D:\AI\Ollama\models\blobs` et `D:\AI\Ollama\models\manifests`. Un niveau `models` ajouté par erreur est une erreur de configuration courante à écarter avant de retélécharger quoi que ce soit.

Utilisez une destination vide dédiée pour cette migration. Ne fusionnez pas dans un dépôt sans rapport en supposant que des noms de fichiers identiques prouvent que les contenus sont interchangeables. Prévoyez assez d'espace pour le dépôt copié complet et pour l'usage futur ordinaire ; changer la variable ne fait pas consommer à deux copies l'espace d'une seule.

## Copier d'abord, puis basculer l'application

Choisissez un disque local disposant de suffisamment d'espace libre et qui restera disponible. Par exemple, `D:\AI\Ollama\models` peut être une destination si ce disque existe et que votre compte peut y écrire. Un disque externe déconnecté est un cas d'échec prévisible, et non une raison d'accorder à l'application des droits d'administrateur.

1. Terminez les générations et téléchargements en cours, puis quittez Ollama depuis son menu dans la zone de notification.
2. Copiez le contenu du stockage de modèles actuel vers la destination choisie avec l'Explorateur de fichiers. Gardez l'original intact et résolvez toute erreur de copie avant de continuer.
3. Ouvrez **Modifier les variables d'environnement pour votre compte** depuis la recherche Windows.
4. Créez ou modifiez `OLLAMA_MODELS` avec le chemin de destination, puis enregistrez.
5. Relancez Ollama depuis le menu Démarrer et ouvrez un nouveau terminal.

Les [instructions sur les variables d'environnement](https://docs.ollama.com/faq) d'Ollama expliquent pourquoi l'application doit redémarrer pour hériter du changement. Un terminal ouvert plus tôt peut conserver l'ancien environnement. Ne créez pas un second serveur uniquement pour tester la variable alors que l'application dans la zone de notification s'exécute encore.

## Une commande de copie facultative pour un grand dépôt

L'Explorateur de fichiers suffit lorsque sa copie se termine proprement. Pour un grand dépôt où un journal de copie est utile, Windows inclut [Robocopy](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/robocopy). L'exemple PowerShell suivant suppose que la source vérifiée est le dépôt par défaut et que la destination est un nouveau dossier dédié. Remplacez les deux chemins si l'installation diffère, et quittez Ollama avant de copier.

```powershell
$source = "$env:USERPROFILE\.ollama\models"
$destination = "D:\AI\Ollama\models"
robocopy "$source" "$destination" /E /L /R:1 /W:1
```

`/L` liste le travail prévu sans copier. Lisez la source et la destination en haut de la sortie. Si elles sont correctes, lancez la copie sans `/L` et conservez un journal en dehors du dépôt de modèles :

```powershell
robocopy "$source" "$destination" /E /R:1 /W:1 /TEE /LOG:"$env:TEMP\ollama-model-copy.log"
$copyExitCode = $LASTEXITCODE
$copyExitCode
```

`/E` inclut les sous-répertoires, tandis que les options de nouvelle tentative bornent les tentatives pour un fichier en échec. Cet exemple ne met volontairement pas en miroir et ne déplace pas la source. N'ajoutez pas `/MIR`, `/PURGE` ni `/MOVE` : leur comportement de suppression est inutile pour conserver une copie de retour arrière.

Robocopy utilise des codes non nuls pour certaines issues qui ne sont pas des échecs. Un code de 8 ou plus indique au moins un échec de copie. Même en dessous de 8, examinez le résumé et tout fichier non concordant ou supplémentaire, surtout si la destination n'était pas vide. Résolvez les erreurs avant de changer la variable ; un listage de modèles réussi ne peut pas rendre complète une copie de fichier échouée.

## Prouver que le nouvel emplacement fonctionne avant de supprimer l'ancien

Exécutez à nouveau `ollama list` et comparez avec la liste notée. Choisissez un modèle déjà affiché et effectuez une petite requête en utilisant son nom exact. Si le modèle est absent, arrêtez-vous et vérifiez la structure des dossiers et le paramètre plutôt que de laisser un nouveau téléchargement masquer une migration échouée.

Vérifiez la destination pendant le test et assurez-vous que l'application utilise le stockage prévu. Conservez l'ancien répertoire jusqu'à ce qu'une charge de travail importante réussisse et que les modèles créés localement soient sauvegardés. Une correspondance de taille de répertoire est une preuve plus faible que l'utilisation réussie des modèles requis.

Si le basculement échoue, quittez Ollama, restaurez la valeur précédente de la variable ou supprimez la substitution nouvellement ajoutée, puis redémarrez. Le stockage d'origine intact rend cette récupération simple.

## Rendre la vérification plus solide qu'une taille de dossier identique

Un serveur en cours d'exécution peut conserver un ancien environnement ou un modèle chargé. Terminez le travail actif, quittez l'application de la zone de notification et relancez-la après avoir défini le nouveau chemin, puis ouvrez un terminal neuf. Comparez `ollama list` avec l'inventaire enregistré avant de demander à un modèle de s'exécuter. Si une entrée requise manque, examinez d'abord le chemin et la structure `manifests`.

Pour chaque modèle créé localement qui compte, testez une petite requête après ce démarrage à neuf. Tester un seul modèle téléchargé courant ne prouve pas qu'un modèle personnalisé a survécu. Conservez le dépôt d'origine jusqu'à ce que ces modèles requis et une charge de travail applicative ordinaire fonctionnent correctement.

S'il reste impossible de déterminer quel répertoire le serveur utilise, examinez le `server.log` actuel dans `%LOCALAPPDATA%\Ollama` au moment du démarrage et du chargement, en utilisant les [emplacements de dépannage officiels](https://docs.ollama.com/troubleshooting). Comparez tout chemin configuré signalé avec la destination prévue. Un chemin affiché dans un terminal nouvellement ouvert ne décrit que ce terminal, ce n'est pas une preuve concernant un autre serveur déjà en cours d'exécution.

Ne créez pas un nouveau téléchargement simplement pour faire paraître active une destination vide. Cela peut masquer une migration infructueuse et consommer plus d'espace sur C. Si les éléments de preuve ne permettent pas de conclure, conservez les deux dépôts et résolvez la configuration avant de supprimer l'original. Pour le retour arrière, quittez l'application, restaurez la variable enregistrée ou supprimez la nouvelle surcharge si aucune n'existait, puis relancez et vérifiez la liste de modèles d'origine.

## Supprimer uniquement l'ancien stockage de modèles vérifié

Après validation, examinez l'ancien répertoire `models` avant de le supprimer via l'Explorateur de fichiers. Ne supprimez pas tout le répertoire `.ollama`, qui peut contenir la configuration et d'autres états. Windows peut supprimer définitivement les fichiers trop volumineux pour la Corbeille, alors lisez la confirmation et conservez toute sauvegarde nécessaire.

Déplacer des modèles ne décharge pas un modèle actuellement en mémoire et ne garantit pas une génération plus rapide. Une destination plus lente peut allonger le chargement initial. Si le problème est la mémoire plutôt que la capacité du disque C, examinez la charge de travail et le [guide mémoire Windows](/fr/windows/blog/windows-high-memory-usage).

Pour les autres téléchargements d'IA, [Hugging Face a sa propre configuration de cache](/fr/windows/blog/huggingface-cache-windows). Configurez le véritable propriétaire du stockage de chaque outil plutôt que de déplacer un répertoire parent partagé en espérant que chaque application le suive.


Canonical: https://mole.fit/fr/windows/blog/move-ollama-models-windows