Fine-Tune Flux.2 and Wan 2.5 on GPU Cloud: LoRA Cost (2026)

Every guide to Flux.2 and Wan 2.5 on the market covers deployment: how to serve the model, what quantization to use, what a generated image or clip costs you. None of them cover training your own LoRA, which is the step that actually makes a diffusion model useful for a specific brand, character, or style. This post fills that gap with real VRAM numbers, tool setup for ai-toolkit and musubi-tuner, and dollar costs per training run on rented GPUs.

One thing to get out of the way first: you can't train a Wan 2.5 LoRA in 2026, because Wan 2.5 has no public weights to train against. We'll explain exactly why, and what to train instead, before getting into the cost math. If your actual goal is fine-tuning a language model rather than a diffusion model, the VRAM math and tooling are completely different; see our breakdown of LoRA and QLoRA VRAM requirements for LLMs instead.

What LoRA Training Actually Needs: VRAM, Dataset Size, and Steps

LoRA fine-tuning freezes the base model and trains a small set of low-rank adapter matrices injected into the attention and feedforward layers. You get most of the customization benefit of a full fine-tune at a fraction of the VRAM and compute, because gradients and optimizer states only need to cover the adapter weights, not the full parameter count. The trade-off is that the base model still has to sit fully loaded in VRAM in the target precision, since every forward and backward pass runs through it.

Image LoRA vs Video LoRA: Why the Requirements Diverge

An image LoRA and a video LoRA are not the same shape of problem, even when they share an underlying architecture family (Flux.2 and Wan are both diffusion transformers). Three things diverge:

• Sequence length. A single 1024x1024 image is one frame of tokens. A 5-second video clip at 24fps is dozens of frames, each contributing to a quadratically scaling attention computation. This is the same reason inference VRAM jumps sharply from image to video models.
• Dataset size. Image LoRAs converge on 15-30 captioned stills. Video LoRAs need enough motion diversity per clip, which pushes typical datasets toward 20-40 short clips rather than 15-30 stills, and captioning has to describe motion, not just composition.
• Training time. Musubi-tuner's own documentation puts video training VRAM at "24GB or more recommended," roughly double its 12GB guidance for image training, and that gap shows up again in wall-clock time: video LoRA runs take hours where image LoRA runs take minutes, driven by both the longer sequence and the lower achievable batch size (usually 1 for video).

VRAM by GPU Tier: Flux.2 Dev, Flux.2 Klein, and Wan 2.2 14B

The clean rule: match the model variant to what your GPU can hold, not the other way around. Trying to force Flux.2 Dev onto a 24GB card by cranking down batch size and resolution burns more wall-clock time than it saves in rental cost.

The RTX 4090 numbers for Flux.2 come from Apatero's Flux.2 LoRA training guide: batch size 4-6 at 1024x1024 holds around 21-22GB and completes a full LoRA in 2-4 hours on a single card. Klein 4B's 24GB figure comes straight from Black Forest Labs' own Klein LoRA guide, which names the RTX 4090 as the sweet spot rather than treating 16GB as the baseline. The musubi-tuner VRAM figures are from the tool's own documentation, which explicitly separates image training (12GB+) from video training (24GB+), noting that actual usage still depends on resolution and how aggressively you use block-swap and FP8 text encoder options.

Dataset Size and Captioning: Images vs Video Clips

For Flux.2, the working default is 15-30 high-quality captioned images. More isn't automatically better here: past 30-40 images for a single style or subject, you tend to fight overfitting before you get quality gains, unless you're deliberately training a broader concept. Captions should describe what varies (pose, lighting, background) rather than restate what's constant across every image (the subject's identity), so the LoRA learns to generalize the fixed trait and adapt the varying ones.

For Wan 2.2, video clips follow a frame-count formula of 4n+1, meaning clip lengths like 9, 41, or 81 frames rather than arbitrary values. This comes from how the model's temporal VAE compresses frames, and getting it wrong causes silent shape mismatches during training rather than a clean error. Datasets are typically smaller in clip count than image datasets (a well-curated set of 20-40 clips is common) but each clip needs to demonstrate the motion or style you're targeting, which makes sourcing harder than snapping 20 stills.

Steps, LoRA Rank, and Learning Rate Defaults

Wan 2.2's higher step count and batch size of 1 aren't a sign that something's wrong; video diffusion models converge more slowly per step because each step covers a much larger, more entangled token sequence, and the batch size ceiling comes directly from the VRAM cost of holding multiple full video sequences in memory at once rather than a tuning choice.

Train Wan 2.5 LoRA? Here's What You're Actually Training in 2026

