MiniMax H3 深度研究專案

研究主軸：MiniMax H3（次要對照：LTX 2.5 / 2.3）
目的：從「拿來就用」進階到「理解每個節點的涵意、優缺點、參數影響」，並追蹤社群最新工作流與改進。
建立日期：2026-09-04

📍 這是什麼

你目前所有影片（迷因 / 狗狗 / 跳舞 / 參考圖生影片 / Video_Gen 網頁）都在跑 MiniMax H3，但都是直接套工作流。這個專案把「模型怎麼運作、每個節點在做什麼、參數拉高拉低會怎樣、社群現在在玩什麼」系統性地記錄下來，讓你能：

1. 看得懂你現有的 7 個工作流 JSON 每個節點在幹嘛
2. 知道優缺點：什麼時候該用 Fast、什麼時候該上 Pro、什麼時候該補 Turbo LoRA / FaceRefine
3. 追得上：社群新出的節點包、LoRA、加速方法，隨時增量加進來

🗺️ 檔案地圖

📊 進度看板

• 建立專案骨架
• 抽出你 7 個工作流的真實節點清單
• 搜集 GitHub / HuggingFace / Civitai 情報
• 撰寫模型總覽 + 對比
• 撰寫節點剖析（核心 + Pro 進階）
• T8「二階段超級加速」工作流深度剖析（SOL Engine + Dual-Clock，2026-09-04）
• T8 SOL Engine 工作流本機實測成功（2026-09-05：17.8 分鐘 1080p 15s 有聲片，詳見 04-工作流/03-）
• 社群工作流深度試用（Director / FaceRefine 等）
• Reddit 論壇討論補抓（官方 API 403，待換管道）
• 節點截圖（從 ComfyUI 補圖到 assets/）
• 實測紀錄（改參數 A/B 對比）——2026-09-13 完成 #12 定案 + FL2VA/Ref2VA 對比 + 四支 cron 模型分工
• 網頁 Video_Gen 兩分頁（參考圖／文生）統一成二採 + #12（2026-09-13 實跑驗證 4s=181s／200s）
• latent 放大器（LBH-123-AI）一采提速實測 → ❌ 放棄（2026-09-28：要快掉畫質、要畫質不快；維持 0.6MP 一采 + DLSS5，見 06-實驗記錄.md）

🔎 一頁看懂你的管線

你實際在跑的兩條主鏈：

二採文生影片（迷因/跳舞/狗狗，純 T2VA）：
  UNET(int8) + Qwen3-VL 32B(NVFP4) + lightx2v LoRA(4step)
  → strip 參考圖 → 純 T2VA → 4 步採樣 → latent 放大 → 二次採樣
  → 影片 VAE + 音訊 VAE 解碼 → 24fps 輸出
  ※ 迷因→Ref2VA、跳舞/狗狗→FL2VA

參考圖生影片（穿越 vlog，用你的照片＋聲音）：
  LoadImage(參考圖)+LoadAudio(聲音) → Ref2VA(Gem prompt)
  → 4 步採樣 → latent 放大 → 二次採樣 → 雙 VAE → 24fps 輸出

網頁 Video_Gen（分頁 1 參考圖 / 分頁 2 文生）：
同二採工作流；分頁 2 strip 參考節點 → 純 T2VA
模型自動二選一：會講話 → Ref2VA int8、不會講話 → FL2VA int8（#12）
（分頁 3 首幀仍是舊 Script_FirstFrame 管線）

🚀 如何延續研究

• 加新情報：把內容寫進 05-論壇情報/ 或對應主題檔，再跑一次 build_dashboard.py 重新生成 HTML。
• 記實驗：在 06-實驗記錄.md 追加一行。
• 每次變動：在 CHANGELOG.md 記一筆（日期 + 改什麼）。
• 更新 HTML：python build_dashboard.py → 產出 dashboard.html，直接開瀏覽器看。

🌐 遠端存取（公司/外網）

• 公網網址：https://devan-pc.tail237327.ts.net/（Tailscale Funnel + HTTPS，公司瀏覽器免安裝直接開）
• 帳號：devan · 密碼：見 serve_dashboard.py 頂端 PASSWORD
• 伺服器：serve_dashboard.py（綁 127.0.0.1:8787，Basic Auth），開機自動啟動（啟動資料夾 MH3_Dashboard_AutoStart.bat）
• 管理：換密碼改 serve_dashboard.py 後重跑 start_server.py；關閉對外 tailscale funnel --https=443 off

最後更新：2026-09-28

MiniMax H3 模型總覽

你每天在跑的模型。這裡講清它的家族、版本、量化、以及那顆關鍵的 Turbo LoRA。

一句話

MiniMax H3 是 MiniMax（海螺）最新一代原生「畫面＋聲音」同時生成的影片模型，ComfyUI 官方原生支援。它跟上一代（LTX / 海螺 02）最大的差異是：音訊不是後製配的，是跟畫面在同一次採樣裡一起生出來的。

家族與任務類型

H3 不只一種用法，官方節點把不同任務拆開（對應你工作流裡看到的節點名）：

你工作流裡的節點名 MiniMaxH3ImageToVideo（其實是 T2V/I2V 共用）和 MiniMaxH3ReferenceToVideo（Ref2VA）就是官方原生節點。

⚠️ FL2VA vs Ref2VA：不是死綁任務類型（2026-09-13 實測）

官方把 FL2VA / Ref2VA 標成不同任務，但底層同架構、可互通：FL2VA 也能吃參考圖生影片、Ref2VA 也能純文生影片。真正的差異是兩個實測特性：

原因：FL2VA 訓練資料含大量「帶燒錄字幕」的中國短影音，所以給台詞就會順手燒字幕；Ref2VA 資料較乾淨。

→ 選擇原則（四支 cron 已套用）：會講話（有台詞）→ Ref2VA（避免燒字幕）；不會講話 → FL2VA（更銳）。

兩套品質等級：Fast vs Pro

你其實有兩套 recipe，差在「速度 vs 品質」的取捨：

核心組件拆解

量化版本（VRAM 不夠時的選擇）

H3 模型很大，社群出了各種量化版（HuggingFace 下載量排序）：

你現在用的是 fp8_scaled（Fast）和 int8_convrot（Pro），都是 VRAM 友善的量化。「convrot」= 卷積權重旋轉（一種量化前的權重變換，減少量化誤差）。

⚡ Turbo LoRA 重點（直接影響你每天的片）

Turbo LoRA 是把 H3 從 ~20 步蒸餾成 4 步的關鍵。社群最熱的版本來自兩個 repo：

1. lightx2v/Minimax-h3-Turbo — 你在用的 fl2v_lightx2v_turbo_4step_v0.1（strength 0.75）
2. larryvrh/MiniMax-H3-Turbo-Lora — 更新、品質更好的版本

Larryvrh 版的重要結論（README 直接講明）：

• v4-600 checkpoint 是現在最強：靜態/小動作鏡頭大幅改善、微細節（臉/手指/質感）更好、完全解決了早期 v1 的過度銳化「塑膠感」
• 唯一的取捨：4 步 + 大而快的動作時，v4 可能出現殘影 / 拖尾（作者正在修）
• 解法：用 6–8 步，殘影幾乎消失，且 v4 比 v1 更能承受高步數
• 只有「4 步 + 重動作」這個狹窄情境，才考慮退回 v1-850

💡 可行動的建議：你跳舞片是「大動作」，如果發現殘影，把步數從 4 拉到 6–8，或改用 v4-600 LoRA。詳見實驗記錄。

來源

• 官方教學：https://docs.comfy.org/tutorials/video/minimax/minimax-h3
• Turbo LoRA（larryvrh）：https://huggingface.co/larryvrh/MiniMax-H3-Turbo-Lora
• Turbo（lightx2v）：https://huggingface.co/lightx2v/Minimax-h3-Turbo
• 官方模型卡：https://huggingface.co/Comfy-Org/MiniMax-H3 、 https://huggingface.co/MiniMaxAI/MiniMax-H3

模型對比：MiniMax H3 vs LTX 2.5 / 2.3

你 8/18 剛從 LTX 2.3 全面切到 H3。這頁把兩家擺在一起比，並標出 LTX 2.5 這個新變數。

TL;DR

• H3 的殺手鐧：原生音訊（畫面＋聲音同次生成）、中文/多模態理解強（Qwen3-VL 32B）、ComfyUI 原生節點、生態系爆炸式成長。
• LTX 的殺手鐧：極快（時序壓縮很激進）、VRAM 友善（19B/22B GGUF 12GB 能跑）、開源成熟、STG 引導控制強。
• LTX 2.5：最新一代，社群開始出現「LTX25 ｜ MM H3」的混合工作流（見 Civitai），但細節我還沒完整驗證，先標「待補」。

全維度對比

為什麼你 8/18 從 LTX 2.3 切到 H3

據你 vault 紀錄，切換主因是：

1. LTX 2.3 是兩段式（T2I → I2V），流程繁瑣、port 8000 舊機
2. H3 純 T2V 一步到位，Gem 格式 prompt 的鏡頭語言理解更好（「H3 比 LTX 更能理解鏡頭運動」）
3. H3 原生音訊，跳舞/迷因片直接有聲音

H3 的已知缺點（社群回報，待你實測驗證）

值得觀察的混合方向

社群已經出現 「H3 生畫面 + LTX 精修」 的混搭工作流（Civitai 有 Minimax H3: EZ | Turbo . Optimal . RTX Upscale . LTX Refine）。這可能比單押一家更划算——但先別急，等實測。

待驗證清單（LTX 2.5）

