LTXV Chunk FeedForward

If LTX video generation is dying with an out-of-memory error right at the peak, LTXV Chunk FeedForward is one of the cheapest fixes to try before you start dropping resolution or frames. It trims the highest VRAM spike inside the transformer by processing one heavy layer in pieces instead of all at once.

The node wears a warning on its sleeve - "EXPERIMENTAL AND MAY CHANGE THE MODEL OUTPUT" - so treat it as a memory lever you A/B-test, not a free lunch. It's the LTX sibling of the same idea kijai uses on the Wan side (his Wan Chunk FeedForward node, which one user measured saving "almost 4GB" of peak VRAM on a heavy 1080p workload). Same trick, aimed at LTX-2 / LTXV.

How it works

Inside a transformer block there's a feed-forward layer that briefly blows the channel dimension up to something large, and that momentary intermediate tensor is often the single biggest thing in VRAM at any instant. Chunking splits that computation into N slices done one after another, so the peak allocation drops to a fraction of the whole - you trade a bit of speed for a lower ceiling. The node patches your model and hands back a MODEL you sample with normally.

The inputs and outputs that matter

• model (MODEL) in, model (MODEL) out - insert it in the model line before your sampler.
• chunks (default 2, range 1–100) - how many slices to break the feed-forward into. This is the knob. More chunks = lower peak VRAM, slightly slower. If 2 didn't get you under the OOM line, try 3 or 4; there's diminishing return past a handful.
• dim_threshold (default 4096) - only chunk layers whose width is above this. It's there so tiny layers don't get chunked pointlessly. The default is sensible; leave it unless you know exactly why you're moving it.

How to install it

ComfyUI Manager → search KJNodes for ComfyUI → install → restart. Manual route:

cd ComfyUI/custom_nodes
git clone https://github.com/kijai/ComfyUI-KJNodes
pip install -r ComfyUI-KJNodes/requirements.txt

then restart. No extra model files; dependencies stay minimal.

Common issues & troubleshooting

Output shifted after adding it. Believe the warning label. Chunking changes the arithmetic order slightly, which can nudge the result. Generate the same seed with and without the node and eyeball the difference - if it's negligible (it usually is), keep it; if it's not, you have your answer.

Still OOMing. Chunking only attacks the feed-forward spike. If your bottleneck is the VAE decode or the text encoder (LTX-2's Gemma encoder is a notorious memory hog), this won't save you - pair it with fp8/GGUF weights, a quantized text encoder, or --reserve-vram. Diagnose which spike is killing you before assuming this is the fix.

It got slower and you didn't need the memory. If you're not actually VRAM-constrained, don't run this - you're paying the speed cost for nothing. It's a fix for the OOM case, not a default you leave in every workflow.