這和光流插幀有什麼不同？

它不是在影格間扭曲像素，而是用 Wan2.1 VACE prior 在 latent 空間合成中間內容。這通常能帶來更穩定的身份一致性、在大幅遮擋變化時較少瑕疵，並且更符合你的文字提示詞或 LoRA 風格。

為什麼（Length − 1）必須能被 4 整除，且尺寸必須能被 16 整除？

VACE 轉場與 UNet 會在時間與空間上以 stride 對齊的區塊運作。使用 4n+1 的影格數（例如 5、9、13…）與可被 16 整除的尺寸，可確保取樣器與解碼器正確對齊，避免瑕疵與掉幀。

我該用 1.3B 還是 14B？支援哪些解析度？

VACE-1.3B 針對 480p 最佳化，運算負擔較低。VACE-14B 支援 480p 與 720p，通常能提供更好的細節與動作一致性。需要更高保真或 720p 時選 14B；資源有限或快速預覽則用 1.3B。

在這個工作流程中，LoRA 會如何影響品質與速度？

啟用 LoraLoader 後，你可以在降低 steps 的同時引導風格或動作。若使用 CausVid 風格 LoRA，可將 steps 設為 2–4、cfg ≈ 1.0；否則像是 20 steps、cfg ≈ 6.0 的預設通常表現良好。建議 LoRA 強度從 0.3–0.7 開始，以平衡引導效果與時間一致性。

Wan2.1 VACE 首尾幀 - ComfyUI 工作流

Wan2.1 VACE 首尾幀生成引入端點錨定的影片合成：你提供起始與結束幀，模型會在兩者間規劃時序連貫的過渡路徑。流程不是單純的光流插值，而是在潛空間中用 Wan2.1 的 VACE prior 合成中間內容，並可用提示詞與選配 LoRA 導引。這樣能在整個序列中維持主體穩定、風格連貫與合理動作規劃。

在 ComfyUI，流程結合 WanVaceToVideo、ModelSamplingSD3 設定檔、KSampler，並嚴格規範幀數與尺寸：空間尺寸須為 16 的倍數，總幀數需符合 4n+1 規則（Length − 1 可被 4 整除）。這種結構加上 TrimVideoLatent 可精確控制片段長度，確保過渡平滑且可控。14B 模型支援乾淨的 480p 與 720p，輕量 1.3B 則優化於 480p。若用 LoRA（如 CausVid），可大幅減少取樣步數並維持時序一致性。

API

從程式碼使用此工作流

每個 Comfy 工作流都是一個 JSON 圖。下方的 payload 就是此工作流，與 ComfyUI 執行時完全相同 — 你可以從此 URL 取得、放入版本控制，或在 ComfyUI 載入並逐節點執行。

video_wan_vace_flf2v.json

正在取得工作流 JSON…

使用 Comfy SDK 以 TypeScript 或 Python 執行。相同程式碼可用於 Comfy Cloud 或你自架的 ComfyUI — 只需更改 base URL。

// Install (beta)
npm i @comfyorg/sdk

// Run "Wan2.1 VACE 首尾幀" (TypeScript)
import { Comfy } from "@comfyorg/sdk";

const client = new Comfy({ apiKey: "comfyui-..." });

// This workflow, exported in API format (see note below)
const wf = await client.workflows.fromFile("video_wan_vace_flf2v_api.json");

const asset = client.assets.fromFile("input.png");
wf.setInput("147", "image", asset);  // LoadImage

const job = await client.run(wf);
await job.getOutputs("69")[0].toFile("output.png");  // SaveVideo

SDK 需使用 API 格式的工作流：請在 ComfyUI 開啟此工作流，並使用檔案 → 匯出工作流（API）。

Comfy Cloud API 存取需有 API 金鑰的方案。

SDK 文件取得 API 金鑰

常見問題