• LTX 2.5 官方 release note / 模型卡
• 與 2.3 的實際差異（速度/畫質/VRAM/原生音訊？）
• 是否值得在 H3 之外補一條 LTX 2.5 管線做對照

來源

• Civitai「LTX25 | MM H3 | Krea2 | ideogram 4 WF collection」：civitai.com/models（搜尋 LTX25）
• LTX-Video 官方：https://huggingface.co/Lightricks/LTX-Video
• 你 vault 的遷移紀錄：media/meme-dog-video.md、comfyui-video-pipelines skill

節點總表（你 7 個工作流的完整盤點）

這是你 Documents/Programs/ 下 7 個 H3 工作流 JSON 的真實節點清單，逐個標註功能與用途。編號 = JSON 裡的節點 id。

兩條主鏈對照

注入點（你的 Python 腳本會改的節點）

全節點一覽（依功能分類）

🔵 模型載入類

🟠 生成入口類

🟢 採樣類

🟣 參數類

🟤 輸出類

🔴 Pro 進階類（詳見 04-Pro進階節點）

⚪ Script 網頁版專用（TE 提示詞增強）

🔘 FirstFrame 專用

工作流清單（7 檔）

節點剖析 ① 生成入口

MiniMaxH3ImageToVideo（節點 194 / 133）

涵意

H3 的主生成節點。名字雖叫「ImageToVideo」，但你的 Fast 工作流其實是把它當文生影片（T2V）在用——因為 H3 的 T2V 和 I2V 共用這顆節點，差別只在有沒有餵首幀圖。它把「模型 + 文字編碼器 + VAE + prompt」打包成採樣器要吃的條件（conditioning）。

關鍵參數

優點

• 一個節點包辦 T2V / I2V，接線簡單
• prompt 是多模態描述（Qwen3-VL 32B 讀），能理解「Zoom in / Medium Shot / Handheld Tracking」這類運鏡語言

缺點

• 參數都藏在節點內，新手看不到底層在做什麼（要懂就得拆模型/採樣鏈）
• 對 prompt 品質極敏感，Gem 格式寫不好，畫面就崩

建議

• 保持 Gem 六段格式（subject_definitions / summary / retention_analysis / detailed_description / overall_soundscape / non_diegetic_music）
• 運鏡描述用英文術語（H3 對英文鏡頭術語理解最好），對白用中文

MiniMaxH3ReferenceToVideo（節點 316）

涵意

Ref2VA——參考圖生影片。跟上面那顆幾乎一樣，但多了 ref_images 輸入，用來鎖定人物外觀（把參考圖的人臉/服裝搬進影片）。你「自拍穿越」就是用這顆 + devan.png。

關鍵參數

優點

• 人物一致性是目前最強方案之一（比 LTX ID LoRA 直覺）
• 不用訓練，一張圖就能鎖外觀

缺點

• 人物小臉時仍會糊（H3 通病，人頭佔畫面比例小時臉會崩）
• 動作幅度大時，外觀鎖定會變鬆

建議

• 參考圖人臉要清晰、正臉、光線均勻
• 若出現小臉糊 → 上 FaceRefine 節點（社群方案，見工作流篇）
• retention_analysis 務必同時寫 <Subject 1> 和 <Picture 1> 兩條 fully_preserved

LoadImage（節點 308）

涵意

載入參考圖。只讀 ComfyUI 的 input 目錄（你的是 D:\Comfy-Desktop\ComfyUI-Shared\input\），所以外部照片要先複製進去（你的 ref_video_gen.py 會自動做）。

建議

• 主角是你 → 用 devan.png（已放好）
• 外部圖 → 給全路徑，讓腳本複製進去

節點剖析 ② 模型載入

UNETLoader（節點 214 / 305 / 129）

涵意

載入擴散主體（UNet / DiT）——真正「畫」出影片每一幀的模型。

你用的檔

參數

• weight_dtype: default — 讓 ComfyUI 自動選精度（會吃模型檔的量化資訊）

優缺點

• ✅ fp8_scaled：VRAM 省、品質損失小，日常自動化最划算
• ⚠️ int8_convrot（Pro）：更省但品質略降，靠 Pro 的多步採樣補回
• ⚠️ pruned：剪枝過，某些冷門能力可能被裁掉

建議

• 日常（cron）用 fp8_scaled 就好，別為省那點 VRAM 犧牲品質
• 追求極致畫質時，再考慮 Pro 的 int8_convrot + 高步數

CLIPLoader type=minimax（節點 204 / 298 / 130）

涵意

載入文字編碼器。H3 的「文字理解大腦」是 Qwen3-VL 32B（多模態模型），type: minimax 告訴 ComfyUI 用 MiniMax 的格式載入。

你用的檔

qwen3vl_32b_h3_ultra_uncensored_heretic_int8_convrot.safetensors

檔名關鍵字拆解：qwen3vl=Qwen3-VL、32b=320 億參數、int8=8bit 量化、convrot=卷積旋轉（量化技巧）、ultra_uncensored_heretic=社群去審查版。

優缺點

• ✅ 32B 超大 → 中文、複雜畫面描述、運鏡語言都吃得很準（這是 H3 贏 LTX 的關鍵）
• ✅ 多模態 → 能理解「畫面裡有什麼」而不只是文字
• ⚠️ 32B int8 還是佔不少 VRAM（這就是為什麼有 GGUF Q4 版可換）

建議

• VRAM 吃緊 → 換 Pro 用的 qwen3vl_32b_minimax_h3-Q4_K_M.gguf（CLIPLoaderGGUF 載入），犧牲一點理解換 VRAM

VAELoader ×2（影片 215/306 + 音訊 203/297）

涵意

H3 有兩顆 VAE，因為它同時生畫面＋聲音：

優缺點

• ✅ 這是 H3「原生音訊」的實體基礎——音訊不是後製，是跟畫面一起在 latent 空間生成的
• ⚠️ 音訊 VAE 用 fp32（比畫面 fp16 更精），佔額外 VRAM
• ⚠️ 社群 latent upscaler 提到「costly 5B-param VAE」——這顆 VAE 本身很大，是超分瓶頸

建議

• 兩個都不能漏接，漏了音訊 VAE 就沒聲音

LoraLoaderModelOnly（節點 205 / 300）

涵意

把 Turbo LoRA 疊到 UNet 上，把採樣步數從 ~20 步蒸餾成 4 步。

你用的檔 + 強度

優缺點

• ✅ 速度提升約 5 倍（20 步 → 4 步）
• ⚠️ strength_model 0.75 是「打折的加速」——降低強度會保留更多原始品質，但步數不足時畫面會不穩
• ⚠️ 已知：4 步 + 大動作 = 殘影（見模型總覽的 Turbo LoRA 段）

建議

• 跳舞片（大動作）若殘影：步數 4 → 6–8，或換 larryvrh 的 v4-600 LoRA
• 靜態/小動作：維持 4 步 + 0.75 最快

節點剖析 ③ 採樣與排程

這串節點決定「怎麼把雜訊一步步變成乾淨影片」。理解它們 = 理解畫質與速度的總開關。

RandomNoise（節點 206 / 301）

涵意

生成起始雜訊（純隨機 latent），是擴散去噪的起點。denoise=1 表示從純雜訊開始。

建議

• 沒什麼好調的，跟 Seed 連動（同 seed 同雜訊 → 可重現）

KSamplerSelect（節點 197 / 291）

涵意

選採樣器演算法。你用 res_multistep——這是 H3 專用/推薦的採樣器（res = residual multistep）。

建議

• H3 就用 res_multistep，別亂換（換成 euler 之類可能不適用於這顆模型的排程設計）

BasicScheduler（節點 196 / 288）

涵意

決定步數、sigma 排程、denoise 強度。

優缺點

• ✅ 4 步 + turbo LoRA = 快
• ⚠️ steps 是影響最大的參數：4 → 6–8 步能明顯改善殘影/細節，但時間線性增加
• ⚠️ steps 太低畫面「欠收斂」（糊、噪、細節少）；太高（turbo LoRA 下）反而可能過銳化

建議

• 先固定 4 步跑日常
• 遇到問題（殘影/糊/小臉）→ 先試拉 steps，再考慮其他手段

BasicGuider（節點 207 / 299）

涵意

CFG 引導（Classifier-Free Guidance）——控制 prompt 被「遵守」的程度。它把「有 prompt 的預測」和「無 prompt 的預測」混在一起，拉高 prompt 服從度。

建議

• 你目前用預設（接 LoRA 後的 model），沒單獨拉 CFG
• 畫面「不聽話」→ 可試微調 guider 的 cfg 值（社群常提 3~6 之間）

SamplerCustomAdvanced（節點 195 / 287）

涵意

核心去噪引擎。把上面全部（noise + guider + sampler + scheduler）串起來，實際執行「雜訊 → 乾淨 latent」的採樣迴圈。

建議

• 純串接節點，不需手動調；理解它是「總指揮」即可

ComfyMathExpression（節點 198 / 289）

涵意

這顆是幀數換算，關鍵字是那個神祕的 17：

max(5, round(a * 24)) + (5 - (max(5, round(a * 24)) % 17)) % 17

拆解：
1. a = 時長秒數（PrimitiveFloat）
2. a × 24 = 秒轉幀（24fps）
3. max(5, ...) = 至少 5 幀
4. % 17 補齊 = 把幀數補到 17 的倍數

為什麼是 17？

17 是 H3 模型的時序 chunk 大小——擴散 transformer 是「一組一組」處理時間軸的（temporal tiling）。幀數若不是 17 的倍數，模型得補 padding 或出錯，所以先算好補齊。

建議

