LTX 2.3 in ComfyUI Generating Black, Gray, or Garbled Video? Here's How to Fix It
Your ComfyUI queue finishes with no red errors, but the output is black, static gray, or noisy garbage. Here's the ordered checklist to find the actual cause.
You hit Queue Prompt, the workflow runs to completion with no red node, no crash, no stack trace — and the video you get back is either solid black, flat gray static, or a screen full of color noise that never resolves into a picture. This is one of the most common LTX 2.3 complaints in ComfyUI, and it's frustrating precisely because ComfyUI doesn't throw an exception for it. The sampler ran, the VAE decode ran, a file got written to disk — the pipeline just produced garbage instead of a video.
Before you start changing settings at random, it helps to separate the three symptoms, because they usually point to different failures:
- Solid black output (every frame is pure black, file size is small) is almost always a decode-path or NaN problem — something in the numeric pipeline collapsed to zero or NaN before or during VAE decode.
- Flat gray or static/noise that never clears (frames all look like TV static, or a uniform gray with no structure) usually means the DiT never received usable conditioning — the text encoder chain broke silently, so the model is denoising against garbage or empty embeddings.
- Garbled color noise / no recognizable content (colorful but incoherent, like a shattered image) is the classic signature of a VAE mismatch — the latents were built for one autoencoder and decoded with another, so the decode math is simply wrong.
These aren't hard rules — precision/dtype issues in particular can produce any of the three — but they're a good starting hypothesis. This is also a known, reported issue: see Lightricks/ComfyUI-LTXVideo #465, where a user got "completely garbled output, pure noise, no recognizable content regardless of prompt" on the 22B transformer, and #134, reporting default settings producing black screen video every time. Neither issue thread contains a definitive root-cause fix from maintainers, which is exactly why a systematic check of your own setup — rather than waiting on an upstream patch — is the fastest way through this.
Check these in order
1. VAE mismatch
LTX 2.3 ships with two different VAE files that are not interchangeable: taeltx2_3.safetensors, a distilled Tiny AutoEncoder meant for fast/low-VRAM decode, and LTX23_video_vae_bf16.safetensors, the full BF16 video VAE. Both live in ComfyUI/models/vae/, and it's easy to load the wrong one into a workflow that was built around the other — the VAE Loader node will happily load either file without complaint, then decode your latents incorrectly. Confirm which VAE the checkpoint or workflow you downloaded actually expects (check the workflow's notes or the model card it came with) before assuming it's a settings problem elsewhere. See the LTX 2.3 video VAE page for the exact filenames and where each one is supposed to be used.
2. Text encoder chain
LTX 2.3's conditioning path is Gemma 3 12B (e.g. gemma_3_12B_it_fp8_scaled.safetensors) feeding into a small projection file, ltx-2.3_text_projection_bf16.safetensors, which both need to sit together in ComfyUI/models/text_encoders/. If the projection file is missing, or you've paired it with a Gemma variant it wasn't calibrated for (fp4 vs fp8 vs bf16), the conditioning that reaches the DiT is broken — and because the shapes still line up, ComfyUI won't error, it'll just feed the transformer noise. This matches what's described in issue #465 above: switching the Gemma variant fixed a shape-mismatch crash but the output stayed garbage, which is consistent with the projection layer still being mismatched even after the crash was gone. Double-check both files are present and correctly paired before touching anything else.
3. Dtype/precision mismatches
Don't force a node's precision away from what the checkpoint expects. If you loaded an fp8 or bf16 LTX 2.3 checkpoint, don't override the VAE or text encoder node to fp16 "to save memory" — mismatched precision across the pipeline is a well-documented cause of black-frame and NaN output in ComfyUI diffusion workflows generally, not just LTX-specific ones. If you need to reduce memory, do it by lowering resolution or batch size first, and only touch precision if the loader node explicitly supports the checkpoint's native dtype.
4. Scheduler/sampler sanity check
Confirm the scheduler and sampler match what the workflow was designed for — an incompatible sigma schedule or sampler for a video-specific model can produce static-like output even with a technically correct pipeline. If you copied nodes between workflows, re-verify steps, CFG, and denoise strength weren't left at defaults meant for a different model.
5. GPU-specific fp16 NaN issues
Certain GPU/driver combinations are known to produce NaNs when running fp16 math on diffusion models, which surfaces as black frames. If you're on such hardware, look for a bf16 or fp32-upcast option on the relevant loader/sampler nodes rather than fp16 — it's slower but numerically stable.
Still broken?
Open the ComfyUI console (the terminal window, not just the browser UI) and scroll through the full run. NaN and dtype warnings are frequently printed there without ever surfacing as a UI error — that's the "silent" part of a silent NaN failure. If you see any warning mentioning NaN, dtype casts, or unexpected shapes anywhere in the log, that's your actual root cause, even if the workflow appeared to finish cleanly. For a from-scratch setup check, walk back through the setup guide and confirm every model file landed in the folder ComfyUI expects. And if you'd rather skip local debugging entirely for a given generation, generating online runs the same LTX 2.3 pipeline on a managed, pre-verified stack — useful when you just need the output now and can debug your local install later.