Fine-tune video and image models at scale with NVIDIA NeMo Automodel and 🤗 Diffusers

NVIDIA and Hugging Face announced a collaboration integrating NVIDIA NeMo Automodel with the Hugging Face Diffusers library, enabling distributed fine-tuning of diffusion models at scale without checkpoint conversion. The open-source integration supports models like FLUX.1-dev, Wan 2.1, and HunyuanVideo, allowing users to scale training from one to hundreds of GPUs using configurable parallelism strategies.

Text-to-Image • 20B • Updated • 185k • 2.54k Fine-tune video and image models at scale with NVIDIA NeMo Automodel and 🤗 Diffusers Enterprise + Article /blog A joint post from NVIDIA and Hugging Face. Special thanks to Sayak Paul from Hugging Face for their contributions to the integration work and for co-authoring this blog. Diffusion models power some of the most exciting open-source releases of the last two years — such as FLUX.1-dev https://huggingface.co/black-forest-labs/FLUX.1-dev for text-to-image and Wan 2.1 https://huggingface.co/Wan-AI/Wan2.1-T2V-1.3B-Diffusers and HunyuanVideo https://huggingface.co/hunyuanvideo-community/HunyuanVideo-1.5-Diffusers-720p t2v for text-to-video. The 🤗 Diffusers https://github.com/huggingface/diffusers library has become the de facto home for these models, giving researchers and builders a single, consistent interface for inference, adaptation, and pipeline composition. In addition, training and fine-tuning diffusion models are also on the rise, requiring utilities that offer memory-efficient sharding, latent caching, multiresolution bucketing, and configurations that scale gracefully from one GPU to hundreds. To cater to these technical demands, we offer the NVIDIA NeMo Automodel https://github.com/NVIDIA-NeMo/Automodel open-source library. Today, we're highlighting the collaboration between NVIDIA and Hugging Face that brings production-grade, distributed diffusion training to any Diffusers-format model on the Hugging Face Hub — with no checkpoint conversion and no model rewrites for any new model. The integration is documented in the Diffusers training guide https://docs.nvidia.com/nemo/automodel/recipes-e2e-examples/diffusion-fine-tuning and is fully open source under Apache 2.0. Table of contents What is NeMo Automodel? what-is-nemo-automodel Supported diffusion models supported-diffusion-models What this collaboration unlocks what-this-collaboration-unlocks A look at the fine-tuning workflow a-look-at-the-fine-tuning-workflow Other Finetuned/LoRA examples other-finetunedlora-examples Try it today try-it-today Coming next: Pythonic recipe APIs coming-next-pythonic-recipe-apis Resources resources What is NeMo Automodel? NeMo Automodel is an open-source PyTorch DTensor-native training library, part of the NVIDIA NeMo framework, built around two design principles that matter for the Diffusers ecosystem: Hugging Face native. Point pretrained model name or path at any Diffusers model ID on the Hub and start training. NeMo Automodel uses Diffusers model classes e.g. WanTransformer3DModel for loading and Diffusers pipelines WanPipeline for generation. Checkpoints round-trip cleanly back into the Diffusers ecosystem. One program, any scale. The recipes and training scripts can be easily modified to suit training at any scale. Parallelism is a configuration choice, not a code rewrite — switch between FSDP2, tensor parallel, expert parallel, context parallel, and pipeline parallel by declaring configurations, not rewriting models. AutoModel currently supports flow-matching models only. Under the hood, it uses flow matching as the training objective, with latent-space training via pre-encoded VAE outputs and multiresolution bucketed dataloading to accelerate throughput. Supported diffusion models NeMo Automodel integration ships with ready-to-use fine-tuning recipes for the open diffusion models below. The list reflects the recipes currently in examples/diffusion/finetune . | Model | Hugging Face ID | Task | Parameters | LoRA recipe | |---|---|---|---|---| | Wan 2.1 T2V 1.3B / 14B | Wan-AI/Wan2.1-T2V-1.3B-Diffusers | Wan-AI/Wan2.1-T2V-14B-Diffusers Wan-AI/Wan2.2-T2V-A14B-Diffusers black-forest-labs/FLUX.1-dev black-forest-labs/FLUX.2-dev hunyuanvideo-community/HunyuanVideo-1.5-Diffusers-720p t2v Qwen/Qwen-Image What this collaboration unlocks For Diffusers users, the practical gains break down into a few concrete capabilities. No checkpoint conversion. Pretrained weights from the Hub work out of the box. There's no separate "training format" to convert to, then convert back. Your fine-tuned checkpoint loads directly into a DiffusionPipeline for inference, or back to the Hub for sharing. Downstream tools — quantization, compilation, LoRA adapters, custom samplers — all keep working. Fast path to new model support. When a new diffusion model lands in Diffusers, enabling it in NeMo Automodel takes a small, contained code addition — a data preprocessing handler and a model adapter — rather than a full custom training script. The rest of the recipe stack FSDP2, bucketed dataloading, checkpointing, generation carries over unchanged, and the same YAML-driven workflow applies. Full and parameter-efficient fine-tuning. Both full fine-tuning and LoRA-style PEFT are supported, so you can choose between maximum quality full FT on a large cluster or maximum efficiency LoRA on a single node . The same recipe structure handles both. Scalable training that goes beyond what built-in scripts offer. NeMo Automodel adds sharding schemes such as FSDP2, tensor, context, and pipeline parallelisms, multi-node orchestration SLURM today, Kubernetes coming , and multiresolution bucketing. These capabilities make training larger models like FLUX.1-dev 12B and HunyuanVideo 13B possible. A look at the fine-tuning workflow In this section, we walk through the typical workflow for fine-tuning any of the supported models. The recommended way to install Automodel is the NeMo Automodel Docker container nvcr.io/nvidia/nemo-automodel:26.06 , which ships with PyTorch, TransformerEngine, and other CUDA-compiled dependencies pre-built. Alternatively, install with pip3 install nemo-automodel or from source pip3 install git+https://github.com/NVIDIA-NeMo/Automodel.git ; see the installation guide https://docs.nvidia.com/nemo/automodel/latest/get-started/installation for all options. This guide walks through a full-transformer fine-tune of FLUX.1-dev on the 78-card Rider–Waite tarot dataset https://huggingface.co/datasets/multimodalart/1920-raider-waite-tarot-public-domain , then generating from the resulting checkpoint. It reuses the checked-in YAML configs and applies run-specific settings as command-line overrides, so no new config files are required. 1. Pre-encode the dataset The diffusion recipe consumes cached VAE latents and text embeddings instead of encoding source images during every training step. Stream the 78 Rider–Waite images directly from Hugging Face and distribute preprocessing across all visible GPUs: uv run --locked --no-default-groups \ --extra diffusion \ --extra diffusion-media \ python -m tools.diffusion.preprocessing multiprocess image \ --dataset name multimodalart/1920-raider-waite-tarot-public-domain \ --dataset media column image \ --dataset caption column caption \ --dataset streaming \ --max images 78 \ --output dir /cache/flux tarot \ --processor flux \ --model name black-forest-labs/FLUX.1-dev \ --max pixels 245760 The captions already contain the trtcrd trigger token. With this pixel budget and the dataset's portrait aspect ratio, preprocessing assigns the samples to the 384×640 bucket used by the showcase run. For image training, preprocessing produces .pt cache files and sharded metadata: /cache/flux tarot/ ├── 384x640/ │ ├── <hash1 .pt │ └── ... ├── metadata shard 0000.json ├── metadata.json └── hf dataset/ └── images/ 2. Launch training with the existing FLUX YAML Use examples/diffusion/finetune/flux t2i flow.yaml directly. The YAML already selects FLUX.1-dev, full transformer fine-tuning, the FLUX flow-matching adapter, an effective batch size of 32, and eight-way FSDP2. Supply the tarot-specific paths and settings as command-line overrides: uv run --locked --no-default-groups --extra diffusion \ torchrun --nproc-per-node=8 \ examples/diffusion/finetune/finetune.py \ -c examples/diffusion/finetune/flux t2i flow.yaml \ --model.transformer engine fp8 false \ --data.dataloader.cache dir /cache/flux tarot \ --data.dataloader.base resolution ' 384,640 ' \ --lr scheduler.lr decay style constant \ --lr scheduler.lr warmup steps 20 \ --step scheduler.max steps 200 \ --step scheduler.ckpt every steps 50 \ --checkpoint.checkpoint dir /tmp/flux tarot/checkpoints/full \ --checkpoint.save consolidated true \ --seed 2026 The run produces checkpoints at steps 50, 100, 150, and 200. The final checkpoint is labeled epoch 66 step 199 ; the label is zero-based even though it represents the completed 200th optimizer step. 3. Generate from the fine-tuned checkpoint Use the existing FLUX generation YAML and point model.checkpoint at the complete training checkpoint: uv run --locked --no-default-groups --extra diffusion \ python examples/diffusion/generate/generate.py \ -c examples/diffusion/generate/configs/generate flux.yaml \ --model.checkpoint /tmp/flux tarot/checkpoints/full/epoch 66 step 199 \ --inference.height 640 \ --inference.width 384 \ --inference.prompts ' "a trtcrd of an astronaut tending a rose garden on Mars, \"the gardener\"" ' \ --output.output dir /tmp/flux tarot/generations/full/step 200 \ --seed 2026 Include trtcrd to invoke the learned tarot style. For a control comparison, keep the seed and scene fixed but omit the trigger: uv run --locked --no-default-groups --extra diffusion \ python examples/diffusion/generate/generate.py \ -c examples/diffusion/generate/configs/generate flux.yaml \ --model.checkpoint /tmp/flux tarot/checkpoints/full/epoch 66 step 199 \ --inference.height 640 \ --inference.width 384 \ --inference.prompts ' "an astronaut tending a rose garden on Mars, \"the gardener\"" ' \ --output.output dir /tmp/flux tarot/generations/control \ --seed 2026 Results At step 200, the triggered astronaut prompts retain their requested content while acquiring a cream, red, and black vintage palette, heavy ink contours, flat color fields, aged-paper tones, and allegorical card composition. The untriggered astronaut remains photographic, demonstrating that the learned effect is substantially associated with trtcrd rather than replacing the base model globally. | Prompt seed | Baseline | Fine-tuned step 200 | |---|---|---| | Astronaut tending a rose garden on Mars seed 2026 | || | Astronaut in a moonlit garden on Mars seed 2028 | || | Astronaut planting a sapling beneath two moons seed 2029 | 4. Performance All measurements were collected on one node with 8× NVIDIA H100 80GB GPUs. Results are means ± sample standard deviation over three steady-state 10-step windows. Text-to-image — 512×512 see if seconds can be aligned | Model | Training | Parallelism | GBS / LBS | Step time | Images/s | Images/s/GPU | Peak allocated/GPU | |---|---|---|---|---|---|---|---| | FLUX.1-dev | Full | FSDP2 | 32 / 4 | 0.902 ± 0.039 s | 35.51 ± 1.55 | 4.44 ± 0.19 | 63.88 GiB | | FLUX.1-dev | LoRA r64 | DDP | 48 / 6 | 0.894 ± 0.008 s | 53.73 ± 0.48 | 6.72 ± 0.06 | 67.43 GiB | | Qwen-Image | Full | FSDP2 | 40 / 5 | 0.974 ± 0.075 s | 41.21 ± 3.06 | 5.15 ± 0.38 | 53.55 GiB | | Qwen-Image | LoRA r64 | DDP | 24 / 3 | 0.515 ± 0.006 s | 46.63 ± 0.54 | 5.83 ± 0.07 | 66.33 GiB | Text-to-video — 512×512×49 frames Each sample is one 49-frame video clip. | Model | Training | GBS / LBS | Activation checkpointing | Step time | Clips/s | Clips/s/GPU | Peak allocated/GPU | |---|---|---|---|---|---|---|---| | Wan 2.1 1.3B | Full | 8 / 1 | Off | 0.942 ± 0.038 s | 8.50 ± 0.35 | 1.06 ± 0.04 | 6.09 GiB | | Wan 2.1 14B | Full | 8 / 1 | On | 3.798 ± 0.017 s | 2.107 ± 0.006 | 0.263 ± 0.006 | 33.35 GiB | | Wan 2.1 14B | LoRA r64 | 16 / 2 | On | 7.585 ± 0.014 s | 2.110 ± 0.000 | 0.263 ± 0.000 | 24.07 GiB | | Wan 2.2 A14B, high-noise | Full | 8 / 1 | On | 4.628 ± 0.031 s | 1.730 ± 0.010 | 0.217 ± 0.006 | 23.57 GiB | | HunyuanVideo 1.5 | Full | 8 / 1 | On | 5.926 ± 0.046 s | 1.350 ± 0.010 | 0.170 ± 0.000 | 15.90 GiB | | HunyuanVideo 1.5 | LoRA r64 | 8 / 1 | On | 5.575 ± 0.006 s | 1.433 ± 0.006 | 0.180 ± 0.000 | 10.58 GiB | Measurement details - Hardware: 8× H100 80GB HBM3, fully NVLink-connected. - Image dataset: , 256 cached samples. lambda/naruto-blip-captions - Video dataset: , 112 cached samples. svjack/Lelouch Vi Britannia FramePack First Last Frame Video Captioned - Full batches were enforced with drop last=true . - Checkpoint writes were disabled. - Step time includes dataloading, forward, backward, gradient clipping, optimizer, and scheduler work. - Memory is peak PyTorch CUDA allocator usage, not total NVML device memory. Other Finetuned/LoRA examples The results from fine-tuning and LoRA showcase the power of NeMo Automodel for domain specialization. For instance, fine-tuning the Wan 2.1 model on a Ghibli video dataset successfully adapted the output style, demonstrated by a noticeable change in a flower's appearance compared to the baseline. Baseline: Finetuned on Ghibli's videos: We also observed the distinct impact of using LoRA, where applying the adapter to Wan 2.1 caused the video to adopt a characteristic Ghibli style, particularly visible in the highlighting of characters' eyes. No LoRA: LoRA: These examples, including those for FLUX.2, confirm that users can achieve both maximum quality via full fine-tuning and maximum efficiency via LoRA-style PEFT, tailoring the output to specific stylistic domains. Try it today Learn more about the integration and find more fine-tuning examples in the NeMo Automodel documentation https://docs.nvidia.com/nemo/automodel/recipes-e2e-examples/diffusion-fine-tuning Coming next: Pythonic recipe APIs YAML is a strong fit for reproducible configuration, especially for teams that want files they can check in, review, and reuse, but many teams also need a programmatic interface. In an upcoming NeMo Automodel release, we plan to surface the diffusion recipes through a fully typed Pythonic API as well. Users will be able to compose the same model, data, optimizer, PEFT/LoRA, parallelism, checkpointing, and generation pieces directly from Python. The Pythonic path is intended to make the recipes easier to use from existing training code, notebooks, and experiment workflows, and to offer a first-class Pythonic interface alongside the YAML quick-start path.