LTX 2.3 ni modeli ya video ya AI ya chanzo huria yenye vigezo bilioni 22 iliyoundwa na Lightricks kwa usanifu wa Diffusion Transformer (DiT). Inasaidia utengenezaji wa maandishi-kuwa-video, picha-kuwa-video, sauti-kuwa-video, na video-kuwa-video ikiwa na matokeo ya wima asilia, VAE iliyojengwa upya, na kiunganishi cha maandishi kilichopanuliwa mara 4 kwa tafsiri sahihi zaidi ya maelekezo. Uzito wa modeli unapatikana kwenye Hugging Face kwa checkpoints za dev na distilled.

LTX 2.3 inalinganishwaje na modeli zingine za video kama WAN 2.2?

Kwenye GPU za H100, mfululizo wa LTX 2 unafanikiwa takriban mara 18 zaidi ya kasi ya WAN 2.2 14B, hivyo ni haraka zaidi kwa utengenezaji wa wingi. LTX 2.3 pia inaleta video ya wima asilia 9:16, vocoder ya sauti iliyoboreshwa, na maelezo makali zaidi kutoka kwenye nafasi ya latent iliyojengwa upya — maboresho ambayo bado hayajafananiwa na modeli nyingi za chanzo huria.

Modeli inasaidia vipimo vipi vya video?

Video zinatengenezwa hadi ubora wa 1080p HD katika uwiano wa 16:9, 9:16, 1:1, na 4:3 na muda wa sekunde 4 hadi 20 ikiwa ni pamoja na matokeo yaliyosawazishwa na sauti. LTX 2.3 ndiyo ya kwanza katika mfululizo wake kusaidia video ya wima asilia 1080x1920, iliyofunzwa kwa data halisi ya picha za wima badala ya video za mlalo zilizokatwa. Maelekezo yanakubali hadi herufi 2,000 kwa maelezo ya kina ya eneo.

Je, LTX 2.3 ni bure kutumia?

Ndiyo. Akaunti mpya kwenye ltx23.app zinapata mikopo ya bure kujaribu utengenezaji wa video kwa AI. Baada ya hapo, unaweza kununua mikopo ya ziada au kujiandikisha kwenye mpango ili kuendelea kuunda. Mipango ya usajili inatoa punguzo la wingi kwa waundaji wa mara kwa mara.

Je, ninaweza kutumia matokeo ya LTX 2.3 kibiashara?

Ndiyo. Video zilizotengenezwa kwenye ltx23.app zinajumuisha haki kamili za kibiashara — hakuna alama za maji, hakuna ada za mrabaha. Leseni ya chanzo huria pia inaruhusu matumizi ya kibiashara ya matokeo yaliyotengenezwa kwa ndani kwa mashirika yanayostahiki, ikijumuisha matangazo, mitandao ya kijamii, utangazaji, na uchapishaji.

Ninaanzaje kutumia LTX 2.3?

Fungua akaunti ya bure kwenye ltx23.app, ingiza maelekezo ya maandishi yanayoeleza video yako, kwa hiari pakia picha au sauti ya rejea, weka vigezo kama muda na uwiano wa skrini, kisha bonyeza tengeneza. Video yako iko tayari kupakuliwa kwa dakika chache — hakuna ujuzi wa kuhariri video au AI unaohitajika.

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

	`ltx-2.3-22b-dev`	`ltx-2.3-22b-distilled-1.1`
Size	46.1 GB	46.1 GB
Steps	~20–40 (20–30 with gradient estimation)	8 + 4 in the two-stage distilled pipeline
Guidance	Full CFG	None required (CFG=1)
Trainable	Yes, in bf16	Not the training target
Best at	Final renders, maximum prompt adherence	Iteration, batch runs, control pipelines

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:

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.
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.
Render the final with dev, using the two-stage pipeline (TI2VidTwoStagesPipeline), the distilled LoRA for stage-2 refinement, and the spatial upscaler.
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.
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:

Lightricks/LTX-2.3 — Hugging Face model card — variant list, 8 steps / CFG=1, 1.1 audio improvement, file sizes
LTX-2 available pipelines documentation — 8 predefined sigmas, distilled-only pipelines, res_2s sampler, retake constraints
Lightricks/LTX-2 — official GitHub repository — distilled LoRA requirement, optimization tips
LTX-2 optimization documentation — gradient estimation 20–30 steps, torch.compile, FP8 policies
LTX-2 installation & CLI flags — flag reference
LTX-2 pipeline selection guide — official selection logic
ComfyUI official LTX-2.3 tutorial — which template uses which FP8 checkpoint
ltx-trainer documentation — training target and hardware
LTX-2.3-22b-IC-LoRA-LipDub — distilled-only lip dub LoRA
ComfyUI-LTXVideo — official integration repository
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.