How to Train Your Own LTX-2.5 LoRA on One GPU, Step by Step

Yes, you can train a LoRA for LTX-2.5 yourself, and you do not need a cluster. Lightricks ships an open trainer for its 22B video model, a rented 48GB GPU will run it, and the whole job is five commands and one YAML file. The two things that trip people up are not the model. They are the frame grid your clips have to sit on, and the text encoder, which has to match the model version exactly.

This guide follows the official trainer end to end, then covers the graphics-interface route through Ostris AI Toolkit for anyone who would rather click than configure. Every setting below is the value Lightricks or the toolkit's own documentation states; where two sources disagree about hardware, both are given.

What You Are Building, and What a LoRA Is Good For

A LoRA is a small adapter file trained on top of a frozen model. It learns one thing: a look, a face, a motion, a camera behaviour. You attach it at generation time and the base model stays untouched. The file is light because only adapter layers train.

LTX-2.5 is a good target for that. Released on August 11, 2026, it pairs a 22B dual-stream diffusion transformer with an LTX-specific fine-tuned Gemma 4 12B text encoder, and it generates picture and sound together. The open trainer handles three shapes of job through one config-driven framework: LoRA for styles, effects and subjects, full fine-tuning for reshaping the model itself, and IC-LoRA for video-to-video control where a reference clip drives the structure.

For a first run, train a LoRA. Lightricks' own guide puts it plainly: LoRA fits on a single GPU and is the right default for styles, effects and specific subjects or motions, while full fine-tuning wants four to eight H100 80GB cards with FSDP sharding. Community trainers report that character, style, motion and camera LoRAs are the four that earn their keep, and that an image-only dataset can teach identity and style but cannot teach motion.

What you get at the end is one file, lora_weights_step_00000.safetensors, plus validation samples and a copy of the config.

What Hardware It Really Needs

Here the sources disagree, and the disagreement is worth knowing before you rent anything.

• Lightricks' trainer README asks for Linux with CUDA, CUDA 13 or newer for best performance, and an Nvidia GPU with 80GB or more VRAM for the standard config. For 32GB cards such as the RTX 5090 it points at a low-VRAM config that enables INT8 quantization, an 8-bit optimizer, an 8-bit text encoder and a LoRA rank of 16 instead of 32.
• Lightricks' fine-tuning guide says the same in other words: 80GB and up on Linux for the standard config, or the INT8 low-VRAM config for 32GB cards.
• Lightricks' community-LoRA guide gives a lower baseline of 32GB VRAM, 32GB RAM, about 100GB of storage and CUDA 12.7, which fits the distilled checkpoint with quantization. The same page adds that full-precision inference on the unquantized dev checkpoint runs closer to an 80GB card, and labels that a third-party estimate rather than an official figure.
• An independent measurement from Inline Studio's own trainer is the most concrete number available: training a clip LoRA at rank 16, batch 1, 512px with gradient checkpointing peaked at 42GB on an L40S, with the 22B base alone occupying 38GB once loaded. They put the floor at a 48GB card and say a 24GB card cannot run their trainer at any resolution. That is their stack, not Lightricks', and they note it takes no quantization config, which is why their floor is higher.

The practical read: 48GB is comfortable for the official trainer, 32GB is the documented low-VRAM path, and if you are renting, take a 48GB card by the hour. Storage matters too: the LTX 2.5 split pack is several files, and the transformer alone is 42GB in bf16.

One gate before any of that. The weights are gated on Hugging Face. Accept the LTX-2 Community License on the model page with the same account your access token belongs to, or every download returns a permission error.

Step 1: Install the Trainer

The trainer lives inside the LTX-2 monorepo. Clone it, install from the repository root, then move into the trainer package:

• git clone https://github.com/Lightricks/LTX-2.git
• cd LTX-2
• uv sync --frozen
• cd packages/ltx-trainer

Two things break installs here. Lightricks' guide flags the first: the ltx-kernels package needs uv_build version 0.9.8 or newer and a CUDA compiler, nvcc, matching your installed PyTorch. Check both before you start, because that is where most setups fail. The second is a Triton dependency, and it is the reason the README asks for Linux: the trainer depends on Triton, so a Windows box needs WSL or a container.

You also need the model itself: the LTX 2.5 transformer, the matching gemma4-12b-with-proj-ltx-2.5 text encoder, the video VAE, and, if your run touches audio, the audio VAE. LTX-2.5 publishes one file per component, unlike the older single-file packs, so the trainer has to be told where each one lives.

Step 2: Assemble the Dataset

This is the step that decides whether the run works. Three constraints govern it.

• Frames follow the model's grid: 8n+1. Valid counts include 49, 73, 97 and 121 frames at 24 fps. The video decoder only encodes certain frame counts, and the trainer snaps down onto that grid.
• Width and height must be divisible by 32.
• Clip length is a budget. For a first LoRA, RunComfy recommends a five-second baseline, which is 121 frames at 24 fps, and warns that a mismatch between frame count, fps and clip duration is one of the main reasons clean speech comes out pitched or out of sync. Shorter clips train faster; 49 frames, about two seconds, is enough for identity and style.

