TorchCompileLTXModel

If you found this node in a workflow you downloaded, don't build anything new around it - the node itself tells you why. Its description reads, in full: "This node has been replaced with TorchCompileModelAdvanced node, please use that instead." Kijai left it in the pack so old workflow JSON still loads without erroring, not because it's the way to do this anymore.

What it did is worth understanding anyway, because the underlying idea is still exactly what you want when you're running LTX Video. torch.compile is PyTorch's just-in-time compiler: instead of running your model's forward pass through the normal Python/eager-mode path every single step, it traces the computation once and produces a faster compiled version. The catch is the trace itself costs time - the first run after compiling is slower, sometimes a lot slower, than normal. Everything after that first shape-matched run is faster. For a video model like LTX, where the same forward pass repeats dozens of times per clip across many sampling steps, that upfront cost amortizes fast. The community's shorthand for this trade, seen across this pack's other TorchCompile nodes, is blunt and accurate: "startup overhead but per-frame speed improvement."

How it worked (and what replaced it)

This node was about as bare as a node gets: one input, one output, both typed * - meaning ComfyUI doesn't restrict what you can plug in, it just wraps whatever model object arrives with a torch.compile call and hands the compiled version back out. No backend choice, no mode, no way to tune anything. That's exactly why it got replaced. TorchCompileModelAdvanced is the node KJNodes wants you searching for now - it exposes real dials (which compile backend, which optimization mode, whether to require a single unbroken graph) instead of this fire-and-forget wrapper. If you want a preview of the kind of controls the newer node family offers, look at this pack's TorchCompileVAE - same family of options, different target.

Inputs and outputs

• model (*, required) - whatever LTX model object your loader produces.
• Output: * - the same object, compiled.

That's the entire schema. There's nothing else to configure, which is the whole problem with it.

How to install it

You get this node automatically with the pack - there's no separate install for it specifically.

Via ComfyUI Manager: search KJNodes for ComfyUI, install, restart.

Manually:

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

(Portable installs: run that same pip command via python_embeded\python.exe -m pip install -r ....) Then restart. The pack keeps dependencies deliberately minimal - no extra model downloads for this node, since it's compiling a model you've already loaded, not fetching one.

Common issues & troubleshooting

You can't find it in the node search. Good - that's the point. Newer ComfyUI Manager registries can hide deprecated nodes from search entirely depending on version, even though the class still loads fine if it's already sitting in a workflow file. Search for TorchCompileModelAdvanced instead.

The first generation after adding it is much slower, not faster. This isn't a bug, in this node or its replacement - it's what compiling means. The trace happens once per shape; only subsequent runs at the same resolution and batch size get the speedup. If you change resolution every run, you're paying the compile tax every single time and may not be gaining anything.

It errors out or does nothing on Windows. torch.compile's default backend needs Triton, and Triton on Windows has historically been rough enough that one community member ended up maintaining unofficial Windows builds almost single-handedly. If you're on Windows and this silently fails, that's the usual suspect - and it's exactly the kind of problem TorchCompileModelAdvanced's backend choice (Triton-based inductor vs. the simpler cudagraphs) exists to let you route around, which the deprecated node here never gave you a way to do.