• 不用動。想改 fps 就改 CreateVideo 的 fps 和這裡的 24

PrimitiveFloat（節點 199 / 292）

涵意

時長秒數。你迷因/狗狗 = 10s，參考圖 = 15s。

建議

• 這是你的 Python 腳本注入點（--duration）
• H3 單段有長度上限（社群常做到 10–15s，更長要分段，見 Motion Context / Director）

ResolutionSelector（節點 200 / 290）

涵意

決定輸出解析度，用「長寬比 + 百萬像素 + 對齊」的方式算，比直接填 WxH 直覺。

建議

• 0.6MP 直式 ≈ 你的日常片，速度品質平衡
• 想更細 → 0.7–1.0 MP，但 VRAM 和時間都會漲（Pro 用 0.7）

VAEDecode / VAEDecodeAudio（213/304、208/302）

涵意

把採樣完的畫面 latent 和音訊 latent 分別解碼成像素幀 / 波形。H3 因為有雙 VAE，所以有兩顆解碼節點。

MiniMaxH3DualClockSamplerT8（T8 節點包，進階加速）

出現在 T8 的「二階段超級加速」工作流（見 04-工作流/03-T8-SOL-Engine），你的 Fast 管線用的是 res_multistep 4 步，兩者路線不同。

涵意

H3 的 latent 是 video(24ch) + audio(32ch) 打包一條流。一般採樣器讓音訊跟著影片的 sigma 排程跑（音訊被迫等影片收斂）；Dual-Clock 把音訊掛到自己的時間鐘，兩條流各走各的收斂曲線。

優缺點

• ✅ 影片＋音訊一起個位數步完成（vs 官方各 30–50 步）
• ✅ 音訊不用等影片慢收斂，效率更高
• ⚠️ 需搭配 turbo LoRA 使用；純原廠模型壓到 4–8 步會欠收斂
• ⚠️ 參數來自 T8 節點包（comfyui-minimax-h3-audio-T8），非 ComfyUI 內建

CreateVideo（209 / 296）

涵意

把解碼好的幀組裝成影片檔，fps=24、bit_depth=8。

SaveVideo（193 / 285）

涵意

存檔，filename_prefix: video/MiniMax_H3 → 輸出到 D:\Comfy-Desktop\ComfyUI-Shared\output\video\。

節點剖析 ④ Pro 進階節點（T8 / 加速 / 省 VRAM）

你的 MiniMax_H3_Pro.json 用了這些社群節點（主要來自 T8mars/comfyui-minimax-h3-audio-T8，288 節點包）。這些是「把 H3 壓榨到極致」的工具。

MiniMaxH3MemoryEfficientSageAttentionPatch（節點 291）

涵意

掛上 SageAttention——一種記憶體高效的 attention 內核，加速 transformer 的注意力計算。

優缺點

• ✅ 顯著加速 + 省 VRAM（注意力是最大瓶頸）
• ⚠️ 需要對應的 CUDA 環境，某些卡/驅動可能不相容

建議

• 你在 Fast 工作流也有提到「sage attention patch」預設啟用——這是標配加速，留著

MiniMaxH3MultiRateSamplerEXPT8（節點 304）

涵意

多速率採樣器（T8 實驗版）——不同擴散時間步用不同精度的評估，前面粗、後面細，省計算又不犧牲品質。

建議

• 進階調校用，日常 Fast 不需要；想壓 Pro 的時間可以試

MiniMaxH3AVDecodeT8（節點 296）

涵意

AV 合併解碼（T8）——把畫面＋音訊的 latent 一次解碼合併，比官方分兩顆 VAEDecode 更順。

MiniMaxH3AudioConditioningT8（節點 307）

涵意

音訊條件控制（T8）——支援參考音色、原聲鎖定、對白驅動口型等。ref_image_size: max 是你 Pro 工作流設的值。

優缺點

• ✅ T8 包的核心賣點：口型同步（Vocal Lock）、參考音色、長片音軌
• ⚠️ 進階功能要照 T8 的範例工作流逐步來，別一次疊太多 LoRA/加速器

UniBlockSwap（節點 309）

涵意

區塊置換——把 transformer 的部分 block 在採樣過程中搬到 CPU RAM，需要時再搬回 GPU。用「記憶體換 VRAM」。

優缺點

• ✅ 讓大模型在 VRAM 不足的卡上也能跑
• ⚠️ 會拖慢速度（CPU↔GPU 搬資料有代價）

建議

• VRAM 不夠時才開，否則別用

ReservedVRAMSetter（節點 269）

涵意

保留 VRAM——劃出一塊 VRAM 不給 ComfyUI 用（留給系統/其他程式），避免 OOM 或驅動崩潰。

建議

• 你 eGPU 是 16G，若常跟桌面/其他程式搶 VRAM，可設 1–2G 保留

CLIPLoaderGGUF（節點 368）

涵意

載入 GGUF 量化的文字編碼器（Pro 用 qwen3vl_32b_minimax_h3-Q4_K_M.gguf），比 int8 safetensors 更省 VRAM。

建議

• 這是把 32B 編碼器從 int8 進一步壓到 Q4 的手段，VRAM 極度吃緊時用

Script 網頁版的 TE 節點（提示詞增強）

你的 Video_Gen 網頁 3 個工作流多了這組（QwenTE_* / TE_*）：

涵意

這組讓網頁使用者不用手寫 Gem 格式——輸一句想法，Qwen 幫你擴寫成完整劇本再送進 H3。

建議

• 你 CLI 端（cron）是手寫 Gem 格式，網頁端（手機）靠這組自動增強，兩條路都保留

核心組件 ① UNET（擴散主體）

UNET / DiT 是真正「畫」出影片每一幀 + 聲音的擴散模型。它在你 ComfyUI 的 diffusion_models/ 資料夾，是你機器上最大的檔案。這篇盤點你手上的 5 個版本，並講清它們的差異。

一句話

H3 的 UNET 有兩大變體：FL2VA（純文字生影片）和 Ref2VA（參考圖生影片），再乘上不同的量化方式（fp8 / int8 / GGUF Q3）。

模型清單

檔名關鍵字拆解

逐個說明

1. minimax_h3_fl2va_pruned_fp8_scaled（20.96 GB）⭐ 你主力

• 內容：FL2VA 變體 + 剪枝 + FP8 量化。你每天迷因/狗狗/跳舞和網頁分頁都跑這顆。
• 優點：fp8 精度損失極小、VRAM 需求合理（約 21GB 檔）、速度/品質平衡最好。
• 缺點：fp8 仍有極輕微品質損失；pruned 剪枝理論上可能裁掉少數冷門能力。
• 適用：日常 T2V 自動化（cron），不建議為省 VRAM 換更激進的量化。

2. minimax_h3_ref2va_pruned_fp8_scaled（20.96 GB）

• 內容：Ref2VA 變體（參考圖專用）+ fp8。
• 優點：人物外觀一致性最強（鎖參考圖人臉/服裝）。
• 缺點：同 fp8 輕微品質損失。
• ⚠️ 注意：你目前的 Fast_Reference 工作流其實是拿 fl2va 模型 + MiniMaxH3ReferenceToVideo 節點在跑，並不是用這顆 ref2va 模型。這顆是官方 ref2va 節點的配對模型，可當備用/對照。

3. MiniMax_H3_Ref2VA_pruned_int8_convrot（20.97 GB）

• 內容：Ref2VA + int8 convrot（更省 VRAM 的量化）。
• 優點：int8 比 fp8 更省 VRAM；convrot 減少量化誤差。
• 缺點：int8 品質略降（Pro 用高步數補回）。
• ⚠️ 待驗證：你的 MiniMax_H3_Pro.json 裡 UNET 節點寫的是 minimax_h3_fl2va_pruned_int8_convrot.safetensors，但資料夾裡實際檔案名是 MiniMax_H3_Ref2VA_pruned_int8_convrot（fl2va vs Ref2VA 對不上）。Pro 工作流可能因此找不到模型——值得開一次確認。

4/5. MiniMax-H3-FL2VA/Ref2VA-Q3_K_M.gguf（15.57 GB）

• 內容：GGUF 的 Q3_K_M 量化（最省空間）。
• 優點：檔最小、可 CPU 推理（GGUF 格式）、極低 VRAM 也能跑。
• 缺點：Q3 量化品質損失明顯，畫面細節會掉。
• 適用：VRAM 極度不足（<8GB）或想試 CPU 推理時才用；你有 16GB eGPU，一般用不到。

選用建議

日常自動化（cron）      → fl2va_pruned_fp8_scaled（你已在用）
參考圖鎖外觀             → ref2va_pruned_fp8_scaled（對照用）
想省 VRAM 上 Pro 高品質  → Ref2VA_pruned_int8_convrot（但先核對 Pro 工作流檔名）
VRAM <8GB / CPU 推理     → Q3_K_M GGUF（最後手段）

待驗證清單

• Pro 工作流 unet_name 與實際檔名不符（fl2va vs Ref2VA）——開 ComfyUI 確認 Pro 能正常載入
• ref2va vs fl2va 模型在「參考圖」任務上的實際畫質差異

核心組件 ② 文字編碼器（Text Encoder）

文字編碼器是 H3 的「文字理解大腦」，把 prompt 轉成語義向量餵給 UNET。底層是 Qwen3-VL 32B。檔在 text_encoders/ 資料夾。

🔑 架構真相（2026-09-04 實測驗證）

H3 的文字編碼器不是完整模型，被拆成三塊，各有功能：

⚠️ 重要教訓：上次想換 generation_tail_50_63 當影片條件編碼器 → 用錯元件，載入器建了完整架構卻只有 tail 權重 → 報錯 Cannot copy out of meta tensor。generation_tail 是給「prompt 生成」階段用的，不是影片條件。

