Picture and sound from one diffusion pass: the resolution ladder, distilled versus development weights, prompt structure, and a working method that does not waste twenty minutes per idea.
Two of your three goals — short cinematic clips and animating stills — are the same pipeline with a different starting condition. This article covers both, and the working method matters at least as much as the settings, because on this hardware every iteration costs minutes.
If you installed the prebuilt GB10 bundle from the previous article, LTX-2.3 is already staged and you can skip to the next section. Otherwise, install Lightricks' own ComfyUI integration and fetch the weights.
cd $HOME/ComfyUI/custom_nodes
git clone https://github.com/Lightricks/ComfyUI-LTXVideo
$HOME/ComfyUI/venv/bin/pip install -r ComfyUI-LTXVideo/requirements.txt
# Weights into the library, not into ComfyUI's own tree
export HF_HOME=/mnt/models/hf
hf download Lightricks/LTX-2 \
--local-dir /mnt/models/comfy/diffusion_models/ltx2Two checkpoints are published and the choice between them shapes your whole workflow:
| Checkpoint | Character | Use for |
|---|---|---|
ltx-2.3-22b-dev | Full sampling schedule, highest ceiling, slowest | Final renders of clips you have already committed to |
ltx-2.3-22b-distilled | A short fixed schedule of predefined sigmas — far fewer steps | Everything else. This is the one you will actually use. |
Start with distilled. The quality gap is smaller than the time gap, and on a machine where an iteration is three minutes, the ability to try five ideas in the time one full-schedule render takes is worth more than a marginal improvement in detail.
--quantization fp8-cast together with --offload cpu or --offload disk in its own CLI, and the equivalent options exist as ComfyUI nodes. On this box you should rarely need them: 42 GB of transformer in a 120 GB pool is comfortable. Reach for offload only when combining LTX with something else large in the same graph.
The single most useful habit for video generation on this hardware is to never explore at final quality. Three rungs:
| Rung | Settings | Answers the question |
|---|---|---|
| Sketch | ~480p, 2 seconds, distilled, fixed seed | Is the composition right? Is the subject recognisable? Is the motion the kind I asked for? |
| Draft | 720p, 4–5 seconds, distilled | Does the motion hold up over time? Does the audio fit? Are there artefacts that will not survive scrutiny? |
| Final | Target resolution and duration, dev weights if warranted | Nothing. This is the render, and you should already know it will work. |
Keep the seed fixed while you are changing the prompt, and change the seed only when you are happy with the prompt and want variations. Doing both at once means you cannot attribute an improvement to either.
The most common mistake in video prompting is writing an image prompt. A still-image prompt describes a frozen moment; a video prompt has to describe change over time, and if you do not specify the change, the model invents one — usually a slow drift that looks like a screensaver.
A structure that works:
[subject and appearance], [what the subject does, as a verb over time],
[camera: what it does], [setting and light], [audio: what is heard],
[style and film grammar]Compare:
# Weak — an image prompt wearing a costume
"a fishing boat in a harbour at dawn, cinematic, 4k, beautiful"
# Better — motion, camera and sound are all specified
"a small wooden fishing boat rocks against its moorings as swell moves
through a stone harbour; the camera tracks slowly right at water level,
holding the boat in frame; cold blue dawn light, low mist over the water;
audio: rhythmic slap of water on the hull, distant gulls, a rope creaking;
handheld documentary feel, shallow depth of field"Because LTX-2 generates sound in the same pass, the audio clause is a real control, not a decoration. Describing what should be heard changes what is generated visually — a prompt that mentions footsteps on gravel tends to produce feet that meet the ground convincingly. It is the closest thing this model has to a physics hint.
Things worth being explicit about, because vagueness produces mush: whether the camera moves and how, whether the subject or the camera is the source of motion, the time of day and light direction, and the intended length of the action (a gesture that completes in two seconds versus one that continues past the end of the clip).
This is the cheapest good-looking video you can make on this box, because you have removed the hardest problem — inventing a coherent, well-composed frame — and left the model with only motion to solve.
The workflow substitutes an image-conditioning node for the empty latent. What matters:
Flux 2 Dev is bundled in the GB10 ComfyUI image and is the obvious partner for generating source stills — but note that holding a 35 GB image model and a 42 GB video model resident simultaneously is 77 GB before text encoders. Generate stills in one session, video in another, rather than building one graph that does both.
Two of LTX-2's nine pipelines solve the "my clip is too short" problem in different ways.
Keyframe interpolation takes a first and last frame and generates the transition. This is the highest-control option available: you decide exactly where the shot starts and ends, and the model fills the middle. For a deliberate move — a door opening, a face turning — it beats prompting for the same motion.
Extension continues from the final frames of an existing clip. Chaining these gets you past the single-generation duration limit, at the cost of gradual drift: colour, detail and identity wander a little with each extension. Two or three chained segments are usually fine; ten will not look like one continuous shot. For genuinely long talking-head footage, the right tool is the long-form pipeline in article 4, which is designed for exactly this and handles identity preservation properly.
Sound arrives with the video, muxed into the output file. Three practical notes.
First, if your workflow crashes during encoding, that is the known NaN/Inf-before-AAC bug — the fix is the patch from article 2, not a change to your graph.
Second, generated audio is atmospheric rather than precise. It is very good at ambience, texture and impact sounds; it is not a substitute for the speech pipeline in series 2. For anything where the words matter, generate speech separately and mux it in.
# Keep the generated ambience, add a cloned voice-over on top
ffmpeg -i clip.mp4 -i voice.wav -filter_complex \
"[0:a]volume=0.35[amb];[1:a]volume=1.0[vo];[amb][vo]amix=inputs=2:duration=first[a]" \
-map 0:v -map "[a]" -c:v copy -c:a aac out.mp4
# Or strip the generated audio entirely
ffmpeg -i clip.mp4 -i voice.wav -map 0:v -map 1:a -c:v copy -shortest out.mp4Third, when you evaluate a draft, listen to it. A clip that looks acceptable and sounds wrong reads as wrong overall, and the audio is frequently the earlier signal that a prompt is not landing.
Three minutes per clip is intolerable if you sit and watch it and perfectly reasonable if you queue eight and come back later. ComfyUI's HTTP API makes that a short script — the full API pattern is in the next article, but the essential loop is small:
#!/usr/bin/env python3
"""Queue one workflow across several prompts and seeds, then walk away."""
import json, itertools, urllib.request
COMFY = "http://127.0.0.1:8188"
GRAPH = json.load(open("workflows/ltx2_t2v_api.json")) # 'Save (API format)'
PROMPTS = [
"a tram crosses a wet cobbled square at night, headlights raking the "
"puddles; camera static at kerb level; audio: rails singing, rain on stone",
"steam rises from a cup on a windowsill as morning light moves across it; "
"slow push in; audio: distant traffic, a clock",
]
SEEDS = [1, 2, 3, 4]
for prompt, seed in itertools.product(PROMPTS, SEEDS):
g = json.loads(json.dumps(GRAPH)) # deep copy per job
g["6"]["inputs"]["text"] = prompt # node ids: check your own graph
g["3"]["inputs"]["seed"] = seed
req = urllib.request.Request(
f"{COMFY}/prompt",
data=json.dumps({"prompt": g}).encode(),
headers={"Content-Type": "application/json"})
print(json.load(urllib.request.urlopen(req))["prompt_id"], seed, prompt[:40])Export the workflow with Save (API format) rather than the normal save — the two JSON shapes are different and only the API format is accepted by /prompt. The node IDs are whatever your graph assigned; open the file and read them once.
Eight variations queued before dinner is a fundamentally different relationship with a three-minute generation time than eight variations watched in real time. This is the working method the hardware rewards.
Open video models in mid-2026 are genuinely capable and still have characteristic failure modes. Knowing them saves you from trying to prompt your way out of a structural limitation:
The clip that works is usually the one that asks the model for less: a clear subject, one motion, one camera behaviour, a few seconds. That is also, not coincidentally, what a good shot looks like.