2026 Ollama 0.34.0 avec DeepSeek-R1 : que faire si la mémoire ne se libère pas après la fin de la tâche ?

La documentation de l’API Ollama définit keep_alive=0 comme une demande de déchargement immédiat du modèle dans le champ consacré au maintien en mémoire. Cela donne une action claire, mais pas un diagnostic : cette option peut contenir temporairement la croissance d’un Runner, sans réparer une fuite sous-jacente. Pour Ollama 0.34.0 avec DeepSeek-R1 lorsque la mémoire ne se libère pas, nous recommandons donc cette séquence :

• Maintenant : ne forcez pas encore une limite mémoire expérimentale et ne réduisez pas le contexte au hasard.
• À la fin du prochain lot : relevez le processus Runner, la pression mémoire, l’échange et les journaux, puis testez keep_alive=0 ou l’arrêt explicite du modèle.
• Après le rechargement suivant : comparez la nouvelle initialisation et la réussite de la tâche.
• Si la croissance revient : traitez l’isolement du processus ou un nœud Mac indépendant comme une décision d’exploitation, pas comme un simple réglage.

Cette démarche sépare une rétention normale, une insuffisance physique de mémoire unifiée et une croissance persistante du processus. Ce sont trois problèmes différents, avec trois réponses différentes.

Cet article s’adresse aux développeurs de traitements par lots qui doivent intégrer la récupération du modèle dans le cycle du travail, aux ingénieurs qui maintiennent un Agent IA en service continu et aux responsables techniques qui arbitrent entre rechargement, fiabilité et capacité isolée. Si le besoin porte surtout sur l’évaluation de capacité d’un modèle à long contexte, consultez aussi notre guide consacré à la capacité d’un Mac pour les modèles DeepSeek-R1 à long contexte.

Dernière mise à jour : 15 septembre 2026. Les sémantiques de keep_alive, les consignes de dépannage macOS et les références Metal ont été vérifiées dans la documentation API d’Ollama, la documentation de dépannage macOS et les documents Apple cités ci-dessous.

Une tâche terminée ne signifie pas nécessairement que le modèle est déchargé

Lorsqu’une requête s’achève, plusieurs objets peuvent encore expliquer l’occupation observée :

• les poids du modèle restent chargés pendant la période de conservation demandée par keep_alive ;
• le cache KV peut avoir servi à la génération et ne pas être restitué au même instant que la réponse ;
• les fichiers mappés peuvent rester visibles dans les outils système sans représenter une allocation privée équivalente ;
• le Runner peut conserver des structures de travail, des allocations Metal ou des buffers en attente ;
• le processus de service peut rester actif même après la disparition du modèle de la liste des modèles en cours.

Sur un Mac Apple Silicon, le processeur et le processeur graphique partagent une mémoire unifiée. Apple documente cette propriété avec hasUnifiedMemory dans Metal : il ne faut donc pas interpréter la mémoire utilisée par Metal comme une réserve graphique séparée de la mémoire du système définie par Apple. La conséquence opérationnelle est importante : une charge DeepSeek-R1 peut faire monter la pression générale du Mac même si le modèle semble surtout « graphique ».

La première vérification consiste à exécuter la commande de liste des modèles en cours après la fin d’une requête. La deuxième consiste à rechercher le processus Runner et son identifiant. La troisième consiste à observer la pression mémoire du système, et non seulement une colonne isolée du Moniteur d’activité. Apple explique que la pression mémoire synthétise notamment la disponibilité de la mémoire et l’activité d’échange dans son guide du Moniteur d’activité.

Une liste vide et une pression encore élevée ne sont donc pas contradictoires. Le modèle peut être retiré de l’état logique d’Ollama alors qu’un processus ancien, un fichier mappé ou une allocation Metal reste observable. Inversement, une pression momentanément élevée ne prouve pas une fuite si le modèle est encore dans sa période de conservation.

La variable qui augmente permet de distinguer le cache d’une croissance du Runner

Réduire le contexte est une expérience utile, mais ce n’est pas une preuve. Il faut comparer séparément trois variables :

1. la quantité de requêtes traitées ;
2. la longueur de contexte et la taille des sorties ;
3. le nombre d’appels simultanés ou de conversations actives.

Si la mémoire monte surtout avec la longueur du contexte, le cache KV ou les structures associées au traitement deviennent des suspects plausibles. Si elle monte avec le nombre de requêtes alors que le contexte reste stable, le processus Runner mérite une inspection plus précise. Si elle monte principalement avec la concurrence, il faut d’abord vérifier la multiplication des chargements, des sessions ou des buffers.

Une référence communautaire illustre précisément cette difficulté : l’Issue macOS consacrée à une croissance du tas d’un Runner décrit un cas où l’occupation annoncée par l’API paraît stable alors que le processus continue de croître. Ce cas concerne Ollama 0.32.15 et d’autres modèles ; il ne constitue ni une confirmation officielle d’une fuite dans Ollama 0.34.0, ni une preuve concernant DeepSeek-R1. Il sert uniquement de piste de comparaison.