你資料夾現有的檔案（6 個）

🎯 外部候選（2026-09-04 從 HF 撈到，未裝）

⭐ sakamakismile/Qwen3-VL-32B-Heretic-MiniMax-H3-NVFP4

qwen3vl_32b_heretic_minimax_h3_nvfp4.safetensors   —  15.68 GB

• ✅ 去審查（Heretic = 社群 uncensor 方法）
• ✅ 15.68GB vs 26GB ≈ 省 40%
• ✅ 完整 safetensors（含視覺塔）→ stock CLIPLoader (type=minimax) 直載，免裝任何東西
• ⚠️ nvfp4 = 4-bit，比 int8（8-bit）精度低 → 字理解可能略降

最小（但要裝 fork）nif0/Qwen3-VL-32B-Instruct-ultra-uncensored-heretic-H3-GGUF

• ✅ 去審查 + GGUF + 可小到 6.7GB
• ⚠️ 需裝 Nif00/ComfyUI-GGUF fork（或 H3-Multishot 的 H3 Clip Loader）才能載 GGUF
• 其他可靠 GGUF：joeygambino/MiniMax-H3-encoder-GGUF（Q4_K_M/Q5_K_M，32 萬下載）

🤔 關鍵結論（實測後的真實認知）

文字編碼器大小 ≠ 生成速度。

• 編碼器只跑一次（載入→編碼 prompt→卸載），採樣 4 步每步都不再碰它
• 真正吃 10–15 分鐘的是 UNET 採樣（16GB 卡放不下 21GB UNET → CPU offload）
• 換小編碼器省的是「載入時間 + 系統 RAM」，不是採樣速度
• 更低精度（4-bit）甚至可能讓字理解略降

❌ 已實測：generation_tail 換裝失敗（用錯元件）
⏳ 測試中：sakamakismile NVFP4（int8 UNET + NVFP4 編碼器組合）
✅ 已實測 2026-09-04：sakamakismile NVFP4（15.68GB）+ int8 UNET 組合成功載入，生成 15s 影片正常，795s（13分15秒）落正常範圍 → 換小編碼器不變快，但省系統 RAM～10GB

待驗證清單

• generation_tail 不能用標準 loader 當影片條件（實測失敗）
• sakamakismile NVFP4（15.68GB）用 stock loader 載成功 + 生成正常（795s）
• 4-bit vs 8-bit 的字理解品質差異（對比 26GB int8）

核心組件 ③ 影片 VAE（Video VAE）

影片 VAE 負責畫面 latent ↔ 像素之間的壓縮與還原。採樣是在「壓縮後的 latent 空間」進行（省算力），最後靠這顆 VAE 解碼成看得見的影片幀。檔在 vae/ 資料夾。

模型清單

說明

minimax_h3_video_vae_fp16（5.21 GB）

• 內容：H3 官方唯一的影片 VAE，fp16 精度。所有工作流（Fast / Reference / Pro / 網頁）都共用這顆。
• 優點：
• 官方配對，解碼品質有保障
• fp16 在速度與精度間平衡
• 缺點：
• 體積大（5.21GB）——社群 latent upscaler 作者指出這是顆「昂貴的 5B 參數 VAE」，是超分/解碼的效能瓶頸
• 沒有其他可選版本（不像 UNET 有各種量化）
• 適用：就是它，沒得換。但值得知道它是效能熱點。

為什麼這顆 VAE 是重點（影響你後續超分）

你在 04-工作流/02-社群最佳實踐.md 看到的 latent upscaler（LBH-123-AI/Comfyui_Minimax_h3_latent_Upscaler）核心賣點就是：

在 latent 空間直接超分（24ch），繞過這顆昂貴的 5B 參數 VAE 解碼/編碼。

意思是：如果你想從 0.6MP 放大到 1080p，傳統做法是「VAE 解碼成像素 → 超分 → 再編碼」，這顆 5B VAE 會變成瓶頸；潛空間超分則跳過它，直接在 latent 上放大，省下大量時間。

待驗證清單

• 0.6MP 直出 vs 潛空間超分到 1080p 的實際品質/時間對比
• 這顆 VAE 是否有 fp8/量化版可省 VRAM（社群是否有出）

核心組件 ④ 音訊 VAE（Audio VAE）

音訊 VAE 負責聲音 latent ↔ 波形之間的壓縮與還原。這是 H3 跟其他影片模型最大的不同點——它的音訊不是後製配的，而是跟畫面在同一次採樣裡一起生出來的，這顆 VAE 就是「原生音訊」的實體基礎。檔在 vae/ 資料夾。

模型清單

說明

minimax_h3_audio_vae_fp32（0.61 GB）

• 內容：H3 官方唯一的音訊 VAE，fp32 全精度。所有工作流共用。
• 優點：
• 官方配對，音訊解碼品質有保障
• fp32 比影片 VAE 的 fp16 更精——音訊對精度更敏感，官方刻意用全精度
• 體積小（0.61GB），負擔不大
• 缺點：
• 沒有其他版本可選
• 跟影片 VAE 一樣，是採樣後解碼的必要步驟
• 適用：就是它，沒得換。

⚠️ 重要：兩個 VAE 都不能漏

你的工作流裡是兩顆 VAE 並行（VAELoader ×2）：

採樣完的 latent → 影片 VAE（VAEDecode）→ 畫面幀
                → 音訊 VAE（VAEDecodeAudio）→ 波形

• 漏接音訊 VAE → 影片沒聲音（只剩畫面）
• 漏接影片 VAE → 只剩聲音沒畫面

這是 H3 工作流最常見的接線錯誤，Debug 時先檢查這兩顆。

音訊相關的延伸（T8 節點）

你在 04-工作流/02-社群最佳實踐.md 看到的 T8mars/comfyui-minimax-h3-audio-T8 包，就是在這顆音訊 VAE 之上加碼：

• Vocal Lock（鎖人聲，畫面動作跟獨立人聲走，完整歌最後才混入）
• 參考音色、口型同步（lipsync）、長片音軌
• 進階音訊控制走 MiniMaxH3AudioConditioningT8 節點（你 Pro 工作流有）

待驗證清單

• T8 的 Vocal Lock / 口型同步實測（若你之後想做唱歌/對白片）

核心組件 ⑤ Turbo LoRA

Turbo LoRA 是 H3 的加速器：把原本 ~20 步的採樣蒸餾成 4 步，速度提升約 5 倍。它是「品質 vs 速度」取捨的總開關。檔在 loras/ 資料夾。

模型清單

⚠️ 同資料夾還有 wan2.2_i2v_lightx2v_4steps_lora_v1_high/low_noise.safetensors（各 1.23GB）——那是 WAN 2.2 的加速 LoRA，不是 H3，別搞混。lightx2v 是跨模型的加速技術，不是 H3 專屬。

檔名關鍵字拆解

逐個說明

1. minimax_h3_fl2v_lightx2v_turbo_4step_v0.1_comfy（1.96 GB）⭐ Fast 主力

• 內容：lightx2v 的 H3 turbo LoRA v0.1，你 Fast 工作流用 強度 0.75。
• 優點：4 步生成，速度提升約 5 倍；強度 0.75 = 「打折的加速」，保留較多原始品質。
• 缺點：已知 4 步 + 大動作 → 殘影/拖尾（跳舞片要注意）。
• 適用：日常迷因/狗狗/跳舞（靜態或小動作最穩）。

2. minimax_h3_turbo_4STEPS_comfyui（0.78 GB）⭐ Pro 在用

• 內容：另一個來源的 turbo 4 步 LoRA，Pro 工作流用強度 1.0。
• 優點：更小（0.78GB）、強度 1.0 = 全速加速。
• 缺點：強度 1.0 + 4 步，品質折損比 0.75 更明顯（但 Pro 靠高步數/多速率採樣補回）。
• 適用：Pro 工作流（或想壓到極致速度時）。

💡 重要升級資訊（來自論壇情報）

你現在用的是 lightx2v v0.1。社群更新的 turbo LoRA 是 larryvrh 的 v4-600（見 05-論壇情報/03-HF模型庫.md）：

• v4-600 是目前最強 checkpoint：靜態/小動作鏡頭大幅改善、微細節（臉/手指/質感）更好、完全解決早期 v1 的過度銳化「塑膠感」
• 唯一取捨：4 步 + 大而快的動作會殘影
• 解法：步數 4 → 6–8，殘影幾乎消失，且 v4 比 v1 更能承受高步數
• 只有「4 步 + 重動作」才考慮退回 v1-850

建議下載換裝：https://huggingface.co/larryvrh/MiniMax-H3-Turbo-Lora（v4-600 checkpoint）

選用建議

日常靜態/小動作          → lightx2v v0.1 @ 0.75（你已在用）
跳舞/大動作（現況殘影）  → 步數 4→6-8，或換 larryvrh v4-600
追求極速                → turbo_4STEPS @ 1.0（Pro）
最高畫質                → 不用 turbo，回原生 ~20 步（慢但穩）

待驗證清單

• 換 larryvrh v4-600 後，跳舞片殘影是否消失
• 步數 4 vs 6 vs 8 的品質/時間實測（記到 06-實驗記錄.md）

工作流 ① 你現有的 7 個工作流

你 Documents/Programs/ 下的實際檔案。這篇講「什麼時候用哪個」。

對照表

三種任務路徑

1. 純文生影片（cron 自動化）

prompt(Gem) → MiniMaxH3ImageToVideo → 4步採樣 → 雙VAE → 24fps

