ComfyUIでLTX-2エラーを修正：OOM、黒フレーム、ちらつきの解決策

こんにちは、ドラです。私はComfyUIのLTX-2をデバッグするつもりで始めたわけではありません。小さな一呼吸から始まりました。何度も実行したワークフローの後、黒いプレビューウィンドウが表示されました。劇的な失敗ではなく、ただ…何もありません。リトライして、コンソールを見守り、設定を少し調整しました。週末までに（2026年1月6～10日にテスト）、繰り返し現れる数個の修正が集まりました。これは壮大なチュートリアルではなく、友人に手渡すようなノートのようなものです。LTX-2をドライバー再インストール朝に変えることなく動作させようとしている友人です。ご存知のように、私たちが皆よく知っている静かなカオスのようなものです。

60秒診断（症状→原因マッピング）

ComfyUIでLTX-2が誤動作するとき、私は推測を打つよりも迅速なパターンマッチングが有効であることに気づきました。何か重いものに触れる前に実行する60秒マップです：

症状：ちらつきまたはフレーム間のドリフト
考えられる原因：不安定なガイダンス（CFGが高すぎる）、シード変更、過度に強いモーション設定。
クイック試行：シードを固定し、CFGを少し下げ、モーション/ノイズ除去を下げ、時間的一貫性ステップを追加します。

症状：奇妙な色の移動、「スノー」、または引き伸ばされたブロック
考えられる原因：重み/バージョンの不一致、間違ったVAE、破損したキャッシュまたは部分的なダウンロード。
クイック試行：ハッシュを再確認し、モデルキャッシュをクリアし、VAE互換性を確認します。

症状：形状またはNoneTypeに関するノードエラー
考えられる原因：ノードが出力されていない（以前の失敗）、またはノード/モデルバージョンの互換性がない。
クイック試行：失敗したブランチを分離し、そのノードまでだけ実行し、ComfyUIコンソールで最初の実際のエラー行を確認します。 これらのいずれかが当てはまる場合、私は停止します。一度に1つの変更。それから、長いレンダリングで時間を消費しないように、2～3秒のクリップを再実行します。

OOMフィックス：解像度/精度/バッチダウングレード順序

私のLTX-2 OOMルーティンは退屈ですが、機能します。この順序で実行し、OOMが続く場合にのみ次のステップに移動します：

1. 最初に解像度

• 高さ/幅を20～30%下げます。半分にするのではなく。多くのLTX-2グラフは歩幅に敏感です（8または16の倍数）。隠れたパディングを避けるために、寸法を16で割り切れるように保ちます。
• 1024×576を目指している場合、896×504を試してください。期待するより元のに近く見えるとお伝えします。

2. 次に精度

• 関連するローダーノードでモデル精度をfp16（またはスタックがサポートしている場合はbf16）に切り替えます。NVIDIAコンシューマーGPUではfp16通常、最も清潔なメモリ削減を提供します。
• 混合精度は問題ありませんが、実行中のノードごとに切り替えることは避けます。重い部分に1つの精度をコミットします。

3. バッチサイズ最後

• ビデオサンプリング用にバッチを1に設定します。小さなバッチでもメモリ内のキーアクティベーションを乗算します。クイックレイテントまたはプレビュー用にのみバッチをバンプします。

また、微妙な勝利に気づきました。最後の変更が実際に役立つかどうかを確認しながら、シードをロックします。

ブラックスクリーン：モデルロードデコード問題

今週の最初のブラックスクリーンはモデル障害ではありませんでした。デコード異常でした。

2つを迅速に分離する方法

ファイルサイズと期間を確認

• ビデオが正しい長さで、ほぼ予想されるサイズの場合、フレームが存在する可能性があります。プレイヤーがピクセル形式または色空間を好まない場合があります。

• 安全なベースラインで再エンコード：
  ffmpeg -i input.mp4 -pix_fmt yuv420p -c:v libx264 -crf 18 output.mp4
  （詳細なエンコードオプションについては、FFmpegドキュメントを参照してください） ComfyUIコンソールをスクラブ

