LoRA Training Guide 2026: SDXL, Anima, FLUX, Qwen, Krea 2 and Video Models

For anime LoRAs, start with the exact SDXL checkpoint you will use for generation, or use Anima’s dedicated trainer. For photographic work, choose the trainer’s exact Z-Image, Qwen, FLUX or Krea 2 architecture. For video, start with a short, low-resolution training run on Wan, the official LTX trainer, or an H3-specific pipeline. A LoRA is an adapter for a compatible base model—not a universal character file.

The most expensive mistakes happen before the first training step: using an inference-only quantized checkpoint, mixing model generations, captioning every image identically, or expecting still images to teach motion. A small reproducible run with held-out prompts is more useful than copying a large preset and waiting overnight.

Updated October 13, 2026

Choose the base model before the trainer

The anime/photo grouping below describes common use cases, not hard limits: FLUX and Krea can also illustrate, and SDXL derivatives can produce realistic images. “WanX” is treated here as the Wan family, with concrete settings for Wan 2.1 and 2.2. Likewise, “FLUX” and “LTX” require a version choice before downloading weights.

Pony V6 XL is SDXL; Pony V7 is not covered by the SDXL recipe. Illustrious/NoobAI descendants may share architecture yet differ in tags and prediction targets. Anima, Z-Image, Qwen and Krea 2 need their own modules. Loading a file without an error does not prove that it was trained for your checkpoint.

Training tools: which one to install

kohya_ss + sd-scripts

Choose kohya_ss if you want a GUI around SDXL training. Select the LoRA/SDXL workflow, point to the exact checkpoint, dataset and output directory, then save the configuration before starting. The underlying sd-scripts project is the reference for flags. A GUI bundling an older revision may not expose newer model support; do not assume every recent sd-scripts feature is present.

sd-scripts for Anima

Use anima_train_network.py for Anima, rather than the SDXL entry point. This route makes its separate DiT, Qwen3 encoder and VAE explicit. It suits users comfortable editing a dataset TOML and running a terminal command; the Anima documentation includes Japanese explanations.

Ostris AI Toolkit

AI Toolkit provides a GUI and YAML jobs for many image architectures. Create a job, choose the exact supported model, add the image/caption folder, set a trigger token and fixed validation prompts, and save periodic checkpoints. Copy the matching example rather than renaming a FLUX job to Qwen. For a cloud UI, enable authentication and keep it private.

Musubi Tuner

Musubi is useful when you need separate caching and training stages, model-specific options and block offloading. Install its own environment, create a dataset TOML, run the architecture’s latent and text-embedding cache scripts, then its train_network script. Do not mix caches between base models or copy Wan’s noise schedule into H3.

Lightricks LTX Trainer

The official LTX training package is the first choice for LTX-family video work. It has preprocessing, training and validation configs in one repository. Start from the supplied low-VRAM or standard T2V LoRA config, not the full fine-tuning config. Its model and text-encoder paths must refer to compatible local files.

Fizgig for a guided MiniMax H3 route

Fizgig offers a more guided H3 workflow with dataset preparation and presets. Choose MiniMax H3 in the training model selector, prepare/caption stills or short clips, apply the Fast preset, and inspect saved samples before increasing duration. It is a community implementation; its automatic learning-rate recipe is not interchangeable with Musubi’s fixed-rate example.

Prepare a dataset that teaches the right thing

1. Define one goal: a person/character, a visual style, a product, or a motion. For an initial image experiment, roughly 20–50 distinct subject images can be manageable; a style usually needs a broader subject mix. These are editorial starting ranges, not minimum requirements. More near-duplicates do not equal more information.
2. Remove duplicates, bad anatomy, watermarks, compression damage and contradictory identities. Vary framing, pose, lighting and backgrounds. Keep a consistent feature only when it is part of what you want learned; otherwise describe it in the caption so it does not silently attach to the trigger.
3. Use matching filenames such as subject_001.png and subject_001.txt. Tag-oriented captions suit many anime checkpoints; coherent natural sentences often suit newer transformer models. Review automatic captions manually, especially names, left/right, number of subjects and actions.
4. Reserve genuinely different images or clips for evaluation. Do not put adjacent frames of the same video in both training and holdout sets: that makes memorization look like generalization.
5. For video, cut at scene boundaries, preserve coherent motion, and record frame rate and duration. A folder of still frames can teach appearance, but lacks the temporal sequence needed to learn a specific movement.
6. Use each trainer’s allowed frame counts and spatial buckets. Audio-video models also need synchronized, useful audio or an explicitly supported video-only mode. Silent dummy tracks and arbitrary frame counts are not universal fixes.
7. Train on material you own or are authorized to use. For recognizable people or voices, obtain appropriate consent. A base-model license, dataset rights and the license of the exported adapter are separate questions.
8. Record the model repository/revision, trainer commit, caption convention and config beside the dataset. Finish a run before updating the environment; regenerate caches when captions, components or preprocessing settings change.

