Corriger les Erreurs LTX-2 dans ComfyUI : Solutions pour OOM, Écrans Noirs et Scintillement

Salut, c’est Dora ici. Je n’avais pas l’intention de déboguer LTX-2 dans ComfyUI. Tout a commencé par une minuscule pause : une fenêtre de prévisualisation noire après un workflow que j’avais exécuté une douzaine de fois. Pas d’échec dramatique. Juste… rien. J’ai réessayé, j’ai regardé la console, j’ai modifié un paramètre ou deux. À la fin de la semaine (tests du 6 au 10 janvier 2026), j’avais collecté une poignée de correctifs qui revenaient sans cesse. Ce n’est pas un grand tutoriel, plutôt des notes que je donnerais à un ami qui essaie aussi de faire fonctionner LTX-2 sans transformer sa matinée en réinstallation de pilotes. Vous savez, ce genre de chaos tranquille que nous connaissons tous trop bien.

Diagnostic en 60 secondes (symptôme → cartographie des causes)

Quand LTX-2 se comporte mal dans ComfyUI, j’ai trouvé que la reconnaissance rapide des motifs vaut mieux que la conjecture. Voici la carte en 60 secondes que je consulte avant de toucher à quoi que ce soit de lourd :

Symptôme : Scintillement ou dérive image par image
Cause probable : guidance instable (CFG trop élevé), changement de graines, paramètres de mouvement trop forts.
Essai rapide : fixer la graine, baisser le CFG d’un cran, réduire légèrement le mouvement/denoise, ajouter une étape de cohérence temporelle.

Symptôme : Changements de couleur bizarres, “neige” ou blocs étirés
Cause probable : décalage de poids/version, mauvais VAE, cache corrompu ou téléchargement partiel.
Essai rapide : re-vérifier les hash, vider le cache du modèle, confirmer la compatibilité du VAE.

Symptôme : Erreurs de nœud concernant les formes ou NoneType
Cause probable : un nœud n’a pas fourni de sortie (échec antérieur), ou versions de nœud/modèle incompatibles.
Essai rapide : isoler la branche défaillante, exécuter jusqu’à ce nœud seulement, vérifier la console ComfyUI pour la première vraie ligne d’erreur. Si l’une de ces conditions s’applique, j’arrête. Un changement à la fois. Ensuite, je réexécute un clip de 2 à 3 secondes pour ne pas perdre du temps sur de longs rendus.

Correctif OOM : Ordre de dégradation Résolution / Précision / Batch

Ma routine OOM pour LTX-2 est ennuyeuse, mais elle fonctionne. Je la fais dans cet ordre et je ne passe à l’étape suivante que si l’OOM persiste :

1. Résolution d’abord

• Réduire la hauteur/largeur de 20 à 30 % au lieu de diviser par deux. De nombreux graphes LTX-2 sont sensibles à la foulée (multiples de 8 ou 16). Je maintiens les dimensions divisibles par 16 pour éviter le remplissage caché.
• Si vous ciblez 1024×576, essayez 896×504. Croyez-moi, c’est beaucoup plus proche de l’original que vous ne l’attendriez.

2. Précision ensuite

• Passer la précision du modèle à fp16 (ou bf16 si votre pile la supporte) dans le nœud de chargement approprié. Sur les GPU grand public NVIDIA, fp16 donne généralement les économies de mémoire les plus nettes.
• La précision mixte convient, mais j’évite de basculer par nœud en cours d’exécution. Engagez-vous à une seule précision pour les parties lourdes.

3. Taille du batch en dernier

• Définir le batch à 1 pour l’échantillonnage vidéo. Même les petits batchs multiplient les activations clés en mémoire. Je n’augmente le batch que pour les latents ou aperçus rapides.

J’ai aussi remarqué un avantage subtil : verrouiller la graine lors de l’ajustement de l’OOM. L’aléatoire peut masquer si votre dernier changement a réellement aidé.

Écran noir : Problèmes de chargement de modèle vs décodage

Mon premier écran noir de cette semaine s’est avéré ne pas être une défaillance du modèle du tout. C’était une bizarrerie de décodage.

Comment je les sépare rapidement

Vérifier la taille du fichier et la durée

• Si la vidéo a la bonne longueur et une taille à peu près attendue, les images pourraient être là. Votre lecteur pourrait ne pas aimer le format de pixel ou l’espace colorimétrique.