Twenty to forty clips is a normal set for a style or a character. What matters more than count is consistency: if you want the LoRA to learn one look, every clip should share it.

An LTX dataset is a JSON, JSONL or CSV file naming each clip and its caption, with optional columns for reference videos, masks or audio. The simplest form is one object per clip, like {"caption": "A cat playing with a ball of yarn", "video": "videos/cat_playing.mp4"}, repeated for every clip in the set.

If your material is long-form, split it first. split_scenes.py cuts a video into coherent scenes, and the trainer's own example filters out anything shorter than five seconds: uv run python scripts/split_scenes.py input.mp4 scenes_output_dir/ --filter-shorter-than 5s.

Captions are next, and LTX expects a specific kind. Each caption is a single detailed paragraph describing the visual content and the audio, including speech, music and ambience. The trainer can write them for you with a multimodal model that understands both: uv run python scripts/caption_videos.py scenes_output_dir/ --output scenes_output_dir/dataset.json.

The default captioner is qwen_omni, which talks to a local vLLM server you start once in another terminal with serve_captioner.py. There is also a gemini_flash backend if you would rather use an API key. Either way, read the captions before training. Lightricks warns in the documentation that automatically generated captions may contain inaccuracies or hallucinated content, and a caption that describes something the clip does not contain teaches the model the wrong thing.

Step 3: Preprocess the Clips Into Latents

Training does not read your videos directly. Preprocessing encodes each clip into latents and each caption into text embeddings, and caches both, which is why a second run is much faster than the first.

The command is uv run python scripts/process_dataset.py dataset.json, followed by --resolution-buckets "960x544x49", then --model-path pointing at your transformer file, --text-encoder-path at the packed Gemma 4 encoder, and on a split LTX 2.5 pack --video-vae-path and --audio-vae-path at the two VAE files.

Three rules apply here. Preprocessing writes to .precomputed/, and that directory is what you point the config at. On a split LTX 2.5 pack the two VAE paths are required, because the transformer carries no VAE weights. And any change that affects encoding, a different checkpoint, a different Gemma root, a different resolution bucket, even a different trigger word, needs --overwrite or a fresh output directory, because existing files are skipped by default and you would silently train against stale features.

The text embeddings are also version-locked: LTX-2.3 uses Gemma 3 and LTX 2.5 uses Gemma 4, and the two are not interchangeable. If preprocessing runs out of memory, the documented fix is smaller buckets, meaning lower width and height or fewer frames.

Step 4: Write the Training Config

Copy an example config and change four groups of values. For a text-to-video LoRA the starting point is configs/t2v_lora.yaml, and these are its values:

• Under model: model_path pointing at the transformer, text_encoder_path at the Gemma 4 encoder, video_vae_path and audio_vae_path at the two VAE files, and training_mode: "lora".
• Under lora: rank: 32, alpha: 32, dropout: 0.0, and target_modules set to ["to_k", "to_q", "to_v", "to_out.0"].
• Under optimization: learning_rate: 1e-4, steps: 2000, batch_size: 1, optimizer_type: "adamw" and enable_gradient_checkpointing: true.
• Under data: preprocessed_data_root pointing at the .precomputed directory from step 3.

The details worth understanding:

• Rank and alpha. 32 and 32 is the documented starting point, and the effective scaling is alpha divided by rank, so equal values mean a scale of 1.0. The low-VRAM config drops to 16 and 16 to save parameters; the trainer's config comments list 8 to 64 as the working range.
• Target modules. The short patterns to_k, to_q, to_v and to_out.0 match every attention module in the model, which means video attention, audio attention and the cross-modal blocks between them. That is Lightricks' recommended approach for audio-video training. Adding the feed-forward patterns (ff.net.0.proj, ff.net.2 and their audio twins) increases capacity if a run underfits.
• Learning rate. 1e-4 for LoRA, with 1e-5 to 1e-4 as the documented range. Two thousand steps is the example's first full run.
• Batch size 1. Keep it there. If you mix images and videos, the trainer requires batch 1 because samples with different shapes cannot be collated, and you use gradient_accumulation_steps when you want a larger effective batch.
• Validation. The config generates sample videos every 100 steps at 960x544 and 89 frames by default, and those samples are how you judge the run while it is going. They are generated with a simplified pipeline, so treat them as a progress signal rather than final quality.
• Checkpoints. One every 250 steps, kept indefinitely by default. Long training runs flatten out; several checkpoints let you pick the step before that happened.

If you are on a 32GB card, start from configs/t2v_lora_low_vram.yaml instead. It sets INT8 quantization on the base model, adamw8bit, load_text_encoder_in_8bit, rank 16, and validation at 576x576 with 49 frames.

Step 5: Run the Training

One command for a single GPU: uv run python scripts/train.py configs/t2v_lora.yaml. For more than one GPU, wrap it with accelerate launch --num_processes N. The trainer validates the config, loads and optimizes the models, runs the loop with progress tracking, generates the validation videos and writes checkpoints into your output directory.

