LTX 2.3 Distilled vs Dev: Which Checkpoint to Use

Both checkpoints are 46.1 GB. Both are 22B parameters. Both are called LTX 2.3. And yet picking the wrong one is the most common reason people conclude the model is "slow" or "not that good."

ltx-2.3-22b-dev and ltx-2.3-22b-distilled-1.1 are not quality tiers. They are two different sampling contracts, and several official pipelines will only accept one of them. Understanding which is which changes your iteration speed more than any settings tweak.

This guide is built from the LTX-2.3 model card, the official pipeline documentation, and the ComfyUI LTX-2.3 tutorial, verified July 2026.

The one-paragraph answer

Distilled runs on a fixed short sigma schedule — the official DistilledPipeline uses 8 predefined sigmas: 8 steps in stage 1, 4 steps in stage 2, and requires no guidance at all. The model card lists the distilled variant as 8 steps, CFG=1.

Dev is the full model: trainable in bf16, run with real classifier-free guidance and a normal step count, where the optimization docs describe reducing from 40 steps to 20–30 using gradient estimation.

That is the whole difference in one line: distilled trades the guidance mechanism for speed; dev keeps it.

What each variant actually is

There is a third file in the repo — ltx-2.3-22b-distilled.safetensors, the original 1.0. The model card describes 1.1 as having improved audio compared to 1.0. If you already downloaded 1.0 and audio quality has been your complaint, that is your upgrade, and it costs you nothing but bandwidth.

Alongside the checkpoints sit the distilled LoRAs, ltx-2.3-22b-distilled-lora-384-1.1.safetensors (7.61 GB). These are not optional extras — the official README states the distilled LoRA is required by current two-stage pipeline implementations, except for DistilledPipeline, ICLoraPipeline, and LipDubPipeline. The two-stage dev path uses it for the stage-2 refinement.

The part almost nobody mentions: some pipelines force your hand

This is the difference between an informed choice and a coin flip. Several official pipelines are hard-wired to one checkpoint:

Distilled required:

• ICLoraPipeline — the docs state it can only be used with a distilled model
• LipDubPipeline — requires a distilled checkpoint plus exactly one lip-dub IC-LoRA
• HDRICLoraPipeline — two-stage video-to-video on the distilled model

Dev-oriented in ComfyUI:

• T2V, I2V, IA2V, and ID-LoRA templates use ltx-2.3-22b-dev-fp8.safetensors
• FLF2V and IC-LoRA Union Control use ltx-2.3-22b-distilled-fp8.safetensors

So the real decision tree starts with what you are doing, not what quality you want. If you are doing structural control or lip dubbing, the checkpoint is chosen for you. If you are doing plain T2V or I2V, you get to choose — and that is where the trade-off below applies.

The trade-off, framed usefully

The instinct is to read "distilled" as "worse." A more accurate reading is "fewer chances to be steered."

Classifier-free guidance is what lets a model exaggerate prompt adherence — pushing output away from the unconditional prediction and toward what you asked for. A distilled model that runs at CFG=1 has given that lever up in exchange for landing in a good place in far fewer steps.

Practically:

• Complex, unusual, or heavily-specified prompts benefit more from dev, because guidance is exactly what enforces the unusual part.
• Straightforward prompts within the model's comfort zone often look nearly identical between the two, at a fraction of the compute.
• Anything you are going to run fifty times — batch generation, dataset creation, thumbnail exploration — should be distilled regardless.

The corollary matters for anyone reviewing output: if you compare a distilled render against a dev render on a simple prompt and conclude there is no difference, you tested the case where there was never going to be one.

Testing which one fits your prompt style? You can iterate on prompts against LTX 2.3 in the browser at ltx23.app without downloading 46 GB twice — then commit to whichever checkpoint your actual prompts turn out to need.

The workflow that uses both

The strongest setup is not choosing. It is staging:

