Salut,
Alors, je t'avoue que ComfyUI ne fait pas vraiment partie de mon workflow habituel, donc sans accès à ton environnement c’est compliqué d’être affirmatif.
Déjà ce n’est pas parce que nvidia-smi affiche encore de la VRAM libre qu’elle est forcément allouable dans n’importe quelles conditions. nvidia-smi te montre ce que le driver voit au niveau global, mais PyTorch gère cette mémoire en interne avec son propre allocateur. Il réserve des blocs, les découpe et les réutilise, ce qui peut mener à de la fragmentation. Du coup tu peux par exemple avoir des gigas libres, mais aucun bloc contigu suffisamment grand pour satisfaire une allocation donnée.
ça vaut le coup de regarder la mémoire côté PyTorch plutôt que de se fier uniquement à nvidia-smi, par exemple avec torch.cuda.memory_allocated(), torch.cuda.memory_reserved() et torch.cuda.max_memory_allocated(). Si tu vois que la mémoire réservée monte run après run sans vraiment redescendre, ou que le max explose à certains endroits du graph, ça peut conforter l'hypothèse d'un leak mémoire.
Concernant le GC, il faut garder en tête qu’un tensor GPU ne sera pas libéré tant qu’il est encore référencé quelque part. Appeler gc.collect() ou torch.cuda.empty_cache() ne changera rien si la mémoire en question est référencée. Pour investiguer ça, torch.cuda.memory_snapshot() peut être utile, parce que ça permet de remonter l’historique des allocations et de voir quels blocs restent actifs et d’où ils viennent.
Peut être que cette issue peut être utile dans ton cas ? (je peux pas mettre le lien : github comfyanonymous/ComfyUI/issues/9739)
À titre de retour d’expérience plus général (plutôt côté audio / texte de mon côté), quand on commence à taper dans les limites mémoire, l'approche qui selon moi est la robuste à long terme reste de traiter les données par chunks et d’éviter au maximum les états persistants en VRAM entre itérations, surtout en prod.