Fixing "CUDA Out of Memory" in ComfyUI When Running LTX 2.3 (Even on FP8)

If ComfyUI just threw torch.OutOfMemoryError: CUDA out of memory. Tried to allocate X.XX GiB (or the shorter RuntimeError: CUDA error: out of memory) while loading or sampling an LTX 2.3 workflow, you're not imagining it: this is one of the most common failure modes people hit with LTX 2.3, and it happens even on the FP8-quantized checkpoints, not just the full-precision ones.

Here's the exact error people usually see, in one of these forms:

torch.cuda.OutOfMemoryError: CUDA out of memory. Tried to allocate 2.34 GiB (GPU 0; 15.99 GiB total capacity; ...)

or during the VAE step specifically:

OutOfMemoryError: Allocation on device

Both mean the same thing: something in the pipeline asked for more contiguous VRAM than your GPU has free at that instant. Below is how to diagnose which part of the pipeline is doing it, and how to actually fix it rather than just restarting ComfyUI and hoping.

Why this happens on LTX 2.3 specifically

LTX 2.3 isn't one model competing for VRAM — it's three, loaded at the same time:

1. The transformer (the actual video diffusion model, ~22B parameters)
2. The text encoder (Gemma 3 12B, used to encode your prompt)
3. The VAE (encodes/decodes between pixel space and latent space)

Each of these has its own quantization tier, and it's easy to mix a heavy variant of one with a light variant of another and still blow your VRAM budget. The classic mistake: someone downloads an FP8 transformer to fit their 16GB card, but keeps the full BF16 comfy_gemma_3_12B_it.safetensors text encoder or the full-size LTX23_video_vae_bf16.safetensors (~1GB, but it also holds a much larger activation footprint during decode than the distilled TAE), and the combined peak still exceeds 16GB. The transformer being quantized doesn't save you if the other two components aren't.

On top of that, VRAM usage during sampling isn't flat — it scales with resolution × frame count × batch size, and the VAE decode step at the end is often the actual peak, not the sampling loop itself. So a workflow that loads fine and samples fine can still OOM at the very last node.

VRAM tiers: match your card to the right checkpoint combo

Before touching any launch flags, make sure you're actually running the right file combination for your hardware. See the full breakdown on the VRAM requirements guide, but the short version:

• ~32GB VRAM (RTX 5090, A6000, etc.): full-precision checkpoints — ltx-2.3-22b-dev.safetensors or ltx-2.3-22b-distilled.safetensors. No quantization needed anywhere in the pipeline.
• ~16GB VRAM (RTX 4080/4070 Ti, 5070 Ti): use a transformer-only quantized checkpoint — either the FP8-scaled variants (ltx-2.3-22b-distilled-1.1_transformer_only_fp8_scaled.safetensors, ltx-2.3-22b-dev_transformer_only_fp8_scaled.safetensors) or the newer int8_convrot variants (ltx-2.3-22b-distilled-1.1_transformer_only_int8_convrot.safetensors, ltx-2.3-22b-dev_transformer_only_int8_convrot.safetensors). Both target roughly the same ~16GB footprint via different quantization math — if one OOMs on your card, it's worth trying the other, since kernel efficiency can differ slightly.
• Below 16GB: you also need to quantize the text encoder. Swap the full Gemma checkpoint for gemma_3_12B_it_fp8_scaled.safetensors, or go further with gemma_3_12B_it_fp4_mixed.safetensors if you're this tight.
• VAE, always: use taeltx2_3.safetensors (the distilled TAE) in ComfyUI/models/vae/ unless you have VRAM to spare. Loading the full LTX23_video_vae_bf16.safetensors when you didn't mean to is a surprisingly common cause of "it worked on FP8 last week, now it OOMs" reports — someone changes a workflow's VAE loader node and doesn't notice.

Browse exact filenames and sizes on the models page before you download anything — it's easy to grab the wrong precision tier by accident since the filenames are long and similar.

ComfyUI launch flags that actually help