Suggested caption examples; these are not generated test results.

Anime: a1explorer, adult woman, blue jacket, standing, forest, daylight
Photo: A photo of a1subject wearing a blue jacket beside a window in soft daylight.
Video: a1subject walks from left to right, turns toward the camera, and stops. The camera remains fixed.

Starter settings: examples, not universal presets

Rows marked “example” summarize a specific trainer document, not a tested optimum for every dataset. The SDXL range and suggested trial budgets are starting recommendations. Rank, alpha, learning rate and optimizer must be considered together; an alpha of 1 is not equivalent to alpha = rank. Keep batch size 1 for the first fit test and enable supported memory-saving options.

Image LoRA training: anime models

Train first on the checkpoint closest to your intended output. A LoRA trained on one anime branch may load on another SDXL derivative, yet lose likeness, change color or need a different strength. That is a validation question, not a promise of cross-family portability.

Pony V6 XL: match its tags and base checkpoint

Use the SDXL LoRA path in kohya_ss/sd-scripts. Keep character identity or style separate from variable clothing and scenery in the captions. Use the chosen Pony checkpoint’s documented quality/tag conventions for validation; do not automatically paste those tags into every Illustrious or NoobAI dataset.

Start with the SDXL row above. In the GUI, set the exact model, dataset, caption extension, bucket resolution, rank/alpha and U-Net learning rate; freeze text encoders initially. Generate the same validation prompts at each save. Choose an earlier checkpoint if the trigger begins forcing one pose or background. Pony V7 requires a different architecture recipe.

Documentation — Pony V6 XL: match its tags and base checkpoint

Illustrious XL: learn the concept, not the training background

Illustrious-derived SDXL checkpoints use the same broad training toolchain, but version and derivative matter. Select the model you will actually generate with and follow its caption guidance; some later versions place more emphasis on natural language than older tag-heavy workflows.

Keep the first experiment narrow: one character or one style, rank 16–32, frozen text encoders and periodic samples. If your character only appears against one background, improve captioning and diversity before increasing rank. Test the resulting adapter on the target checkpoint with both familiar and unseen outfits/compositions.

Documentation — Illustrious XL: learn the concept, not the training background

NoobAI XL: check epsilon versus v-prediction first

NoobAI has separate prediction variants. Its V-Pred card explicitly identifies v-prediction and a zero-terminal-SNR inference setup. Use the trainer’s matching v-parameterization/noise settings for that checkpoint; do not apply an ordinary epsilon SDXL preset blindly, and do not enable v-prediction for every model bearing the Noob name.

After selecting the correct branch, use the same small SDXL trial and inspect saved results with the matching inference scheduler. If colors or contrast collapse, check the prediction type and scheduler before blaming the dataset. The model card links a dedicated v-pred LoRA tutorial; keep that branch-specific configuration with the exported file.

Documentation — NoobAI XL: check epsilon versus v-prediction first

Anima: a separate DiT training path

Anima is not an SDXL fine-tune. Prepare the Anima DiT, Qwen3-0.6B encoder and matching Qwen-Image VAE, plus the tokenizer/adapter assets required by the chosen release. Use networks.lora_anima and anima_train_network.py. A Pony LoRA cannot be converted into an Anima LoRA by renaming the file.

A conservative first run trains the DiT only and caches encoder outputs. Use the documented rank-8/alpha-1 example as one coherent recipe. If you later train the text encoder, disable cached encoder outputs and give it its own lower learning rate. Anima’s cache/dropout behavior has specific support; do not assume identical behavior in SDXL.

How to use it

1. Create the dataset TOML and set the component paths in the Anima example command.
2. Use bf16 where supported, gradient checkpointing and the documented cache options; explicitly choose DiT-only training for the first run.
3. Save every epoch, then compare held-out prompts on the same Anima version. Only increase rank or train additional modules after identifying a specific weakness.

Documentation — Anima: a separate DiT training path

Image LoRA training: photographic models

Z-Image: prefer Base for the first training run

Musubi’s current guide recommends the released Base model for training. The old “Turbo is the only model” advice is obsolete. Base and Turbo are not interchangeable optimization targets: distilled Turbo needs a trainer-supported de-turbo model or training adapter, with the correct inference treatment afterwards.

Prepare the DiT, VAE and text encoder, cache the dataset with the Z-Image scripts, then use zimage_train_network.py and networks.lora_zimage. Start from its rank-32/LR-1e-4 example, make a short fit test, and inspect the converter instructions if your inference loader expects a different LoRA key layout.

How to use it

1. Choose Base, De-Turbo or Turbo-with-adapter deliberately; write that choice in the run name.
2. Cache latents and captions with the matching components, then train and save several checkpoints.
3. Load the adapter in the matching Z-Image inference workflow; apply the documented format conversion when required.

Documentation — Z-Image: prefer Base for the first training run

Qwen-Image: text-to-image and edit training need different data

For the original text-to-image model, Musubi documents a rank-16/LR-5e-5 route. An image-edit LoRA needs a source/control image, target image and an instruction describing the change; a simple folder of portrait captions does not teach the editing operation. Version-specific flags determine how those controls are encoded.

AI Toolkit currently lists Qwen-Image-2.1 as supporting generation and editing, with control images enabling the latter. Pick that exact architecture instead of using Musubi’s older model_version original example unchanged. Begin with a small paired-data test for editing and verify that the subject is preserved while the requested property changes.

How to use it

1. Choose generation or editing, then the exact Qwen release in the trainer.
2. For editing, align source/target pairs and write action-oriented instructions; verify a few loaded examples before caching.
3. Train a small adapter, compare saved checkpoints on unseen inputs, and check both edit strength and preservation.

Documentation — Qwen-Image: text-to-image and edit training need different data · AI Toolkit: Qwen-Image-2.1

FLUX: distinguish FLUX.1, FLUX.2 and Klein

AI Toolkit’s FLUX.1-dev example is a useful transparent starting point: it specifies rank/alpha, sample prompts, save interval and training steps. Copy that YAML to a new job, change dataset/output paths and the trigger, and run it with python run.py. Accept any required model license and use an authorized token privately.

For FLUX.2-dev or Klein, choose their own supported architecture and components. Do not use the FLUX.1 template solely because the product name starts with FLUX. Natural-language captions should describe the visible scene while leaving the identity/style trigger consistent. More words are not automatically better; remove hallucinated captions.

How to use it

1. Start from the matching example or GUI model preset, not a renamed job from another generation.
2. Use fixed validation prompts, including a new setting and a prompt without the trigger.
3. For FLUX.1-dev, compare checkpoints around the reference 2,000-step budget; stop earlier if the adapter becomes rigid.

Documentation — FLUX: distinguish FLUX.1, FLUX.2 and Klein

Krea 2: RAW training, Turbo validation

Musubi recommends training Krea 2 RAW and using the LoRA with Turbo for inference. Prepare raw.safetensors, the Qwen-Image VAE and the Qwen3-VL-4B single-file encoder. The documented path uses krea2_cache_latents.py, krea2_cache_text_encoder_outputs.py and krea2_train_network.py.

Keep the rank-32/alpha-32/LR-1e-4 example intact initially. At 1024, the fixed shift example is 2.5; resolution-aware krea2_shift is a separate option. RAW samples need CFG, while Turbo examples use low steps and CFG off. Blurry RAW samples with CFG disabled are not by themselves proof of a failed LoRA.

How to use it

1. Cache with the RAW training components and keep the Turbo checkpoint separate.
2. Train on RAW; for closer-to-use validation, use the documented Turbo sampling option where compatible with your memory mode.
3. Evaluate the adapter on Turbo at the documented 8-step, CFG-1 starting point, then compare identity, pose flexibility and backgrounds.

Documentation — Krea 2: RAW training, Turbo validation

Video LoRA training: Wan, LTX and MiniMax H3

Wan 2.1 / 2.2: train appearance or motion deliberately

Musubi supports Wan 2.1/2.2 with task-specific weights. Choose T2V or I2V before caching; a single-frame route is useful for appearance, while motion requires coherent video clips. Use wan_cache_latents.py and wan_cache_text_encoder_outputs.py before wan_train_network.py.

Wan 2.2 A14B splits high-noise and low-noise experts. The documentation’s ranges are 0–900 and 900–1000 for I2V, and 0–875 and 875–1000 for T2V, with distribution preservation when training one expert. Keep those values tied to the documented implementation. Training both experts needs much more memory than a single branch.

How to use it