• 真のモデルロード問題は自分たちを発表します：欠落した重み、互換性のないキー、またはVAE/モデルハッシュの不一致。

• サンプリングログが成功し、例外がない場合、それはおそらく表示/エンコードパスです。

潜在的な次元の不一致

• LTX-2パイプラインは特定の歩幅（多くの場合16の倍数）を期待します。潜在的または制御入力が一致しない場合、空白または暗いフレームが表示される可能性があります。
• リサイズノードがモデルが期待する前に発生し、すべてのブランチが幅/高さに同意することを確認します。

色範囲の驚き

• フル対リミテッドレンジは一部のプレイヤーで黒く圧迫されているように見えることができます。クイック再エンコード（上記）は通常それを解決します。

これがモデルロード問題の場合、私はソースに行きます。ローダーノードのLTX-2チェックポイントパスが実際のファイルを指していることを確認し、チェックサムを確認し、ノードの予想される重み形式（safetensorsまたはckpt）がファイルと一致することを確認してください。公式ComfyUIドキュメントとモデルのREADMEは、バージョン/フォーマットのメモについて信頼する唯一のページです。

ちらつき修正：安定性パラメータとプロンプトアンカリング

ちらつきは必ずしもバグではありません。モデルが正確にその通りに行っている場合があります。

何が私のために物事を安定させたか：

• シードを固定
  A/Bテストのシードをロックします。すぐに1つのぬるぬるした変数を削除します。

• CFGを少し下げる
  8～9の場合、6を試します。過度に高いガイダンスはフレームを異なる方向に引っ張ることができます。

• ノイズ除去とモーション強度
  ここでの穏やかな削減（10～20%）は、ステップをクランクするよりも多くの場合があります。わずかなノイズ除去が時間的信号をより良く保つことを見つけました。

• プロンプトアンカリング
  安定した基本プロンプトを保ち、変更を小さな、明示的なセクション（キーフレームまたは簡潔な括弧）に移動します。フレーム全体で文全体を変更すると、ドリフトが招待されます。

• 時間的一貫性パス
  グラフに時間的/一貫性ノードがある場合、軽く実行してください。詳細を発明しませんが、ジッターを和らげることができます。

• サンプラーの選択
  同じシードで2～3のサンプラーをテストします。ビデオでは一部がよりジャンプです。同じステップカウントでエッジを落ち着かせるかのであれば、それを保ちます。

小さなメモ：「完全な」フレームコヒーレンスを追いかけるのをやめました。私の目的は、編集中の精神的疲労が少なくなり、顕微鏡の下での完璧さではなく、カットできるものです。

破損した出力：重量不一致/パスエラー

破損はピンクブロック、きらめくような雪、またはプロンプトと一致しなかった色バンディングとして私に現れました。毎回、それは平凡なものでした：

• 不一致の重み
  ローダーは特定のLTX-2バリアントを期待していました。同様の名前の別の名前がありました。ファイル名にモデルの日付またはハッシュを含めるようにします。

• 間違ったVAE
  VAEをカジュアルに交換することは私を少し噛みました。修正は簡単でした。LTX-2ノードドキュメントまたはモデルREADMEで指定されたVAEを使用してください。何も指定されていない場合、バンドルされたものまたはグラフ著者が推奨するものにデフォルトします。

• 部分的なダウンロード
  3～8 GBのチェックポイントが95%で失敗すると、フォルダビューで完全に見えます。ファイルサイズをリポジトリリストと比較し、利用可能な場合はハッシュを確認します。

• パスしゃっくり（特にWindowsで）
  非ASCII文字と非常に長いパスは過去に読み込みを壊してしまいました。モデルパスを短く保ち（例：D:\models\ltx2\…）、可能な場合はスペースを避けます。

• 混合形式
  safetensorsとckptは一部のノードでは互い変えられません。ノードの期待と一致します。

破損を疑う場合、既知の良い小さなプロンプトで小さな解像度で再実行します。それが清潔であれば、問題は私の現在のコンボに住んでいることを知っています。インストール全体ではなく。