• Réencoder avec une base sûre :
  ffmpeg -i input.mp4 -pix_fmt yuv420p -c:v libx264 -crf 18 output.mp4
  (voir la documentation FFmpeg pour plus d’options d’encodage) Examiner la console ComfyUI

• Les vrais problèmes de chargement de modèle s’annoncent : poids manquants, clés incompatibles, ou décalage de hash VAE/modèle.

• Si vous voyez des journaux d’échantillonnage réussis et aucune exception, c’est probablement un chemin d’affichage/encodage.

Décalages de dimensions latentes

• Les pipelines LTX-2 attendent certaines foulées (souvent des multiples de 16). Si vos entrées latentes ou de contrôle ne correspondent pas, vous pouvez obtenir des images vides ou quasi noires.
• Je vérifie que tous les nœuds de redimensionnement se produisent avant que le modèle ne s’en attende, et que toutes les branches s’accordent sur la largeur/hauteur.

Surprises de gamme de couleurs

• Plage complète par rapport à limitée peut sembler écrasée au noir dans certains lecteurs. Un réencodage rapide (ci-dessus) règle généralement le problème.

S’il s’agit d’un problème de chargement de modèle, je vais à la source : vérifier que le chemin du point de contrôle LTX-2 dans le nœud de chargement pointe vers le fichier réel, confirmer la somme de contrôle, et s’assurer que le format de poids attendu du nœud (safetensors vs ckpt) correspond au fichier. La documentation officielle ComfyUI et le README du modèle sont les seules pages auxquelles je fais confiance pour les notes de version/format.

Correctif Scintillement : Paramètres de stabilité et ancrage des prompts

Le scintillement n’est pas toujours un bogue. Parfois, c’est le modèle qui fait exactement ce qu’on lui a dit, avec trop de liberté.

Ce qui a stabilisé les choses pour moi :

• Fixer la graine
  Je verrouille la graine pour tout test A/B. Cela élimine une variable glissante tout de suite.

• Baisser le CFG d’un cran
  Si je suis à 8–9, j’essaie 6. Une guidance trop élevée peut tirer les images dans des directions différentes.

• Denoise et force de mouvement
  Des réductions douces ici (10–20 %) aident souvent plus que d’augmenter les étapes. J’ai trouvé qu’un denoise légèrement moins préserve mieux les signaux temporels.

• Ancrage des prompts
  Garder un prompt de base stable et déplacer les changements dans une petite section explicite (keyframes ou une brève parenthèse). Changer la phrase entière entre les images invite la dérive.

• Passage de cohérence temporelle
  Si votre graphe a un nœud temporel/cohérence, l’exécuter légèrement. Il n’inventera pas de détails, mais il peut lisser les saccades.

• Choix du sampler
  Je teste 2 à 3 samplers avec la même graine. Certains sont plus saccadés sur la vidéo. Si l’un calme les bords au même nombre d’étapes, je le garde.

Petite note : J’ai arrêté de chasser la “cohérence de cadre parfaite”. L’objectif pour moi est de réduire la fatigue mentale lors de l’édition, quelque chose que je peux couper avec, pas la perfection au microscope.

Sortie corrompue : Décalage de poids / Erreurs de chemin

La corruption s’est manifestée pour moi comme des blocs roses, de la neige scintillante ou un dégradé de couleurs qui ne correspondait pas au prompt. À chaque fois, c’était quelque chose de banal :

• Poids décalés
  Le chargeur attendait une variante spécifique de LTX-2 : j’en avais une différente avec un nom similaire. J’inclus maintenant la date ou le hash du modèle dans les noms de fichiers.

• Mauvais VAE
  Changer les VAE à la légère m’a mordre. Le correctif était simple : utiliser le VAE spécifié par la documentation du nœud LTX-2 ou le README du modèle. Si aucun n’est spécifié, utiliser celui fourni avec le bundle ou recommandé par l’auteur du graphe.

• Téléchargements partiels
  Un point de contrôle de 3 à 8 GB échouant à 95 % semble complet dans un affichage de dossier. Je vérifie la taille du fichier par rapport au listing du dépôt et, le cas échéant, je vérifie le hash.

• Petits problèmes de chemin (Windows particulièrement)
  Les caractères non-ASCII et les chemins très longs m’ont cassé des chargements dans le passé. Faites-moi confiance, je garde les chemins des modèles courts (par ex. D:\models\ltx2\…) et j’évite les espaces quand je peux.

• Formats mélangés
  safetensors vs .ckpt n’est pas interchangeable dans certains nœuds. Je fais correspondre l’attente du nœud.