1. Select the exact task/checkpoint and a small frame bucket; confirm one decoded training clip looks right.
2. Cache with the matching VAE/T5 and any task-required components, then start with the published Wan example.
3. For 2.2, train the selected expert/range or follow the two-expert recipe explicitly. Record which inference branch loads each adapter.
4. Validate complete clips for motion consistency and identity drift, not just attractive first frames.

Documentation — Wan 2.1 / 2.2: train appearance or motion deliberately

LTX: use the official version-matched trainer

The current official trainer covers LTX-2, 2.3 and 2.5. Their components are not identical: the documentation specifies Gemma 3 for LTX-2/2.3 and an LTX-specific fine-tuned Gemma 4 for 2.5. Changing the checkpoint while reusing old embeddings can invalidate the run.

Use the official 32GB low-VRAM config when appropriate: rank/alpha 16/16, LR 1e-4, batch 1 and 2,000 steps with INT8/checkpointing. The standard setup recommends 80GB. These are documented configurations, not a guarantee that any 32GB card fits every length/resolution.

How to use it

1. Install the LTX repository environment and obtain the matching local model/encoder files.
2. Split clips, review captions and run process_dataset.py into a fresh precomputed folder with a supported resolution/frame bucket.
3. Copy t2v_lora_low_vram.yaml or the standard config, change model and precomputed-data paths, then launch scripts/train.py.
4. Validate image-to-video, audio or reference behavior only with the corresponding training strategy and target modules.

Documentation — LTX: use the official version-matched trainer · LTX: low-VRAM YAML

MiniMax H3: keep the complete H3 recipe together

H3’s large audio-video model makes a generic “video LoRA” preset especially risky. For a guided entry, Fizgig Fast documents rank/alpha 8/8, 50 epochs and 0.25 MP with its own adaptive schedule. Its published 16GB example allows short clips up to 56 frames at 0.25 MP; that is tool-specific guidance, not a universal H3 minimum.

For Musubi, the example uses rank/alpha 16/16 and LR 1e-4, but also requires exactly one complete loss route: training adapter, guidance loss or teacher matching. Its base-time defaults are uniform/none/shift 1.0; video/audio shifts are handled internally. Copying Wan’s flow shift would change the wrong part of the system.

How to use it

1. Choose Fizgig’s guided preset or Musubi’s documented route; do not mix their learning-rate schedules.
2. Start with appearance training from stills or the shortest supported motion clips. For Fizgig, use its clip-preparation guidance rather than arbitrary video lengths.
3. With Musubi, choose a supported task/loss route and cache all required video, audio and text features consistently.
4. Run a short save-and-reload test. Then assess the final intended base model with the LoRA: training-adapter samples can differ from final inference.

Documentation — MiniMax H3: keep the complete H3 recipe together · Fizgig: MiniMax H3

From dataset to the first usable LoRA

Use the following SDXL example as a starting template for an epsilon-prediction SDXL checkpoint. Replace every path and install sd-scripts according to its own instructions first. It deliberately freezes text encoders so cached embeddings stay valid. NoobAI V-Pred and other architectures need their own prediction/model settings; do not reuse this command unchanged.

Configuration example — dataset.toml

[general]
caption_extension = ".txt"
shuffle_caption = false

[[datasets]]
resolution = 1024
batch_size = 1
enable_bucket = true

[[datasets.subsets]]
image_dir = "/path/to/images"
num_repeats = 5

SDXL / Epsilon

accelerate launch sdxl_train_network.py --pretrained_model_name_or_path="/path/to/sdxl-epsilon.safetensors" --dataset_config="dataset.toml" --output_dir="output" --output_name="subject_lora" --network_module=networks.lora --network_dim=16 --network_alpha=16 --network_train_unet_only --learning_rate=1e-4 --optimizer_type=AdamW8bit --lr_scheduler=constant --max_train_steps=1000 --save_every_n_steps=250 --mixed_precision=bf16 --save_model_as=safetensors --gradient_checkpointing --cache_latents --cache_text_encoder_outputs

A 100–200 optimizer-step smoke test should verify that caching, backward computation, checkpoint saving and inference loading all work. Do not spend the full budget before confirming the exported adapter has an effect. Then extend the run and compare checkpoints rather than automatically keeping the last one.

For modern Musubi jobs, the sequence is dataset TOML → latent cache → text-encoder cache → architecture-specific training → matching inference. Copy the complete command from the linked model document; the important differences include component files, target modules, timestep sampling and loss recipe—not just the learning rate.

Evaluate checkpoints and fix common failures

Nothing changes

