把一支影片的生成時間從 80 秒壓到 43 秒：每一個試過的做法與實測數字
這篇把加速的過程完整寫出來：先量什麼、發現瓶頸在哪、改了哪三件事、各自省下多少，以及哪些聽起來合理的做法我們沒有做、為什麼。
2026-08-20 作者 William Hsu
先量，再改
這個模型有取樣步數可以調，直覺會說把步數降下來就快了。量過之後不是這樣。
ComfyUI 執行時會透過 websocket 逐節點回報進度，我把一支 3 秒影片的每個階段時間記下來：
| 階段 | 耗時 |
|---|---|
| 解讀照片內容（文字／影像編碼器） | 約 17.7 秒 |
| 取樣（真正讓照片動起來的那一步） | 約 11 秒 |
| VAE 解碼（把結果沖洗成畫面） | 約 11.4 秒 |
| 其餘 | 把模型權重搬進顯示卡 |
取樣只佔四分之一左右，降步數能省的有限。
瓶頸是 30GB 的模型要塞進 16GB 的顯示卡
顯示卡是 RTX 5070 Ti，16 GB 顯示記憶體。這套模型光是文字編碼器加上主模型就超過 30 GB， 塞不進去，所以每跑一次都得把權重串流進顯示卡。
花掉的時間是搬資料，不是計算。後面三個改動都是往「讓要搬的東西變小」這個方向做。
做法一：換小一號的文字編碼器
25.3 GB 換成 14.6 GB 的量化版本，一次少搬 10 GB 以上。三個做法裡這個效果最大。
量化理論上會掉畫質。我用同一組隨機種子跑前後對照，同樣的照片、同樣的動作、同樣的種子， 成品放在一起看不出差別。種子一定要固定，不然兩次結果本來就不一樣，比了也沒意義。
做法二：取樣從 6 步降到 4 步
看起來像偷工減料，但我用的加速 LoRA 本來就是為 4 步設計的。跑 6 步不會更好，只是多花時間。 這個參數是從別的設定沿用來的，跟現在的模型不匹配。
做法三：拿掉用不到的音訊解碼
這套模型的工作流裡帶了音訊解碼的節點。我們的成品是沒有聲音的循環短片， 那一整段運算的結果從頭到尾沒有人用。
沿用別人的工作流很容易留下這種東西。找的方法就是逐節點量測， 然後對每個花時間的節點問一句：它的輸出有被用到嗎。
結果
單張從 60～80 秒（最糟的情況到 137 秒）降到穩定的 42～45 秒。
變異數也收斂了，137 秒那種情況不再出現。對使用者來說差別是「每次都 43 秒」 對上「平均 60 秒但偶爾 137 秒」。
一個意外的佐證
後來做另一項測試時，同一組參數重複跑第二次只花了 17.2 秒， 因為 ComfyUI 把上一次的編碼結果快取住了，直接跳過那 17.7 秒。這正好對上前面那張時間表。
沒有做的事
- 把模型常駐在顯示記憶體裡 16 GB 裝不下 30 GB，硬體限制，只能換卡
- 更激進的量化 再往下壓，畫質開始看得出來。這個工具的重點是還認得出是同一個人， 不值得用畫質換那幾秒
- 換更小的 VAE 解碼器（例如 TAE 那類）那 11.4 秒還有壓縮空間，但要額外的節點， 畫質影響也要重新驗證。這條還在待辦清單上，沒做完就不會寫在這裡當成果
回頭看
三件事值得記下來。沒有逐節點量測的話，我會把時間花在降低取樣步數上，而那只佔四分之一。 顯示記憶體不夠的時候，瓶頸是搬資料，優化方向要跟著改成讓要搬的東西變小。 前後對照一定要固定隨機種子，否則分不清畫質的差異是來自改動還是來自隨機。