Setting Up A LoRA Training Run

Previous: How To Build A Dataset Next: Run and Monitor Training

You have a dataset, you know what you want the LoRA to learn, and you’ve picked a training mode. The next decision is what resolution and clip length to train at. The short answer is more than one, and how you combine them comes down to how much compute you have.

This chapter covers why one resolution isn’t enough, the approach most people should start with, and the higher-fidelity path for when you have the hardware.

Why one resolution isn’t enough

Train at a single resolution and you’re looking at a tradeoff, because resolution and the number of frames both cost memory and you can only spend so much per clip. Go low-resolution and you can afford a lot of frames: the LoRA sees movement and learns motion, how your subject moves and its overall shape, but it never sees fine detail. Go high-resolution and you can only afford a few frames: the LoRA learns sharp texture and detail but sees too little movement. Each setting teaches a different slice of what you want.

For a narrow concept it may not matter: a tight style LoRA or a camera-move LoRA has one thing to learn, and a single resolution is enough. But for anything that has to get both motion and detail right, a single resolution is unlikely to do the whole job. The solution is to train the same dataset at more than one resolution.

Pick your approach

There are three ways to cover more than one resolution in a LoRA. The right one depends on what the LoRA has to learn and, just as much, on the compute you have and the resolution you need out of it.

The mixed and single paths don’t need a multi-GPU cluster; a single GPU is enough. A single-bucket run is just the mixed workflow with one entry in --resolution-buckets, so the steps below cover it too (skip the multi-bucket batch-size rule, which only applies when you train several buckets at once).

If you’re not sure, start with a mixed run. It’s the simplest option that still gives you multi-resolution coverage. Use a chained run when you’re training for high-resolution output and have the compute to handle it.

The practical default: a mixed run

A mixed run trains several resolution buckets in one go. You preprocess once, listing every bucket, then launch a single training run.

Pick buckets that fit comfortably on your GPU. Training smaller doesn’t cap the size you can generate later (you upscale at inference); it only changes how much fine detail the LoRA absorbs from your footage, so for most concepts training smaller isn’t a sacrifice. A solid, healthy default is 1280×704×81, and you can shift that same budget toward motion (lower resolution, more frames) or detail (higher resolution, fewer frames). For a mixed run, combine a lower-resolution, longer-frame bucket for motion with a higher-resolution, shorter-frame one for detail.

# Preprocess all buckets in one pass (semicolon-separated)
uv run python scripts/process_dataset.py dataset.json \
    --resolution-buckets "960x544x121;1280x704x81" \
    --model-path /path/to/ltx-2-model.safetensors \
    --text-encoder-path /path/to/gemma-model \
    --lora-trigger "your_trigger"
# Train once
uv run python scripts/train.py configs/mixed.yaml

One requirement: when a run trains more than one bucket, set optimization.batch_size: 1 in the config. The trainer can’t batch clips of different shapes together.

The chain: maximum fidelity when you have the compute

The chain trains the same dataset at low, then mid, then high resolution in sequence, each stage warm-started from the last, so a single LoRA ends up with everything: the motion from the low-resolution stage and the fine detail from the high-resolution one. It’s the approach we use internally for production-quality, high-resolution work: more to run than a mixed pass, but its payoff is the high-resolution stage, so it earns its keep when you can train and generate at that resolution.

Two things change across the stages; everything else stays put.

Frame count drops as resolution climbs, from 321 to 121 to 33. This isn’t stylistic: it keeps the amount the model has to process per clip in a workable range, so long low-res clips and short high-res clips cost about the same. (The math, and the limit you stay under, is in Run and monitor training.)

Learning rate decays each stage, from 1.0e-4 to 5e-5 to 2e-5. Each stage starts from the previous stage’s weights, so a high rate would wash out what the earlier stage learned. Lowering it lets each stage refine rather than overwrite.

Held constant across every stage: the rank, the alpha (keep it equal to the rank), the first-frame conditioning probability (from your training mode), and whether audio is on.

Running the chain

A chain is three ordinary training runs where each one starts from the last: preprocess each stage’s resolution, then launch the three runs in sequence.

Preprocess once per stage, changing only the bucket, with the same dataset and trigger word each time.

uv run python scripts/process_dataset.py dataset.json \
    --resolution-buckets "512x288x321" \
    --model-path /path/to/ltx-2-model.safetensors \
    --text-encoder-path /path/to/gemma-model \
    --lora-trigger "your_trigger"

Run that three times, once per stage, with --resolution-buckets set to 512x288x321, then 960x544x121, then 1920x1088x33.

Train stage 1 from the base model, then warm-start each later stage by pointing model.load_checkpoint at the previous stage’s final weights.

# Stage 1: train from the base model
uv run python scripts/train.py configs/stage1.yaml
# Stages 2 and 3: warm-start from the previous stage's weights
model:
  load_checkpoint: outputs/stage1/lora_weights.safetensors

Point load_checkpoint at the LoRA weights file (lora_weights.safetensors), not a full training-state checkpoint. Loading the weights carries the learning forward while letting each stage set its own learning rate; resuming from full state can pin the rate to the previous stage’s value.

For each later stage, set its resolution, frame count, and learning rate from the table, point load_checkpoint at the prior stage’s weights, and launch. The output of stage 3 is your finished LoRA. On multiple GPUs, wrap each train.py call with accelerate launch as the Training Guide shows.

Watch out: each stage must use the preprocessed data for its own bucket. Don’t point stage 3 at stage 1’s data.

Set the rank before you start

Rank sets how much the LoRA can learn. Higher rank means more capacity, but also a heavier file, more memory, and more training time, so pick the lowest rank that captures your concept cleanly. As a starting point, a single character or style wants 32 to 64, a dense multi-character world wants 96 to 128, and a pure motion or camera LoRA wants only 8 to 16. (The Configuration Reference lists every LoRA parameter, including rank.)

Pick it before you start, and if you’re chaining, know that it’s fixed across all the stages, so you can’t change your mind later. A single character with a strong style is a reasonable rank-64 case: enough capacity to hold the look without paying for a series-scale LoRA.

With an approach and a rank chosen, you’re ready to launch and watch what the run is doing.

Next: Run and Monitor Training