ROCm Text Generate LTX2 Prompt

LTX-2 is a video model, but its prompt generation is secretly an LLM problem. Stock ComfyUI's TextGenerateLTX2Prompt runs a Gemma 3 12B text encoder through a long system prompt, generating one token at a time with a manual KV cache - and on an AMD GPU the attention path can fall back to a slow einsum implementation that makes every token crawl. This node is the ROCm Ninodes pack's drop-in replacement: same inputs, same output, same system prompts, but with device handling and memory cleanup tuned for AMD hardware.

What it does

It's a faithful copy of the stock node's pipeline - the docs are explicit that it formats the same LTX2 T2V/I2V system prompts and runs the same clip.tokenize → clip.generate → clip.decode flow. You get identical output for identical inputs, which is what you want from a "drop-in": no workflow rewiring, no prompt-style drift.

The inputs are the LTX2 prompt-gen standard set:

• clip - the CLIP/LLM model (for LTX-2 that's Gemma 3 12B).
• prompt - your raw input, which the node wraps in the LTX2 system template.
• max_length (default 256, up to 2048) - how many tokens to generate. This is the main dial; too low and the model cuts itself off mid-sentence, too high and you wait.

Optional but useful: image flips it into image-to-video mode (it injects the image soft token into the I2V system prompt), and the sampling controls - sampling_mode (on/off for stochastic vs. greedy), temperature (0.7), top_k (64), top_p (0.95), min_p (0.05), repetition_penalty (1.05), seed. For beginners: leave them alone until the prompt feels repetitive (bump repetition_penalty) or too random (lower temperature).

The single generated_text output wires straight into the LTX-2 prompt/conditioning side of your workflow.

The ROCm-specific bits are subtle. It pins the CLIP's execution device to your torch device so generation doesn't wander onto the CPU, and it runs a gentle memory cleanup before and after - a no-op when memory is fine, a small insurance policy when it isn't.

Why it's faster, and the one flag that matters

The performance difference is mostly the attention backend, not this node. The pack's docs are upfront: the real speed lever is running ComfyUI with

python main.py --use-pytorch-attention

That makes the text encoder use PyTorch SDPA instead of the basic attention implementation, which on ROCm is dramatically faster for this workload. The caveat: if you see wrong output or crashes with SDPA on your particular ROCm/PyTorch build (there have been reports with custom attention masks), drop the flag - the node still works, just slower.

Install and the honest framing

It comes with the whole pack - Manager → "ROCm Ninodes," or git clone https://github.com/iGavroche/rocm-ninodes.git into custom_nodes, restart, and look under ROCm Ninodes → Generative AI. Light dependencies, no model downloads (the Gemma 3 12B encoder is a ComfyUI model you already have for LTX-2).

Straight talk: if you're on an NVIDIA card, this node is a solve in search of a problem - the stock node is fine. If you're on AMD with ROCm, particularly a gfx1151/Strix Halo box, this is the version you want, mostly because it keeps the LLM on the GPU and gives you a single place for ROCm settings as the pack evolves. It won't magically make a 12B LLM fast on an APU - but it removes the avoidable slowness, which is all any drop-in node can promise.