LTX-2.3 vs WAN 2.2: Open-Source Video Model Comparison (2026)

Hi, I’m Dora. I didn’t set out to compare LTX-2.3 vs WAN 2.2. I just wanted a render before lunch: a short product clip, a clean camera move, no wobble, and no babysitting nodes. I kept seeing people toss around “~18x faster,” which sounded like a dare. So over a few days in March 2026, I ran the same prompts through both models in ComfyUI, nudged settings, and paid attention to how my brain—and my GPU fans—felt. This is what stuck with me.

One boundary before the numbers: I recorded an RTX 4090, ComfyUI nightly, and the same prompt and numeric seed where supported, but my notes don’t include a complete checkpoint, precision, output-size, frame-count, and timing log for every pair. The results below are my workflow observations, not a controlled speed benchmark.

At a Glance: What Each Model Optimizes For

If I oversimplify on purpose:

LTX-2.3 got me a first draft quickly. That mattered when I was testing a storyboard or deciding whether the prompt itself worked. Its official model page also describes native audio-video generation.
WAN 2.2 gave me more of the motion weight and camera feel I was chasing in these tests. I waited longer, but sometimes needed fewer revisions to get the shot I had in mind.

In daily use, that meant more inexpensive attempts with LTX and, once I’d found the right setup, fewer restarts with WAN. That’s my March experience, not a rule that WAN wins every camera prompt.

Core Differences Table

These notes came from my March 2026 runs on one RTX 4090 with ComfyUI nightly. The official WAN 2.2 T2V-A14B model card describes 480p and 720p, five-second generation for that checkpoint. A custom ComfyUI workflow can extend or process an output differently, so I wouldn’t treat my exported file settings as the model’s native limits.

What I compared	LTX-2.3 in my workflow	WAN 2.2 in my workflow
First-draft speed	Usually the quicker route	Usually the longer wait
Camera and motion	Stable framing; occasionally floaty movement	Motion felt weightier on my chosen shots
Fine texture	Could soften when motion became busy	Held fabric, skin, and wood texture better in my close-ups
Audio	Generated sound in the LTX path I used	I added or routed audio separately
Setup cost	Shorter iteration loop	More time tuning nodes and managing memory

A few details don’t fit neatly in the table. I exported both sets at 24 fps, but an export frame rate doesn’t tell me how many unique frames each model generated before any interpolation or conversion. WAN needed more babysitting when I pushed my workflow above 768p; that is not a claim that the official T2V-A14B checkpoint natively supports that output size. LTX felt stable at 720p and workable at 1080p with shorter durations in my setup.

For speed, I used WAN as 1x and wrote down 10–14x for LTX across most prompts, with ~18x once on a simple scene. I rarely got under 16 GB VRAM without compromises, and my WAN workflow felt smoother with 20+ GB on longer runs. Those figures are retained from my notes; without the missing configuration fields, they should not be generalized to another machine or checkpoint.

How I Would Re-run the March Comparison

If I needed to make a buying or deployment decision from this test, I’d run it again with a small, fixed shot list. My original three shots are enough: a product spin, a walking shot, and a push-in through a doorway.

For each attempt, I’d save a row with the exact LTX and WAN checkpoint names, ComfyUI version and workflow file, GPU, precision or quantization, resolution, requested frames, exported fps, steps or sampler, seed, audio setting, peak VRAM, and wall-clock time from pressing Queue to a playable file. I’d also separate queue time from generation time if the workflow exposes both. The same numeric seed across two model families does not produce equivalent randomness; it only helps repeat a run within each setup.

I’d review failures before picking a winner:

Product spin: Does the product change shape, or does texture soften as it rotates?
Walking shot: Do feet meet the ground, and does the body keep its weight through the step?
Doorway push-in: Is the parallax believable, or does the background wobble?
Audio check: Is usable sound already in the file, and how much time does a separate audio pass add?
Deployment check: How many runs produce a clip I would actually send, and what is the total time or cost per accepted clip?

These are checks for a repeat test, not new results I’ve invented. My March notes contain texture softening, floaty motion, and the extra WAN audio step; they don’t contain a measured failure rate for each shot. That distinction matters more to me than a tidy “18x” headline.

Speed: LTX-2.3’s Largest Advantage

What the ~18x Speed Claim Actually Means for Iteration Workflows

That number didn’t magically make every render finish in seconds. What it changed was the rhythm. On my product spin, walking shot, and doorway push-in, LTX usually gave me a usable draft in 1–2 minutes; WAN took 12–18 minutes on the same machine in my recorded workflow. I could try several prompt variants while my coffee cooled instead of feeling stuck with one mediocre take.

I caught mistakes earlier. Bad lighting prompt? Wrong focal-length feel? Easy to rerun. But the 10–14x range and one ~18x result are observations from that setup. Checkpoint choice, precision, requested frames, size, node graph, and whether audio and decoding are included can change the ratio. For teams testing a hosted route, the LTX-2.3 text-to-video model on WaveSpeedAI provides a separate workflow to evaluate; its latency should be measured separately from local ComfyUI time.

When Speed Stops Being the Deciding Factor

