影像與影片模型的微調，難的從來不只是 GPU 數量。模型格式轉換、資料預處理、平行化設定，以及訓練完的 checkpoint 怎麼回到推論 pipeline——每一層都可能長出一套客製程式碼。NVIDIA 與 Hugging Face 在 7 月 17 日發布的聯合文章，把 NeMo Automodel 這套分散式訓練函式庫直接接上 Diffusers 生態，訴求很直接：Hub 上的模型原樣進訓練，訓練完原樣回去。
不必轉檔的訓練層
NeMo Automodel 是 NVIDIA 開源、以 PyTorch DTensor 為基礎的訓練函式庫，屬於 NeMo framework 家族。這次整合走 Hugging Face native 路線：把 pretrained_model_name_or_path 指向 Hub 上任何 Diffusers model ID 就能開訓，載入用的是 Diffusers 的 model classes，生成沿用 Diffusers pipelines。
更關鍵的是 checkpoint 可以乾淨回頭：訓練結果直接用 DiffusionPipeline 載入推論，或推回 Hub 分享；量化、LoRA adapters 這類下游工具照常可用。訓練框架不再把模型鎖進另一個格式生態——這是整個合作最實際的改變：production 等級的分散式 diffusion 訓練，第一次不必經過 checkpoint 轉換與模型改寫就能套用到 Hub 上的 Diffusers-format 模型。整套整合以 Apache 2.0 授權完全開源，並收錄進 Diffusers 的訓練文件。
平行化是宣告，不是改寫
FSDP2、tensor、expert、context、pipeline parallel 這些平行化策略，在這套架構裡是配置選項。同一份訓練程式與 recipe 結構，從單張 GPU 到多節點叢集只改 YAML，不必為了換平行策略重寫模型程式碼。
訓練模式也放在同一個結構裡：full fine-tuning 追最大品質，LoRA 式的參數效率微調追最大效率，兩者共用同一套 recipe stack，而不是兩條各自維護的路。
六個現成 recipes 與硬體門檻
目前提供六個現成 fine-tuning recipes，全部是 flow-matching 模型——這是現階段的硬邊界，其他訓練目標的 pipeline 不在覆蓋內。訓練發生在 latent space，消耗的是預先編碼的 VAE outputs；資料端用 multiresolution bucketed 的分桶載入，依解析度組 batch，特別適合尺寸不一致的影像資料集。
| 模型 | 形態 | 備註 |
|---|---|---|
| Wan 2.1 T2V | 文生影片 | 1.3B 版可放進單張 40GB A100 |
| Wan 2.2 T2V A14B | 文生影片 | MoE：總參數 27B、每步激活 14B；目前無 LoRA recipe |
| FLUX.1-dev | 文生影像 | 官方示範流程的主角 |
| FLUX.2-dev | 文生影像 | 32B，六者中最大 |
| HunyuanVideo 1.5 | 文生影片 | — |
| Qwen-Image | 文生影像 | — |
規模跨度值得注意：Wan 2.1 的 1.3B 版本放得進單張 40GB A100，小團隊單卡就能起步；FLUX.2-dev 到 32B；Wan 2.2 A14B 是 MoE 架構，總參數 27B 但每步只激活 14B——省的是計算量，不是叢集配置的複雜度，而且它目前沒有 LoRA recipe。
實際流程：先預編碼，再跑 recipe
安裝建議用 Docker 容器 nvcr.io/nvidia/nemo-automodel:26.06，PyTorch、TransformerEngine 等 CUDA 依賴都已預建；或直接：
pip3 install nemo-automodel流程第一步是 pre-encode 資料集：VAE latents 與 text embeddings 先算好放進快取，訓練時每步直接讀，不再重複編碼；前置作業可以分散到所有可見的 GPU 上跑。這個設計的經濟學在重複訓練時最明顯：編碼只算一次，之後每次實驗、每組超參數都直接讀快取；資料集愈大、實驗輪數愈多，省下的重複計算就愈可觀，代價則是多一個前置步驟與快取的儲存空間。
官方示範用 78 張 Rider–Waite 塔羅牌資料集 full fine-tune FLUX.1-dev：樣本分進 384×640 的 bucket、8-way FSDP2、跑 200 步。生成階段以固定 seed 對照，帶觸發詞 trtcrd 的 prompt 會出現學到的塔羅風格，不帶就回到原本的輸出——效果歸因於微調本身，而不是抽樣運氣。
效能數據的正確讀法
官方 benchmark 在單節點 8× H100 80GB（NVLink）上量測，數字是三個穩態 10-step 視窗的平均值加減樣本標準差。FLUX.1-dev full fine-tuning（FSDP2）約 0.902 s/step、每 GPU 4.44 images/s、峰值記憶體 63.88 GiB；同一模型換 LoRA r64（DDP）每 GPU 可到 6.72 images/s。量測用的影像資料集是 256 張附文字標註的樣本，影片為 512×512×49 frames。
這些數字的價值在比較同一環境裡不同 recipe 的相對效率，不是對其他硬體配置的速度承諾。而兩個數字對照就有選型含義：同模型、同硬體下，LoRA r64 的每 GPU 吞吐（6.72 images/s）高於 full fine-tuning（4.44 images/s），而 full fine-tuning 換到的是完整的權重更新。目標若是風格或領域適配，吞吐與成本結構都站在 LoRA 這邊；要把模型能力推向新領域，才動用 full fine-tuning 的預算。
取捨、限制與 builder 建議
限制先講清楚：只支援 flow-matching 模型；recipes 只覆蓋六個模型；多節點編排目前走 HPC 工作排程器，Kubernetes 支援還在規劃中。但擴充設計得很收斂——新增一個模型只需要 data preprocessing handler 與 model adapter 兩塊小程式，FSDP2、分桶載入、checkpointing、generation 整個 recipe stack 原封不動。支援新模型的工作從「重建一條 pipeline」縮小成「補上兩個明確介面」，這對要追新模型的團隊是最大的維護成本差異。
目前 recipes 以 YAML 為主；官方 roadmap 是未來以 fully typed 的 Pythonic API 釋出，與 YAML 快速上手路徑並存，方便接進 notebook 與既有訓練程式。
Builder 的起手順序：先用 Wan 2.1 1.3B 在單卡上驗證整條流程；資料先 pre-encode 再訓練；風格或領域適配用 LoRA，需要極限品質再上 full fine-tuning；讀 benchmark 時記得它們是同環境下的相對數字，換硬體要自己重測。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。