修復ComfyUI中的LTX-2錯誤：OOM、黑幀和閃爍解決方案

嘿，大家好，我是Dora。我本來沒打算調試ComfyUI中的LTX-2。一切源於一個微小的停頓：一個我運行過無數次的工作流之後，預覽窗口變黑了。沒有戲劇性的失敗。只是……什麼都沒有。我重試了，查看控制台，調整了幾個設置。到了本週末（測試時間：2026年1月6–10日），我已經收集了一些反覆出現的修復方案。這不是什麼宏偉的教程，更像是我會遞給也在試圖讓LTX-2乖乖聽話的朋友的筆記，而不是把早上變成驅動程式重裝。你知道，就是我們都太熟悉的那種無聲混亂。

60秒診斷（症狀→原因對應）

當LTX-2在ComfyUI中出現異常時，我發現快速模式匹配比盲目猜測更有效。這是我在做任何重大改動前會過一遍的60秒快速診斷表：

症狀：閃爍或幀間漂移
可能原因：不穩定的引導（CFG太高）、更改種子、過度強烈的運動設置。
快速嘗試：固定種子、降低CFG、調低運動/降噪，添加時間一致性步驟。

症狀：奇怪的色彩偏移、「雪花」或拉伸塊
可能原因：權重/版本不匹配、錯誤的VAE、損壞的快取或部分下載。
快速嘗試：重新驗證雜湊值、清除模型快取、確認VAE兼容性。

症狀：關於形狀或NoneType的節點錯誤
可能原因：某個節點未輸出（早期失敗）或不兼容的節點/模型版本。
快速嘗試：隔離故障分支、僅運行到該節點、查看ComfyUI控制台找出第一個真實錯誤行。如果命中其中一個，我就停下來。一次只改一個東西。然後我重新運行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通常能帶來最乾淨的記憶體節省。
混合精度可以接受，但我避免在運行中每個節點都切換。對重型部分使用一種精度。

3. 最後調整批次大小

將批次設置為1來進行視頻採樣。即使很小的批次也會在記憶體中增加關鍵激活。我只在快速潛在圖或預覽時增加批次。

我還注意到了一個細微的優勢：在調整OOM時鎖定種子。隨機性可能會掩蓋你的最後一個改動是否真的有幫助。

黑屏：模型加載vs解碼問題

我本週遇到的第一個黑屏實際上根本不是模型故障。這是一個解碼怪癖。

我如何快速區分這兩者

檢查文件大小和時長

如果視頻長度正確且大小符合預期，幀可能已經存在。你的播放器可能不喜歡像素格式或色彩空間。
用安全基線重新編碼： ffmpeg -i input.mp4 -pix_fmt yuv420p -c:v libx264 -crf 18 output.mp4
（更多編碼選項請參考FFmpeg文檔） 檢查ComfyUI控制台
真正的模型加載問題會自己顯露：缺少權重、不兼容的鍵或VAE/模型雜湊不匹配。
如果你看到成功的採樣日誌且沒有異常，這可能是顯示/編碼路徑的問題。

潛在維度不匹配

LTX-2管道期望特定的步幅（通常是16的倍數）。如果你的潛在圖或控制輸入不匹配，你可能會得到空白或接近黑色的幀。
我驗證任何調整大小節點發生在模型期望之前，所有分支都在寬度/高度上達成一致。

色彩範圍驚喜

完整範圍vs受限範圍在某些播放器中可能看起來被壓成黑色。快速重新編碼（上面的方法）通常能解決問題。

如果確實是模型加載問題，我會回到源頭：檢查加載器節點中的LTX-2檢查點路徑是否指向實際文件、確認校驗和、確保節點的預期權重格式（safetensors vs ckpt）與文件匹配。只有官方ComfyUI文檔和模型的README是我信任的版本/格式說明頁面。

閃爍修復：穩定性參數和提示詞錨定

閃爍並不總是一個bug。有時它是模型完全按照指示去做，自由度太高。

讓我東西穩定下來的方法：

固定種子
我在任何A/B測試中鎖定種子。它立即消除了一個滑溜的變數。
降低CFG
如果我處於8–9，我試試6。過度高的引導會將幀拉向不同的方向。
降噪和運動強度
這裡的輕微減少（10–20%）通常比增加步驟數幫助更大。我發現稍微降低降噪能更好地保留時間信號。
提示詞錨定
保持穩定的基礎提示詞，將更改移至小的、明確的部分（關鍵幀或簡短的括號注釋）。在幀之間更改整個句子會邀請漂移。
時間一致性傳遞
如果你的圖形有時間/一致性節點，輕輕運行它。它不會憑空產生細節，但可以磨去抖動。
採樣器選擇
我用相同的種子測試2–3個採樣器。某些在視頻上更跳躍。如果一個在相同步數下能平靜邊緣，我就保留它。

小提示：我停止追求「完美」的幀連貫性。我的目標是編輯時減少心理疲勞，得到能剪的東西，不是顯微鏡下的完美。

損壞的輸出：權重不匹配/路徑錯誤

損壞對我來說表現為粉紅色塊、閃閃發光的雪花或不符合提示詞的色帶。每次，都是些無聊的東西：

權重不匹配
加載器期望特定的LTX-2變體：我有一個名稱相似的不同變體。我現在在文件名中包含模型日期或雜湊值。
錯誤的VAE
隨意交換VAE給我帶來了麻煩。修復很簡單：使用LTX-2節點文檔或模型README中指定的VAE。如果沒有指定，默認使用捆綁的或圖形作者推薦的VAE。
部分下載
一個3–8 GB的檢查點在95%處失敗看起來在文件夾視圖中很完整。我會根據倉庫列表檢查文件大小，並在可用時驗證雜湊值。
路徑故障（特別是Windows）
非ASCII字符和非常長的路徑過去曾在我這裡破壞加載。相信我，我保持模型路徑簡短（例如D:\models\ltx2\…）並在可能時避免空格。
混合格式
safetensors vs .ckpt在某些節點中不可互換。我會匹配節點的預期。

當我懷疑損壞時，我用已知良好的微小提示詞在微小分辨率下重新運行。如果那很乾淨，我知道問題在我當前的組合中，而不是整個安裝。

日誌閱讀：哪個層出現了崩潰

我節省時間的大部分方法來自於閱讀第一條失敗行，而不是最後的戲劇性一行。ComfyUI的控制台如果你花30秒時間通常會告訴你足夠多的信息。

我尋找的東西：

CUDA記憶體不足
不是bug。如上所述減少分辨率/精度/批次。如果它在相同的步驟每次都失敗，你正在碰到特定的激活峰值，降低步驟或啟用記憶體高效注意力。
CUDNN_STATUS_EXECUTION_FAILED或非法記憶體訪問
通常是驅動程式或庫不匹配。我在文本文件中記錄我的CUDA、PyTorch和GPU驅動版本。如果我最近更新了其中一個，我會回滾或重建venv。ComfyUI文檔有一個已知良好組合的小矩陣。
大小不匹配/形狀錯誤
張量形狀錯誤。這通常是節點圖問題：調整大小發生在一個分支但不在另一個分支，或控制輸入期望不同的規模。我追蹤它們分歧的地方的維度。
KeyError/缺失state_dict鍵
權重–節點不匹配。將列出的缺失鍵與模型README進行比較。錯誤的檢查點變體或過時的節點。
AttributeError: ‘NoneType’ …
前面的節點沒有返回任何東西。我將圖形僅運行到該節點。第一個None是真正的罪魁禍首。