The validation samples are the part to watch. They regenerate every 100 steps by default, so you see whether the LoRA is learning your look before the run finishes, and the checkpoints every 250 steps let you keep an earlier one if a later step overfits.

Three errors to expect:

• frames must satisfy (frames - 1) % 8 == 0 means a clip is off the frame grid. Re-cut it, or let the trainer snap it down if your tooling offers that.
• A Gemma version mismatch means the text encoder folder does not match the checkpoint. LTX 2.5 needs the LTX fine-tuned Gemma 4; stock Gemma 4 is not a substitute, and the pipeline checks encoder metadata against the checkpoint and fails if they differ.
• Slow training usually traces to gradient checkpointing without enough VRAM headroom, a batch size that does not fit and is being offloaded, or a Windows build without a compiled Triton. The tuning levers are in the trainer's troubleshooting guide: 8-bit text encoder, smaller resolutions, fewer frames, and lower rank.

Step 6: Load the LoRA and Test It

Training leaves lora_weights_step_00000.safetensors in the output directory. Loading it in the official pipelines takes two flags: --lora-paths points at the file and --lora-scale sets how strongly to apply it, alongside the same transformer, text encoder, VAE, duration head and spatial upsampler paths you downloaded. A typical call ends --lora-paths path/to/your_lora.safetensors --lora-scale 0.8.

Lightricks' guidance for the scale is 0.8 to 1.2, changed one value at a time against a fixed seed so you can see what the strength did. Pass several paths to load several LoRAs at once, and expect effects to average out rather than stack cleanly, which is why two character LoRAs in one prompt tend to produce a third face instead of either character.

In ComfyUI, LTX-2.5 shipped with native templates. Use one built for the split LTX 2.5 checkpoint pack, drop the LoRA into models/loras/ and load it with a LoRA loader node. An LTX-2.3-era workflow will trip over the different file layout.

IC-LoRAs take a different road. Structural adapters such as pose, depth, canny or the team's own Clean Plate run through a separate ICLoraPipeline and only work with the distilled checkpoint, not the dev checkpoint. They also need a reference video, which is where the control signal comes from.

One compatibility note that saves a retrain: most LoRAs and IC-LoRAs trained on LTX-2.3 run on LTX-2.5 unchanged, per Lightricks' own testing, despite the new text encoder. Validate any older adapter across your full prompt range before relying on it. The Community Library tags each listing with a licence and a compatibility line, which is the fastest check before you download.

The Alternative: Ostris AI Toolkit

If you would rather not touch a YAML file, Ostris AI Toolkit is the same job through a browser interface, and it supports the LTX family alongside Flux, Qwen-Image, WAN and others. Its manager script installs PyTorch for your hardware, brings its own Node.js and FFmpeg, and serves the UI on localhost:8675.

RunComfy, which hosts the same toolkit, publishes the LTX-2.5 defaults that matter: convrot8 quantization on both the transformer and the text encoder, rank and alpha 32, bf16, AdamW8Bit, learning rate 1e-4, batch 1, 2000 steps, weighted timesteps with FlowMatch, an audio loss multiplier of 1.0, 121 frames at 24 fps, and Auto Frame Count off. Two of its warnings are worth repeating: do not copy qfloat8 settings from an LTX-2.3 job, because LTX 2.5 is a new transformer and text-encoder package, and rebuild your caches whenever the model, resolution, timing or audio processing changes.

The trade-off is speed. One reported issue against AI Toolkit measured LTX-2 LoRA training running about five times slower than the official trainer with a compiled Triton 3.4.0 build on Windows. Treat that as a user report on one machine rather than a guarantee, and benchmark your own before committing to a long run. If you have no GPU at all, both the toolkit and Inline Studio can be rented by the hour on cloud GPUs.

Five Mistakes That Kill a First Run

1. The wrong Gemma. LTX 2.5 needs the LTX fine-tuned Gemma 4 12B. Stock Gemma 4 fails the metadata check, and Gemma 3 belongs to LTX 2.3.
2. Stale caches. Existing .pt files are skipped, so changing the checkpoint, the resolution bucket or the trigger word without --overwrite trains against yesterday's features.
3. Off-grid clips. Frames must be 8n+1 and dimensions divisible by 32. Anything else either errors or gets silently trimmed.
4. Captions that describe the picture only. LTX learns sound as well, and a caption with no audio description leaves the audio branch guessing.
5. Training on a distilled checkpoint. Train the dev transformer. Distilled checkpoints exist for fast inference, and training on one breaks the distillation it was built around.

What You Can Legally Ship

The weights ship under the LTX-2 Community Licence, which allows commercial use at no cost for companies under $10 million in annual revenue and requires a commercial licence above that. The model repository is gated, and that acceptance is part of the download.

Your LoRA is your own file, but running it still means running the base model under its licence, and each published LoRA carries its own terms on top, whether Apache 2.0, MIT, the LTX licence or OpenRAIL. Check both before you ship anything commercial.

The trainer, the configs and the dataset documentation are in the LTX-2 repository, the model weights are at huggingface.co/Lightricks/LTX-2.5, and finished LoRAs are indexed in the LTX Community Library.