Appearance
快了 2.6 倍，然後我發現自己量錯了兩次
MiniMax H3 的 8 步加速實測、兩個文件上查不到的坑，和一個我公開收回的畫質結論
作者：Ray 日期：2026 年 9 月 2 日
8 月底，MiniMax H3 多了一個官方的加速方案：alibaba-pai 放出 PDD 蒸餾 LoRA，而且有 Ref2VA 專屬檔——20 步變 8 步。
我在 RunPod 上自架 H3 拍一部連載短劇，一集 22 顆鏡頭，全部 20 步跑要四個多小時。如果這東西是真的，那是一個晚上跟兩個晚上的差別。
我花了一個晚上把它接起來、量了兩組對照。
結論是值得接。但那個晚上真正花掉時間的不是接線，是搞清楚我量到的數字算不算數。
先講結果
同一個鏡頭、同一顆種子、同一組參考圖，只換取樣路徑：
192 影格（8.0 秒），768 × 1376，Ref2VA
20 步 res_multistep 683.87 秒 3.56 秒／影格
8 步 euler ＋ PDD Acc 262.09 秒 1.37 秒／影格
─────────────────────────────────────────
快 2.6 倍一集 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 步的大臉縮小——
那個縮放本身就會製造「一個糊、一個平滑」的假象。
我拿著一組被自己的前處理污染的圖，寫了一段看起來很專業的觀察。直到我把兩支原始影片並排給人看，得到的回答是：
其實我看不大出來差別。
在沒有乾淨對照的情況下，直接看原片的判斷比我的裁切比對可信。
要真的測畫質，得拿到景別相同的兩版。但同種子在不同取樣路徑下走位就是會變——所以這個對照可能根本做不出來。
與其追一個做不出來的對照，不如直接用，出問題再說。
唯一可以確定的代價：走位會變
這一項量兩次都一樣，而且它比畫質重要：
同種子、同參考圖、同提示詞，只換取樣路徑
→ 構圖、景別、人物走位【都會不一樣】第一支測試裡加速版景別變寬、人變小；第二支裡角色多做了一個拱手的動作、鏡頭更近。
實務上的意思是：
⛔ 不能把 8 步版當成 20 步版「同一顆的另一版」來剪
⭐ 決定用幾步之後就固定，不要中途換如果你已經拍了半集 20 步，中途換成 8 步，那半集的構圖邏輯會斷掉。
我原本最擔心的事沒有發生
在跑之前，我最怕的不是畫質，是表演。
我之前實測過一次：同一份精確到 0.1 秒、有九個節拍的表情腳本，跑 226 影格全中，跑 362 影格全部跳過——臉從平靜直接跳到大笑，中間的微表情一格都沒有。
蒸餾把 20 步砍成 8 步，看起來就是同一類的風險：細微的臉部運動會不會被一起磨掉？
所以我特別設計了一顆測試鏡頭，要的是「真心的笑」——眼睛先笑（下眼瞼上推、眼尾細紋），嘴角半秒之後才跟上。那個順序寫錯就變成社交假笑，是這類戲最挑剔的動作。
兩版跑出來：
✅ 笑容有出現 兩版同一個時間點都是閉唇的溫和微笑
✅ 眼睛有瞇起 兩版後段都看得到下眼瞼上推
✅ 臉不是死的 跟 362 影格那次完全不同8 步做得到表情。
⚪ 至於「眼睛先、嘴角後」那個順序有沒有精確執行——我測了兩版都沒有乾淨成立，但那是我的分鏡設計問題（鞠躬的動作把轉變遮住了），不是步數的問題。那是另一篇的事。
所以
接起來的成本：一個晚上，其中三分之二花在確認數字。文件上查不到的坑有兩個，這篇都寫了。
買到的東西：一集從 4.2 小時變 1.6 小時。
我的用法：預設全部 8 步。**看不出差別，就不要為它付四倍的時間。**真的有哪一顆出來覺得糊，那一顆單獨用 20 步重跑就好——每顆是獨立生成，沒有綁定成本。
如果只能帶走一句：不是「8 步很好用」，是
你量到的第一個數字，通常包含一個你沒注意到的東西。
我這次是首次載入。上一次是我把別的工作排進同一張卡。再上一次是我用被自己縮放污染的圖去比畫質。
自架真正買到的，是這些錯誤會當場現形。 在 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 連結為推薦連結，透過它註冊我會獲得少量回饋，不影響你的價格。