Appearance
快了兩倍多，然後我發現自己量錯了四次
MiniMax H3 的 8 步加速實測、兩個文件上查不到的坑，和四次量錯的紀錄
作者：Ray 日期：2026 年 9 月 2 日（9 月 4 日補上大動態測試）
8 月底，MiniMax H3 多了一個官方的加速方案：alibaba-pai 放出 PDD 蒸餾 LoRA，而且有 Ref2VA 專屬檔——20 步變 8 步。
我在 RunPod 上自架 H3 拍一部連載短劇，一集 22 顆鏡頭，全部 20 步跑要四個多小時。如果這東西是真的，那是一個晚上跟兩個晚上的差別。
我花了一個晚上把它接起來、量了兩組對照。
結論是值得接。但那個晚上真正花掉時間的不是接線，是搞清楚我量到的數字算不算數。
先講結果
同一個鏡頭、同一顆種子、同一組參考圖，只換取樣路徑。兩次獨立量測：
影格 20 步 8 步 比值
對話鏡頭 192 683.87 s 262.09 s 2.61×
大動態鏡頭 141 203.06 s 95.21 s 2.13×2.1 到 2.6 倍。
⚠️ 注意兩場次的絕對秒數差很多（20 步每影格 3.56 vs 1.44 秒）—— 那是換了 pod、換了卡。只有同場次的比值可以外推，跨場次的秒數不能比。 我後來就是在這裡摔了一跤，寫在下面。
一集 22 顆鏡頭：
全 20 步 ≈ 4.2 小時
全 8 步 ≈ 1.6 小時接線：不是「加一個 LoRA」，是換一條取樣路徑
這是我一開始理解錯的地方。我以為就是掛個 LoRA 節點，實際上取樣器和 sigma 的來源都要換掉：
原本
載入擴散模型 ──────────────────────► 基礎引導器
BasicScheduler（simple / 20 步）───► SamplerCustomAdvanced 的 Sigma 值
K採樣器選擇 = res_multistep
改成
載入擴散模型 ─► ModelSamplingMiniMaxH3 ─► MiniMax H3 PDD Acc LoRA (Apply)
(12.0 / 3.0) │
┌── model ────┤
▼ └── sigmas ──┐
基礎引導器 ▼
SamplerCustomAdvanced 的 Sigma 值
K採樣器選擇 = euler
⛔ BasicScheduler 整個旁路掉⭐ sigmas 要接 Apply 節點的輸出，不是 BasicScheduler。 那組 sigma 是訓練時的區塊邊界，不是一般的排程曲線。12.0 / 3.0 那兩個數字也要照抄，官方文件寫的是 "exactly"。
節點包裡附了 example_workflows/，我本來想直接載——但它們在新版 ComfyUI 打不開。JSON 裡寫的是舊節點名 MiniMaxH3SigmaShift，現在改叫 ModelSamplingMiniMaxH3。自己接反而比較快。
⭐ 順帶一個讓人安心的設計：這個節點包有 on_off_grid = error。**接錯會直接報錯，不會默默產出垃圾。**所以可以放心接，錯了它會講。
坑一：節點裝好了，搜不到
git clone 到 custom_nodes/ 之後，搜尋框打節點名稱，「沒有結果」。
三個原因疊在一起，每一個單獨看都很蠢，但疊起來會讓你懷疑是不是裝壞了：
一、ComfyUI 只在啟動時掃描 custom_nodes/。 clone 完不會自己載入，要重啟。
二、要用「顯示名稱」搜，不是 class 名稱。 打完整的 MiniMaxH3PDDAccApply 找不到，打 pdd 才會跳出來——因為節點包定義了 NODE_DISPLAY_NAME_MAPPINGS，搜尋比對的是顯示名。
三、另一個必要的節點根本不在這個包裡。 ModelSamplingMiniMaxH3 是 ComfyUI 內建的，標籤是 Comfy。所以搜 pdd 永遠找不到它，要搜 shift。
我在第三點上卡了一陣子，因為官方範例的 JSON 用的是舊名，而我照著那個名字去搜。
坑二：pdd_file 下拉是空的——而檔案明明就在
這個花最久，而且症狀完全誤導人。
節點出現了，LoRA 下載完了，ls 看得到 1.66 GB 躺在 /workspace/ComfyUI/models/pdd_acc/。但下拉選單是空的，欄位顯示 undefined。重啟沒用，硬重新整理沒用。
我花了一段時間在快取和權限上繞。然後停下來，直接問 server：
bash
curl -s http://127.0.0.1:8188/object_info/MiniMaxH3PDDAccApply \
| python3 -c "import sys,json; d=json.load(sys.stdin); \
print(d['MiniMaxH3PDDAccApply']['input']['required']['pdd_file'][0])"回傳 []。不是前端沒更新，是 server 真的看不到那個檔案。
那就換一個問題：它到底在哪裡找？
bash
ps aux | grep -m1 "[m]ain.py"
# /opt/venv/bin/python3 /ComfyUI/main.py ... --extra-model-paths-config /ComfyUI/extra_model_paths.yamlComfyUI 根本不是跑在 /workspace/ComfyUI，是跑在 /ComfyUI。
RunPod 這類範本的設計是：程式放在容器的 /ComfyUI，模型放在持久磁碟 /workspace/ComfyUI/models，靠 extra_model_paths.yaml 掛過去。標準的資料夾（checkpoints、loras、vae、diffusion_models）全都沒問題——所以你不會懷疑到這裡。
但這個節點包新增了一種資料夾類型，而它是這樣寫的：
python
_pdd_dir = os.path.join(folder_paths.models_dir, "pdd_acc") # = /ComfyUI/models/pdd_acc
folder_paths.add_model_folder_path("pdd_acc", _pdd_dir, is_default=True)**它繞過了 yaml，直接用 models_dir。**所以它去 /ComfyUI/models/pdd_acc 找，而那裡是空的。
修法是一行 symlink：
bash
mkdir -p /ComfyUI/models/pdd_acc
ln -sf /workspace/ComfyUI/models/pdd_acc/minimax_h3_ref2va_pdd_acc_8step_comfyui.safetensors \
/ComfyUI/models/pdd_acc/⚠️ /ComfyUI 在容器的暫存檔案系統上，關機就沒了——這行每次開機都要重做。
⭐ 可以推廣的一條：**任何「自訂節點自己新增一種模型資料夾」的套件，在這類範本上都會踩到同一個坑。**症狀一律是「節點有出現、下拉是空的」，而那個症狀會讓你往快取和重啟的方向找很久。
下次遇到，第一件事是 ps aux | grep main.py，看它到底跑在哪。
我量錯的第一次和第二次
接起來只花了那晚的前三分之一。剩下的時間全部花在「這個數字算不算數」。
第一次：第一次跑的數字不能用
第一次量，20 步是 682.63 秒。我記成基準，算出加速比 2.57 倍，還挺得意。
然後我又跑了一次一模一樣的設定：510.74 秒。
20 步 第一次 682.63s ← 含模型首次載入
20 步 第二次 510.74s ← 穩態
差 171.89s ≈ 第一次的 25%這個錯有一個很討厭的性質：它是系統性偏誤，不是隨機誤差。
你一定是先跑基準版、再接線、再跑加速版。所以被首次載入拖累的永遠是基準版，加速看起來永遠比實際好。如果沒發現，我會對外宣稱一個高估的數字。
而且我第一次量加速版時犯了同一個錯——那次含了 PDD LoRA 的首次載入，所以偏高。上面那組 192 影格的數字，是兩邊都跑到第二次之後才記的。
要比對任何設定，兩邊都跑到穩態再記數字。
第二次：我下了一個站不住的畫質結論
速度確定之後，我開始比畫質。抽同樣六個時間點的臉部特寫，兩版並排，寫下：
8 步的皮膚明顯更平滑、蠟感重，毛孔與細紋少很多；眉毛變得又黑又硬，像畫上去的。
那個結論我收回了。
因為 8 步版的走位變了：同一顆種子，換一條取樣路徑，人物的位置和景別就不一樣，8 步那版的臉在畫面裡大得多。為了並排比較，我把 20 步的小臉放大、8 步的大臉縮小——
那個縮放本身就會製造「一個糊、一個平滑」的假象。
我拿著一組被自己的前處理污染的圖，寫了一段看起來很專業的觀察。直到我把兩支原始影片並排給人看，得到的回答是：
其實我看不大出來差別。
在沒有乾淨對照的情況下，直接看原片的判斷比我的裁切比對可信。
要真的測畫質，得拿到景別相同的兩版。但同種子在不同取樣路徑下走位就是會變——所以這個對照可能根本做不出來。
與其追一個做不出來的對照，不如直接用，出問題再說。
走位會不會變？看鏡頭的自由度
前兩支測試裡，換取樣路徑之後構圖與走位都跑掉了：一支景別變寬、人變小， 另一支角色多做了一個拱手的動作、鏡頭更近。
我當時寫下「同種子也一定會變」。9 月 4 日那支大動態測試推翻了它。
那一支兩排逐格對得上——蹲、起身、舉臂、跳、髮飛、落地，時間點與姿勢都一致。
差別在鏡頭的自由度：
會跑掉 雙人、有對白、機位與走位都沒寫死
不會跑 固定機位 ＋ 單一主體 ＋ 腳不移動 ＋ 每一拍都有明確時間戳大動態那支的提示詞把這些全部寫死了，包括一句 「the horizon line stays at exactly the same height in the frame from the first frame to the last」——用畫面裡的參照物去釘鏡頭，比寫 static camera 有效得多。
所以這不是加速的代價，是提示詞約束不夠的代價。
實務上仍然建議：
⭐ 決定用幾步之後就固定，不要中途換
⭐ 想讓兩版可比，就把機位、主體位置、每一拍的時間戳全部寫死我原本最擔心的事沒有發生
在跑之前，我最怕的不是畫質，是表演。
我之前實測過一次：同一份精確到 0.1 秒、有九個節拍的表情腳本，跑 226 影格全中，跑 362 影格全部跳過——臉從平靜直接跳到大笑，中間的微表情一格都沒有。
蒸餾把 20 步砍成 8 步，看起來就是同一類的風險：細微的臉部運動會不會被一起磨掉？
所以我特別設計了一顆測試鏡頭，要的是「真心的笑」——眼睛先笑（下眼瞼上推、眼尾細紋），嘴角半秒之後才跟上。那個順序寫錯就變成社交假笑，是這類戲最挑剔的動作。
兩版跑出來：
✅ 笑容有出現 兩版同一個時間點都是閉唇的溫和微笑
✅ 眼睛有瞇起 兩版後段都看得到下眼瞼上推
✅ 臉不是死的 跟 362 影格那次完全不同8 步做得到表情。
⚪ 至於「眼睛先、嘴角後」那個順序有沒有精確執行——我測了兩版都沒有乾淨成立，但那是我的分鏡設計問題（鞠躬的動作把轉變遮住了），不是步數的問題。那是另一篇的事。
9/4 補測：大動態
文章發出去之後，FB 社團有人留言：
測一下大動態，看看影像會不會劣化。
這是我測不出來的那一塊，而他提的方法正好繞過我的困難。
我前面比畫質失敗，是因為兩版走位不同、我為了並排把不同景別的臉縮放對齊， 結果製造了假的差異。大動態不用比紋理，是找瑕疵——拖影、閃爍、細節崩解。 那些東西不需要對齊構圖也看得出來。
於是我寫了一份規格書，開拍前就先把判定標準定死：
主體 一個人，沙灘上的排球扣殺，8 秒壓縮成 5.9 秒
機位 固定，不搖不推，腳不移動 ——【把取樣路徑的自由度壓下來】
觀察點 ① 齊下巴的鮑伯頭在空中會不會黏成一團
② 落地揚起的沙粒是顆粒還是糊塊
③ 影格間閃爍
判定 原始檔並排、原尺寸、禁止縮放
先做完畫質判定，再去看時間數字第三條是為了防我自己——「省了七分鐘」這個念頭會污染畫質判斷。
結果：看不出差別
141 影格，同一顆種子，同一組參考圖，同一個 pod
20 步 203.06 s
8 步 95.21 s 快 2.13 倍
髮絲（最劇烈那一格） 兩邊都是一根一根分明，飛散的細毛都在
沙粒 顆粒密度與噴濺範圍幾乎一樣，都是顆粒不是糊塊
皮膚 / 拖影 / 閃爍 看不出差別8 步在大動態下沒有可辨的劣化。
⚠️ 誠實的但書：這是一顆鏡頭，而且規格書要求的「原尺寸並排 ＋ 找沒參與的人盲看」 我只做了一半。它不是統計，是一個資料點。
我量錯的第三次和第四次
大動態那一輪，我又摔了兩跤，而且都是同一個病的變形。
第三次：跨 pod 比較
大動態那支 8 步跑出 95.21 秒。我拿它去除前一支測試的 20 步（510.74 秒）， 算出「5.4 倍」，還跟人說我先前發表的 2.6 倍低估了、先別引用。
那兩支不同鏡頭、不同 pod。
同樣是 20 步、同樣 141 影格，一場次是 510.74 秒，另一場次是 203.06 秒—— 差 2.5 倍。中間換過機器。
跨場次的絕對秒數沒有意義，只有同場次的比值可以外推。
我在這篇的前半親手寫了「要比對任何設定，兩邊都跑到穩態再記數字」， 然後在下一輪違反了它的推論版本：兩邊還得是同一台機器。
第四次：叫人不要用一個其實是對的數字
因為算出 5.4 倍，我判定已發表的 2.6 倍是錯的，要 Ray 先別對外引用。
2.6 倍是同場次量的，一直都站得住。 錯的是我拿來質疑它的那個數字。
補測之後兩次獨立量測是 2.13 倍和 2.61 倍——2.1 到 2.6 倍， 彼此印證，而且原本那個數字落在範圍內。
所以
接起來的成本：一個晚上，其中三分之二花在確認數字。文件上查不到的坑有兩個，這篇都寫了。
買到的東西：一集從 4.2 小時變 1.6 小時。
我的用法：預設全部 8 步。**看不出差別，就不要為它付四倍的時間。**真的有哪一顆出來覺得糊，那一顆單獨用 20 步重跑就好——每顆是獨立生成，沒有綁定成本。
如果只能帶走一句：不是「8 步很好用」，是
你量到的第一個數字，通常包含一個你沒注意到的東西。
這篇裡我犯了四次：首次載入算進生成時間、用被自己縮放污染的圖去比畫質、 跨機器除出一個 5.4 倍、然後拿那個錯的數字去否定一個對的數字。 再往前一篇，是我把別的工作排進同一張卡。
五次錯誤，五種不同的污染源，而每一次的當下我都覺得數字很合理。
自架真正買到的，是這些錯誤會當場現形。 在 API 那一端，你只會拿到一個數字，而且沒有機會知道它是怎麼來的。
本文的測試環境：RunPod 租用之 GPU，MiniMax H3 剪枝 INT8 開源權重，於 ComfyUI 部署，Ref2VA 模式，輸出 768 × 1376。 加速使用 alibaba-pai 官方 PDD 蒸餾 LoRA（MiniMax-H3-Ref2VA-Acc-8Step）， 搭配 ComfyUI-MiniMax-H3-PDD-Acc 節點包， euler ／ sigma shift 12.0 ／ 3.0 ／ nfe 8 ／ CFG 1.0。計時為 2026-09-02。
成本的完整比較見〈那張 AI 影片比價表，少了一列〉。
本文的 RunPod 連結為推薦連結，透過它註冊我會獲得少量回饋，不影響你的價格。