Votre entraînement plante avec une erreur de mémoire CUDA épuisée. Détaillez ce que vous vérifiez.

Parcourez les consommateurs de mémoire dans l'ordre : taille de lot et longueur de séquence, activations conservées pour la passe arrière, état de l'optimiseur, et fragmentation due aux formes variables. Les correctifs rapides sont un lot plus petit avec accumulation de gradient pour préserver le lot effectif, le gradient checkpointing, le bf16, et un optimiseur économe en mémoire. Vérifiez aussi que vous n'accumulez pas des tenseurs qui portent encore un graphe de calcul.

La première chose que je vérifie, c'est si ça meurt immédiatement ou après quelques centaines de pas, parce que ce sont des bugs différents. Immédiat, c'est un problème de capacité ; croissant, c'est une fuite. Pour la capacité je décompose ce qui réside réellement : poids, gradients, état de l'optimiseur (avec Adam, deux copies supplémentaires) et activations conservées pour la passe arrière. Sur un transformeur, les activations dominent en général, et elles évoluent comme la taille de lot fois la longueur de séquence, donc ce sont les premiers curseurs. Je baisse le lot et j'utilise l'accumulation de gradient pour garder un lot effectif identique, ce qui coûte du temps réel et rien d'autre. Ensuite le gradient checkpointing, qui recalcule les activations pendant la passe arrière et échange environ trente pour cent de calcul en plus contre une grosse économie de mémoire. Le bf16 divise par deux la taille des activations en plus de ça. Si ça grossit au fil des pas, quelque chose retient un graphe. Le classique, c'est d'ajouter le tenseur de perte brut à une liste pour la journalisation, ce qui garde vivant le graphe de calcul de chaque pas, et le correctif est d'appeler item dessus. Je le confirme en affichant la mémoire allouée et réservée tous les cent pas, parce qu'un escalier bien net vers le haut est le signe qui ne trompe pas.