摘要： NVIDIA 與 Hugging Face 把 NeMo Automodel 這套分散式訓練函式庫直接接進 Diffusers 生態，Hub 模型可不轉檔進訓練並接回推論。7 月 17 日的合作文章介紹六個 flow-matching 現成 recipe、YAML 配置平行化，以及 full fine-tuning 與 LoRA 兩條路徑。目前限制是只覆蓋六個模型，Kubernetes 編排仍在規劃中。
微調影像與影片模型的難處，從來不只在 GPU 的數量。模型格式要轉換、資料要預處理、平行化要設定，訓練完的 checkpoint 還得想辦法接回推論 pipeline——每一層都是客製膠水程式碼的溫床。7 月 17 日，NVIDIA 與 Hugging Face 聯名發布合作文章，把 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 時記得那是同環境下的相對數字，換了硬體請自己重測。