Cette nuance évite deux erreurs coûteuses. La première consiste à annoncer trop vite une fuite spécifique à DeepSeek-R1. La seconde consiste à augmenter les limites de mémoire ou à appliquer des paramètres noyau non confirmés alors que le problème vient d’une concurrence mal contrôlée. Nous recommandons de créer une reproduction minimale avec une séquence représentative de vos appels, puis de noter, pour chaque étape, l’identifiant du Runner et l’état du système.

Pour les travaux audio, vidéo ou design qui associent génération de texte, aperçu visuel et export, cette séparation est encore plus importante : une application créative peut avoir sa propre consommation mémoire, indépendante du modèle. Il faut donc fermer ou isoler les autres charges avant de conclure sur Ollama.

Le protocole de récupération dépend du mode de lancement

La récupération ne se vérifie pas de la même manière selon que le service est lancé par Ollama.app, par une commande manuelle ou par un appel distant.

1. Photographier l’état avant toute action

Avant l’arrêt, notez :

• le nom exact du modèle et la charge utilisée ;
• le PID du Runner observé ;
• la pression mémoire et l’activité d’échange ;
• la présence du modèle dans la liste des modèles actifs ;
• l’heure et l’identifiant de la requête ;
• les extraits pertinents des journaux.

Pour les journaux macOS, suivez les indications de la documentation de dépannage Ollama. Cette étape est essentielle : sans état initial, un redémarrage peut donner l’impression d’avoir corrigé le problème sans permettre de savoir ce qui s’est réellement passé.

2. Tester l’API avec une récupération explicite

Pour une charge contrôlée, envoyez la requête d’inférence avec keep_alive réglé à 0, conformément à la sémantique officielle de l’API :

{
  "model": "deepseek-r1",
  "prompt": "Votre requête de test",
  "keep_alive": 0
}

Le nom exact du modèle doit naturellement correspondre à celui installé dans votre environnement. La valeur 0 demande à Ollama de ne pas conserver le modèle après cette opération ; elle ne garantit pas la destruction immédiate de chaque allocation du Runner ni la réparation d’un état Metal dégradé.

Après la réponse, vérifiez à nouveau la liste des modèles actifs, le PID et la pression mémoire. Si l’entrée disparaît mais que le PID reste inchangé avec une occupation qui ne revient pas, la récupération logique et la récupération physique ne coïncident pas encore.

3. Tester l’arrêt explicite en dehors d’une requête

Pour un lot terminé, l’arrêt du modèle par la commande prévue par Ollama fournit une deuxième méthode de comparaison :

ollama stop deepseek-r1

Cette commande ne doit pas être exécutée par un appel quelconque si plusieurs consommateurs utilisent le même modèle. Dans Ollama.app, identifiez d’abord le processus et le modèle réellement gérés par l’application. Dans un service lancé manuellement, vérifiez au contraire le terminal, le processus parent et l’environnement qui a lancé le serveur. Un appel API qui demande le déchargement ne contrôle pas nécessairement la même frontière opérationnelle qu’un arrêt du service complet.

4. Vérifier le processus, et non seulement la liste Ollama

Utilisez les outils macOS pour retrouver le Runner, son PID et son évolution. La commande suivante sert à l’observation, pas à la suppression automatique :

pgrep -alf ollama

Vous pouvez ensuite relever la pression mémoire dans le Moniteur d’activité et observer l’échange. Les indicateurs de travail maximal recommandé de Metal ne sont pas une limite universelle à copier dans une commande ; Apple les présente comme une information de dimensionnement pour un périphérique donné dans la documentation du jeu de travail recommandé. Nous déconseillons donc d’en déduire un sysctl générique ou de présenter une valeur expérimentale comme un correctif officiel.

5. Recharger une seule fois et comparer

Après la récupération, relancez exactement une charge de test comparable. Comparez :

• le temps nécessaire avant la première sortie ;
• le PID créé ou réutilisé ;
• le retour de la pression mémoire ;
• la réussite complète du travail ;
• les erreurs de session ou d’outil.

Ces mesures doivent provenir de votre propre environnement Apple Silicon. Les délais de chargement et les amplitudes de récupération ne peuvent pas être transformés en seuils généraux sans mesure locale ou source originale adaptée.

6. Redémarrer le service seulement si les preuves le justifient

Si l’ancien Runner reste présent, si les journaux signalent un état Metal incohérent ou si un nouveau chargement échoue après le déchargement logique, passez au redémarrage complet du service. Conservez les journaux avant l’opération. Un redémarrage peut libérer l’état du processus, mais il efface aussi une partie de la situation utile au diagnostic si les preuves ne sont pas enregistrées.

La récupération forcée échange de la mémoire contre du temps de chargement

Le choix ne se résume pas à « libérer » ou « ne pas libérer ». Il faut estimer le coût d’un nouveau chargement, le délai avant la première réponse, la fréquence des bascules de modèle et la probabilité d’interruption.

Notre grille de décision attribue une note qualitative sur cinq, uniquement comme outil d’arbitrage :

• Récupération à chaque requête — stabilité mémoire : 4/5 ; continuité : 1/5. Adaptée à un test isolé ou à un petit lot dont chaque requête constitue une frontière naturelle. Elle impose cependant un rechargement fréquent et peut dégrader fortement la latence.
• Récupération à la fin d’un lot — stabilité mémoire : 4/5 ; continuité : 4/5. C’est généralement le compromis le plus défendable lorsque les requêtes sont regroupées et que personne d’autre ne consomme le modèle pendant le lot.
• Récupération pendant une période d’inactivité — stabilité mémoire : 3/5 ; continuité : 5/5. Pertinente pour un Agent qui doit rester disponible, à condition de disposer d’un signal fiable indiquant que la file est vide.
• Redémarrage régulier sans preuve — stabilité mémoire : 2/5 ; continuité : 1/5. Ce n’est pas une correction standard : cela peut masquer la cause, interrompre des outils et rendre les incidents plus difficiles à reproduire.
• Nœud isolé remplaçable — stabilité opérationnelle : 5/5 ; coût de capacité : variable. Cette option devient rationnelle lorsque plusieurs clients se partagent un Runner ou lorsque la récupération locale empêche de tenir les engagements de traitement.

Pour un Agent continu, ne déchargez jamais le modèle parce qu’un seul appelant le demande. Utilisez une file qui doit être vide, un verrou d’exclusivité, un contrôle de santé et une reprise avec nombre de tentatives défini par votre politique d’exploitation. Un service API doit vérifier les requêtes en vol et les appels d’outils ; un traitement planifié doit vérifier que le lot est terminé et que son résultat est durablement écrit.

Les critères de validation diffèrent également. Pour l’API, testez une conversation active, une invocation d’outil et une requête concurrente avant d’autoriser la récupération. Pour le traitement par lots, testez la fermeture du lot, la génération du résultat, le déchargement et un nouveau lot. Dans les deux cas, l’arrêt doit pouvoir être annulé si un contrôle de santé échoue.

La liste de vérification évite de confondre récupération logique et récupération physique

• [ ] Reproduire la croissance avec une séquence DeepSeek-R1 représentative, et non avec une seule requête artificielle.
• [ ] Noter le PID du Runner avant la récupération.
• [ ] Noter la pression mémoire et l’activité d’échange avant la récupération.
• [ ] Vérifier si le modèle est encore présent dans la liste des modèles actifs.
• [ ] Capturer les journaux Ollama et macOS avant tout redémarrage.
• [ ] Tester keep_alive=0 sur une charge sans consommateur concurrent.
• [ ] Vérifier la disparition du modèle, puis l’évolution du PID et de la pression mémoire.
• [ ] Recharger le modèle une fois et confirmer que la tâche aboutit.
• [ ] Pour un Agent partagé, vider la file et acquérir un verrou avant tout arrêt.
• [ ] Si le Runner reste bloqué, redémarrer le service en conservant les preuves.
• [ ] Ne pas présenter un paramètre sysctl non confirmé comme une réparation.
• [ ] Définir à l’avance le critère de sortie vers un processus isolé ou un nœud indépendant.

Le point de sortie arrive avant la prochaine fuite

Continuez sur le Mac local si la récupération à la fin des lots laisse le service stable, si le rechargement reste acceptable pour le travail réel et si les tâches concurrentes peuvent être correctement drainées. Séparez les travaux si le problème apparaît seulement lorsque plusieurs Agents, modèles ou applications audio, vidéo et design partagent le même Runner. Passez à une capacité Mac isolée si chaque cycle exige un redémarrage, si les échecs interrompent des tâches utiles ou si une équipe doit supporter un service continu sans pouvoir remplacer rapidement le processus fautif.

La question économique est alors plus précise qu’un simple pourcentage de mémoire. Une machine partagée cumule les voisins bruyants, les rechargements imprévisibles et les interruptions difficiles à attribuer. Une infrastructure locale peut rester pertinente pour une charge lourde et stable, surtout si un accès physique ou une exécution permanente est indispensable. En revanche, pour valider un lot, tester un Agent ou absorber une période de travail variable, la location d’un Mac indépendant chez JexMac peut éviter d’immobiliser le poste principal et permet d’intégrer le coût de récupération dans le test.

Avant de changer d’environnement, exécutez une comparaison « exécution — déchargement — rechargement » avec vos propres requêtes. Si cette séquence doit être répétée trop souvent pour terminer le travail, évaluez un Mac distant isolé en incluant le temps de reprise, le risque d’interruption et la possibilité de remplacer le nœud, plutôt que de continuer à modifier des paramètres mémoire sans confirmation. Les modalités disponibles peuvent être vérifiées sur notre page de location de Mac, puis confrontées à votre charge réelle avant toute décision.

FAQ