• 迷因/狗狗/跳舞都用這條，無首幀，模型自由發揮
• 跳舞片注意：大動作 + 4 步可能殘影

2. 參考圖生影片（自拍穿越）

devan.png → LoadImage → MiniMaxH3ReferenceToVideo → 4步採樣 → 雙VAE

• <Picture 1> 鎖你外觀，Gem 劇本描述你「做什麼」
• 你 8/12 已把體重描述從 70→75kg，記得劇本裡的人物描述要同步

3. 首幀生影片（網頁分頁3）

首幀圖 → ImageResizeKJv2 → MiniMaxH3ImageToVideo → ...

• 用「第一幀」定住開場畫面，後面自由發展

腳本 ↔ 工作流對應

已知約束

• 單段時長：10–15s 最穩，更長要分段（Motion Context / Director）
• 0.6MP 直式：目前主力解析度，Pro 才上 0.7
• 共用輸出計數器：video/MiniMax_H3 前綴跨工作流共用，重啟歸零
• eGPU 單顆共用：所有管線共用 RTX 5060 Ti，排程別撞車（狗狗 04:00 / 跳舞 06:00 / 迷因 07:00 已錯開）

網頁兩分頁已統一成二採 + #12（2026-09-13）

Homepage\Video_Gen 的「參考圖」與「文生」兩分頁都改走 MiniMax_H3_Ref_Resampled.json，
模型用 #12 配置（int8 Ref2VA / FL2VA + NVFP4 CLIP + lightx2v 4 step），與四支每日 cron 同管線：

• 會講話（分頁一有聲音參考、或 prompt 內有台詞 <d>…</d>、「」→）用 Ref2VA int8；不會講話用 FL2VA int8（特寫較銳、同速）。每次執行的 CONFIG| log 會寫出選中理由。
• 影片長度限制 4–15 秒（節點 310 限制），網頁下拉與後端驗證都已同步（分頁三仍 1–15）。
• --suffix 可加「純淨畫面、無文字無字幕」尾端後綴，但 2026-09-13 實測擋不住燒字幕 → 預設關閉。
• 分頁三（首幀）仍是舊 Script_FirstFrame 管線。

後段影片放大 vs 二採（兩條不同的「變大」路徑）

你手上有兩條會「把影片變大」的流程，本質完全不同，不要搞混：

功能涵意：後段影片放大是「事後把影片拉大」，它不會新增任何真實資訊，只是用 AI 把像素補密、同時帶上一層「銳化/磨皮」的修飾感。你實測過：DLSS 超分成品反而不如 Fast 單次生成（608×1056）耐看——因為解析度提升無法抵消後段超分帶來的 AI 修飾感。

→ 結論：重自然感時，選「二採」（模型自己補細節）或直接單次生成，別迷信後段超分；後段超分只在需要「特定輸出解析度」且能接受修飾感時用。RTX 超分細節另見 rtx-vsr-upscale skill（DLSSNR_Video 優於 RTX VSR）。

工作流 ② 社群最佳實踐（值得試的節點包）

搜集自 GitHub（star 排序）的 MiniMax H3 社群節點包。這些是「你可能不知道、但能解決你痛點」的東西。尚未在你機器實測，先用來擴充視野。

高優先（直接對應你的痛點）

🎬 長片分段 — ComfyUI_MiniMaxH3_Director（1330★）

• 做什麼：多段音視頻「導演台」節點，把分段計畫/條件編碼/採樣解碼/匯出整合在一個節點裡
• 任務類型：t2v / i2v / fl2v（首尾幀）/ r2v（參考主體）/ v2v（影片轉影片）/ rv2v
• 殺手鐧：「段間引導」——用上一段末尾 5/22/39 幀釘住下一段，做動作＋音訊無縫銜接（原生立體聲）
• 適合你：想把短片串成長片、或做多分鏡故事片時
• repo：https://github.com/AIMixer/ComfyUI_MiniMaxH3_Director

👤 小臉修復 — ComfyUI-H3-FaceRefine（318★）

• 做什麼：H3 人頭佔畫面比例小時臉會糊，這節點逐幀偵測臉 → 裁切放大 → H3 重繪 → 貼回
• 原理：糊的根源是「頭在畫面的比例」，不是輸出解析度（720p 也一樣糊）
• 適合你：跳舞片人物全身入鏡時，臉常常糊 → 這個能救
• repo：https://github.com/Carasibana/ComfyUI-H3-FaceRefine

🔗 多段無縫銜接 — ComfyUI-H3-Motion-Context（890★）

• 做什麼：把 A 片段的尾幀＋音訊餵給 B 片段，讓動作/速度/方向/聲音跨剪接延續
• 關鍵差異：直接切前一幀的 latent（bit 級別一致），避免官方 Add Guide 的「解碼→縮放→重編碼」造成的色彩漂移
• 需求：ComfyUI 0.34.0+（H3 的任意關鍵幀錨點）
• repo：https://github.com/NikoDemon80/ComfyUI-H3-Motion-Context

中優先（加速 / 超分）

⚡ 免訓練加速 — ComfyUI-Spectrum-MiniMax-H3（623★）

• 做什麼：把 Spectrum（spectral feature forecasting，Chebyshev 多項式 + ridge regression 在線擬合）接到 H3，跳過部分 transformer 評估來加速
• 論文：https://arxiv.org/abs/2603.01623
• 適合你：想在 4 步之外再壓時間時試
• repo：https://github.com/xmarre/ComfyUI-Spectrum-MiniMax-H3

🔍 潛空間超分 — Comfyui_Minimax_h3_latent_Upscaler（503★）

• 做什麼：在 latent 空間直接超分（24ch），繞過昂貴的 5B 參數 VAE 解碼/編碼
• 2026-08-28 新：MMH3 Split Upscale（tiled hires-fix 式）——時序切塊＋空間切磚，縫合去噪＋雙級色彩匹配＋三重時序錨點
• 適合你：0.6MP 想放大到 1080p+ 又不想重跑時
• repo：https://github.com/LBH-123-AI/Comfyui_Minimax_h3_latent_Upscaler

🚀 Turbo 升級 — ComfyUI-MiniMax-H3-Turbo（546★）

• 做什麼：你已用 lightx2v turbo，這是 larryvrh 的更新版（v4-600 最佳）
• 兩個節點：Turbo LoRA（MODEL→MODEL）+ Turbo Sampler（→SamplerCustomAdvanced）
• repo：https://github.com/Larryvrh/ComfyUI-MiniMax-H3-Turbo

進階（T8 全能包）

🎧 comfyui-minimax-h3-audio-T8（933★，288 節點）

• 你 Pro 工作流的 T8 節點來源
• 做什麼：T2VA/I2VA/L2VA/FL2VA/Ref2VA、參考音訊、口型同步（Vocal Lock）、長片、DLSS-NR 超分、OpenVDN 8 步加速
• 注意：官方 README 提醒「不要一開始就疊多個 LoRA + 注意力加速器 + 採樣器」
• repo：https://github.com/T8mars/comfyui-minimax-h3-audio-T8

其他（一覽）

建議的試用順序

1. FaceRefine（解決跳舞片小臉糊，最貼你的痛點）
2. Turbo v4-600（換 LoRA，解決殘影）
3. Director 或 Motion Context（想做長片/多分鏡時）
4. latent upscaler（想放大解析度時）

每試一個，記到 06-實驗記錄.md，並更新這份「已實測」標記。

2026-10-30 四臂實測：作者「SelfLift 高清二采」vs 本機現有工作流

狀態：本機實測完畢（RTX 5060 Ti 16GB、限瓦 180W）。五段同條件：16:9、243 幀（10.125 s @24fps）、參考圖 devan.png、同 prompt、seed 20261030、euler/simple、cfg 1。
來源影片：YouTube LiC0G5H9Mw8（作者「小黃瓜」，5090 實測）。作者工作流：OneDrive\文件\AI\ComfyUI\MimiMaxH3\*.json（原始檔一支都沒改）。

0. TL;DR

1. 作者的加速不是新節點，是排程拆法：一次生成把 8 步拆成 6 步低解析 + 2 步高解析，中間用 H3 latent upscaler 過渡（lowres_scale 0.5 / rho 0 / w 0.5–1.0）。
2. 我們家的 SelfLiftH3Sampler 是同一套演算法、同樣的預設參數，差別只在步數分配（我們 4 低 + 2 高、作者 6 低 + 2 高）。⇒ 單段影片不需要為二采換外掛。
3. 今天補裝了作者用的 ComfyUI-MiniMaxH3-TimelineDirector v0.8.0；它的價值在時間軸／多段／續接／鎖原音，單段 10 秒用不到，而且它內部呼叫的 SelfLift 參數跟我們那顆節點一模一樣。
4. 唯一本機完全拿不到的加速是 SageAttention：sageattention 沒有 cp313/cu130 wheel，PathchSageAttentionKJ 一接就 ModuleNotFoundError（auto 不會自動退回）。
5. 作者標示的 1920×1088 × 10 秒，16GB 卡跑不動：hostbuf_file_reader_read failed → aimdo memory compile error → 後端 abort。降到 1024×576 才完整跑完。
6. 實測（同模型、同解析度）：我們 208.4 s／作者 293.2 s／一採抽卡 106.7 s／一採→精修 234.0 s。

1. 影片在講什麼（逐字稿重點）

他對「二采」的兩種定義（這段才是重點）：

• 方案一（先低清再放大再重跑）：低清生成 → 放大 → 低 denoise（0.1–0.2）再跑。時間相加（5 分 + 5 分 = 10 分）。適合抽卡：先抽 20–30 支挑一支再放大。
• 方案二（SelfLift，一次拆步）：目標 1920×1080、8 步，前 6 步在 960×540、後 2 步在 1920×1080。比方案一快，也比直接全解析度 8 步快。