ログ読む：どのレイヤーがクラッシュしたか

時間節約のほとんどは、最後の劇的なものではなく、最初の失敗ラインを読むことから来ました。ComfyUIのコンソールは通常、30秒間スローダウンすれば十分です。

私が探しているもの：

• CUDAメモリ不足
  バグではありません。上記のようにres/精度/バッチを削減します。同じステップで毎回失敗した場合、特定のアクティベーションピークに当たっていますステップをドロップするか、メモリ効率的な注意を有効にしてください。

• CUDNN_STATUS_EXECUTION_FAILEDまたは違法なメモリアクセス
  多くの場合、ドライバーまたはライブラリの不一致。私はCUDA、PyTorch、およびGPUドライバーバージョンを記録します。最近1つを更新した場合、ロールバックするか、venvを再構築します。ComfyUIドキュメントには、既知の良いコンボの小さなマトリックスがあります。

• サイズ不一致/形状エラー
  テンソルが間違った形です。これは通常ノードグラフの問題です。リサイズがある枝で発生し、別の枝では発生しません。制御入力は異なるスケールを期待しています。次元がどこで発散するかを追跡します。

• KeyError/欠落state_dictキー
  重みノードの不一致。リストされた欠落キーをモデルREADMEと比較します。間違ったチェックポイントバリアントまたは廃止されたノード。

• AttributeError：‘NoneType’…
  前のノードは何も返しませんでした。グラフをそのノードまでだけ実行します。最初のNoneが実際の犯人です。

役に立った2つの習慣：

• デバッグ中に短いクリップを実行します。10秒の障害ログは、1分の沈黙ほど時間を浪費しません。
• 疑わしいノードで利用可能なデバッグ/詳細トグルを有効にします。推測を打つより余分なコンテキストが優れています。

プロジェクトフォルダに小さな「環境カード」を保ちます。GPUモデルとVRAM、ドライバー、CUDA、PyTorch、ComfyUIコミット、ノードパックバージョン、およびLTX-2チェックポイントハッシュ。何かが壊れるとき、モデルを責める前に、先週のカードと比較します。

クラウドに切り替える時（WaveSpeedトラブルシューティング近道）

私はLTX-2のためにクラウドに急いでいきません。「私のマシンの気分」から実際の問題を分離するための最も清潔な方法である瞬間があります。

いつ切り替えるか

• VRAM 16 GB未満で、重い妥協なしに1024pの出力が必要です。
• 私はローカルCUDA/ドライバーバージョンに関連する不安定なクラッシュを見ており、再構築する時間がありません。
• 第二の意見が必要です。同じグラフ、異なるハードウェア。

WaveSpeed（または同等のGPUワークスペース）で何をするか

• 既知の良いイメージを選択（ドキュメント化されたCUDA/PyTorchコンボ）。デバッグするときは、生のTFLOPSより重要です。
• 最小限のグラフ、正確なLTX-2の重み（ハッシュ付き）、および1つの短いテストプロンプトのみを同期します。
• 最小限の再現可能なケースを最初に実行します。それがクラウドで機能し、ローカルで機能しない場合、それはおそらく環境です。両方で失敗した場合、グラフまたは重みです。

コストとトレードオフ

• はい、計算費がかかります。しかし、1つの清潔な再現は午後のドライバールーレットを節約することができます。
• クラウドディスクはパス問題を隠すこともできます。ただし、異なる方法で。パスを短くAsciiのまま保ちます。

これはワークフローを移動するためのプッシュではありません。詰まっていて、締め切りがあなたの忍耐より大きいときの静かな近道です。

私たちはWaveSpeedを、ちょうどこのような瞬間のために構築しました。これはクリーンなGPU環境を必要とするときです。LTX-2のデバッグに詰まっている場合、WaveSpeedここで試すことができます。

---

この週で最も狂ったLTX-2バグはどれですか？コメントをドロップして、それが新しい落とし穴かどうかを知らせてください。