1. Conservez le message et le contexte avant de relancer
Arrêtez d’ajouter des tâches à la file. Notez le texte exact de l’erreur, le fichier ou la question concernés, le nombre d’éléments traités ensemble et l’étape atteinte. Le modèle se chargeait-il, le calcul avançait-il ou la sortie était-elle en cours d’écriture ? Gardez les réglages dans une note et les résultats déjà terminés dans leur dossier.
Un écran figé ou une application fermée sans explication ne suffit pas à identifier la cause. Retrouvez son journal lorsqu’il existe. Une panne de connexion, une entrée invalide et une mémoire saturée peuvent produire des symptômes voisins dans l’interface. Si le logiciel ne précise rien, écrivez « cause non déterminée » et préparez un essai minimal plutôt que d’inventer un diagnostic.
2. Séparez mémoire du GPU, mémoire système et espace disque
La mémoire du GPU sert aux éléments du calcul sur la carte. La RAM du serveur et le stockage répondent à d’autres besoins. Les capacités affichées sur les fiches GPU BriefGPU ne décrivent pas la RAM ou le disque effectivement disponibles. Vérifiez la ressource mentionnée par le message et les informations de votre environnement.
Dans Python, MemoryError désigne un échec d’allocation mémoire ; ce nom seul ne désigne pas un manque de VRAM. Le code ENOSPC correspond à un manque d’espace sur le périphérique visé. Ces repères orientent la recherche, mais le journal de l’application reste nécessaire pour localiser l’opération.
| Observation | Premier contrôle | Ce qu’un GPU plus grand ne résout pas à lui seul |
|---|---|---|
| Message CUDA out of memory pendant le calcul | Mémoire de la carte utilisée, autres tâches et taille du groupe | Une incompatibilité du logiciel ou un fichier corrompu |
| MemoryError pendant la lecture des fichiers | Mémoire du processus, quantité de données chargées en RAM | Le chargement de tout le dossier dans la mémoire système |
| No space left on device pendant un export | Espace et éventuel quota du dossier de sortie ou temporaire | Un disque plein ou une limite de stockage |
| Application fermée sans message exploitable | Journal, étape atteinte et essai sur une seule entrée | Une cause encore inconnue |
3. Revenez à une entrée et à un seul travail actif
Vérifiez d’abord les traitements que vous avez vous-même lancés. Un aperçu, une ancienne session ou un second outil peut encore travailler. Fermez proprement les tâches devenues inutiles après avoir conservé leur état. Ne terminez pas un processus que vous ne reconnaissez pas et ne redémarrez pas tout l’environnement pour gagner quelques minutes de diagnostic.
Reprenez l’entrée qui a échoué, seule, sans diminuer sa qualité. Si elle passe isolément mais échoue en groupe, le nombre d’éléments simultanés devient une piste. Réduisez par exemple un groupe de quatre à deux, puis à un si nécessaire. Le nombre de fichiers du dossier reste identique ; seule la quantité travaillée en même temps change.
Certains outils proposent un traitement séquentiel pour limiter les pointes de mémoire. Diffusers documente notamment le découpage du décodage d’un groupe d’images. Cette possibilité dépend du pipeline utilisé : consultez ses options avant d’activer un réglage trouvé pour un autre modèle.
4. Réduisez la charge sans perdre le résultat demandé
Si une entrée seule échoue, examinez ses dimensions ou sa longueur. Pour une image, passer de 2 048 × 2 048 à 1 024 × 1 024 divise le nombre de pixels par quatre. Cela ne garantit pas une mémoire totale divisée par quatre : le modèle et les autres éléments gardent leurs propres besoins. Une réduction n’est acceptable que si la sortie conserve les détails nécessaires.
Pour un assistant, distinguez les documents fournis, la question et la réponse générée. Le cache de génération peut consommer davantage de mémoire avec un contexte long ; les mécanismes exacts dépendent du modèle. Testez une demande plus courte ou une seule requête à la fois. Ne retirez pas le passage qui contient la réponse puis ne concluez pas que le problème est résolu.
Conservez toujours l’entrée d’origine. Nommez la variante d’essai et écrivez ce qu’elle change. Si l’outil propose un découpage en tuiles ou un transfert de certains éléments vers la RAM, vérifiez sa documentation et contrôlez les raccords, la qualité et le temps observé. Une option économe en VRAM peut déplacer la contrainte ailleurs.
5. Ne confondez pas mémoire réservée et mémoire utile
Avec PyTorch, la mémoire réservée par l’allocateur et celle occupée par les tenseurs sont deux mesures différentes. Vider le cache inutilisé ne libère pas les tenseurs encore actifs. Une commande de nettoyage ne transforme donc pas une charge trop grande en charge compatible.
Si une relance propre de votre application aide, rejouez ensuite le même petit cas et notez le résultat. Une réussite après redémarrage ne prouve pas à elle seule une fuite mémoire corrigée. Si l’usage augmente à chaque passage identique, conservez cette observation et consultez la documentation ou l’assistance du logiciel avant d’accumuler les relances.
Exemple : isoler le problème dans un dossier de douze images
Voici un scénario illustratif, sans mesure de matériel. Une indépendante prépare douze images, dont deux comportent de grandes dimensions et du texte fin. Le traitement par groupes de quatre échoue. Elle garde le message, puis essaie l’une des grandes images seule, à la qualité initiale. Le tableau montre comment interpréter des observations possibles.
Dans ce scénario, elle retient les groupes de deux uniquement après avoir contrôlé les deux grandes images ensemble et quelques images ordinaires. Elle vérifie le texte et les contours dans les fichiers exportés. Elle ne généralise pas ce résultat à toutes les tailles d’image, à tous les modèles ni à un autre logiciel.
| Essai du scénario | Observation hypothétique | Décision locale |
|---|---|---|
| Quatre images simultanées | Échec mémoire | Conserver l’erreur et réduire le groupe |
| Une grande image, mêmes réglages | Sortie complète et acceptable | La qualité cible peut passer sur ce cas isolé |
| Deux grandes images ensemble | Sorties complètes et acceptables | Tester ce groupe sur une courte tranche |
| Image réduite fortement | Calcul terminé, texte illisible | Écarter cette réduction malgré la réussite technique |
Quand une autre capacité devient une piste justifiée
Comparez une autre carte lorsque le manque de mémoire GPU est identifié, que le cas indispensable échoue seul et que les réductions compatibles avec votre qualité ne suffisent pas. Gardez le logiciel, la version, les paramètres et l’entrée concernés : ce dossier rend le prochain essai comparable. Il ne permet pas de déduire exactement combien de Go supplémentaires suffiront.
Une erreur au chargement du modèle peut aussi limiter l’intérêt de réduire le groupe : une partie importante de la charge existe avant la première entrée. Les options de précision ou de quantification changent les conditions d’exécution et parfois les résultats ; elles demandent un essai séparé. Ajouter des lots n’unifie pas automatiquement la mémoire de plusieurs cartes.
Terminez avec un diagnostic utilisable
Votre note de sortie tient en cinq éléments : message et étape, ressource suspectée, entrée conservée, réglage qui passe ou échoue, contrôle de qualité effectué. Ajoutez ce qui reste inconnu. Si aucun petit cas ne fonctionne, arrêtez la répétition du lot complet et demandez de l’aide avec ces informations.
Ne supprimez pas vos seuls originaux pour libérer le disque, ne baissez pas plusieurs paramètres ensemble et ne comptez pas une sortie partielle comme réussite. Réservez du temps pour sauvegarder les résultats valides. Le diagnostic doit réduire l’incertitude ; il n’a pas besoin de se transformer en une séance interminable de réglages.