Internal Lab Note · Performance
縮短時間的可能
同一台 RTX 5090、同一個 MiniMax H3，兩天前跑一支 720P 15 秒要 32.8 分鐘，今天是 11.3 分鐘。 這份筆記把四個加速變因逐一單變因拆開量—— SageAttention、Spectrum 採樣加速器、步數、以及一個 ComfyUI 自己的記憶體問題—— 並記錄六次「看起來很合理卻被實測推翻」的推論。
成品先看
Output先講結論
TL;DR四個變因互不重疊，所以是乘法疊加，合計省 63%。
它們作用在完全不同的層：SageAttention 讓每一次 attention 更便宜、 Spectrum 減少 transformer 呼叫次數、降步數減少排程步數、 purge 解決的是 VAE 階段的記憶體飢餓。 沒有一個是在跟另一個搶同一塊時間。
| 變因 | 省下 | 對照條件 | 代價 |
|---|---|---|---|
| SageAttention | 36.4% | 480P／260 幀／20 步／無 Spectrum 307s → 195.3s |
啟動參數掛上即可，無畫質代價 |
| Spectrum 加速器 | 29.3% | 720P／362 幀／20 步／purge 開 1213.1s → 858.2s |
同 seed 不可重現；有聲音時音訊會被重寫 |
| 步數 20 → 14 | 21.2% | 720P／362 幀／有 Spectrum／purge 858.2s → 676.6s |
畫質下降，但比原生縮步小得多（見下） |
| VAE purge | 40.7% | 720P／362 幀／14 步 1140.8s → 676.6s |
下次要重載 UNet（63~95 秒） |
疊起來是這樣（以第一天 480P／260 幀／20 步／無加速的 307s 為基準）：
＋ SageAttention 195.3s −36.4%
＋ Spectrum（20 步） 145.7s −25.4%
＋ 降到 14 步 113.8s −21.4%
合計省 63%
變因一：SageAttention
36.4%
掛在 ComfyUI 的啟動參數上（--use-sage-attention），不是節點層的東西，
所以工作流裡看不到它，很容易在做對照時忘記它的存在。
| 條件 | 時間 | 差異 |
|---|---|---|
| 2026-08-03（未開） | 307 s | — |
| 2026-08-05（開啟） | 195.3 s | −36.4% |
這是四個變因裡最大的一塊，而且沒有畫質代價。它便宜到值得當成預設， 但也因為它藏在啟動參數裡，先前兩天的成本表沒有標註它的狀態—— 於是那張表在今天差點誤導我們兩次。
成本表一定要標測試條件，否則它會變成過期的記事紙。
一張只寫著「RTX 5090 / 480P / steps 20 實測」的表，看起來完整， 卻沒有記下 SageAttention、取樣器、模式。條件沒寫下來的數字， 在條件改變的那一天會安靜地開始說謊。
變因二：Spectrum 採樣加速器
25.8%ComfyUI-Spectrum-MiniMax-H3 掛在原生 H3 上，用 Chebyshev ridge 擬合 transformer 之後的 hidden feature， 在部分 solver step 用預測取代實算。20 步的排程只實際呼叫 14 次 transformer。
| 條件 | 總時間 | 採樣 | s/it |
|---|---|---|---|
| 無 Spectrum | 1213.1s | 956s | 47.83 |
| 有 Spectrum | 858.2s | 713s | 35.66 |
| 差異 | −29.3% | −25.4% | −25.4% |
理論值是 30%（20 步扣掉 6 步預測）。實測採樣階段省 25.4%， 差的 4.6 個百分點就是 forecast 本身的開銷——預測不是免費的，只是很便宜。 專案 README 標示「30% transformer-step reduction」，數字對得上。 總時間省得更多（29.3%），因為 VAE 那段兩邊一樣長，分母被拉大後比例反而更好看—— 這也提醒了：報加速比例時要講清楚分母是什麼。
它在 log 裡留下了一個很好認的指紋。
開 Spectrum 那次的 s/it 在 6.73 ~ 91.49 之間跳， 因為 actual 步（約 90 秒）與 forecast 步（約 6.7 秒）交錯，tqdm 顯示的是移動平均； 不開的那次從頭到尾是穩定單值。 要確認加速器有沒有真的在工作，看 s/it 的抖動比看平均數可靠。
但它的價值不在「省時間」，而在同樣的計算成本下畫質損失比較小：
| 跑法 | 時間 | SSIM |
|---|---|---|
| 原生 20 步（基準） | 208.2s | 1.000 |
| Spectrum 20 步（實算 14 次） | 186.6s | 0.9348 |
| 原生 14 步（同樣算 14 次） | 183.9s | 0.7769 |
| 原生 13 步 | 181.4s | 0.7071 |
付一樣多的 transformer 呼叫，Spectrum 的畫質明顯高一截。 拿它跟「原生跑滿」比速度會低估它；正確的對照組是同計算成本的原生縮步。
但這條的前提是「音訊要跟外部參考音硬對齊」，也就是 TTS 精確對嘴模式。 聲線範本模式（模型自己說新台詞）不受此限——音訊本來就是模型生的， 被重寫之後仍然是模型生的，沒有「對不上外部音檔」這回事。
另外低步數時它的施展空間會被壓縮：20 步能預測 6 步，14 步只剩 3 步。
| 條件 | ASR 相似度 | 削波 | 嘴型 |
|---|---|---|---|
| 無 Spectrum（對照組） | 0.972 | 0 | 正常開合、露齒 |
| 有 Spectrum（首次測試） | 0.972 | 1 | 正常開合、露齒 |
| 有 Spectrum（嚴格對照） | 1.000 | 0 | 正常開合、露齒 |
相似度一模一樣，連 ASR 的錯誤形狀都相同。
兩支都把同一句台詞聽成加引號的版本，所以檢查工具跳的
長度比 1.058 警報兩邊都會跳——那是 ASR 的標點習慣，
跟加速器無關。指標報警時先確認它的前提還成不成立，
這個工具的判準原本是為了抓 TTS 爆音而設計的。
結論：fastmode 不再只限純動作片。有對白只要走聲線範本模式， 一樣吃得到那 63%。
重做的方式是：把對照組實際送出的那份 graph 從
/history/{prompt_id} 撈回來，
只改掛上加速器的那兩條線，並改用對照組實際用過的參考圖與參考音檔。
這一次才是真的只差加速器。
對話類影片的偏離，比動作片小得多。
加速器的官方說明寫著「快速或短暫的動作會偏離軌跡」，
本文前面那組 124 幀動作片的 SSIM 也確實掉到 0.9348。
但這支單人說話、動作簡單的片子，嚴格對照下畫面幾乎沒有差別。
偏離程度取決於畫面裡有多少快速動作，不是取決於有沒有開加速器。
所以對話類影片是它最安全的應用場景之一——這跟我們原本的直覺相反。
首次測試那支出現的服裝結構錯誤（裙子接在胸線上）， 在嚴格對照裡沒有出現 → 那是參考素材不同造成的，與加速器無關。
變因三：步數
21.2%20 步降到 14 步，其他全部固定（720P／362 幀／同 seed／Spectrum 開／purge 開）， 連提示詞改寫都不影響時間——提示詞不參與計算量，所以修劇情可以搭便車。
| 步數 | 總時間 | 採樣 | VAE | 實算／預測 |
|---|---|---|---|---|
| 20 | 858.2s | 713s | 145.2s | 14 / 6 |
| 14 | 676.6s | 548s | 128.6s | 11 / 3 |
有一個對照很漂亮：採樣時間比 1.301、實算次數比 1.273（14 次 vs 11 次）， 兩者幾乎重合。時間跟著「實際 transformer 呼叫次數」走，不是跟著「步數」走。
變因四：一個 ComfyUI 的記憶體問題
40.7%同一支工作流，兩次執行差了 464 秒。 拆開看，慢的那次不是採樣慢，是 VAE 解碼從 2 分鐘變成 9~10 分鐘。
log 每一輪都寫著同一行：
[INFO] Model MiniMaxH3VideoVAE prepared for dynamic VRAM loading. 4965MB Staged.
[INFO] 0 models unloaded.
採樣結束、UNet 的活全幹完了，ComfyUI 一個模型都沒卸。 那 19995MB 的 H3 UNet 原封不動佔著 VRAM，而 VAE 解碼完全用不到它—— 於是 VideoVAE 只能拿剩下的空間做 dynamic loading，把 4965MB 硬擠進去。
解法是在 SamplerCustomAdvanced 與兩個 VAEDecode 之間插一個
VRAM_Debug（KJNodes），latent 從 any_input 穿過去：
VRAMdebug: free memory after: 30.01 GB
VRAMdebug: freed memory: 23.80 GB （耗時 6 秒）
| 條件 | 總時間 | 採樣 | VAE |
|---|---|---|---|
| 無 purge | 1140.8s | ~9 分 | 9~10 分 |
| 有 purge | 676.6s | 9.1 分 | 2.1 分 |
| 另一支剛好沒卡的 | 694.7s | 9.6 分 | 2.0 分 |
這是偶發的，不是可預測的規律。
採樣完只剩約 6GB 時，VAE 擠不擠得下是碰運氣——擠得下 2 分鐘， 擠不下多花八分鐘搬資料。purge 把碰運氣變成一定夠。
不要花力氣找「誰有罪」。我們先後歸因給「參考圖尺寸讓採樣變慢」和 「參考圖尺寸讓 VAE 變慢」，兩次都被實測推翻（三張參考圖那支反而快 45%）。 ComfyUI 生態裡有五十幾個記憶體清理節點，這件事的普遍性寫在工具的數量上。
取捨非常不對稱，所以預設偏向 purge：
| 情境 | 做法 | 理由 |
|---|---|---|
| 連續生成多支短片 | 不 purge | UNet 常駐，每支省 63~95 秒重載 |
| 長片（≥15 秒／720P） | 一定 purge | 1 分鐘重載換 6~8 分鐘卡頓 |
| 不確定 | purge | 輸只輸 1 分鐘，贏能贏 6 分鐘 |
六次被推翻的推論
Method這份筆記真正的成本不是 GPU 時間，是六次看起來很合理、數據也支持、 結果全錯的推論。它們的形狀一模一樣：拿一個解釋力很強的模型去套數字， 卻沒有先確認那個模型的前提成不成立。
- 「直接減步數比加速器划算」——時間確實差不多，但畫質從 0.935 崩到 0.777。 比較速度時忘了另一軸。
- 「固定成本 130 秒、採樣優化天花板 37.6%」——用 20/14/13 三個點擬合直線， 回代誤差全部小於 1 秒。但三點擬合兩參數，貼合是必然。 跑一個區間外的 6 步去外插，模型預測 153.4s、實測 141.2s，假設當場崩掉。
- 「模型總量 39.55GB 塞不進 31.8GB，所以一直換入換出」——
log 裡寫著
current: cpu，text encoder 根本不在 VRAM； 而且每輪都是0 models unloaded。反證一直印在畫面上，我沒讀。 - 「參考圖尺寸讓採樣變慢」——採樣只差 1 分鐘，差的是 VAE 那 6 分鐘。
- 「超線性懲罰變小了（×3.32→×2.02）」——拿今天的 720P 比昨天的 480P， 把 SageAttention 的功勞算到超線性頭上。用同一天的數字重算是 ×3.18。
- 「Spectrum 省 15%」——用不同幀數線性外推。 同一支影片的 260 幀每幀 2.104s、294 幀每幀 2.218s，差 17%， 外推出來的數字全是垃圾。
從這六次裡長出來的四條規矩：
① 擬合誤差小 ≠ 模型正確，一定要用區間外的點外插驗證。
② 指標算出壞消息時，先檢查指標本身——那個 0.385 量的是「與參考音的相符度」，
只有硬對齊模式才有意義。
③ 有實測數字時不要用外推，尤其在超線性系統裡。
④ 規則要連前提一起記：「有對白 → 10 秒內」的前提是「用 TTS 精確對齊」；
換成聲線範本模式後前提消失，規則卻還在執行。
怎麼照做
Reproduce上面那些百分比不是本文的重點，能自己量到才是。 這節把三個變因的取得、安裝、接線、以及「怎麼確認它真的生效」全部寫出來。 前提：你已經能在本地跑起 MiniMax H3（配置見 前篇）。
① SageAttention −36%
這是啟動參數，不是節點——工作流裡看不到它，最容易被漏掉。
.\python_embeded\python.exe -m pip install sageattention
# 2. 啟動時加參數（改你的 run_nvidia_gpu.bat）
.\python_embeded\python.exe -s ComfyUI\main.py --windows-standalone-build --use-sage-attention
--use-sage-attention、一個沒有——
跑同一個工作流比較。本文那 36.4% 就是這樣量的（480P／260 幀／20 步，其餘全部固定）。
不要只看啟動 log，載入訊息不保證它在採樣時真的被用上。
② Spectrum 加速器 −29%
cd ComfyUI\custom_nodes
git clone https://github.com/xmarre/ComfyUI-Spectrum-MiniMax-H3.git
# 重啟 ComfyUI
節點名稱 Spectrum Apply MiniMax H3，在 sampling/spectrum 分類下。
接法是把它插在 UNet 與取樣之間，MODEL 穿過去：
└──→ BasicScheduler.model
| 參數 | 值 | 說明 |
|---|---|---|
| 全部參數 | 維持預設 | blend_weight 0.5／degree 4／warmup_steps 5⋯ 官方保守設定，本文數據就是用預設量的 |
debug | 改成 True | 唯一要改的。不開就無法確認它有沒有生效 |
history_storage | system_ram | 放 RAM，別跟 latent 搶 VRAM |
Euler、RES multistep、RES multistep CFG++。
ancestral 系列會靜默走回原生——不報錯、不提示，你會以為「這節點沒用」。2. ComfyUI 太舊：需要 2026-08-03 的 commit
e377e263 之後的版本。
（實測 08-02 的版本也能跑，因為它檢查的是 API 屬性而非 commit hash，但那是未驗證區間。）3. 步數太低：warmup 佔前 5 步、RES 又強制保留最後 3 步原生， 14 步只剩 3 步能預測。步數越低它能幫的忙越少。
debug 之後，console 每次跑完會印一行總結：
fallbacks=0 是關鍵——不是 0 就代表它中途退回原生了。另一個更直覺的指紋：看 s/it 的抖動。有生效時它會在 6~91 秒之間跳（實算步與預測步交錯， tqdm 顯示的是移動平均）；沒生效時是穩定單值。
③ 採樣完 purge VRAM 最多 −40%
需要 ComfyUI-KJNodes
的 VRAM_Debug（KJNodes/memory 分類）。
把它卡在取樣與解碼之間，latent 從 any_input 穿過去：
└──→ VAEDecodeAudio.samples
參數： empty_cache=True gc_collect=True unload_all_models=True
VRAMdebug: free memory after: 30.01 GB
VRAMdebug: freed memory: 23.80 GB
完整接線（把三項都加上去的樣子）
└→ BasicScheduler ─┤
CLIPLoader ─┐ ├→ SamplerCustomAdvanced
VAELoader ──┼→ MiniMaxH3ReferenceToVideo ──────────────┘ │
LoadImage ──┘ （ref_images 可接多張） ↓
VRAM_Debug
│
┌───────────────┴──────────────┐
VAEDecode VAEDecodeAudio
└──────→ CreateVideo ←────────┘
↓
SaveVideo
最高效能的設定，取決於你在拍什麼——先看下一節的分流表。
純動作片可以三項全開＋14 步；有對白就要跑滿 20 步， 而且能不能開 Spectrum 取決於你用哪種音訊模式。 沒有一組設定適合所有情況，這也是為什麼本文每個數字都標了對照條件。
現在的產線
Pipeline用今天測到的係數重排 30 秒成品的時程：
| 階段 | 時間 | 備註 |
|---|---|---|
| 生成 ×2 段（20 步＋Spectrum＋purge） | 28.6 分 | 有對白就跑滿 20 步 |
| RTX Super Res → 1080P | 1.7 分 | 40~50 秒／支，幾乎免費 |
| ForcedAligner 字幕 | ~1 分 | 逐段真對齊 |
| 合計 | 約 31 分 | 第一天的推估是 43 分 |
| 你要拍的 | 怎麼跑 | 備註 |
|---|---|---|
| 純動作、無對白 | 14 步 ＋ Spectrum ＋ purge | 15.08 秒單段沒問題 |
| 有對白（預設走這條） | 聲線範本模式、20 步、可開 Spectrum | 長度不受 10 秒限制，準確度 1.000 |
| 有對白・要一字不差 （人名／日期／數字） |
TTS 硬對齊、20 步、不開 Spectrum | 切 10 秒一段；非必要不用 |
| 唱歌 | 不要用這個模型 | 見下 |
說話這件事，已經可以幾乎完全放棄 TTS 硬對齊了。
聲線範本模式沒有長度綁定、沒有 TTS 爆音風險、可以開加速器， 而內容準確度在配方齊全時是 1.000。 硬對齊只剩「台詞必須一字不差」這一個理由還站得住。
唱歌是另一回事：歌不能讓模型自己重唱（旋律會跑掉）， 所以只能走硬對齊；而硬對齊又受 10 秒限制，一首歌要切成一堆碎段， 接縫多、漂移累積。這個用途應該回去用分段錨定的舊管線—— 每一段各自錨定一張乾淨參考圖、段長依樂句切而不是均分， 抗漂移抗 morph。H3 在唱歌這件事上沒有優勢。
Reproducibility
環境
RTX 5090（31.8GB）／ComfyUI 0.30.0 本地／--cuda-malloc --use-sage-attention／
取樣器 res_multistep／模型 minimax_h3_fl2va 與
minimax_h3_ref2va（int8）／文字編碼器 qwen3vl_32b（在 CPU）／
2026-08-05 同日測得。
所有百分比皆為單變因對照。跨硬體與跨 ComfyUI 版本不保證可複製， 但控制變因的設計與各項 Pitfall 應該可以移轉。 SageAttention 那一項的舊值取自 2026-08-03 的實測，當時未開啟該參數。