ComfyUI ships VRAM-mode flags that change how aggressively it keeps model weights resident on the GPU versus streaming them from system RAM. They're mutually exclusive with each other (pick one):

• --lowvram — splits the UNet/transformer into parts and only loads each part into VRAM as it's needed for that step, instead of keeping the whole model resident. This is the first thing to try if you're borderline OOMing on a 16GB card:

  python main.py --lowvram
  

• --novram — a more aggressive version of the above, minimizing GPU-resident weights as much as possible. Slower, but it's the move if --lowvram still isn't enough:

  python main.py --novram
  

• --reserve-vram N — keeps N GB of VRAM permanently free, which helps because ComfyUI's default memory management can otherwise let allocations creep right up to the edge before failing. Useful when something else (a browser, a second app, your desktop compositor) is also holding a bit of VRAM:

  python main.py --reserve-vram 1.5
  

On Windows portable builds, add these flags to your run_nvidia_gpu.bat (or whichever .bat you use to launch) rather than typing them each time. You can combine --reserve-vram with --lowvram in the same launch command. Run python main.py --help to see the full current flag list for your ComfyUI version, since new memory-management options (like async offload controls) get added periodically.

Reduce resolution, frame count, and batch size

If you're already on the right checkpoint tier and flags and still OOMing, the workflow itself is asking for too much:

• Resolution: VRAM scales roughly with the square of resolution. Dropping from 1024 to 768, or 768 to 512, on the long edge often clears an OOM immediately — test at a lower resolution first, then step back up.
• Frame count: LTX 2.3 workflows commonly default to long clips (multiple seconds of frames). Cut the frame count for a test run, confirm the pipeline completes, then increase gradually.
• Batch size: make sure it's set to 1. Batch sizes above 1 multiply your peak VRAM roughly linearly and are rarely necessary for a single generation.
• VAE decode specifically: if the OOM happens at the very last step (VAE decode) rather than during sampling, that's a strong sign the decode itself is the bottleneck — this is exactly what tiled decoding exists for. If your workflow has a standard VAE Decode node, check whether a tiled VAE decode node is available for your setup and use it; it processes the frame in smaller spatial chunks instead of one large allocation.

Still OOM? Check these before assuming it's unfixable

• Something else is holding VRAM. Browsers (especially with hardware-accelerated video/WebGL tabs open), other GPU-accelerated apps, or a second ComfyUI instance can eat a gigabyte or two you didn't account for. Close everything else and check nvidia-smi for used memory before launching.
• You're accidentally loading both a full and an FP8/quantized checkpoint at once. This happens when a workflow has two checkpoint loader nodes (e.g., one left over from an earlier version of the workflow) and only one is bypassed rather than deleted. Check every Load Checkpoint / Load Diffusion Model node in the workflow graph, not just the one you meant to use.
• Offload / smart-memory settings are fighting your flags. ComfyUI's default "smart memory" management sometimes disagrees with manual flags like --reserve-vram in edge cases — if you're stacking multiple memory flags and still seeing inconsistent behavior, try --disable-smart-memory alongside --lowvram to force fully manual behavior.
• VRAM fragmentation from a previous run. If ComfyUI has been running for a long session with multiple different workflows loaded, restart the process before troubleshooting further — cached allocations from a prior model don't always get released cleanly.

If none of that gets you there, your hardware genuinely isn't in range for local LTX 2.3 generation at the settings you want, and that's fine — running it online skips the VRAM math entirely and lets you generate at full quality without touching a checkpoint file.

Sources

• Startup Flags — ComfyUI Docs
• Configuration and Command-Line Arguments — comfyanonymous/ComfyUI (DeepWiki)
• ComfyUI seems to ignore the --reserve-vram and/or --disable-smart-memory? · Issue #6314 · Comfy-Org/ComfyUI
• Fix LTX-2 Errors in ComfyUI: OOM, Black Frames & Flicker Solutions — WaveSpeed Blog
• Fixing OOM Errors in ComfyUI with LTX-2.3 and NVIDIA GPUs — ANTLATT.COM
• Quick Start Guide For LTX-2 In ComfyUI — NVIDIA GeForce