Check that the adapter actually loaded, the trigger is present, the model architecture matches and the inference strength is nonzero. Inspect missing-key warnings before increasing training steps.

Everything looks like one training image

Try an earlier checkpoint, lower LoRA strength and improve dataset diversity. Reduce repeats or total steps before assuming a larger rank will help.

Loss falls but samples get worse

Use held-out prompts and fixed seeds. Training loss can improve while composition, likeness or motion becomes less flexible. Keep the best validated checkpoint, not the smallest loss.

Out of memory

Identify whether the failure occurs during caching, training or validation. Reduce batch, resolution or video length; use supported checkpointing, quantization and block swap. Gradient accumulation changes effective batch but does not make one oversized sample fit.

Video flickers or motion disappears

Check coherent source clips, frame-rate handling, the correct temporal task and video/audio targets. A good still-image identity test does not establish temporal learning.

A cached run ignores new captions

Regenerate the relevant text cache after editing captions, triggers, encoders or supported dropout settings. Do not reuse another model’s latent cache.

VRAM, time and the real training budget

Do not choose hardware from inference screenshots. Training also stores activations, gradients and optimizer state; validation can peak above training. For a cautious buying/rental plan, SDXL is the lighter starting point, modern image DiTs often benefit from 16–24GB or more with supported offloading, and video demands grow quickly with frame count. These are planning tiers, not certified minima.

Musubi recommends at least 12GB for image and 24GB for video training in its general guidance, plus 64GB system RAM; the exact architecture can need more. Krea’s own documented 1024/batch-1 comparison does not fit bf16 on a 3090 but provides quantized routes. LTX’s official 32GB/80GB configurations and Fizgig’s constrained H3 example illustrate why one “video needs 16GB” claim is misleading.

Estimate a cloud run from a short measured test: billable time = downloading and caching + optimizer steps × measured seconds per step + validation and saving. Multiply by the provider’s current hourly rate, then add storage and transfer. Local cost includes equipment and electricity. Public trainer code may be free; the GPU, base-model license and hosted service are separate.

Effective batch = per-device batch × gradient accumulation × GPU count. For 40 images repeated 5 times, effective batch 2 and 10 epochs, the simple estimate is about 1,000 optimizer steps. Bucketing and dropped partial batches can change the actual count, so use the trainer’s reported total. Epoch counts cannot be compared without these details.

Practical questions

Can one LoRA work across all these models?

No. Adapter shapes and target layers depend on architecture. Even across related SDXL checkpoints, compatible loading does not guarantee matching aesthetics or identity. Publish the exact training base and tested inference base.

Should I train the text encoder?

Start frozen for a simpler baseline and lower memory use. Cached text embeddings cannot update a frozen-away encoder. If the trainer supports encoder LoRA, test it as a separate experiment with an appropriate learning rate and without incompatible caching.

Are 20 images enough?

They may be enough for a narrow exploratory subject run if distinct and well captioned. They are not a guarantee. A style needs subject diversity; a motion needs coherent clips. Fix coverage and labels before multiplying repeats.

Should rank always be 32?

No. Rank controls adapter capacity and memory, while alpha changes scaling. Start with a coherent documented recipe, then change one variable. Anima’s alpha-1 example and Krea’s alpha-equals-rank example should not be treated as identical.

Can a still-image LoRA teach a video model a new movement?

It can help appearance, but isolated stills do not encode temporal order. Use supported video training with clips that show the movement and validate complete sequences.

Can I train a Turbo or quantized checkpoint directly?

Only when that trainer explicitly supports that format and recipe. Some routes quantize frozen weights while training bf16 adapters; others merge a training adapter first. GGUF inference support is not proof of training support.

How do I use the result?

Keep the adapter in the inference application’s LoRA folder, choose the matching base/loader, use the trained trigger and compare several strengths and seeds. For a small test, compare strength 0, 0.5 and 1; the useful range is model- and adapter-dependent. Follow any documented format conversion.

Which route should you start with?

Choose one base, one concept and one repeatable validation set. For a first anime character, SDXL with kohya_ss is the most direct route; choose Anima when that is your intended generation model. For modern photographic models, AI Toolkit is convenient while Musubi exposes the architecture-specific details.

For video, decide whether you need appearance, motion, editing or audio before preparing data. Start short, keep the entire model-specific recipe together, and verify the first exported checkpoint before scaling up. A smaller adapter that preserves flexibility is usually more useful than a long run that memorizes the dataset.

Related reading: Best AI Image Model and LoRA Download Sites: Checkpoints, LoRA and NSFW Safety