Quand je soupçonne une corruption, je réexécute un prompt minuscule connu comme étant bon à une résolution minuscule. Si c’est propre, je sais que le problème réside dans ma combinaison actuelle, pas dans toute l’installation.

Lecture des journaux : Quel niveau a crashé

La plupart de mes économies de temps proviennent de la lecture de la première ligne d’échec, pas de la dernière ligne dramatique. La console ComfyUI vous dit généralement assez si vous ralentissez pendant trente secondes.

Ce que je cherche :

• Mémoire CUDA insuffisante
  Ce n’est pas un bogue. Réduire la résolution/précision/batch comme ci-dessus. Si ça échoue à la même étape à chaque fois, vous frappez un pic d’activation spécifique, réduisez les étapes ou activez l’attention économe en mémoire.

• CUDNN_STATUS_EXECUTION_FAILED ou accès mémoire illégal
  Souvent une inadéquation du pilote ou de la bibliothèque. Je note mes versions CUDA, PyTorch, et du pilote GPU dans un fichier texte. Si je viens de mettre à jour l’une d’elles, je la rétrécis ou je reconstruis la venv. La documentation ComfyUI a une petite matrice de combinaisons connues comme bonnes.

• Erreurs de taille/forme de décalage
  Un tenseur a la mauvaise forme. C’est généralement un problème de graphe de nœud : un redimensionnement se produit sur une branche et pas sur une autre, ou une entrée de contrôle attend une échelle différente. Je trace les dimensions où elles divergent.

• KeyError / clés state_dict manquantes
  Décalage poids–nœud. Comparer les clés manquantes listées avec le README du modèle. Variante de point de contrôle incorrecte ou nœud obsolète.

• AttributeError: ‘NoneType’ …
  Un nœud antérieur a retourné rien. J’exécute le graphe jusqu’à ce nœud seulement. Le premier Aucun est le vrai coupable.

Deux habitudes qui ont aidé :

• Exécuter de courts clips lors du débogage. Dix secondes de journaux d’échec gaspille beaucoup moins de temps qu’une minute de silence.
• Activer tout basculement de débogage/verbosité disponible sur le nœud suspect. Le contexte supplémentaire vaut mieux que deviner.

Je garde une petite “carte d’environnement” dans le dossier du projet : modèle GPU et VRAM, pilote, CUDA, PyTorch, commit ComfyUI, versions du pack de nœuds, et le hash du point de contrôle LTX-2. Quand quelque chose casse, je la compare à celle de la semaine dernière avant de blâmer le modèle.

Quand basculer vers le cloud (raccourci de dépannage WaveSpeed)

Je ne me précipite pas vers le cloud pour LTX-2, mais il y a des moments où c’est le moyen le plus propre de séparer “l’humeur de ma machine” des vrais problèmes.

Quand je bascule

• VRAM inférieure à 16 Go et j’ai besoin de sorties 1024p sans compromis lourds.
• Je vois des crashs instables liés à mes versions CUDA/pilote locales, et je n’ai pas le temps de reconstruire.
• Je veux un deuxième avis : même graphe, matériel différent.

Ce que je fais sur WaveSpeed (ou tout autre espace de travail GPU comparable)

• Choisir une image connue comme étant bonne (combinaison CUDA/PyTorch documentée). C’est plus important que les TFLOPS bruts quand vous déboguez.
• Synchroniser uniquement le graphe minimal, les poids LTX-2 exacts (avec hash), et un court prompt de test.
• Exécuter d’abord le plus petit cas reproductible. S’il fonctionne dans le cloud et pas localement, c’est probablement l’environnement : s’il échoue dans les deux, c’est le graphe ou les poids.

Coûts et compromis

• Vous paierez pour le calcul, oui. Mais une repro propre peut économiser une après-midi de roulette des pilotes.
• Les disques cloud peuvent aussi cacher des problèmes de chemin, juste de manières différentes. Je garde toujours les chemins courts et ASCII.

Ce n’est pas une poussée pour déplacer votre workflow. C’est juste un raccourci tranquille quand vous êtes coincé et la date limite est plus forte que votre patience.

Nous avons construit WaveSpeed pour des moments exactement comme celui-ci — quand vous avez juste besoin d’un environnement GPU propre pour éliminer rapidement les choses. Si vous êtes coincé en train de déboguer LTX-2, vous pouvez essayer notre WaveSpeed ici.

---

Quel est le bug LTX-2 le plus fou que vous ayez rencontré cette semaine ? Laissez un commentaire et dites-moi si c’est un nouveau piège.