LTX2 Text Encode (Optimized) 💾

LTX-2's text encoder is the elephant in every low-VRAM room. It's a Gemma 3 12B model followed by a gigantic text_embedding_projection layer, and that projection is where text encoding pegs your memory - the KB's LTX-2 notes document the whole saga of OOMs and workarounds around Gemma. This node is a drop-in CLIPTextEncode replacement that processes the projection in chunks instead of one giant tensor, roughly a ~1GB peak-VRAM saving on the encode step. It's the LTX2TextEncodeOptimized node from kakachiex2/comfyui-ltx2-efficient, and it's a genuinely practical fix for the "text encoder eats everything" complaint.

How it works

It takes the same two inputs as a normal text encode - a clip and your text - and returns a CONDITIONING. Internally it tokenizes, runs the Gemma encoder, then does the heavy projection in slices of chunk_size positions with aggressive torch.cuda.empty_cache() calls between chunks. Two details make it more careful than a naive chunked rewrite:

• fp32 normalization. The Gemma output is normalized in float32 before the projection to avoid the NaN/Inf that bf16 math can produce. That's not paranoia: the author's own bug report in the repo (Reference/Bug.txt) is a SaveVideo crash with [aac] Input contains (near) NaN/+-Inf - exactly the failure mode this sanitization exists to prevent.
• Dual connectors. LTX-2 splits the projected embeddings into a video connector and an audio connector and concatenates the results. The node walks both, and it sanity-checks the final output for NaN/Inf too.

One naming gotcha worth knowing: the force_cpu toggle says it processes the projection on CPU "for low VRAM." The current code actually runs the chunked projection on the GPU with memory management - the comment in the source even says so ("Process projection on GPU (preserves precision!)"). Either way the default behavior is the safe, chunked path, so don't overthink the label.

The inputs

• clip - your loaded LTX-2 text encoder (DualCLIPLoader with the Gemma weights).
• text - multiline prompt, same as any text encode.
• chunk_size - default 64. Smaller = less VRAM, slower; 64 is a good balance per the author's own tooltip.
• force_cpu - default true; controls whether the projection is chunked (and where).

Output is a single CONDITIONING that feeds straight into positive/negative on a sampler.

Installation

Part of the kakachiex2/comfyui-ltx2-efficient pack. ComfyUI Manager (search "LTX2 Efficient") or:

cd ComfyUI/custom_nodes/
git clone https://github.com/kakachiex2/comfyui-ltx2-efficient
cd comfyui-ltx2-efficient
pip install -r requirements.txt

Restart, and swap it in place of your regular CLIPTextEncode. No model files come with it - the Gemma text encoder is something you already load for LTX-2.

Troubleshooting

• No speed difference / behaves identically - for a non-LTX-2 text encoder (i.e. the model isn't an LTXAVTEModel with text_embedding_projection), the node detects that and falls back to a standard encode. That's by design, not a bug.
• Still OOM on encode - drop chunk_size to 32 or 16. If that's not enough, the real lever is a quantized Gemma (fp8 or 4-bit) from your checkpoint setup, which attacks the problem at the source.
• Audio encodes crackle or SaveVideo throws a NaN error - that's the failure the node's sanitization is designed to catch, so make sure you're actually routing your positive/negative through this node rather than a plain encoder.

This is the sleeper node of the pack, honestly. The sampler gets the attention, but on a 6-8GB card the text encode is often the first thing to blow up, and this is the node that quietly prevents it.