If you searched for how to train a Wan 2.5 LoRA, here's the direct answer: you can't, not because the tooling isn't ready, but because there's nothing to point it at. Wan 2.5-Preview shipped in September 2025 as a multimodal audio-video model, accessible only through Alibaba Cloud's API. As of mid-2026, the Wan-AI organization on Hugging Face still lists checkpoints only up through the Wan 2.2 line (T2V-A14B, I2V-A14B, TI2V-5B, S2V-14B, and Animate-14B), all with downloadable weights. Wan 2.5 isn't among them. No safetensors file, no config, no base model to attach a LoRA to.

This mirrors the earlier jump from Wan 2.1 to 2.2. Wan 2.2 (July 2025) kept the same public-weights model and upgraded the architecture to a Mixture-of-Experts design, trained on substantially more image and video data than 2.1, without changing the VRAM footprint teams already had infrastructure for. Wan 2.5 broke that pattern by staying closed, likely because the synchronized audio-video component involves training data that's harder to distribute openly than pure video weights.

The practical answer, and the one this whole post is built around: train your LoRA on Wan 2.2 14B now. The training scripts, VRAM planning, and dataset structure you build for Wan 2.2 transfer directly if Wan 2.5 weights ever ship. It would be a checkpoint swap, not a rebuild. Our Wan 2.5 deployment guide covers this same caveat in more depth from the inference side, including what changes on GPU selection if the audio component does eventually ship as open weights.

Cost to Train a Flux.2 LoRA on GPU Cloud

Direct answer: A single Flux.2 LoRA run costs roughly $1-3 on a rented RTX 4090 and finishes in 2-4 hours, or $5-10 on a multi-GPU A100 rig in 45-90 minutes. Most teams land under $15 total once you budget for a couple of iterations to dial in the dataset and rank.

ai-toolkit Setup on H100, A100, and RTX 4090

ai-toolkit from Ostris is the toolkit most teams reach for first. It's MIT-licensed, supports Flux.1-dev, Flux.2-dev, and both Flux.2-klein variants, and ships example training configs you can copy and point at your own dataset directory. Setup on a Spheron GPU instance:

git clone https://github.com/ostris/ai-toolkit
cd ai-toolkit
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt

# accept the Flux.2 license on HuggingFace first, then:
huggingface-cli login

