Local LTX 2.5 on AMD ROCm

Purpose

This article provides guidance and reference values for running LTX 2.5 image-to-video locally on a single AMD GPU with ROCm and ComfyUI. It covers three things:

1. What has to be configured to get the setup running at all (and what must not be set).

2. Measured run times for clip lengths from 5 to 60 seconds and resolutions from 256x384 to 1024x1536.

3. Where the limits of the setup are and which resource ends a run.

Key findings

• --enable-dynamic-vram reduced the model load from 22-25 minutes (swap full) to about 70 seconds including the first successful run.

• PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True must not be set together with dynamic VRAM.

• Long clips are limited by host RAM in the decode, not by the GPU.

• Without upscaling a 60 s clip takes 2.2 minutes at 256x384 and 9.6 minutes at 384x576. With a second, upscaling stage a 5 s clip in 1024x1536 takes 2.5 minutes and a 25 s clip 44 minutes.

Setup

• GPU: AMD Radeon R9700, 32 GB VRAM, ROCm

• CPU: AMD Ryzen 5 7600 (6 cores, 12 threads); the container uses 8 of the 12 logical CPUs

• RAM: 28 GB for the container, 8 GB swap

• System: Proxmox LXC container, ComfyUI v0.37.0

• Model: LTX 2.5 22B distilled, transformer as GGUF Q4_K_M (15.7 GB), Gemma text encoder int8, video output only (the audio branch is computed but never decoded)

What is possible

24 fps, warm runs unless noted. "Run time" is the whole run from queueing to the finished mp4.

Notes:

• Frames must be 8n+1: at 24 fps 5 s = 121, 10 s = 241, 30 s = 721, 60 s = 1441.

• Width and height must be divisible by 32. The second stage doubles both.

• The host RAM peak of short clips is dominated by model and cache leftovers and is not comparable between rows; it is meaningful from about 15 s.

• With the distilled model CFG is 1.0, so the negative prompt has no effect.

Limitations

• Host RAM, decode of long clips: the finished video is held as float images, about 19 MB per frame at 1024x1536. The RAM peak grows by about 0.4 to 0.5 GB per second of clip. At 25 s the peak was 23.5 GB, with 465 MB swapped out in a 28 GB container.

• Time, second stage at the target resolution: it takes 57 % of a 5 s run and 80 % of a 25 s run (1024x1536). Run time grows roughly with the square of the length at this size, and faster at 25 s.

• VRAM (allocator), second stage, 30 s at 1024x1536: with the default allocator the sampler asked for 4.31 GiB with 3 GiB free after 25 minutes, while 4.38 GiB were reserved but unallocated. That is a fragmentation failure rather than a plain lack of memory.

The GPU is the bottleneck during sampling. Other parts of a run are limited by RAM and CPU:

• Loading the models (loading the text encoder and encoding the first prompt takes about 40 s on a cold start; the GPU is idle).

• During decode the GPU is only partly busy.

• Writing the finished video (h264 encode on the CPU) and releasing the memory afterwards.

The 32-34 GB VRAM that a monitor shows during normal runs is not a limit: with dynamic VRAM it is an opportunistic cache, not demand.

Required configuration

Start ComfyUI with --enable-dynamic-vram. On ROCm it is not on by default. Without it ComfyUI loads the transformer partially (about 3 GB stay on the CPU) and the weights are moved back and forth while the process fills all RAM and the system swaps at about 100 MB/s in both directions: 22-25 minutes before the first sample. With the flag the log shows DynamicVRAM support detected and enabled and the transformer is loaded completely in about 12 seconds.

My full service line (systemd drop-in) is:

python main.py --listen --port 8002 --disable-fast-disk --enable-dynamic-vram --reserve-vram 4 --cache-classic

Only --enable-dynamic-vram was shown to matter. Lowering --reserve-vram, --fast-disk, a different swappiness, dropping the page cache and disabling other custom nodes did not help against the long load time. I did not isolate the other flags in the line above.

Do not set PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True. It is a common tip against VRAM fragmentation. Together with dynamic VRAM it raised the host RAM peak of a 5 s clip from 15 GB to 24 GB, and 25 s and 30 s clips in 1024x1536 were killed in a 28 GB container (RAM peak 35-36 GB, up to 21 GB swapped out). In my first setup it also came with black or noisy output, NaN warnings invalid value encountered in cast), Not enough GPU memory and hipErrorIllegalAddress crashes.

Decode settings (VAEDecodeTiled): tile size 640, overlap 64, time tile 128, time overlap 32.

• A time overlap of 8 (the default) leaves a faint glitch every 120 frames (every 5 s at 24 fps). A time overlap of 32 or 64 removes it; 32 costs about 30 % more decode time, 64 about twice.

• Small tiles (128-192) with one time block gave a softer picture and a decode three times slower for 12 s clips.

• Tile 1024 needs 22-26 GB host RAM and can swap. Overlap 128 doubles the time without gain.

• A single time tile over the whole clip has no seams but needed 28 GB RAM at 30 s / 384x576.

Workflow

A minimal ComfyUI workflow for testing is attached.

Credits

Many thanks to sy0ww4bb1984 and the article LTX 2.3 and 2.5 simple. The simplified workflow attached here is based on it, and it gave me the first direction for running LTX 2.5 locally.