代價他也講了：加速愈激進，高動態場景愈容易糊、拖影、細節崩。文戲／日常／平緩運鏡適合加速；打鬥、複雜運鏡、大場景要放棄一點速度。

2. 五支工作流的真相（省你比對時間）

五支 JSON 節點圖完全一樣（11 節點），只差三個旋鈕：

⇒ 影片的「四大加速」不是四支不同工作流，是同一支的四個開關。

3. 作者工作流（E）的節點結構

UNETLoader  minimax_h3_ref2va_pruned_int8_convrot
  └─ LoraLoaderModelOnly  dmad_…_4step @1.0
       └─ PathchSageAttentionKJ  auto
            ├─ BasicScheduler  simple / 8 步 / denoise 1
            │    └─ KSamplerSelect  euler
            └─ MiniMaxH3FiniteSegmentVideoSampler (seed 42)
                 ↑ MiniMaxH3TimelinePlanner(1920×1088, 6.5833s, timeline_data)
                 ↑ CLIPLoader qwen3vl_32b_minimax_h3_int8 / VAELoader video fp16 / audio fp32
                 → GetVideoComponents → SaveVideo

三個讀原始碼確認的細節：

• transition = 總步數 − secondPassHighSteps ⇒ 8 − 2 = 6 低解析步。
• 低解析倍率固定 0.5、rho 0、w_min 0.5、w_max 1.0；upscaler 必須是 H3 相容（LTX 的會被拒絕）。
• 幀數硬限制 5 + 17n：10 秒 → 最近 243 幀（10.125 s），240 幀會直接報錯。

timeline_data 才是整份計畫：fps 24、selection{start,duration}、images[]、videoClips[]（含 referenceMode: edit、referenceWidth/Height）、segmentConfig.segments[]（每段 images/audios/prompt/startFrame/endFrame）。

4. 與我們現有工作流的差異（節點級）

完全可共用（不用重抓、不用改）：UNET、CLIP、video/audio VAE、BasicScheduler、KSamplerSelect、LoraLoaderModelOnly、minimax_h3_latent_upscaler_3d_bf16、GetVideoComponents、VHS_VideoCombine。

真的不能共用：只有「誰來拆步」那一段與「時間軸分段」。其餘全是排列組合。

本機缺口：① sageattention 未安裝（無 cp313/cu130 wheel）② 作者的 dmad_…_4step LoRA 沒有 → 實測一律改用我們現有的 lightx2v_turbo_4step（同為 4-step 蒸餾）。

5. 實驗設定

• 作者原始 1920×1088 在本機爆掉（見第 6 節），因此統一：高解析 1024×576、一採低解析 512×288，維持他「高解析一半」的設計。
• 243 幀（10.125 s）／seed 20261030／prompt 全部相同（單鏡、窗邊暖光、轉頭看窗外、無人聲對白）。
• A 與 A2 的差別：A ＝ 我們 workflow 原封不動（內建 10Eros hybrid int8）；A2 ＝ 同一支 workflow 但 UNET 換成跟作者一樣的 ref2va int8，用來隔離「工作流差異」與「模型差異」。

6. 實測結果

負面結果（保留）：1920×1088 / 8 步 / 243 幀 → 執行 38 秒後 hostbuf_file_reader_read failed → aimdo memory compile error → Fatal Python error: Aborted，後端需重啟。不是步數問題，是 2MP × 243 幀的權重 prefetch／attention 超過 16GB。

另一筆對照：C 在 960×544 / 6 步 = 459.6 s（模型未快取），同 6 步下「0.52MP → 0.13MP」約 4.3 倍，與像素量大致線性。

7. 畫質與機制觀察

• 速度：同模型下我們 208.4 s vs 作者 293.2 s ⇒ 我們快 29%（差在 4 低步 vs 6 低步）。作者多花的 2 步低解析換的是結構穩定度。
• 抽卡：C 的 106.7 s 是 B 的 36%。抽 20 支的成本約等於 2.1 支全流程。
• 接二采的成本：C + D = 340.7 s，比直接跑 B（293.2 s）多 16%，但只在你選定草稿之後才付。
• D 的內容延續性（可量化）：D 對「C 放大到同尺寸」的 PSNR 是 24.7 / 25.2 dB（frame 120 / 228）；兩個獨立生成的臂之間只有 7–14 dB ⇒ D 確實是「同一支片被精修」，不是重生成。這正是「抽對卡後直接優化、避免不一致」要的效果。
• 銳利度（Laplacian 變異數，統一縮到 1024×576）：frame 120 → A 26.4 / A2 29.5 / B 43.6 / C 11.6 / D 22.3；frame 228 → A 25.0 / A2 29.8 / B 15.4 / C 6.1 / D 8.8（該幀已轉成後腦勺逆光，數字偏低）。⇒ 原生二采（B）的高頻細節最高；D 靠 DLSS 補回一些但仍在 B 之下；C 明顯最軟。
• 我們的 SelfLift（A/A2）偏軟的原因：只有 2 步高解析、低解析階段只跑 4 步（作者 6 步），結構與高頻都少一截；輸出端 DLSS 會再抹一次。
• 構圖不完全一致：即使同一顆 ref2va、同 seed，A2 與 B 的機位仍有位移（PSNR 7–9 dB）——差在條件編碼路徑（JZL bus vs Timeline encoder）與 ref_scale 1.1。

8. 建議

1. 抽卡走 C：512×288、6 步、關二采，1 分 47 秒一支。
2. 定稿只補二采（D）：載入成品 → VAE 編碼 → latent 2× → 3 步 denoise 0.3。內容延續性 25 dB，動作與構圖直接沿用抽到的草稿，不會重生成走鐘；代價是比一次到底多 16% 時間。
3. 單段影片不用換 TimelineDirector：二采能力 SelfLiftH3Sampler 已有且參數相同；外掛留給多段長片／鎖原音。
4. 想吃 SageAttention 再裝：沒有 cp313/cu130 wheel 就一定要把 PathchSageAttentionKJ 拿掉（auto 會直接拋錯，不會退回）。
5. 16GB 卡的解析度天花板：10 秒 × 2MP 不可能；要 1920×1088 只能縮短片長（約 6.6 秒／158 幀）或改走分段。

9. 待辦

• 找 sageattention 2.2.0 的 cp313/cu130 預編 wheel；沒有就要自己編（需 CUDA toolkit）。
• 作者 dmad_minimax_h3_4step_full_critic LoRA 要不要抓（目前用 lightx2v 4-step 替代）。
• 1920×1088 用 6.58 秒（158 幀）再試一次，確認是不是只有長片才爆。
• D 的 denoise 從 0.3 往上試（0.35–0.45），看能不能把 B 的高頻細節補回來而不走鐘。

10. 產物

• 五段影片：C:\Users\devan\Documents\Programs\h3ab_20261030\（A_ours_selflift.mp4、A2_ours_ref2va.mp4、B_author_full.mp4、C_author_draft_only.mp4、D_draft_refine.mp4）
• 腳本：C:\Users\devan\Documents\Programs\h3_ab_20261030.py（四臂工作流產生器）、compare_arms.py（抽幀／指標）
• 原始數據：h3ab_20261030\results.jsonl、metrics.json

論壇情報 ① GitHub 節點生態（搜尋於 2026-09-04）

api.github.com/search/repositories?q=comfyui+minimax（star 排序）。原始資料：_raw/github_repos.json。

完整清單（Top 15）

觀察

• 生態系爆炸式成長：H3 上線後社群節點迅速湧現，一個月內就出現長片（Director/Motion Context）、修臉（FaceRefine）、加速（Spectrum/Turbo）、超分（Upscaler）四大方向
• 你 Pro 工作流的 T8 節點 = T8mars 包，這是目前功能最全的包
• 「Director」有多個同名 repo（AIMixer 1330★、huangserva 887★、seesee75 282★），要挑主流的那個

論壇情報 ② Civitai 工作流（搜尋於 2026-09-04）

civitai.com/api/v1/models?query=...&sort=Most Downloaded。原始資料：_raw/civitai_*.json。

MiniMax H3 相關（下載量排序）

LTX 相關（對照）

觀察

1. LTX 2.5 確實存在（LTX25 | MM H3 | Krea2 混合工作流），但下載量第一的仍是 LTX 2.3——2.5 還在爬升期
2. H3 的熱門工作流主軸：Turbo 4 步、6GB VRAM 極限、無縫多鏡頭、LTX Refine 混搭
3. 值得抓來研究的：
   - Minimax H3: EZ | Turbo . Optimal . RTX Upscale . LTX Refine（混搭 H3+LTX，可能是你的下一階段）
   - MiniMax-H3 Multishot — Seamless Chain（對照 Motion Context 方案）
   - Ultra Fastest True 4 Steps + HD Sound | 6GB VRAM（VRAM 極限壓榨）

備註：Civitai 需登入才能下載工作流檔，若要抓實際 JSON 給我網址，我用瀏覽器去撈。

論壇情報 ③ HuggingFace 模型庫（搜尋於 2026-09-04）

huggingface.co/api/models?search=...&sort=downloads。原始資料：_raw/hf_*.json。

MiniMax H3 模型（下載量排序）

LTX 模型（對照）

觀察

