# Ollama lent sur Mac ? Vérifiez le chargement, le contexte et la mémoire

> Utilisez les informations d'exécution et de chronométrage d'Ollama pour distinguer le chargement à froid, la taille du contexte et la pression sur la mémoire, puis déchargez les modèles inactifs sans les supprimer.

Published: 2026-10-22 | Updated: 2026-10-25

Ollama peut être lent parce qu'un modèle est encore en cours de chargement, parce qu'une invite a un grand contexte, parce qu'une partie du modèle s'exécute sur le CPU ou parce que le Mac subit une pression sur la mémoire. Ces cas nécessitent des changements différents. Supprimer des modèles téléchargés peut libérer de l'espace disque, mais cela n'accélère pas automatiquement le modèle qui génère actuellement une réponse.

## Comparez le chargement à froid avec une seconde requête

Gardez le même modèle, la même invite et les mêmes réglages. Lancez une courte requête, puis répétez-la pendant que le modèle reste chargé. Si seule la première requête est lente, le chargement est une piste utile. Si les deux génèrent lentement, examinez l'exécution et la mémoire. Notez la comparaison plutôt que de traiter une seule réponse comme une référence.

La [documentation de l'API](https://docs.ollama.com/api/generate) d'Ollama expose des champs de chronométrage distincts tels que `load_duration`, `prompt_eval_duration` et `eval_duration` dans les réponses terminées. Ils distinguent le chargement, la lecture de l'invite et la génération de la sortie. Ne comparez pas les débits de tokens de modèles, de tailles de contexte ou d'invites différents comme s'ils mesuraient un seul changement.

## Mesurer une requête locale par étape

Pour un serveur local sur le port habituel, la requête suivante facilite l'inspection des champs de mesure de temps en renvoyant une réponse JSON. Remplacez `MODEL_NAME` par un modèle local déjà installé depuis `ollama list` ; n'utilisez pas de modèle cloud pour cette comparaison. La requête effectue une inférence et consomme des ressources, mais ne supprime pas les données du modèle.

```bash
curl -sS http://localhost:11434/api/generate \
  -H 'Content-Type: application/json' \
  -d '{"model":"MODEL_NAME","prompt":"Explain what a file cache does in two sentences.","stream":false,"options":{"num_predict":128}}'
```

Relancez la même requête pendant que le modèle reste chargé. Le streaming étant désactivé, le terminal affiche la réponse une fois terminée ; cette commande sert donc à obtenir les champs de mesure de temps renvoyés, et non à chronométrer le premier jeton à l'œil. Si la requête échoue, conservez son erreur et arrêtez la comparaison plutôt que d'interpréter un champ manquant comme zéro.

| Champ renvoyé | Utilisation |
| --- | --- |
| `load_duration` | Comparer le temps de chargement initial et répété |
| `prompt_eval_count` et `prompt_eval_duration` | Voir la quantité d'entrée traitée et son coût |
| `eval_count` et `eval_duration` | Comparer la génération de sortie pour la même charge de travail |
| `total_duration` | Garder le coût de la requête complète à côté des mesures de temps des composants |

Les durées documentées sont en nanosecondes. Divisez une durée par 1 000 000 000 pour obtenir des secondes. Pour la vitesse de sortie, divisez `eval_count` par `eval_duration / 1,000,000,000`, à condition que la durée soit positive. À titre d'exemple arithmétique, `100` jetons pour `5,000,000,000` nanosecondes donnent `20` jetons par seconde ; ce n'est pas un résultat mesuré pour un Mac ou un modèle donné.

Ne divisez pas les jetons de sortie par la durée totale pour ensuite appeler cela une vitesse de génération pure. Cela inclurait le chargement et le travail sur l'entrée. Notez aussi si le prompt répété utilise une entrée mise en cache, car une seconde requête plus rapide peut refléter à la fois un modèle déjà chargé et une réutilisation du prompt. Conservez la réponse complète plutôt que de ne rapporter que le chiffre le plus flatteur.

## Voyez ce qui est réellement chargé

Dans Terminal, inspectez l'état actuel :

```
ollama ps
```

La [FAQ d'Ollama](https://docs.ollama.com/faq) explique la colonne `PROCESSOR`. Elle peut indiquer GPU, CPU ou une répartition. Le [guide matériel](https://docs.ollama.com/gpu) documente l'accélération Metal sur les GPU Apple. Si vous attendiez d'un modèle local qu'il utilise le GPU, le résultat en cours d'exécution est plus utile qu'une supposition fondée sur le nom du Mac.

Vérifiez aussi que la requête va bien au serveur local que vous inspectez. Une interface peut pointer vers un autre hôte ou un modèle cloud. Dans ce cas, la sortie locale de `ollama ps` ne décrit pas la requête distante.

## Réduisez le contexte avant de blâmer la taille du modèle

Les fichiers de modèle ne représentent qu'une partie des besoins en mémoire. Un contexte plus grand nécessite de la mémoire supplémentaire, et les requêtes simultanées ajoutent du travail. La [documentation sur la longueur de contexte](https://docs.ollama.com/context-length) d'Ollama décrit les valeurs par défaut dépendantes du matériel et le contrôle du contexte dans l'application. Ne supposez pas que chaque installation a la même valeur par défaut.

Pour un test contrôlé, utilisez une invite courte, une seule requête et un contexte plus petit qui contient encore les informations nécessaires à ce test. Si la tâche de codage complète exige ensuite plus de contexte, restaurez-en assez pour préserver son sens. Une réponse plus rapide qui perd silencieusement des instructions nécessaires n'est pas une optimisation réussie.

N'essayez un modèle plus petit ou une quantification que comme comparaison séparée. Cela change à la fois l'utilisation des ressources et la qualité des réponses. Conservez quelques questions représentatives pour évaluer si l'option plus rapide reste utile.

## Tester un changement de contexte sans le rendre permanent

Pour un court prompt de diagnostic, l'API accepte une option de contexte par requête. Dans la requête précédente, ajoutez `"num_ctx":4096` dans `options` aux côtés de `num_predict`, en utilisant un modèle local qui prend en charge ce contexte. Il s'agit d'une taille de test donnée en exemple, pas d'un réglage recommandé pour chaque modèle ou tâche de programmation.

Gardez le modèle et le prompt inchangés, puis inspectez le modèle en cours d'exécution avec `ollama ps` et comparez la pression sur la mémoire. Ne réduisez pas le contexte autour d'une longue conversation en supposant que la réponse contient encore chaque instruction. Comparez d'abord une petite tâche qui tient dans ce contexte ; ensuite, testez la charge de travail réelle avec un contexte suffisant pour ses entrées.

La FAQ et la page dédiée à la longueur de contexte décrivent les valeurs par défaut différemment ; ce guide ne s'appuie donc pas sur une valeur par défaut universelle. Un réglage d'application, une interface ou une option au niveau de la requête peuvent aussi influencer la valeur en cours d'exécution. Lorsque la version installée indique `CONTEXT` dans `ollama ps`, notez cette valeur à côté de `PROCESSOR` plutôt que de la déduire de la taille du fichier du modèle.

Une lecture de mémoire plus basse n'est pas la seule condition de réussite. La tâche doit encore s'achever avec des réponses acceptables, et le reste du Mac doit rester utilisable. Si un contexte plus petit fait perdre des faits importants ou si le changement n'apporte aucune différence reproductible, retirez l'option de test et restaurez la configuration précédente qui fonctionnait.

## Surveillez tout le Mac pendant la génération

Ouvrez **Moniteur d'activité › Mémoire** et surveillez la pression pendant la génération, pas seulement une fois la réponse terminée. Les puces Apple Silicon utilisent une mémoire système partagée, donc les autres apps comptent aussi. Un modèle qui tient sur le disque ne prouve pas qu'il tient confortablement à côté du reste de votre charge de travail.

Enregistrez votre travail et fermez une tâche lourde inutile, puis répétez la même requête. Si la pression s'améliore et que la lenteur évolue avec elle, vous avez une piste utile. Le [guide sur la pression sur la mémoire](https://mole.fit/fr/blog/mac-memory-pressure-explained) explique comment lire les indicateurs du Mac sans traiter chaque octet mis en cache comme du gaspillage.

## Déchargez un modèle inactif sans le supprimer

Attendez d'abord qu'une éventuelle requête utilisant le modèle soit terminée. Pour libérer un modèle chargé dont vous n'avez plus besoin, utilisez `ollama stop` suivi de son nom exact tel qu'il apparaît dans `ollama ps` :

```
ollama stop MODEL_NAME
```

Remplacez `MODEL_NAME` avant d'exécuter la commande. Cela décharge le modèle de la mémoire. Cela ne supprime pas ses fichiers téléchargés, et la requête suivante peut de nouveau payer le coût du chargement. Décharger répétitivement un modèle entre les requêtes peut donc rendre l'expérience plus lente.

Si l'espace disque est la véritable contrainte, examinez les modèles stockés séparément dans le [guide de nettoyage des modèles d'IA](https://mole.fit/fr/blog/how-to-remove-ai-tool-leftovers-mac). Conservez les modèles créés localement et tout ce que vous ne pouvez pas retélécharger de manière fiable. Pour les performances, comparez un changement à la fois et liez le résultat à la même charge de travail.
## Examiner un écart avec le journal du serveur

Si la requête locale reste lente ou si la répartition entre processeurs est inattendue, le [guide de dépannage](https://docs.ollama.com/troubleshooting) d'Ollama indique que le journal du serveur Mac se trouve à `~/.ollama/logs/server.log`. Lisez la portion autour de l'heure du test et cherchez des échecs de chargement, des problèmes d'allocation mémoire ou le backend d'exécution sélectionné. Pour un serveur démarré manuellement, les messages correspondants peuvent se trouver dans son terminal.

Notez la version d'Ollama, le tag exact du modèle, le contexte, la répartition entre processeurs et l'étape qui domine les mesures de temps. Avant de les partager, vérifiez les extraits de journal pour y repérer des prompts privés et des chemins locaux. Ne modifiez pas plusieurs variables d'environnement GPU ou serveur simplement parce qu'elles apparaissent dans un ancien billet d'optimisation ; le journal doit d'abord identifier l'écart qu'un changement est censé corriger.

---

Canonical HTML page: https://mole.fit/fr/blog/ollama-slow-on-mac
Blog index for agents: https://mole.fit/fr/blog/llms.txt
Site index for agents: https://mole.fit/llms.txt