1. Explore with distilled. 8+4 steps means you can test ten framings in the time one dev render takes. Lock down composition, motion, and timing here.
2. Confirm the prompt is doing the work. If a shot only works because you rerolled the seed twenty times, more steps will not save it — fix the prompt.
3. Render the final with dev, using the two-stage pipeline (TI2VidTwoStagesPipeline), the distilled LoRA for stage-2 refinement, and the spatial upscaler.
4. Consider the HQ variant. TI2VidTwoStagesHQPipeline uses the res_2s second-order sampler instead of Euler and, per the docs, typically allows fewer steps for comparable quality. It is the most underused switch in the stack.
5. Fix regions, don't reroll. If one second of the final is wrong, RetakePipeline regenerates only that [start_time, end_time] window instead of the whole clip.

Step 5 is where the two-checkpoint workflow really pays: cheap exploration, one expensive render, surgical repair. Rerolling a full dev render because of one bad second is the most expensive habit in local video generation.

Speed levers that apply to both

From the official optimization documentation:

• FP8 quantization — --quantization fp8-cast on any FP8-capable GPU; --quantization fp8-scaled-mm for FP8 checkpoints on Hopper and newer. Set PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True alongside it.
• Gradient estimation — 20–30 steps instead of 40 on the dev path.
• torch.compile — off by default; --compile mode=reduce-overhead captures CUDA graphs and is described as the main latency lever for the denoising loop, at the cost of reserved static memory.
• Skip inter-stage memory cleanup — pipelines clean GPU memory between stages by default; if you have headroom, skipping it cuts runtime.
• Single-stage for prototyping — TI2VidOneStagePipeline is faster but is explicitly labeled primarily for educational purposes, typically outputting around 512x768. Do not ship from it.

FAQ

Is LTX 2.3 distilled worse than dev? Not categorically. It runs at CFG=1 on a fixed 8+4 step schedule, so it has less room to be steered toward unusual prompts. On typical prompts the gap is much smaller than the step-count difference suggests.

What is the difference between distilled 1.0 and 1.1? The model card describes 1.1 as having improved audio relative to 1.0. Use 1.1.

Do I need the distilled LoRA if I use the dev checkpoint? Yes, for the two-stage pipelines — it drives the stage-2 refinement. DistilledPipeline, ICLoraPipeline, and LipDubPipeline are the documented exceptions.

Which is better for low VRAM? Both weigh the same in bf16, so precision and offload matter more than the choice. In practice distilled wins on a constrained machine because fewer steps means less time paying the offload penalty.

Can I train a LoRA on the distilled model? The dev checkpoint is the one described as trainable in bf16. Train against dev.

Bottom line

Distilled versus dev is a sampling contract, not a quality ladder: 8+4 steps at CFG=1 versus a full guided run at 20–40. Some pipelines pick for you; when they do not, iterate on distilled and finish on dev.

And when you just want the output without maintaining two 46 GB checkpoints, ltx23.app runs LTX 2.3 in the browser.

Sources

Verified July 2026 against primary documentation:

1. Lightricks/LTX-2.3 — Hugging Face model card — variant list, 8 steps / CFG=1, 1.1 audio improvement, file sizes
2. LTX-2 available pipelines documentation — 8 predefined sigmas, distilled-only pipelines, res_2s sampler, retake constraints
3. Lightricks/LTX-2 — official GitHub repository — distilled LoRA requirement, optimization tips
4. LTX-2 optimization documentation — gradient estimation 20–30 steps, torch.compile, FP8 policies
5. LTX-2 installation & CLI flags — flag reference
6. LTX-2 pipeline selection guide — official selection logic
7. ComfyUI official LTX-2.3 tutorial — which template uses which FP8 checkpoint
8. ltx-trainer documentation — training target and hardware
9. LTX-2.3-22b-IC-LoRA-LipDub — distilled-only lip dub LoRA
10. ComfyUI-LTXVideo — official integration repository
11. LTX-2 technical paper (arXiv 2601.03233) — architecture and distillation background

Step counts and sigma schedules are those documented for the official pipelines; custom samplers in ComfyUI can deviate from them.