1. H3 官方版下載量是 LTX 官方版的 43 倍（21M vs 0.49M）——H3 熱度壓倒性領先，驗證了你「H3 是被最多人討論/增進的模型」的判斷
2. 你的模型來源都對得上：lightx2v/Minimax-h3-Turbo（LoRA）、官方 Comfy-Org/MiniMax-H3（節點）
3. 升級候選：larryvrh/MiniMax-H3-Turbo-Lora 的 v4-600（修殘影），值得抓來測

文字編碼器候選（2026-09-04 新增）

搜尋「去審查 + 小體積 + 可載」的文字編碼器，重點 repo：

已驗證架構：H3 文字編碼器 = 截斷 50 層（0–49，影片條件）+ 視覺塔 mmproj（I2V）+ generation_tail（50–63，prompt 生成用，非影片條件）。

實驗記錄

每次改參數 / 換模型 / 換 LoRA 的 A/B 實測都記這裡。格式：日期 → 改什麼 → 結果 → 結論。

模板（複製貼上）

### YYYY-MM-DD — 實驗標題
- **目的**：
- **改動**（工作流 / 參數 / LoRA）：
- **對照**（改前 vs 改後）：
- **結果**（畫質/速度/VRAM/殘影/音訊）：
- **結論**：✅ 採用 / ❌ 放棄 / ⏳ 待更多測試

待測清單（優先順序）

1. Turbo LoRA v4-600：跳舞片 4 步殘影 → 換 larryvrh v4-600，或步數拉到 6–8
2. FaceRefine：跳舞/自拍穿越的小臉糊 → 掛 FaceRefine 節點
3. LTX Refine 混搭：H3 生畫面 + LTX 精修（Civitai Minimax H3: EZ）
4. Pro vs Fast 對比：同一 prompt，Pro（int8 convrot 高步數）vs Fast（fp8 4步）畫質差異
5. LTX 2.5：裝一條 LTX 2.5 管線，與 H3 並排對照

2026-10-08 — H3 X2 VAE「直出 4K」（解碼階段 2× 放大）❌

• 目的：驗證 HF jinwyp/MinimaxH3_4K_ComfyUI 的「直出 4K」在 16GB 卡可不可行、值不值得
• 改動：自家 SelfLift 工作流手術 3 處 → 新增 X2 VAELoader（MiniMax-H3-X2-Detail-v1）＋327 換成 MiniMaxH3VAEDecodeFast（output_device=cpu，節點包須用 TripleHeadedMonkey 版）＋2606 largest_size 1920→3840；另建 Programs/build_selflift_x2_workflow.py、Programs/t2v_selflift_x2_smoke.py
• 對照：同 seed 20261008、8 秒、0.6MP、9:16、同 UNET（皆重啟後冷啟動）
• 現行：1106×1920／7.78 MB／Prompt executed 266.4 s（後段 66.5 s）
• X2：2212×3840／19.76 MB／336.2 s（後段 228.7 s ＝ ×3.4）
• 結果：跑得起來（顯存峰值 15.8 GB、最低剩 487 MiB 撐過；X2 log 確認 packed_channels: 12／PixelShuffle 2x）。但系統 RAM free 最低量到 0.0 GB（現行版 69.9 GB）；畫質無可見增益，白胸毛與高對比邊緣出現 16/32 px 週期性網格偽影（＝作者報告自述的格紋）；作者自己的研究報告就是 negative result（像素變多、資訊沒等比變多）
• 結論：❌ 放棄（已刪檔回收 5.3 GB）。可歸因成本＝後段 +162 s（8 秒片；15 秒外推多 5–6 分鐘）。要更大畫質改走 SeedVR2／FlashVSR 真超分或直接提高生成 MP。完整記錄：tech-skills/10-ComfyUI相關/39-H3-X2-VAE-4K解碼實測與不採用結論.md

2026-09-05 — T8 SOL Engine「二階段超級加速」全流程首跑 ✅

• 目的：實測 T8 二階段工作流（H3 864×480 草稿 + LTX-2.5 精修 1920×1088）在本機 16GB 卡能否跑通、速度多少
• 改動：完整補齊缺件——節點 v1.72.0、FeiHou Remix 原配三件套（34GB+2.7GB）、LTX-2.5 六件套（48.3GB）；工作流 JSON 改為中性口播 prompt（devan.png 主角，15s）；跳過 SageAttention patch（改 pytorch attention）
• 對照：本機 Fast 管線 15s 864×480 ≈ 795s（13.25 分）｜ 此工作流 15s 1920×1088 = 1068s（17.8 分）
• 結果：✅ 全流程跑通。第一階段 493s + 第二階段 575s；品質佳（人像還原/口型/動作自然）；唯一取捨是捨棄 SageAttention 記憶體優化
• 結論：✅ 採用——「多花 37% 時間 → 直出 Full HD」比直接 1080p 生成划算太多。文戲/口播片適用，大動作片仍不適用

2026-09-04 — int8 UNET + NVFP4 編碼器實測

• 目的：驗證「int8 UNET + NVFP4 編碼器」組合能否載入 + 是否變快
• 改動：Fast 工作流 → UNET 換 minimax_h3_fl2va_pruned_int8_convrot、CLIP 換 qwen3vl_32b_heretic_minimax_h3_nvfp4
• 結果：✅ 兩者都成功載入（NVFP4 用 stock loader 沒炸）、生成正常 15s 影片（9:16/24fps/有聲）
• 時間：795 秒（13 分 15 秒），落在 H3 15s 正常範圍（12–18 分）
• 結論：⏳ 組合能用＋省系統 RAM～10GB，但生成速度沒有明顯變化 → 印證「換小模型 ≠ 變快」，瓶頸在 UNET 採樣/offload。速度槓桿在 Spectrum 加速 or 降解析度。

2026-09-13 — 27 組速度/畫質矩陣 → #12 定案 ✅

• 目的：在「最快 × 畫質最乾淨」之間找出最佳 UNET/CLIP/LoRA 組合
• 改動：同一 prompt（台灣街道 遠景→臉部特寫）＋同參考圖＋同 seed，掃 3×3×3=27 組（UNET GGUF Q3 / fp8 / int8 × CLIP GGUF Q2 / NVFP4 / int8 × LoRA 4step / 8step / 8step+8stepLoRA）
• 結果：#12 = int8 擴散（Ref2VA pruned int8 convrot）+ NVFP4 CLIP + lightx2v LoRA + 4 steps 勝出——8s 僅 365s、小臉細節最不糊
• 附帶發現：8-step LoRA 無助益（小臉更糊、耗時相同 481s vs 480s）；GGUF UNET × NVFP4 CLIP 是高風險組合（跑 6 組後 GPU is lost 崩潰）
• 結論：✅ 採用 #12 為預設擴散配置

2026-09-13 — FL2VA vs Ref2VA：銳利度＋字幕實測（15s 吐金魚）✅

• 目的：驗證「FL2VA 更銳」傳聞，並確認 FL2VA 自產字幕是否為模型通病
• 改動：同 15s 吐金魚 prompt（devan.png 參考圖＋devan_voice.wav 聲音＋同 seed），只換擴散模型 Ref2VA int8 ↔ FL2VA int8
• 對照：
• 時間：兩者完全相同 848s（14分08秒）（都是 int8）
• 銳利度（Laplacian 變異數）：特寫 Ref2VA=19.2 vs FL2VA=34.5（+79%）；遠景平手（24.1 vs 23.6）
• 檔案：FL2VA 8.37MB > Ref2VA 6.56MB（細節較多）
• 字幕：FL2VA 把台詞燒成畫面字幕（t=7「你怎麼了」一字不差）；Ref2VA 完全無字幕
• 結論：✅ FL2VA 更銳、時間一樣，但有台詞就燒字幕；Ref2VA 無字幕。→ 定案「會講話 → Ref2VA，不會講話 → FL2VA」（詳見 01-模型總覽.md）

2026-09-13 — 四支每日 cron 統一成二採工作流 ✅

• 目的：把迷因/跳舞也從 Fast 工作流遷到二採（與狗狗/穿越一致），並套用模型分工
• 改動：
• 穿越 vlog、迷因 → Ref2VA int8（會講話→無字幕）
• 跳舞、狗狗 → FL2VA int8（不會講話→銳）
• 迷因/跳舞腳本從 MiniMax_H3_Fast.json（節點 194/199/211）遷到 MiniMax_H3_Ref_Resampled.json（strip 參考圖→純 T2VA，注入 2614/310/2617/323）
• 迷因 NEGATIVE_PROMPT 移除（二採無負面提示詞輸入；「奶油小生」壓制需改寫進 prompt subject_definitions）
• 結果：✅ 乾跑驗證過（strip+注入+UNET 全對）；時間變長（迷因 8-10→13-15 分、跳舞 8-12→10-14 分），換畫質/銳利度
• 結論：✅ 採用

2026-09-13 — 網頁 Video_Gen 兩分頁統一成二採 + #12（實跑驗證）✅

