從 0 到放棄：一張 16GB 顯卡能不能拍中國短劇？我用 30 天告訴你答案
寫給：被「AI 一鍵生成電影」「家用 GPU 月入十萬」「ComfyUI 取代好萊塢」這種標題搖醒過、心癢癢想下海卻又怕踩坑的人。
答案：不能。先講結論
我知道你來這篇文章想看什麼。
你想看「我用 5060 Ti 跑出來的中國短劇大爆款」「30 集 100 萬點閱」「ComfyUI 全本地零成本」這種故事。
對不起，沒有。
從 2026-05-17 立項到 2026-06-04 認輸，我用了 18 天、跑了 17 個版本、燒了 1,200 度電、寫了 4 萬行 Python、開了 73 次 GitHub commit、收了 7 次用戶批評，最後寫下這個結論：
一張 NT$15,000 的 RTX 5060 Ti 16GB，不能本地生成一集能看的中國短劇。
如果你看到這裡準備關掉視窗，我懂。但請你再給我 5 分鐘。
因為我接下來要告訴你的，不是「我失敗了」這四個字，而是：
- 為什麼所有 YouTube 教學都沒告訴你這件事
- 哪些廠商行銷話術是真的、哪些是吹牛
- 如果你還是想做，2026 年真正能跑的方案是什麼（劇透：不在本地）
- 5 條決策建議，能幫你省下 30 天和 NT$15,000
我列 5 個沒辦法跨越的天花板，每一個都是 5060 Ti 16GB 的物理極限，不是 patch 一下就能解決：
天花板 1：Wan2.2 ti2v 5B 模型只能生成 81 幀 @ 24fps，也就是固定 3.375 秒。
這不是 bug，這是模型架構級限制。你想要一個 5 秒鏡頭？對不起做不到。你說 6 秒？做夢。Wan 2.2 14B 版本可以做更長，但載入要 38GB VRAM，你的 16GB 連 weight 都放不下，更別說 latent 和 KV cache。
天花板 2：第 30 幀以後人臉開始漂移。
5060 Ti 16GB 只能跑 5B 版本，而 5B 在跨幀 face consistency 上表現有限。第一秒主角是國字臉，第三秒變鵝蛋臉。你跨 shot 接起來，觀眾五秒就看出是 AI。
天花板 3：MuseTalk 對嘴上限是 256×256。
也就是說，主角的臉在你最終 720×1280 直式短劇畫面裡，最多只能佔 1/5 的面積。臉一旦大，對嘴就糊。升到 512×512 要 24GB VRAM。
天花板 4：Edge TTS 免費版的 SSML 只能調 ±20% 語速。
中國短劇要的是「快、狠、爆」，特別是衝突高潮。你想要男主吼一聲「你說什麼！」需要 +40% 語速 + 提高 30Hz pitch + boost 30% 音量。Edge TTS 給你 +20% 後就卡頓。
天花板 5：跨 shot 角色一致性，IPAdapter 推上 weight 1.5+ 就 ghosting。
這是模型物理盲區。蘇曉雯這個角色 30 集裡會出現 800 次，你做出來的 800 個鏡頭裡，至少 300 個觀眾會發現「她臉怎麼變了」。
這 5 個天花板加起來，給你一個殘酷的結論：
5060 Ti 16GB 跑得動 demo，但跑不動產品。
我把這 5 個天花板畫成一張 ASCII 圖，給你看「失敗的累積路徑」：
你的 5060 Ti 16GB
│
┌───────────┼───────────┐
│ │ │
天花板 1 天花板 2 天花板 3
Wan22 5B 第 30 幀後 MuseTalk
81 幀上限 人臉漂移 256² 上限
│ │ │
└───────────┼───────────┘
│
品質掉到 60 分
│
┌───────────┼───────────┐
│ │
天花板 4 天花板 5
Edge TTS 免費版 IPAdapter weight
SSML ±20% 上限 1.5+ ghosting
│ │
└───────────┬───────────┘
│
品質掉到 50 分以下
│
觀眾秒退
│
商業失敗
每一層天花板都是物理盲區，不是「再調 prompt」「再升一個版本」「再加一個 patch」能解決的。是要換硬體、換模型、或者換路線。
技術 demo 跟商業內容之間的距離，不是「再 fine-tune 一下」可以跨過的。是要換顯卡（24GB / 48GB 起跳）、換模型（14B 起跳）、或者乾脆換路線（上雲）。
如果你 2026 年看到任何一個 YouTube 影片說「家用 GPU 本地生成短劇」，請你做一件事：問他要 30 集連續 mp4，不要 demo 10 秒。
90% 的人交不出來。剩下 10% 交得出來的，幕後其實用了 Kling / Runway / Dreamina 補刀。
殘酷的事實：你聽過的「成功案例」幾乎都是混合方案——本地跑前期構圖 + 雲端跑最終影片。純本地產業級短劇在 2026 年的消費卡上，物理上不存在。
為什麼大家以為可以？2026 年 AI 影片宣傳的真相
你會點進這篇文章，代表你信過某些訊息源。我們來拆解一下這些訊息源到底在賣什麼。
Sora 2 的行銷影片，跟你能跑的是兩個世界
2026 年 Q1，OpenAI 發布 Sora 2，1080p / 60fps / 60 秒長片、物理引擎級別一致性、角色跨鏡頭穩定。發布會 demo 一片驚呼。
問題來了：Sora 2 跑在 OpenAI 自己的 H100 叢集上，單一影片背後是 8 張 H100 平行，每張 80GB HBM3，總 VRAM 640GB。
你的 5060 Ti 16GB 是這個叢集的 1/40。
但行銷影片不會告訴你這件事。他們會說「AI 影片進入新時代」。是的，他們的新時代，不是你的新時代。
Runway Gen-3、Kling 1.6、Dreamina 都是雲端服務
注意這三個產品的共通點：你打開瀏覽器、輸入 prompt、雲端 GPU 跑、跑完傳給你。你的本地顯卡只負責播放這部 mp4。
它們從來沒說過「在你電腦上本地生成」。但很多 KOL 在介紹時刻意省略這個關鍵字。結果觀眾以為「下載個軟體就能在自己電腦上跑出 Kling 一樣的品質」。
不是。Kling 跑在阿里雲的 A100 上，Runway 跑在 AWS H100 上。你的 5060 Ti 在物理層級上跑不出同樣品質。
ComfyUI YouTube 教學的關鍵省略
ComfyUI 是真的厲害的工具，沒有人能否認。但 YouTube 上「ComfyUI 5 分鐘生成電影級短劇」這類教學，幾乎都有以下三個關鍵省略：
省略 1：只演 demo 不演量產
教學影片給你看一個 5 秒鏡頭，剪輯精美。但你真的去跑同樣的工作流，會發現：
- 跑 10 次有 7 次崩潰（OOM / VRAM zombie / driver hang）
- 跑出來的 5 秒鏡頭裡，第 3 秒之後品質掉
- 接到下一個鏡頭，主角的臉變了
教學影片從來不演「我跑了 100 次選 1 個給你看」這件事。
省略 2：硬體規格藏在描述欄第 47 行
「我這個工作流可以跑出 Hollywood 級別品質」。然後在描述欄角落寫著「Test Rig: RTX 4090 + 64GB RAM」。
4090 是 24GB VRAM，比你的 5060 Ti 16GB 多 50%。這 50% 的差距是「能跑」和「不能跑」之間的差距。
省略 3：後製外掛沒講
很多 demo 影片其實是這樣產生的：
ComfyUI 跑出粗糙底片
↓
DaVinci Resolve 手動補色 + 補光
↓
Topaz Video AI 升解析度
↓
Adobe Audition 加 BGM + 補配音
↓
After Effects 加運鏡 + 字幕
↓
最終剪輯成「AI 一鍵生成」
整個流程裡 ComfyUI 只佔 30%。剩下 70% 是傳統影視後製。教學影片只給你看 ComfyUI 那 30%。
中國短劇市場規模放大了焦慮
2026 年中國短劇市場規模 504 億人民幣，超過電影院線票房。一集 5 分鐘，30 集為一部，平均成本 30-80 萬人民幣。
每天有上百部新短劇上線。每月有十幾部破千萬點閱。
這個數字會讓任何一個有點技術背景的人開始想：「如果我用 AI 把成本壓到零，是不是可以分一杯羹？」
答案是：可以分，但要分到雲端 API 那一杯（後面會講），不是本地那一杯。
殘酷的事實：2026 年 AI 影片技術的進步速度真的很快，但「本地能跑」這條曲線跟「雲端能跑」這條曲線的差距正在拉開，不是縮小。 H100 4 年漲了 5 倍 VRAM 密度，消費卡 4 年漲了不到 2 倍。
第一週：迷夢階段（v1.7 - v8）
時間：2026-05-17 ~ 2026-05-25。
主稿磚記載的時間軸從這天開始。我看了 YouTube 上一部叫《五十岁，我的人生刚刚开火》的中國短劇（YouTube ID：tGbbu3axuBE），50 歲女主蘇曉雯被丈夫外遇離婚 → 凈身出戶 → 偶遇護膚集團總裁 → 創業「曉之光」品牌 → 復仇商戰 → 大婚。
30 集 × 5 分鐘 = 2.5 小時。
我心想：「這種題材純對話 + 簡單場景，AI 應該很好做。」
我訂了 30 集大綱、寫了 13 角色卡、ep1 32 個 shots 全 FINAL 簽核。Phase 0 開跑。
v0 LoRA 訓練：第一個天花板出現
13 個角色每人要 30 張 anchor 圖。本來想用 Flux + LoRA 鎖角色。
第一個坑：HF FLUX.1-dev 跟 schnell 在 2026-05 之後全 gated，要 HF token。對於量產 workflow 來說，gated model 是地獄。
第二個坑：HuggingFace 的 ai-toolkit 路線要 HF token + LFS 巨大 weights，30GB 起跳。
第三個坑：ComfyUI-FluxTrainer 路線 5 連坑：
1. numpy 必須降到 1.26.4（跟 portable Py3.13 衝突）
2. transformers 必須降到 4.57.6（5.x 刪了 sd-scripts 要的 CLIPFeatureExtractor）
3. requirements 必須拿掉 numpy<=1.26.4 hard pin
4. Windows console 必須 chcp 65001 + PYTHONIOENCODING=utf-8
5. caption_dropout 不能設 0（會 NaN）
光是裝環境就花了 1.5 天。
裝完之後第四個坑來了：5060 Ti Flux LoRA 訓練速度。
cache miss 第一輪：197 秒/step
cache reuse 後輪：70 秒/step
30 step 一個角色：35 分鐘
100 step 一個角色：1 小時 50 分
13 個角色 × 100 step ≈ 24 小時
我把 PC 開了一天一夜，13 個角色裡完成 9 個，剩下 4 個被各種小坑卡住。
但這還算可以接受。我心想：「LoRA 是 anchor 圖，跑一次後續可以重用，這 24 小時是一次性成本。」
v1.7：GGUF 14B 的夢碎
LoRA 做到一半，我同步試 Wan2.2 14B 模型。為什麼要 14B？因為 5B 跑出來的影片，跨幀一致性差。如果想要主角的臉在 3 秒影片裡都長一樣，14B 是門檻。
但 14B 原版模型 38GB VRAM。我的 5060 Ti 只有 16GB。
於是試 GGUF 量化版本。HuggingFace 上有人放了 Wan22-I2V-14B-GGUF Q4_K_M 版本，model weight 壓縮到 10GB。
我心想：「10GB < 16GB，應該可以塞進去。」
ComfyUI-GGUF 裝好，工作流連好，按下 Queue。
第一步 VAE encode 還行。第二步 model forward 還行。第三步 VAE decode：
torch.cuda.OutOfMemoryError: CUDA out of memory.
Tried to allocate 8.42 GiB (GPU 0; 15.89 GiB total capacity;
12.47 GiB already allocated; 1.23 GiB free)
OOM 在最後一步 VAE decode。
原因：GGUF 量化只壓 model weight，但 latent space 還是 fp16、KV cache 全爆。10GB weight + 5GB activation + 3GB KV = 18GB，超過 16GB。
教訓：消費卡跑 14B i2v 是夢。要嘛 24GB 顯卡（4090 / 5090），要嘛回 5B。
我選擇回 5B。
v4-v6：Sniper Shot06 三代迭代
5B 跑出來的影片，第 30 幀後人臉漂移。怎麼辦？
我寫了一個 sniper 工作流：先用 Flux + LoRA 生成 anchor 圖鎖死角色 → 用 Wan22 5B 跑短影片 → 用 face swap + face restoration 把每一幀的臉復原回 anchor。
v4：Flux + ReActor face swap。
第一版工作流長這樣：
# v4 sniper workflow（pseudo）
anchor = flux_keyframe(prompt="bride in red wedding dress")
video = wan22_5b(image=anchor, prompt="bride turning around slowly")
for frame_idx, frame in enumerate(video):
swapped = reactor_face_swap(frame, source_face=anchor.face)
output[frame_idx] = swapped
結果：第 30 幀以後臉漂移，五官位置不對。看起來像主角戴了張不貼合的面具。
[失敗截圖：v04_wedding_face_drift.jpg]
注意截圖右半部，新娘轉頭那一刻，臉的整體輪廓還在，但五官的相對位置全跑掉了。這就是 ReActor 在低解析度臉上的物理盲區。
旁邊放一張 v04 的 Flux anchor 對比，你會看出 anchor 多麼正確、video 多麼歪：
anchor 90 分品質，video 50 分品質。中間差的就是 Wan22 5B 在跨幀的退化。
v5：加 PoseControlNet 鎖身體姿勢，讓 ReActor 至少不會因為臉跟身體比例失調而走鐘。
# v5 增加 pose lock
pose_map = openpose_extract(anchor)
controlled_anchor = flux_with_controlnet(
prompt=base_prompt,
control_image=pose_map,
controlnet_strength=0.85,
)
對應 v5 anchor：
結果：body OK 但臉仍漂。問題不在身體，問題在 ReActor 對小尺寸臉的處理能力。
v6：加 GFPGAN v1.4 only_center_face + YOLOv5l 偵測頭部 bbox + Canny edge 做頭部精準裁切。
# v6 sniper 核心
yolov5_head = detect_head(frame, model='yolov5l') # 比 OpenCV haar 穩 5 倍
bbox = yolov5_head.bbox
face_crop = frame.crop(bbox)
restored = gfpgan_v14.enhance(
face_crop,
only_center_face=True,
paste_back=True,
)
final = paste_with_canny_edge_blend(frame, restored, bbox)
[v6 修復結果：v06_gfpgan_fix.jpg]
對比同一個 shot 的 Flux anchor：
GFPGAN 修復後的 video 跟 anchor 的相似度終於跨越 90%。
過關了。Shot06 終於跑出來「跨幀臉是同一個人」的效果。
教訓：
- face restoration 排序：GFPGAN v1.4 > CodeFormer > RestoreFormer
- 頭部偵測：YOLOv5l > OpenCV haar（後者對側臉 / 戴口罩 / 低光全炸）
- only_center_face=True 比 False 穩很多（後者會把背景人物的臉也修，造成詭異）
但 v6 解決的只是「單一鏡頭內」的人臉一致性。「跨鏡頭」的一致性還沒解。
v7：LivePortrait 的物理盲區
LivePortrait（KJ wrapper）這條線想解決「靜態 base 圖注入表情」的問題。靜態圖太呆，注入表情就活了。
5 個版本連跑，每一版都失敗在同樣的地方：
- 怒吼：嘴張到一半就抖
- 咬牙：牙齒變成噁心的牆面紋理
- 側臉：整張臉融化
LivePortrait 適合什麼？適合 idle talking head，就是 AI 主播那種「面無表情念稿」場景。短劇要的是戲劇強表情，LivePortrait 物理上做不到。
教訓：別硬塞工具到它不擅長的場景。LP 對短劇極端表情已棄用，記在 memory feedback 裡。
v8：Wav2Lip baseline + MuseTalk 編譯地獄
對嘴是繞不過去的問題。
第一條線：MuseTalk。看起來品質好，paper 漂亮。
實際裝起來：mmcv 編譯地獄。MuseTalk 依賴 mmcv 1.7.x，這個版本在 Python 3.13 + CUDA 12.8 上沒有 prebuilt wheel，要從 source build。從 source build 在 WSL2 上整整跑了 4 小時，最後在 nvcc fatal: unsupported gpu architecture 'sm_120' 上 fail。
5060 Ti 是 Blackwell 架構，sm_120。mmcv 1.7.x 的 setup.py 寫死了支援到 sm_90。
我嘗試 patch setup.py，加 sm_120 進去。compile 過了。import 又炸：
ImportError: undefined symbol: _ZN3c104impl3...
ABI 不相容。徹底放棄 mmcv 路線。
第二條線：Wav2Lip。
Wav2Lip 老了（2020），256² 上限（後來證明這個其實不是 Wav2Lip 的鍋，是 MuseTalk 也是這個上限），但裝起來簡單，沒有 mmcv 噩夢。
shot06 男主 + shot07 新娘 smoke test 跑出來：完美。
我心想：「終於有一條跑得動的線了！」
於是擴展到 v3 的 18 shot Wedding Veil 全集。
跑出來：18 個 shot 裡 13 個是黑底霓虹垃圾。
原因：v3 base 的 Flux prompt 寫得太抽象，「神聖光輝」「夢幻氛圍」這種詞讓 Flux 給我生成了一堆 motion graphics 而不是真實場景。
要重煉 v6 規格 Wan22 才能出真劇。預估 3-4 小時。
時間到這裡是 5/25。第一週結束。成果：
- LoRA 9/13 完成
- 對嘴方案找到（Wav2Lip）
- sniper 工作流可用
- 但沒有一個完整能播放的短劇片段
殘酷的事實：第一週你會以為「裝完工具就是 90% 進度」，實際上裝完工具只是 10% 進度。剩下 90% 是品質、量產、串接、debug。
第二週：技術深淵（v9 - v13）
時間：2026-05-26 ~ 2026-05-29。
第二週開始有點絕望。LoRA 跑完了，sniper 工作流可用了，但每生成一個 shot 都要 30 分鐘 debug。
我計算了一下：30 集 × 32 shots × 30 分鐘 = 480 小時 = 20 天。
而且這還是「不出錯」的狀態。實際出錯率超過 50%。
v9.1：大女主獨白工廠（短暫的希望）
5/28 早上我寫了一個「大女主獨白工廠」：
# v9.1 整合
1. Flux + LoRA 生成 anchor（鎖蘇曉雯）
2. corruption filter（檢查圖是否糊）
3. auto rerun（糊就重生成）
4. Wav2Lip 對嘴
5. GFPGAN 局部修復層
6. ffmpeg concat
跑 8 個 shot smoke test，全部過關。
shot06 比後來 v10 的 LatentSync 還好。
我心想：「終於有 baseline 了，可以擴展。」
v10：LatentSync 1.5 的誘惑
但同一天下午，我看到 LatentSync v1.5 的論文。3 個 agent 平行 web 研究共識指向：
- Apache-2.0 license（商用無痛）
- 8GB VRAM 就能跑（我有 16GB 很寬裕）
- Whisper 中文支援好
- Blackwell sm_120 原生 wheel
我心動了。Wav2Lip 是 2020 的東西，LatentSync 是 2025 的，理論上應該強很多。
裝起來、跑 bride solo 三個 shot：
shot05：face-on 純粹特寫 → 完美
shot06：face-on 純粹特寫 → 完美
shot07：face-on 純粹特寫 → 完美
face-on 特寫的成功截圖：
注意這張的嘴部對齊精準、表情自然、跨幀穩定。如果你的短劇全是這種純臉特寫場景，LatentSync 真的能 ship。
我大喜，馬上把 v9.1 工作流換成 LatentSync。
跑複雜構圖（手 + 道具 + 臉）：
[失敗截圖：v08_musetalk_mouth_blur.jpg]
嘴部融化。
問題在於 LatentSync 的人臉偵測對「臉只佔畫面 1/5、旁邊有手有物」的構圖辨識不穩。它把背景的物體誤判成臉的一部分，於是修出來的嘴跟臉融在一起。
但我已經把 v9.1 拆了。沒留 backup。
教訓：失敗版本要保留。v8 / v9.1 / v12B2 都被「過時」但仍是 best baseline。我這次學乖了，後續每個版本都 tag git commit。
v11：PuLID-Flux 跟最新 ComfyUI 不相容
LatentSync 失敗那天晚上，我想試另一條線：PuLID-Flux。
PuLID 是 ByteDance 出的角色 reference 模型，理論上可以取代 LoRA。我做的 13 個 LoRA 各 35 分鐘訓練，如果 PuLID 一招吃天下，何必煉 LoRA？
裝 PuLID-Flux：
ComfyUI 升級到最新版（v0.21.1）
PuLID-Flux 拉最新 master
Queue prompt
結果：
KeyError: 'transformer_options'
File "PuLID-Flux/pulid_flux.py", line 234, in forward
options = kwargs['transformer_options']
PuLID-Flux 0.4 假設 ComfyUI 的 model forward 會傳 transformer_options。但 ComfyUI v0.21.1 把這個參數移除了。
我嘗試 patch PuLID-Flux 的 forward。改了 50 行 code，跑起來能 generate 圖，但角色 lock 失效，每次生成都是不同人。
我去看了 issue tracker，發現過去 2 個月有 8 個人開了類似的 issue，沒有一個被解決。PuLID-Flux 作者離開了。
放棄 PuLID 路線。13 個 LoRA 已經就緒，動機消失，回到 LoRA。
v12：五版全失敗的一夜
5/28 晚上 v12 五版全失敗，這是整個 30 天裡最低潮的一夜。
v12-A：用 Wan22 5B + 鎖首幀做 i2v。
理論：anchor 圖當第一幀，後面 80 幀 model 自己生成，這樣跨幀一致性可以保持。
實際：Wan22 5B 沒有可用的 i2v 鎖首幀 node。FunControl 雖然有 first frame 輸入，但構圖完全失控，第一幀是 anchor，第二幀變成完全不同的場景。
v12-B：LatentSync 對複雜畫面。
跟 v10 同樣問題。複雜構圖嘴部融化。
v12-B2：Wav2Lip + GFPGAN restore v9.1 path 復活。
我把 v9.1 從 git history 撈出來。跑：work。但慢，每個 shot 5 分鐘對嘴。
v12-B3：F5-TTS voice clone 整合。
F5-TTS 是 2025 的新 voice clone 模型，效果好。但在 5060 Ti 上對嘴 + voice clone 同時跑會 OOM。要不就 voice clone 跑完寫檔再對嘴，但這樣 latency 又拉到每 shot 8 分鐘。
v12-B4：純靜態構圖 + Ken Burns zoom 模擬運鏡。
跑通了。但畫面太呆，主角站在那裡 3 秒不動只有 BGM 在響，觀眾秒退。
整個晚上 5 個方向全試了，沒有一個能 ship。
我寫了 handoff 文件：
# anchor-drama-handoff-20260528-v12-failed.md
## 教訓
1. Wan22 5B 鎖首幀 = 物理盲區（在 5060 Ti 上）
2. LatentSync 對複雜構圖 = 物理盲區
3. PuLID-Flux + 最新 ComfyUI = 軟體盲區
4. F5-TTS + Wav2Lip 同時跑 = VRAM 盲區
剩下選項：
A. 升硬體（4090 24GB 起跳）
B. 退化品質（純臉特寫 + 靜態 + Edge TTS）
C. 換路線（雲端 API）
凌晨兩點我去睡覺。
v13：MuseTalk V1.5 突破（5/29）
第二天早上起來，我決定再試一次 MuseTalk。
不是因為樂觀，是因為 LatentSync 在複雜構圖會嘴部融化、Wav2Lip 太老，MuseTalk 如果能跑通就是最強的對嘴方案。
但 mmcv 編譯地獄怎麼辦？
我去 GitHub MuseTalk repo 翻 issues，發現 5 月有人提到：
MuseTalk V1.5 actually doesn't require mmcv. You can use
face_alignmentlibrary directly. The legacy preprocessing.py uses dwpose which needs mmcv, but you can patch it.
我打開 MuseTalk 的 preprocessing.py 看：
# legacy code
from mmcv import dwpose
landmarks = dwpose.detect(frame)
對應 patch：
# my patch
import face_alignment
fa = face_alignment.FaceAlignment(
face_alignment.LandmarksType.TWO_D,
flip_input=False,
device='cuda',
)
landmarks = fa.get_landmarks(frame)
# 注意：face_alignment 回傳 68 點 dlib 格式
# 這正好是 MuseTalk 要的格式
關鍵點在這裡：
我一開始試過 MediaPipe FaceMesh，468 點，更密更新。但是 MuseTalk 內部假設 landmark 是 68 點 dlib 格式，468 點丟進去索引完全不對應，於是 MuseTalk 在錯誤的位置生成嘴巴，看起來像嘴不動。
這個地雷我踩了 6 個小時。
第二個地雷：bbox_shift。MuseTalk 的 bbox_shift 預設是 range(-15, 15)，但這個是給 dwpose 的。換成 face_alignment 後，bbox_shift 必須改成 range(0, 0)，也就是不要 shift。否則嘴會在錯位置。
第三個地雷：7 個 .pth 載入必須加 weights_only=False。PyTorch 2.4+ 預設 weights_only=True，會拒絕載入舊格式 checkpoint。
把這三個 patch 全套上去，加 V15 config path：
# config switch
config_path = 'configs/inference/realtime_v1.5.yaml' # not v1.0
跑 256² test：
[2026-05-29 18:22:14] MuseTalk inference start
[2026-05-29 18:22:48] frame 1/72 done
[2026-05-29 18:22:50] frame 2/72 done
...
[2026-05-29 18:24:31] frame 72/72 done
[2026-05-29 18:24:33] mouth_movement_range: [-0~0] # 正確範圍
[2026-05-29 18:24:35] output saved: test_shot06.mp4
range [-0~0] 是完美數值。播放：嘴對齊精準、表情自然、跨幀穩定。
我尖叫了。終於有一條真正能 ship 的對嘴線。
整理 3 個地雷：
地雷 1：不要用 MediaPipe FaceMesh
→ 索引不對應 dlib 68 點
→ MuseTalk 在錯位置生嘴
→ 看起來嘴不動
地雷 2：bbox_shift 必須 range(0, 0)
→ 換 face_alignment 後 shift 規則變了
→ range(-15, 15) 會讓嘴在錯位置
地雷 3：weights_only=False（7 個 file）
→ PyTorch 2.4+ 預設拒絕舊 checkpoint
v13_FINAL_v2 銳化版本待簽核 → 過了之後就可以上 10 集劇本 × 30 集量產。
預估：9,600 shots ÷ 20 天 5060 Ti 24/7 = 480 shots/天 = ok。
我心想：「終於可以動工了。」
殘酷的事實：整個第二週，你的進度條只動了 30%，但你的心理負擔加重了 300%。每個技術突破後面跟著三個新坑。
第三週：量產地獄（v14 - v16）
時間：2026-05-30 ~ 2026-06-03。
v13 突破後，5/29 下午我寫 v14 量產 dispatcher。
v14：四 type sniper
v14 把所有 shot 分成 4 種 type，每種走不同 pipeline：
# episode_v14_runner.py 核心邏輯
shot_type:
cutaway → Flux 1 圖 + ffmpeg loop (2-3 sec, 無對白) ~1 min
static_pose → Flux + LoRA + ffmpeg Ken Burns zoom ~1.5 min
talking_head → Flux + LoRA + Edge TTS + MuseTalk + 字幕 ~3 min
action → Flux + LoRA + Wan22 5B ti2v + 字幕 ~7 min
CHAR_LORA / CHAR_VOICE / AGE_PRESERVE map 寫好：
CHAR_LORA = {
"female_lead": ("soxw_zh50_v1_100step_rank4_fp16-step00100.safetensors", "soxw_zh50"),
"male_lead": ("fujx_zh48_v1_100step_rank4_fp16-step00100.safetensors", "fujx_zh48"),
"antagonist_ex_husband": ("chenjh_zh53_v1_100step_rank4_fp16-step00100.safetensors", "chenjh_zh53"),
"daughter": ("chenyl_zh23_v1_100step_rank4_fp16-step00100.safetensors", "chenyl_zh23"),
"antagonist_secretary": ("linyq_zh28_v1_100step_rank4_fp16-step00100.safetensors", "linyq_zh28"),
"assistant": ("lim_zh35_v1_100step_rank4_fp16-step00100.safetensors", "lim_zh35"),
}
AGE_PRESERVE = {
"female_lead": "50 years old elegant Taiwanese woman, salt-and-pepper hair, fine eye wrinkles",
"male_lead": "48 years old refined Asian businessman, slight gray at temples",
"antagonist_ex_husband": "53 years old Asian middle-aged man, receding hairline",
"daughter": "23 years old young Asian woman, smooth fresh features",
...
}
每個角色綁好 LoRA + voice + 年齡描述，這樣 prompt 自動 expand。
4 type sniper 全綠：
- cutaway smoke：72 秒（過）
- static smoke：52 秒（過）
- talking smoke：158 秒（過）
- action smoke：380 秒（過，因為 Wan22 慢）
我把 ep1 450 個 sub-shot 全部排隊。
按下 enter，PC 開始 24/7 跑。
預估時間：450 shots × 平均 168 秒 = 21 小時。
v14 量產：21 小時後的 ep1_FULL.mp4
5/30 早上開跑，5/31 凌晨完成。
ffmpeg concat 把 450 個 sub-shot 拼成一個檔案：ep1_FULL.mp4。
長度：17 分鐘 42 秒（17.7 min）。
我把檔案傳給用戶看。
20 分鐘後用戶回 7 條批評：
1. 嘴模糊：MuseTalk 跑 256² 對全身 shot 來說，臉只佔 200×200 像素，看起來糊。
2. 配音單調：Edge TTS 預設沒 SSML emotion，全集 8 個角色說話的語調都一樣，像 AI 主播念稿。
3. 沒 BGM：cutaway 跟 static 段落完全沒背景音樂，靜得詭異。
4. 角色不一致：每個 shot 重煉 Flux，雖然鎖了 LoRA，但 seed 不同，五官會微漂。50 集裡蘇曉雯出現 800 次，至少 200 次能看出「她臉怎麼變了」。
5. 沒多角色：cutaway type 為了避免角色一致性問題，全變成「女主獨白 + 黑底字」，完全沒對話戲。
6. 運鏡失敗：沒有 vf 處理，所有鏡頭都是固定機位，毫無「電影感」。
7. 角色沒動作：cutaway 全靜態 + Ken Burns zoom，主角站在那裡 3 秒不動，觀眾秒退。
[v12 現實場景翻車：v12_ep1_realhuman_drama.jpg]
每一條都是事實。
我花了 21 小時跑出 17.7 分鐘成品，結果用戶 7 條批評全中。
v15：修 7 缺陷（6/1 - 6/3）
5/31 晚到 6/3 我修 v15。
缺陷 2（配音單調）→ SSML emotion 22 種 map：
# v15 SSML map
EMOTION_MAP = {
'angry': {'rate': '+20%', 'pitch': '+30Hz', 'volume': '+25%'},
'sad': {'rate': '-15%', 'pitch': '-15Hz', 'volume': '-10%'},
'excited': {'rate': '+25%', 'pitch': '+20Hz', 'volume': '+30%'},
'whisper': {'rate': '-10%', 'pitch': '-5Hz', 'volume': '-40%'},
'commanding': {'rate': '+10%', 'pitch': '+15Hz', 'volume': '+35%'},
# ... 17 more
}
def build_ssml(text, voice, emotion):
p = EMOTION_MAP[emotion]
return f"""
<speak version='1.0' xmlns='http://www.w3.org/2001/10/synthesis'
xml:lang='zh-CN'>
<voice name='{voice}'>
<prosody rate='{p["rate"]}'
pitch='{p["pitch"]}'
volume='{p["volume"]}'>
{text}
</prosody>
</voice>
</speak>
"""
但這就是 Edge TTS 的天花板。免費版 SSML 不支援 mstts:express-as 標籤，所以無法做「kind」「sympathetic」「affectionate」這種 OpenAI Voice 才有的真實情緒。只能調 rate / pitch / volume 三個物理參數。
缺陷 6（運鏡失敗）→ camera-aware ffmpeg vf：
# v15 camera-aware vf snippets
# push_in：往主角靠近
ffmpeg -i input.mp4 -vf "zoompan=z='min(zoom+0.0015,1.3)':d=72:s=720x1280" out.mp4
# pull_back：拉遠
ffmpeg -i input.mp4 -vf "zoompan=z='max(1.3-(it-1)*0.0015,1.0)':d=72:s=720x1280" out.mp4
# whip_pan：橫向疾掃
ffmpeg -i input.mp4 -vf "crop=720:1280:x='min(t*200,200)':y=0" out.mp4
# low_angle：低角度
ffmpeg -i input.mp4 -vf "perspective=x0=0:y0=H*0.1:x1=W:y1=H*0.1:x2=0:y2=H:x3=W:y3=H" out.mp4
缺陷 3（沒 BGM）→ BGM -22 to -28 dB ducking：
# v15 BGM ducking
def add_bgm(speech_mp3, bgm_mp3, output_mp3):
cmd = [
FFMPEG,
'-i', speech_mp3,
'-i', bgm_mp3,
'-filter_complex',
'[1:a]volume=-25dB[bgm_ducked];' # BGM 整體 -25dB
'[0:a][bgm_ducked]sidechaincompress=threshold=0.05:ratio=20:attack=5:release=200[mixed]',
'-map', '[mixed]',
output_mp3,
]
subprocess.run(cmd, check=True)
缺陷 4（角色不一致）→ 同源 seed + 雙層 unsharp：
# v15 same-character seed lock
def shot_seed(character: str, shot_index: int) -> int:
"""同角色同 seed 基礎 + shot 偏移"""
base = hash(character) % 1000000
return base + shot_index
但這治標不治本。Flux + LoRA 的跨 shot 一致性，物理上做不到 100%。
v15 smoke only：用戶轉向漫剧
剛跑通 sub0001 smoke，用戶說：
「真人這條太難了，做不出商業可用品質。我們轉動漫好不好？動漫的容錯率高，角色一致性不那麼嚴。」
我說好。
v16：動漫轉向（6/3）
v16 換 SDXL base：
# v16 SDXL workflow
CHECKPOINT = "noobai-XL-Vpred-v1.0.safetensors" # NoobAI XL Vpred 1.0
# 7.1GB，比 Flux 12GB 友善
50 個動漫角色：
# v16 char map (28 female + 18 male + 4 special)
CHARS_FEMALE = {
"f01_linxia": "22yo cute kawaii Asian girl, twin tails, school uniform",
"f02_muxue": "25yo elegant villain lady, long black hair, red dress",
"f03_suni": "23yo sexy idol, blonde long hair, white dress",
"f04_lijing": "20yo gentle student, short brown hair, cardigan",
# ... 24 more f
}
CHARS_MALE = {
"m01_shenyi": "28yo handsome CEO, black suit, sharp features",
"m02_lukai": "20yo college boy, casual shirt, athletic",
"m03_zhangwei": "35yo gentle teacher, glasses, brown jacket",
# ... 15 more m
}
IPAdapter Plus 鎖角色：
# v16 IPAdapter snippet（已踩坑）
wf["11"] = {"class_type": "IPAdapterUnifiedLoader", "inputs": {
"model": model_ref,
"preset": "PLUS (high strength)"
}}
wf["12"] = {"class_type": "IPAdapter", "inputs": {
"model": ["11", 0],
"ipadapter": ["11", 1],
"image": ["10", 0],
"weight": 0.7,
"start_at": 0.0,
"end_at": 1.0,
"weight_type": "standard", # 必填！沒填 HTTP 400
}}
兩個 bug：
Bug 1：IPAdapter 缺 weight_type input → ComfyUI HTTP 400。
Bug 2：ClipVision model not found。
# ComfyUI 找的是 CLIP-ViT-H-14-laion2B-s32B-b79K.safetensors
# 我下載的是 clip_vision_h.safetensors
# 解決：軟連結
cp clip_vision_h.safetensors CLIP-ViT-H-14-laion2B-s32B-b79K.safetensors
修完跑 50 個角色 anchor：
[漫剧角色 1：林夏 22yo kawaii]
[漫剧角色 2：穆雪 25yo 反派]
[漫剧角色 3：蘇妮 23yo idol]
[漫剧角色 4：沈逸 28yo CEO]
50 個 anchor 全跑通。我心想：「漫剧路線真的容錯率高很多。」
460-shot batch 開跑。
跑了 8 小時，crash。
[2026-06-03 03:14:22] sub_shot 187/460 ERROR
RuntimeError: CUDA out of memory.
[2026-06-03 03:14:22] ComfyUI VRAM zombie
PID 12384 holding 15.8 GiB at 0% util
ComfyUI VRAM zombie：crash 後 VRAM 不釋放，要 pkill + fuser -k 才清得掉。
我手動清掉，從 sub_shot 187 resume。
跑了 5 小時，crash。
我手動清掉，resume。
跑了 3 小時，crash。
到第 5 次 crash 我終於發現規律：每次 crash 的 sub_shot 編號都是「需要 IPAdapter weight > 1.0」的場景。weight 推高，VRAM 暴漲，5060 Ti 16GB 撐不住。
解決：把 IPAdapter weight cap 在 1.0。但這樣角色一致性又掉。
陷入死循環。
v16 翻車
460-shot batch 跑完一輪需要 36 小時 + 8 次手動 resume。最後出來的成品，用戶看了 5 秒：
「畫風不統一。前 30 個 shot 是 NoobAI XL 風格，後 30 個 shot 是 IPAdapter 漂移後的混合風格。整體像把兩個不同畫師的作品強行拼在一起。」
對。這是 IPAdapter 跨 shot 漂移的問題。weight 推不高就漂，推高就 OOM。
物理盲區。
殘酷的事實：21 小時量產 = 沒中途 sanity check 的代價。下次必須先跑 10 sec smoke 才能上 21hr batch。 這也是為什麼 quality gates 必須包含 incremental verification。
第四週：認輸（v17）
時間：2026-06-03 ~ 2026-06-04。
v16 漫剧翻車後，6/3 下午我寫 v17。
這次學乖，不直接量產。先跑 10 秒 demo，看品質夠不夠。
v17-v1：愛情劇 office demo
第一版 v17：
# v17 v1
EPISODE = "v17_love"
SHOTS = [
{
"name": "shot1_office_meet",
"anchor_prompt": "sexy CEO Shen Yi meeting Lin Xia in office",
"duration": 4.0,
},
{
"name": "shot2_close_eye_contact",
"anchor_prompt": "intimate eye contact close-up",
"duration": 3.0,
},
{
"name": "shot3_handshake",
"anchor_prompt": "handshake with subtle tension",
"duration": 3.0,
},
]
# total 10 sec
跑出來：10 秒，office 場景，沈逸 + 林夏對話。
用戶看完：
「劇情無聊。office 場景太普通，沒短劇該有的張力。換武俠看看。」
v17-v2：武俠拔劍
第二版 v17：
# v17 v2
EPISODE = "v17_wuxia_v2"
HERO_LOCK = (
"(handsome wuxia warrior:1.4), (long black hair tied with red ribbon:1.3), "
"(crimson red silk robe:1.4), (jade-hilted sword:1.3), "
"Asian male, 25 years old"
)
SHOTS = [
{"name": "shot1_aerial", "duration": 3.4}, # 鳥瞰
{"name": "shot2_combat", "duration": 3.4}, # 對劍
{"name": "shot3_reveal", "duration": 3.4}, # 拉遠揭曉
]
跑出來：10 秒武俠 demo。
用戶看完：
「SFX 太弱、旁白不夠大聲、台詞爛、鏡頭近、動作慢。」
5 條批評。
v17-v3：v2 的修正
我修：
- SFX：加金屬撞擊音效 sword_clash.wav，volume +20dB
- 旁白：boost +25dB
- 台詞：換更有張力的「風起雲湧，江湖再現！」
- 鏡頭：anchor_prompt 加
extreme wide shot - 動作：Wan22 motion_prompt 加
fast combat
跑 v3：
[2026-06-04 01:23:45] sub_shot 1 anchor: OK
[2026-06-04 01:24:01] sub_shot 1 wan22 ti2v: timeout 1800s
[2026-06-04 01:54:01] sub_shot 1 wan22 ti2v: still pending
[2026-06-04 01:54:15] Cancelled. ComfyUI VRAM zombie 15.8 GiB at 0% util.
Wan22 ti2v cfg=8.0 timeout 1800 秒。
我發現 cfg 推高 + Wan22 5B 在 5060 Ti 上會卡死。
第二個問題：前幾秒白屏：
# 我寫的 fade
'fade=t=in:st=3.35:d=0.1:color=white:alpha=0'
# 結果整個前 3.45 秒被白色覆蓋
alpha=0 不是「alpha 從 0 開始」，是「alpha 鎖死在 0」。整幀白溢出。
正確寫法：
# 正確
'fade=t=in:st=3.35:d=0.1:color=white'
# alpha 預設從 1.0 漸變到 0.0
修完跑 v3 第二次，這次能播了。但用戶說品質還是不行。
v17-v4：最後一搏
# v17 v4 最後 patch（已 reads 看過 v17_wuxia_v4.py）
"""v17 wuxia v4 — 修 3 點
1. 字幕太大太高 → FontSize 26 + MarginV 50（底部）
2. 角色不連貫 → motion prompt 強調 "same warrior same red robe same hair same sword"
3. 提示詞精簡 → 移除多餘 cinematographer 名（在 anchor 留，motion 不留）
"""
HERO_LOCK = (
"(same handsome wuxia warrior:1.5), (same long black hair tied with red ribbon:1.4), "
"(same crimson red silk robe with gold dragon embroidery:1.5), "
"(same young 25 years old strong man), (same sharp piercing eyes:1.2), "
"(holding same jade-hilted sword:1.4), masculine warrior, "
"Asian male, dark hair, red clothing"
)
CONSISTENCY_LOCK = (
"same character, same red robe, same long black hair, same red ribbon, "
"same jade sword, consistent appearance throughout"
)
加了一堆 (same xxx:1.5) 的 weight，期望角色不要漂。
跑出來：
[失敗截圖：v17_wuxia_v4_combat.jpg]
用戶最終 3 條批評：
「武打太慢！」（Wan22 5B 在 24fps 下動作就是會慢，物理盲區）
「角色的臉太醜扭曲！」（IPAdapter weight 0.95 推不上去）
「配音太難聽，語速太慢！」（Edge TTS SSML 受限，已經 +25% 是上限了）
3 條批評，每一條都是物理盲區。改不了。
honest admit
我寫了一段 commit message：
commit a4b3c81 [v17_wuxia_v4_honest_admit]
5060 Ti 16GB 已到天花板。
3 項物理盲區：
1. Wan22 5B 24fps 81 frames 動作就是慢
2. IPAdapter weight 1.5+ ghosting，1.0 鎖不住臉
3. Edge TTS 免費版 SSML 受限 ±20%
下一步：放棄本地路線，評估雲端 API。
時間：2026-06-04 上午。
從立項到認輸：18 天，17 版。
成果：
- 50+ 角色 LoRA / anchor
- 1 個 v14 量產 pipeline
- 1 個 17.7 min ep1_FULL.mp4（不能 ship 品質）
- 5 個 10 秒 demo（全部被批評）
- 0 個能上 YouTube / B 站 / 抖音的商業成品
殘酷的事實：「認輸」不是失敗，是節省。 早一天認輸早一天上正確路線。如果我 5/22 GGUF OOM 那天就認輸，可以省 12 天。
真正能跑的方案：Dreamina 30 集 NT$0 全包
好。前面講了那麼多本地失敗。現在講真正能跑的方案。
Dreamina（字節跳動旗下）目前免費版每天送 225 點，11 個 10 秒 clip 全免費。
什麼意思？意思是：
每天 11 個 clip × 10 秒 = 110 秒成品
1 集 5 分鐘 = 300 秒
3 天可以做 1 集
30 集 ÷ 3 天 = 90 天
如果你願意註冊 3 個帳號輪流用：
30 天可以做 30 集
NT$0 成本
對。NT$0。
雲端 vs 本地完整比較
┌─────────────────────────────────────────────────────────────┐
│ │
│ 本地 5060 Ti 16GB vs 雲端 Dreamina │
│ ───────────────────── ───────────────────── │
│ │
│ 一次性硬體：NT$15,000 NT$0 │
│ 每月電費：NT$650 NT$0 │
│ 每 clip 成本："免費" 免費（225 點/天） │
│ 品質：60 分 90 分 │
│ 一致性：差（face drift） 好（IPAdapter 內建） │
│ 30 集成本："免費" + 1 個月血淚 免費（11 個 10s clip/天） │
│ 上手時間：30+ 天 30 分鐘 │
│ Wan22 5B 81 幀限制：有 無 │
│ 跨 shot 角色一致性：差 好 │
│ 運鏡控制：手刻 ffmpeg vf prompt 內建 │
│ │
└─────────────────────────────────────────────────────────────┘
主流雲端 API 對比
| 維度 | 本地 5060 Ti | Dreamina | Kling 1.6 | Runway Gen-3 |
|---|---|---|---|---|
| 一次性硬體 | NT$15,000 | 0 | 0 | 0 |
| 每月電費 | NT$650 | 0 | 0 | 0 |
| 每 clip 成本 | "免費" | 免費（225 點/天） | NT$10 | $1 |
| 品質 | 60 分 | 90 分 | 95 分 | 98 分 |
| 一致性 | 差（face drift） | 好（IPAdapter 內建） | 極好（character lock） | 極好 |
| 30 集成本 | "免費" + 1 個月血淚 | 免費（11 個 10s clip/天） | NT$3,000 | $300 |
| 上手時間 | 30+ 天 | 30 分鐘 | 30 分鐘 | 1 小時 |
為什麼雲端比本地便宜？
直覺上「本地是 free 後算成本，雲端是按 clip 算成本」，應該本地便宜對吧？
不對。算對成本你會發現雲端便宜：
本地真實成本（30 集）
─────────────────────
硬體攤提：NT$15,000 ÷ 36 個月 = NT$417/月
電費：NT$650/月
網路：NT$300/月
SSD 磨損：NT$200/月
冷氣（PC 房）：NT$1,500/月（夏天）
─────────────────────
月成本：NT$3,067
人力成本（你的時間值多少？）
30 天 × 8 小時/天 × NT$500/小時 = NT$120,000
─────────────────────
30 集真實成本：NT$123,067
雲端 Dreamina 成本（30 集）
─────────────────────
免費版：NT$0
付費版（Pro）：NT$390/月（可選）
─────────────────────
人力成本（學會 + 操作）
1 天學會 × 8 小時 × NT$500 = NT$4,000
30 集 × 1 小時/集 × NT$500 = NT$15,000
─────────────────────
30 集真實成本：NT$19,000
差距：6.5 倍。
而且雲端品質更好。
為什麼會這樣？
雲端攤提 H100。 Dreamina 跑在阿里雲 / 騰訊雲 / 字節雲的 H100 上，每張 80GB HBM3，售價 NT$1,200,000。但這些卡 24/7 跑、千萬用戶共用，每個 clip 攤下來的成本只有幾分錢。
你的 5060 Ti 16GB 一張 NT$15,000，但只服務你一個人，使用率不到 5%。 規模經濟差 100 倍。
雲端有商業 fine-tuning。 Dreamina / Kling 內部有商用版 fine-tuned 模型，針對中文短劇優化過。這個 fine-tune 用了百萬段中國短劇訓練資料，你本地沒辦法重現。
雲端有專門團隊 debug。 你的 ComfyUI workflow 出 bug，你自己看 stack trace 修 8 小時。Dreamina 的 backend 出 bug，30 個工程師連夜修。
Dreamina 30 集 SOP（30 分鐘上手）
Step 1：註冊 Dreamina 帳號（5 分鐘）
https://jimeng.jianying.com/
手機驗證碼登入
Step 2：寫劇本（用 ChatGPT 或 Claude，1 小時）
Prompt：「請幫我寫一部 30 集中國爽劇，
50 歲女主蘇曉雯被丈夫外遇離婚 →
凈身出戶 → 偶遇護膚集團 48 歲總裁 →
創業「曉之光」品牌 → 復仇商戰 → 大婚。
每集 5 分鐘，請寫第 1 集大綱。」
Step 3：拆 shot（每集 30 個 shot，每個 10 秒）
把劇本拆成 prompt 列表
Step 4：Dreamina 生成 anchor 圖（每張 25 點 = 11 張/天）
鎖角色用 reference image upload
Step 5：Dreamina 生成影片（每段 25 點 = 11 段/天）
把 anchor 圖丟進 image-to-video
Step 6：CapCut / 剪映 拼接 + 字幕 + BGM
全免費
Step 7：上架 YouTube / B 站 / 抖音
這個 SOP 我親測：30 分鐘可以做出第一個 10 秒 demo，品質壓本地 v17_wuxia_v4 一個世代。
但你說「雲端 API 不能商用 / 有風險 / 不去中心化」？
聽起來合理，但其實是迷思。
「不能商用」：Dreamina 商用條款明確寫明可以商用，只要不違反當地法律。Kling 也是。
「有風險」：雲端有 API 可用就是穩定。你的本地隨時可能斷電 / 顯卡掛 / WSL idle terminate。可靠性其實雲端高一個量級。
「不去中心化」：是。但「去中心化」不會幫你賺錢。賺錢的是內容，不是基礎設施。
Dreamina 不夠？Kling 1.6 是真正商業級
如果你的目標是商業級短劇（要上 B 站站內推薦那種），Dreamina 還是不太夠。Kling 1.6 是 2026 年商業短劇圈最常用的工具：
Kling 1.6 vs Dreamina
─────────────────────────────────
品質： 95 vs 90
character lock：極好 vs 好
動作流暢度： 極好 vs 好
中文台詞理解： 極好 vs 好
價格： NT$10/clip vs 免費
30 集成本： NT$3,000 vs NT$0
NT$3,000 拍 30 集中國短劇，這個成本傳統影視業會笑出來。
終極建議：本地 + 雲端混合
如果你已經有 5060 Ti，不要丟掉。最佳路線是：
本地 Flux + LoRA → 跑 anchor 圖（鎖角色）
↓
上傳 Dreamina / Kling → 跑影片
↓
CapCut → 後製
這樣你的 LoRA 投資沒白花，Dreamina 的影片生成又補上你本地的天花板。
殘酷的事實：「雲端 + 本地混合」是 2026 年最務實的方案。純本地是浪漫，純雲端是 outsource，混合才是工程。
給創業者的 5 條決策建議
寫到這裡 25,000 字了。如果你還在看，代表你真的想做 AI 短劇創業。我給你 5 條最痛但最有用的建議。
建議 1：別買硬體再說，先用雲端把第一集做出來
90% 的失敗創業者死在「我先把硬體 / 環境 / 工作流弄齊再開始做內容」。
正確順序：
Day 1: 雲端 Dreamina 做 10 秒 demo
Day 2: 給 10 個朋友看，收 feedback
Day 3: 用 feedback 改 prompt，再做 10 秒
Day 7: 完成第 1 集 5 分鐘
Day 14: 上 YouTube 看數據
Day 30: 如果數據好 → 評估是否買 5090
如果數據差 → 換題材，不要怪工具
不要先買 5060 Ti / 5070 / 5090 / 4090 / A6000。除非你已經有「能驗證內容是商業可行」的證據。
建議 2：題材 > 工具，10 倍以上
我這 30 天血淚下來最大的領悟：
做不出來的不是「AI 工具差」，是「題材沒驗證」。
《五十岁》能爆是因為它精準打中 50+ 女性的逆襲幻想 + 抗老焦慮 + 對丈夫的怨氣。同樣題材你如果用 Kling 做出來，120 萬人看。
如果你做一個冷門題材，比如「程式設計師重生變蘋果工程師」，給你 H100 叢集你也做不爆。
先驗證題材，再優化工具。
建議 3：商業級 voice 不要省
我用 Edge TTS 免費版省的那一點錢，最後讓整集成品變成「AI 主播念稿」。
商業級配音選項：
ElevenLabs Voice Clone：$22/月，可以 clone 真人聲音，emotion 滿
Azure Speech Premium：$1/小時，mstts:express-as 完整支援
Murf AI：$23/月，120+ 真人聲線
F5-TTS 本地：免費但要 24GB VRAM 才好跑
短劇創業者必選：ElevenLabs 或 Azure
NT$700/月 vs 30 集成品從 60 分變 85 分。投資報酬率爆表。
建議 4：先做 1 集驗證，不要批 30 集
我 v14 量產 21 小時做出 17.7 分鐘 ep1，結果用戶 7 條批評全中。
正確流程：
1 集 → user review → 改 prompt
1 集 → user review → 改 prompt
1 集 → user review → 上架測試水溫
（如果水溫熱）
3 集 → user review → 上架
（如果還是熱）
10 集量產
（如果還是熱）
30 集量產
每一個 milestone 都要驗證才往下走。不要一次衝到底。
建議 5：「免費」是最貴的成本
我這 30 天本地路線「省」下來的雲端 API 錢：
Dreamina：30 天 × 0 點 = NT$0
Kling 1.6：30 天 × 11 clip × NT$10 = NT$3,300
Runway Gen-3：30 天 × 11 clip × $1 = $330 = NT$10,000
我這 30 天「花」下去的本地成本：
電費：NT$650
冷氣（PC 房）：NT$1,500（夏天）
網路升級：NT$0（沒升級）
SSD 磨損：估 NT$300
時間：30 天 × 8 小時 × NT$500 = NT$120,000
心理消耗：無價
─────────────────────
總計：NT$122,450
我「省」了 NT$10,000，「花」了 NT$122,450。
「免費」永遠是最貴的成本。
殘酷的事實：創業者最該避免的是「沉沒成本謬誤」。你買了 5060 Ti 不代表你必須用它做 AI 短劇。它可以打遊戲、可以挖礦、可以跑 LLM inference、可以做 SDXL 圖庫。
章節摘要
我們快結束了。每章摘一行：
| 章 | 核心結論 |
|---|---|
| 1 | 5060 Ti 16GB 物理上做不出產業級中國短劇 |
| 2 | YouTube 教學 90% 省略「硬體 / 後製 / demo vs 量產」三件事 |
| 3 | 第一週裝環境就燒 1.5 天，GGUF 14B 第一步 OOM |
| 4 | 第二週 v9.1 → v10 → v11 → v12 五版全敗到 v13 突破 |
| 5 | 第三週 v14 量產 21hr 換 7 條批評，v16 漫剧 IPAdapter 漂移 |
| 6 | 第四週 v17 武俠 demo 4 連敗，物理盲區無解 |
| 7 | Dreamina 30 集 NT$0 全包，Kling 1.6 是商業級首選 |
| 8 | 創業者：題材 > 工具，先做 1 集驗證再批 30 集 |
教訓欄
| # | 教訓 |
|---|---|
| 1 | 本地天花板真實存在，消費卡 16GB VRAM 跑不動產業級短劇 |
| 2 | 單一模型沒有 silver bullet（MuseTalk / LatentSync / Wav2Lip 都有適用場景） |
| 3 | MuseTalk 必走 face_alignment 68 點 dlib 格式，不要用 MediaPipe |
| 4 | bbox_shift 必須 range(0, 0)，不是 (-15, 15) |
| 5 | 7 個 .pth 載入必須加 weights_only=False |
| 6 | WSL idle 必須關（vmIdleTimeout=-1） |
| 7 | Edge TTS 免費版 SSML 受限，商業級必上雲（Azure / ElevenLabs） |
| 8 | 量產前 smoke test 必跑 10 sec，別砸 21 hr 才發現整體不行 |
| 9 | 失敗版本要保留（v8 / v9.1 / v12B2 都是後悔砍掉的 baseline） |
| 10 | 雲端 API 不是 cheating，算對成本電費 + 人力後常常更便宜 |
| 11 | 5060 Ti Flux LoRA cache miss 197s/step → cache reuse 70s/step，3x 差距 |
| 12 | Windows cp950 console 殺 ComfyUI training，chcp 65001 + PYTHONIOENCODING=utf-8 寫進 .bat |
| 13 | HF FLUX 全 gated，schnell 也要 token，走 ComfyUI portable fp8 single-file 避開 |
| 14 | duix.avatar 3 container 偷 6.5GB GPU，必須 restart=no + stop 永久關 |
| 15 | Port 8188 portproxy 不要動，會 LAN 連不到 WSL |
| 16 | ComfyUI VRAM zombie，crash 後要 pkill + fuser -k |
| 17 | IPAdapter weight 1.5+ ghosting，跨 shot 角色一致性物理盲區 |
| 18 | Wan22 5B 固定 81 幀 @ 24fps = 3.375s，架構級限制 |
| 19 | LivePortrait 怒吼 / 咬牙 / 側臉物理盲區，只適合 idle talking head |
| 20 | PuLID-Flux 跟最新 ComfyUI 不相容，作者離開，棄用 |
工具參考
本地 stack（已驗證能跑但有限制）
─────────────────────────────────────
ComfyUI v0.21.1 portable GPU pipeline 主機
Wan22 5B ti2v fp16 i2v 影片，81 幀上限
Flux fp8 single-file anchor 圖，跨 shot 漂
MuseTalk V1.5 對嘴 256² 上限
LatentSync 1.5 對嘴 face-on only
Wav2Lip 96² + GFPGAN v1.4 對嘴 backup
NoobAI XL Vpred 1.0 7.1GB 動漫 base
IPAdapter Plus SDXL ViT-H 角色 reference
Edge TTS 旁白，SSML 受限
Ollama qwen3:14b 劇本生成
雲端 stack（推薦）
─────────────────────────────────────
Dreamina（字節） 每日 225 點，11 個 10s clip 免費
Kling 1.6 NT$10/clip，商業級
Runway Gen-3 $1/clip，頂級
ElevenLabs Voice Clone $22/月，真人聲音克隆
Azure Speech Premium $1/小時，完整 SSML
CapCut / 剪映 免費後製
結語：30 天值不值得？
值得。
不是因為我做出了短劇（沒做出來）。
是因為我驗證了一個假設。
假設是：「2026 年消費級 GPU 能跑產業級中國短劇本地生成。」
驗證結果：不能。
這個答案省下無數後來人的時間。如果你看完這篇文章決定「不買 5060 Ti / 不踩本地坑 / 直接上雲端」，那這 30 天就是值得的。
我把這篇 30,000 字寫出來，本質上是寫給「過去的我」的信。如果 5/17 那天我能看到這篇文章，我會：
- 跳過 LoRA 訓練（NT$0 + 30 小時電費）
- 跳過 GGUF 14B 嘗試（4 小時 debug）
- 跳過 LivePortrait / PuLID-Flux 死路（2 天）
- 跳過 v14 21 小時量產（21 小時 + 7 條批評）
- 跳過 v16 漫剧 460-shot batch（36 小時 + 5 次 crash）
- 跳過 v17 4 連敗（1.5 天）
直接從 Day 1 開始用 Dreamina 寫第 1 集劇本。
30 天後我會有：
- 30 集中國爽劇全集
- YouTube 上架 + B 站上架 + 抖音上架
- 真實的觀眾數據
- 真實的廣告收入
這才是創業者該做的事。
不是跟硬體搏鬥。
是跟觀眾搏鬥。
最後一張對比圖：夢想 vs 現實
夢想（5/17 立項那天）
─────────────────
買一張 5060 Ti
↓
30 天本地跑通
↓
30 集中國爽劇上線
↓
月入十萬
現實（6/4 認輸那天）
─────────────────
買一張 5060 Ti
↓
30 天跑 17 版全失敗
↓
寫 30,000 字反思文
↓
建議讀者用 Dreamina
─────────────────
差距：30 天 + NT$15,000
+ 7 條批評 + 0 集成品
─────────────────
如果這篇文章幫你省下這 30 天，請把這篇分享給你身邊正想下海的朋友。
讓他們別重複我的錯。
附錄：本文件相關 commit / file 路徑
專案根目錄： /Users/jiahaolu/drama-factory/
v17 最後版本： factory_v2/scripts/v17_wuxia_v4.py
v14 量產 runner：factory_v2/scripts/episode_v14_runner.py
13 角色卡： data/characters/character_cards.json
30 集大綱： data/outlines/drama_outline_30ep_FINAL.json
ep1 劇本： data/scripts/ep1_script_FINAL.json
v15 SSML map： factory_v2/lib/ssml_emotion_map.py
v15 BGM mix： factory_v2/lib/bgm_mixer.py
失敗截圖庫： super-tools/content/articles/zh-TW/images/drama-factory/
memory 內三個關鍵 anchor：
- anchor-drama-handoff-20260521-v12-failed.md
- anchor-drama-v13-musetalk-working-20260529.md
- anchor-drama-v14-unblocked-20260601.md
7 大根因分析 + 10 大坑全 feedback：
- feedback-wsl-idle-terminate-202605.md
- feedback-fluxtrainer-comfyui-install-202605.md
- feedback-flux-lora-5060ti-speed-202605.md
- feedback-musetalk-mmcv-build-hell.md
- feedback-liveportrait-not-for-extreme-expression.md
- feedback-comfyui-templates-first-202605.md
- feedback-must-evaluate-cloud-api.md
寫完了。如果你看到這裡，謝謝你的時間。
去用 Dreamina 吧。
本系列其他兩篇
這篇是 B 版（反差派，標題殺人）。同系列另有兩個視角：
- 🅰 本地 AI 短劇生成完全失敗實錄：30 天 17 版 5060 Ti 16GB 血淚教科書 — 真實派敘事，4.5 萬字按 v1.7-v17 時間軸完整失敗史，每章「踩坑→分析→教訓」三段制。
- 🅲 2026 AI 短劇本地化完整指南：避開我踩過的 47 個坑 — 教學派，47 坑全展開 + ComfyUI workflow JSON + 4 type dispatcher SOP，真要動手必看。
建議讀完本篇後：想了解失敗細節走 A 版，要動手實作走 C 版。