CogVideo TorchCompileSettings

This node doesn't generate anything. It's a settings bundle. You configure how torch.compile should compile the CogVideoX transformer, and hand the result to the model loader's compile_args input. When it's connected, the wrapper tries to compile the selected layers into faster kernels, and every render after the first one runs quicker. The node says it plainly in its own description: torch.compile of the selected layers is attempted, it requires Triton, and torch 2.5.0 is recommended.

That Triton requirement is the entire story with this node, so let's be honest about it up front. On Linux, Triton usually just works. On Windows it's the thing that eats your afternoon - the same wall people hit with SageAttention, where community-built Triton wheels are the only way in and one person basically maintains the Windows builds. If you can't get Triton installed, TorchCompile simply isn't your speedup. Unplug the node and the workflow still runs, just at normal speed. Reach for fp8 and offloading at the loader instead.

How it works

torch.compile traces the model's computation graph and fuses operations into optimized GPU kernels. The catch is timing: the first run gets slower, sometimes a lot, because that's when compilation happens. Every subsequent run with the same shape reuses the cached kernels and comes out ahead. For video, where you're grinding many denoising steps across many frames, the per-step saving compounds nicely - but only if you actually do more than one render. Compile once, throw it away, and you paid the tax with no refund.

The inputs that matter

Five inputs, and most people touch two of them:

• mode - default is the safe pick and what you should start on. max-autotune searches harder for fast kernels and can squeeze out more, at the cost of a much longer first-run compile; max-autotune-no-cudagraphs and reduce-overhead are variations for specific situations. Only go past default if you're running long batches where a slow warm-up amortizes.
• backend - inductor (the default) is the one you want. cudagraphs is situational and most people leave it alone.
• dynamo_cache_size_limit (default 64) - how many compiled variants Dynamo is allowed to keep before it starts evicting. The default covers most people. If your resolution or frame count changes a lot between runs and you see repeated recompiles, raising this can help.
• fullgraph (default off) and dynamic (default off) - leave both off unless you know why you're flipping them. fullgraph demands the whole model compile as one graph and tends to be brittle; dynamic compiles for varying shapes and usually costs more than it saves.

The single output is torch_compile_args (type COMPILEARGS), which goes into the compile_args input on the CogVideoX model loader. Note the node's category is listed as MochiWrapper - it's a shared settings node the wrapper reuses across model families, not a typo. It works the same wherever it's wired.

Common issues & troubleshooting

"Triton not found" or a compile error on the first run. The big one. TorchCompile needs Triton and a recent enough PyTorch (2.5.0 per the node). No Triton, no compile. On Windows you'll likely need a community Triton wheel; if that's a dead end, disconnect this node and use other speedups.

The first generation is slower, not faster. Expected - that's the compile pass. The payoff shows up on the second and later runs at the same shape.

It keeps recompiling and never gets faster. If you change width, height, or frame count every run, Dynamo recompiles each time and you never bank the win. Keep your output shape stable across a batch, or raise dynamo_cache_size_limit. Toggling dynamic on can sometimes help, but measure it - it often makes things worse.