• 目的：把網頁「參考圖」與「文生」兩分頁也換成與四支 cron 相同的二採 + #12 設定（原分頁二還在舊 MiniMax_H3_Script.json 單次生成）
• 改動：
• t2v_video_gen.py：MiniMax_H3_Script.json（fp8 FL2VA 單次）→ MiniMax_H3_Ref_Resampled.json（strip 參考圖/聲音節點 → 純 T2VA，注入 2614/310/2617/323）
• 兩支腳本（video_gen.py、t2v_video_gen.py）新增擴散模型自動二選一：有聲音參考或 prompt 有台詞 → Ref2VA int8，否則 → FL2VA int8（可用 --model 覆寫）；seed 改每次隨機（舊版沿用工作流固定 seed，每次結果幾乎一樣）
• duration 下限改 4 秒（節點 310 限制 4–15）：app.py _parse_duration(min_sec=4)、app.js populateDuration(...,4)、兩支腳本各自擋 <4；分頁三仍 1–15
• 對照（實跑，4 秒 / 9:16 / 0.6MP，RTX 5060 Ti）：
• 分頁二（文生、FL2VA int8、無台詞）：181 秒 → 1120×1920、24fps、4.46s、4.1MB、含 AAC；畫格檢查：夜市牛肉麵構圖正確、無亂碼字幕、AI 痕跡輕微
• 分頁一（參考圖 + 聲音參考、Ref2VA int8）：200–201 秒 → 人物自然、畫質正常
• 換算：8 秒≈365s、15 秒≈848s（二採常態）
• 附帶發現：燒字幕是機率性的。同一組對話 prompt 4 支樣本：Ref2VA 2 支乾淨 / 1 支燒出台詞字幕，加了「純淨畫面、無文字無字幕」後綴的那支仍燒字幕（FL2VA 幾乎必燒）→ 後綴預設關閉，只留 --suffix 開關
• 結論：✅ 採用（兩分頁與四支 cron 至此完全同管線）

2026-09-28 — MinimaxH3 Latent Upscaler（latent 放大器）一采提速實測 ❌

• 目的：驗證社群 503★ LBH-123-AI/Comfyui_Minimax_h3_latent_Upscaler（3D conv v1、345M 參數、24ch latent 全 3D 卷積）能否取代 DLSS5、在一采（8 步）流程「不犧牲畫質就提速」
• 改動：下載 fp16 權重（minimax_h3_latent_upscaler_3d_conv_v1，放 latent_upscale_models/）＋節點包（ComfyUI 0.37.2 已註冊 MinimaxH3LatentUpscaler3D）；從網頁 8 步工作流 MiniMax_H3_Ref_Resampled_1pass8s.json 複製兩份變體（_latentupscale.json / _latentupscale_06mp.json）
• 對照（同 seed 20260928 / 同 prompt / devan.png，15s 9:16 / 8 步 / Ref2VA / 音頻 off / enhancer off）：
• A 基準：0.6MP 一采 → VAE 解碼(608×1056) → DLSS5 2× → 1920 ＝ 781s
• B：0.15MP 一采 → latent 2× → 0.6MP 等效 → DLSS5 → 1920 ＝ 221s（快 3.5×）
• B2：0.6MP 一采 → latent 2× → 2.4MP 解碼（無 DLSS）→ 1920 ＝ 882s（慢 13%）
• 結果：
• B 快 3.5× 但太軟/蠟感（0.15MP 基底過低，頭髮塊狀、衣物紋理抹平）
• B2 略勝 A：銳利度/邊緣/高頻微幅領先、時間穩定度幾乎相同（7.318 vs 7.338，無閃爍代價）、視覺保留較多毛髮/紋理、塗抹感較少
• B2 反而更慢 → latent 2× 後要在 2.4MP 做 5B VAE 解碼是瓶頸（印證「省時間不省 VRAM」）
• 附帶發現：一采工作流的 MinimaxH3LatentUpscaler3D 節點本來就內建但 dead（影片解碼直接吃一采原始 latent，放大器輸出接到已剪掉的二次採樣）；force_unload 被誤填成字串 "cuda"（應為布林）
• 結論：❌ 放棄。放大器本質是「加速工具不是品質工具」，原設計是「低解析生成→latent 放大→再二次採樣 refine」；既然二采已否決，它在一采就沒有提速立足點——要快掉畫質（B）、要畫質不快（B2）。維持 A（0.6MP 一采 + DLSS5）

研究日誌 CHANGELOG

所有新增/修改都記一筆，最新在上。格式：日期 — 改什麼（誰）

2026-09-28 — latent 放大器一采提速實測 ❌ 放棄

• 實測社群 LBH-123-AI/Comfyui_Minimax_h3_latent_Upscaler（3D conv v1）：下載 fp16 權重＋節點包，在網頁一采 8 步工作流做 A/B/B2 三變體
• A（0.6MP+DLSS5）781s 基準｜B（0.15MP+latent2×+DLSS5）221s 快 3.5× 但太軟｜B2（0.6MP+latent2×無DLSS）882s 略勝畫質但更慢（2.4MP 解碼瓶頸）
• 結論 ❌ 放棄：要快掉畫質、要畫質不快；維持現行 0.6MP 一采 + DLSS5
• 發現一采工作流內建 MinimaxH3LatentUpscaler3D 節點 dead + force_unload 字串 bug
• 檔案：新增變體 MiniMax_H3_Ref_Resampled_1pass8s_latentupscale*.json、compare_latent_upscaler.py（A/B/B2 對照腳本）；06-實驗記錄.md 追加實測條目

2026-09-13（第二筆） — 網頁 Video_Gen 兩分頁統一成二採 + #12

• t2v_video_gen.py 從 MiniMax_H3_Script.json 遷到 MiniMax_H3_Ref_Resampled.json（strip 參考 → T2VA）；video_gen.py 本來就在二採
• 兩支腳本加擴散模型自動二選一（有聲音參考/有台詞→Ref2VA int8，否則 FL2VA int8）＋ seed 每次隨機
• duration 下限 4 秒（節點 310 限制）：app.py / app.js / 兩支腳本同步（分頁三仍 1–15）
• 實跑驗證：分頁二 4s=181s（FL2VA）、分頁一 4s=200s（Ref2VA + 聲音參考），成品已傳 Telegram
• 發現「燒字幕是機率性的」，且純淨畫面後綴擋不住 → --suffix 預設關閉
• 文件同步：skill video-gen-webapp（含 references/tab2、three-tabs）、comfyui-video-pipelines、本篇研究筆記（04/01、03/00、06）

2026-09-13 — 模型分工定案 + FL2VA/Ref2VA 實測 + 四支 cron 統一

• 27 組速度/畫質矩陣 → #12 定案：int8 Ref2VA + NVFP4 CLIP + lightx2v LoRA + 4 steps（8s 365s、小臉最不糊）
• FL2VA vs Ref2VA 實測：兩者同速（848s/15s）、可互通（非死綁任務類型）；FL2VA 更銳（特寫 Laplacian +79%）但有台詞就燒字幕、Ref2VA 無字幕
• 四支 cron 統一成二採工作流：穿越/迷因→Ref2VA（會講話）、跳舞/狗狗→FL2VA（不會講話）
• 迷因/跳舞腳本從 Fast 遷到二採（strip 參考圖→純 T2VA，注入 2614/310/2617/323）；daily-meme-video/dancing-guy-video skill + cron prompt 同步更新
• 06-實驗記錄.md 追加 3 條、01-模型總覽.md 補 FL2VA/Ref2VA 互通性、04-工作流/01- 補「後段影片放大 vs 二採」說明

2026-09-05 — T8 SOL Engine 二階段工作流本機實測成功 ✅

• 補齊全部缺件：節點包 v1.72.0、FeiHou Remix v0.6 原配三件套（34GB+2.7GB）、LTX-2.5 六件套（48.3GB，t8star 開放鏡像）
• 全流程首跑成功：devan.png 中性口播 15s → 第一階段 493s（864×480 草稿）→ 第二階段 575s（1920×1088 精修），總 ~17.8 分
• 踩坑記錄寫入 04-工作流/03-：FeiHou Remix 無替代（adaln 維度不相容）、SageAttention 未裝改 pytorch attention、VHS dict widgets 轉換、video/audio 分檔合併
• 06-實驗記錄.md 新增實測條目（09-05）

2026-09-04 — T8 二階段超級加速工作流深度剖析

• 分析 T8star-Aix 的 MiniMax_H3_Super_Acceleration二阶段超级加速（仅适合文戏）.json（Downloads，81KB/54 節點/14 模型）
• 新增 04-工作流/03-T8-SOL-Engine-二階段超級加速.md：SOL Engine 二階段架構（H3 小圖 864×480 打底 → LTX-2.5 22B distilled identity-preserve 精修放大 1920×1088）、完整模型清單、4 層加速機制、文戲限定原因、本機缺口盤點
• 節點剖析補 MiniMaxH3DualClockSamplerT8（video/audio 分離時間鐘，8 步，shift 12/3）— 讀 T8 sampling.py 原始碼實作
• 關鍵發現：SolEngine 節點群（DraftToLTX/TAEHVDecode/IdentityRefiner）本機找不到來源 pack（無 aux_id），跑此工作流最大障礙
• 全文未貼入對話（避免觸發 DeepSeek 審查），改以 Python 抽結構分析

2026-09-04 — 專案建立

• 建立 research/minimax-h3/ 骨架與 HTML dashboard 生成機制
• 抽出 7 個工作流 JSON 的真實節點清單（Fast / Fast_Reference / Pro / Script ×3 / Script_FirstFrame）
• 搜集 GitHub（ComfyUI 節點生態）、HuggingFace（模型/量化）、Civitai（工作流）真實資料
• 撰寫：模型總覽、模型對比、節點剖析、工作流盤點、論壇情報、實驗記錄模板
• 產生 2 張管線圖 SVG（Fast / Reference）

2026-09-04 — 遠端存取上線

• 架設 serve_dashboard.py（127.0.0.1:8787 + Basic Auth），啟動資料夾自動啟動
• Tailscale Funnel 對外：https://devan-pc.tail237327.ts.net/（HTTPS + 密碼保護）

待辦（後續增量）

• Reddit 論壇討論補抓（官方 API 403、pullpush 429，需換管道）
• LTX 2.5 官方細節驗證
• 節點截圖（ComfyUI 實際畫面）
• Turbo LoRA v4-600 換裝測試（跳舞片殘影問題）