Copy the closest example config from config/examples/ (the repo ships 24GB-tier configs for Flux.1 variants; for Flux.2, start from those and adjust name_or_path to black-forest-labs/FLUX.2-dev or the Klein checkpoint you're targeting), point folder_path at your captioned image directory, and set:

network:
  type: "lora"
  linear: 32
  linear_alpha: 32
train:
  steps: 1200
  lr: 0.0012
  batch_size: 6

For Flux.2 Klein 4B on a 24GB card, this is the practical entry point. For Flux.2 Dev's full 32B model, an RTX 4090 works at reduced batch size and holds around 21-22GB, but an A100 80G or H100 gives you room to run higher batch sizes and finish faster. For an H100 or A100 to run comfortably, see live pricing on the H100 GPU rental page.

Real Dollar Cost Per LoRA Run (Worked Examples)

Spheron pricing fetched 09 Jul 2026: RTX 4090 on-demand $0.58/hr, RTX 5090 on-demand $0.68/hr, A100 80G SXM4 on-demand $1.69/hr, A100 80G PCIe on-demand $1.48/hr and spot $1.19/hr, H100 PCIe on-demand $2.01/hr.

Budget for 2-3 iterations while you tune rank, learning rate, and dataset composition, which puts a fully dialed-in Flux.2 LoRA in the $5-15 range on a single consumer GPU, or a bit higher if you're using multi-GPU A100 rigs to cut wall-clock time. The 4x A100 configuration only pays off if turnaround time matters more than raw dollar cost; for a one-off LoRA where you're not in a hurry, a single RTX 4090 is the cheaper path.

Pricing fluctuates based on GPU availability. The prices above are based on 09 Jul 2026 and may have changed. Check current GPU pricing → for live rates.

Cost to Train a Wan 2.2 Video LoRA on GPU Cloud

Direct answer: A Wan 2.2 video LoRA takes meaningfully longer than an image LoRA. One practitioner's published training log on a 96GB workstation card put a full I2V LoRA run at close to 24 hours, stretching to 2-3 days on a lower-VRAM consumer setup. On an H100 or A100 80G, expect a run in the $25-50 range for a single well-tuned LoRA, driven almost entirely by wall-clock hours rather than the hourly rate.

musubi-tuner and diffusion-pipe Setup and VRAM Tiers

musubi-tuner from kohya-ss is the standard for Wan 2.1/2.2, HunyuanVideo, and Flux.1 Kontext LoRA training. Its own documentation states 12GB or more for image training and 24GB or more for video training, with block-swap and FP8 T5 text encoder options available to bring that 24GB figure down further on tighter hardware.

git clone https://github.com/kohya-ss/musubi-tuner
cd musubi-tuner
pip install -r requirements.txt

huggingface-cli download Wan-AI/Wan2.2-T2V-A14B --local-dir ./models/wan22-t2v-14b

Cache your dataset's latents and text encoder outputs ahead of the training run itself, which musubi-tuner handles with dedicated wan_cache_latents.py and wan_cache_text_encoder_outputs.py scripts, then kick off training with wan_train_network.py pointed at your cached dataset and a config setting rank, batch size, and block-swap depth.

diffusion-pipe is the alternative worth knowing about if you need to go beyond a single GPU's VRAM ceiling. It supports Wan 2.1 and Wan 2.2 directly, and its hybrid data- and pipeline-parallelism (via a pipeline_stages setting) splits a model across multiple GPUs rather than requiring the whole thing to fit on one card. That matters if you're training at 720p or with longer clips than a single 80GB GPU comfortably holds.

Real Dollar Cost Per LoRA Run (Worked Examples)

One practitioner's published Wan 2.2 I2V LoRA training log reported a training time of close to 24 hours on a 96GB workstation card, stretching to 2-3 days on a lower-VRAM consumer card. Treat that 24-hour figure as a single real-world data point rather than a guaranteed benchmark: your own run time depends heavily on clip count, resolution, and how much block-swap you use. Applying Spheron's live rates to that range:

The gap between a datacenter GPU and a consumer card narrows more than you'd expect on total dollar cost, because the consumer GPU's lower hourly rate roughly offsets its longer wall-clock time. Where the datacenter GPU wins is turnaround: waiting 24 hours instead of 3 days matters if you're iterating on multiple LoRA candidates for a client or campaign.

Pricing fluctuates based on GPU availability. The prices above are based on 09 Jul 2026 and may have changed. Check current GPU pricing → for live rates.

Flux.2 LoRA vs Wan 2.2 LoRA: Side-by-Side Cost Comparison

The order-of-magnitude gap here comes almost entirely from sequence length. A video clip's attention computation scales quadratically with frame count, and that compounds across thousands of training steps in a way a single 1024x1024 image never does. If your budget is tight and your use case can work as a still image (product photography, character sheets, style transfer), Flux.2 gets you a usable custom model for a few dollars. Video LoRA training is a real commitment, and it's worth prototyping the concept in Flux.2 first if the visual style overlaps, before spending a day or three of GPU time on the video version.

From Trained LoRA to Production: Serving Your Custom Model

A trained LoRA adapter is a small file, usually tens to a few hundred megabytes, not a new base model. Serving it is a separate problem from training it, and it's worth planning for before you start training so you're not stuck with an adapter format your serving stack can't load.

Loading a Custom LoRA into ComfyUI or diffusers

In ComfyUI, load your trained safetensors file through a LoraLoader node chained after the checkpoint loader, and set the strength parameter to control how strongly the adapter influences generation, typically starting around 0.8-1.0 and adjusting from there. For Wan 2.2 video workflows specifically, the ComfyUI-WanVideoWrapper custom node handles LoRA loading through its own dedicated loader node. Our ComfyUI on GPU cloud guide covers the base Docker and SSH tunnel setup both Flux.2 and Wan workflows build on.

In diffusers, load a trained LoRA onto a pipeline with pipe.load_lora_weights("path/to/your-lora.safetensors") after loading the base Flux.2 or Wan pipeline, and call pipe.fuse_lora() if you want the adapter permanently merged into the weights for a small inference speedup at the cost of losing the ability to toggle it off. For a full production deployment walkthrough covering FP8 quantization and FastAPI wrapping for Flux.2 inference, see the Flux.2 production deployment guide.

Serving Multiple Brand LoRAs Without a GPU Per Style

If you're training LoRAs for multiple brands, characters, or client styles, running a dedicated GPU per adapter gets expensive fast and mostly sits idle. The pattern that avoids this: keep one base model resident in VRAM and hot-swap adapters per request. This is exactly what vLLM's multi-LoRA serving does for language models, and the same idea applies to diffusion pipelines with load_lora_weights and unload_lora_weights calls per request instead of fuse_lora, at the cost of a small per-swap latency hit versus a permanently fused adapter. Our guide on serving multiple LoRA adapters on one GPU covers the architecture in more detail, including where the VRAM overhead per adapter actually comes from.

Training a Flux.2 or Wan 2.2 LoRA is a job you spin up for a few hours, not infrastructure you keep running. Rent the GPU tier that matches your model, pay only for the run, and shut it down when the LoRA is done.

A100 GPU pricing → | Spheron H100 → | View all GPU pricing →