I hit a ceiling on scenes with parallax, a dolly plus tilt, or a lingering rack focus. In those attempts, WAN’s slower pass landed closer to the shot in my head. If I needed a particular camera move, I’d stop after the second unconvincing LTX pass and try WAN.

That is also why I track time to an accepted clip, not just seconds for one generation. A faster render that needs four retries can lose its advantage.

Visual Quality and Prompt Adherence: Where Each Model Leads

Fine Detail and Texture Retention

Close-ups exposed the difference in my runs. Fabric weave, skin pores, and wood grain held up better with WAN 2.2 when I used gentle denoising. LTX-2.3 sometimes softened textures as movement became busy. I could push the LTX workflow with more steps, but then I gave back some speed.

I wouldn’t promote that into a blanket quality ranking. The result depends on which LTX checkpoint and pipeline, which WAN variant, and what motion you’re asking for. My useful takeaway is narrower: check a moving close-up, not just a sharp first frame.

Camera Control and Cinematic Motion (WAN’s Edge)

This is where WAN won my shot list. Its camera arcs felt intentional rather than merely mobile, and the walking shot carried more of the weight I wanted. LTX-2.3 kept framing steady, which was welcome for the product clip, but some movement felt floaty to me.

If you have exact camera language, test whether either model follows it from start to finish. Don’t judge from a single attractive frame or assume the prompt transfers unchanged between workflows.

Native Audio: LTX-2.3 vs WAN 2.2

LTX-2.3’s Audio-in-One-Pass vs WAN’s Approach

I don’t score draft sound. I just need it to be non-distracting while reviewing. LTX-2.3’s audio-video path gave me soft ambience and light foley in one generation, consistent with Lightricks’ description of the model. It removed a couple of steps from my review loop.

My WAN 2.2 T2V setup required an extra audio step. For polished work I often replaced the sound anyway; for a quick stakeholder preview, LTX’s included audio was convenient. This comparison is about the specific WAN 2.2 T2V path I ran, not every later WAN model or third-party workflow.

ComfyUI Ecosystem Maturity: WAN’s Head Start

Available Workflows, LoRAs, and Community Resources

In March, I found more WAN-first community graphs for the things I wanted to try: camera movement, motion presets, and LoRAs. LTX-2.3 nodes were straightforward to wire, but I spent more time looking for examples when a shot needed extra control.

That is a description of what I found, not a count of available workflows. Both ecosystems keep moving. I now save the graph and model versions that worked rather than assuming a template will behave the same way after an update.

Licensing and Commercial Use: Side-by-Side

I got this wrong in my first notes. I described WAN 2.2 as commonly restricted to research use, but the official WAN 2.2 T2V-A14B checkpoint lists Apache 2.0 on its model card. A community repack or add-on can have its own terms, so I still check the exact files I download.

LTX-2.3 is different: its official Hugging Face model card lists the ltx-2-community-license-agreement. Lightricks’ licensing page describes conditions for commercial deployment, including a revenue threshold for some uses. I keep the model card, license, and checkpoint version in the project folder before client work. “Open weights” describes access to the files; it doesn’t make the two licenses interchangeable.

Decision Framework: When to Use Each

How I decide, quickly:

Lots of variants to find a direction: LTX-2.3 first.
A clear camera brief where motion weight matters: Try WAN 2.2 early.
Product beauty with steady framing: Start with LTX; switch if moving texture or the camera path misses the brief.
Sound needed in a draft preview: LTX’s native audio-video path saves me a step.
A clip beyond 12–16 seconds: Some WAN community templates behaved better for me, but that observation is about those workflows. The official WAN 2.2 T2V-A14B card describes five-second clips, so I would verify any extension pipeline separately.

For a high-stakes shot, I’ll prototype quickly in LTX and then test WAN for the finish. I don’t simply swap nodes and assume the prompt, seed, timing, and audio behavior will match. I keep both outputs and compare them against the same shot brief.

FAQ

Is LTX-2.3 really 18x faster than WAN 2.2?

I saw 10–14x most often on my RTX 4090 and ~18x once on a simple scene. My notes also say 1–2 minutes for a usable LTX draft versus 12–18 minutes for WAN in that workflow. Because I didn’t log every checkpoint, precision, frame count, and output size, I wouldn’t call those figures a reproducible benchmark. Re-run the fixed-shot test above on your own setup.

Which model has better ComfyUI support right now?

In my March work, WAN 2.2 had more of the example graphs and community fixes I needed. LTX-2.3 was comfortable for simpler pipelines. Check the current nodes and templates for your particular task before treating that observation as permanent.

Can I use both models in the same pipeline?

I use them in the same production process, not as interchangeable model nodes. I prototype with LTX-2.3, keep the shot brief, then build a WAN 2.2 run around the same goal. I check scheduler, frame count, memory, audio, and output size again.

In the end, I reach for LTX-2.3 when quick iteration and draft audio matter, and WAN 2.2 when the motion and camera feel in my tests justify a longer wait. The fastest route to a render isn’t always the fastest route to a clip I’d send. That’s the comparison I wish I’d made first.

Previous posts: