Deux fois par jour, ma session graphique tombait. Écran figé, retour à l’écran de connexion, tout ce qui était ouvert perdu. Quinze redémarrages de gnome-shell en sept jours.
Le premier diagnostic accusait le disque. J’étais sûr que non. J’avais raison, et il a fallu deux jours pour le prouver.
Ce que disaient les logs
NVRM: GPU0 ... Out of memory [NV_ERR_NO_MEMORY]
gnome-shell: Cursor update failed: drmModeAtomicCommit: Argument invalide
La chaîne est limpide une fois qu’on la voit. Le pilote NVIDIA ne peut plus allouer. mutter n’obtient plus ses tampons d’affichage. drmModeAtomicCommit échoue. gnome-shell meurt.
Une RTX 3060 a 12 Go de mémoire vidéo. Sur une machine sans écran, ils sont pour le calcul. Sur la mienne, il y a aussi un bureau — et le bureau ne demande pas la permission.
Le premier correctif, qui n’a pas marché
J’ai réservé 2 Go au bureau via OLLAMA_GPU_OVERHEAD, coupé deux services gourmands, déplacé les grosses générations ailleurs. Logique : la VRAM déborde, donc on lui laisse de la marge.
Le lendemain : quatre plantages de plus.
C’est le moment intéressant. Un correctif qui échoue ne dit pas « essaie plus fort ». Il dit que le modèle mental est faux.
Ce que je n’avais pas vu
Le problème n’était pas un modèle qui reste et remplit la mémoire. C’était le contraire.
En comptant les chargements de modèle dans les journaux de la journée :
1079.
Mille soixante-dix-neuf fois, en treize heures, un modèle de 6,7 Go était chargé en mémoire vidéo puis relâché. Deux modèles alternaient, l’un pour la radio, l’autre pour un outil de tri musical qui tournait par salves nocturnes.
Et le coupable était le réglage censé arranger les choses. OLLAMA_KEEP_ALIVE=0s décharge le modèle dès la requête finie — je l’avais mis là pour libérer la mémoire. Mais avec un client qui appelle toutes les quarante secondes, il ne libère rien de durable : il fabrique un cycle permanent d’allocation et de libération. Six virgule sept gigaoctets qui vont et viennent, toute la journée.
La spirale
À 13 h 08, la séquence complète :
13:06:16 Ollama alloue 6699 Mio
13:08:1x gnome-shell redémarre — il réclame ses tampons
13:08:24 Ollama réalloue 6699 Mio
13:08:4x gnome-shell redémarre encore
13:08:5x NVRM: NV_ERR_NO_MEMORY ×4
13:08:59 Ollama réalloue
13:09:0x NVRM: NV_ERR_NO_MEMORY ×4
Le bureau tombe, redémarre, réclame de la mémoire — pile pendant qu’Ollama en reprend 6,7 Go. Il retombe. Chaque crash augmente la probabilité du suivant.
Le correctif
Les deux gros consommateurs sont partis sur des modèles distants. Même point d’entrée, même API : seul le nom du modèle change, et le démon route vers le cloud sans toucher au GPU.
Vérification sur les quinze minutes suivantes : onze requêtes servies, zéro chargement de modèle, zéro erreur NVIDIA, zéro plantage. Mémoire vidéo au repos : 320 Mio sur 12 Go.
Ce que ça m’a appris
Trois choses, dont deux désagréables.
Le garde-fou peut être le problème. KEEP_ALIVE=0s est un bon réglage pour un usage occasionnel et un piège pour un service qui tourne en boucle. Le même paramètre, deux régimes opposés.
Un correctif qui échoue est une information. J’ai perdu une journée à renforcer une hypothèse fausse au lieu de la jeter.
Compter bat deviner. Je tournais autour depuis des jours avec des théories. Une commande qui compte les lignes du journal a tranché en dix secondes. 1079 : il n’y avait plus rien à discuter.
Au passage, deux suspects ont été innocentés : le disque, et le navigateur. Le navigateur ne tournait même pas pendant les plantages. Les coupables sont rarement ceux dont on parle le plus fort.
Le principe
Ne pas chercher ce qui est gros. Chercher ce qui est fréquent.
RTX 3060 12 Go · Ubuntu 26.04 · Ollama · GNOME/Wayland