Compile Model+

torch.compile is one of the few speed tricks that pays off on modern transformers without touching the weights - JIT-compiling the model's forward pass into fused, optimized kernels. On big video models and Flux it's often the difference between "watchable" and "wait, it's done?" The catch has always been that ComfyUI's stock TorchCompileModel node falls over when LoRAs are in the graph. That's the problem "Compile Model+" (class EnhancedCompileModel) exists to solve - it's the WaveSpeed take on torch.compile that works with your LoRA stack intact.

The pack's README calls it out directly: "One of the advantages of this node over the original TorchCompileModel node is that it works with LoRA."

How it works

The node wraps whatever model you feed it, then patches the target object (the diffusion_model, by default) with a compiled version: the forward pass is traced and lowered through the backend you pick, and the optimized kernels are cached on disk so the second run is fast. The first run is the expensive one - expect a long, scary-looking wait while it compiles. That's normal; it's one-time.

Under the hood it does two quiet fixes that make LoRAs behave. It patches torch._dynamo's OptimizedModule so attribute access, state dicts and LoRA weight unloading see through the compiled wrapper to the original module, and it patches same_meta in inductor's post-grad pass so shape-mismatch edge cases don't crash the compile. That's the difference between "works with LoRA" and "crashes the moment you swap a checkpoint."

Inputs that matter

• model - feed it the output of your loader (or of Apply First Block Cache; they chain fine). The output is the same type, so it drops right back into your sampler.
• mode - the compile mode. Leave empty for the default, or use max-autotune / max-autotune-no-cudagraphs for maximum speed at the cost of a longer first compile.
• dynamic - enable this if you keep changing resolution or prompt length and see repeated recompiles. Costs a little peak performance, saves a lot of wall-clock pain.
• backend - inductor by default; you can point it at another compiler.
• fullgraph - force a single full graph compile; stricter, occasionally faster, more likely to fail on unsupported ops.
• disable - a bypass switch so you can leave the node in the graph while debugging.

You'll almost never touch is_patcher or object_to_patch - those exist for advanced patch-the-patch scenarios.

Install

Same pack as everything else here - ComfyUI Manager, search "WaveSpeed", or:

cd ComfyUI/custom_nodes
git clone https://github.com/chengzeyi/Comfy-WaveSpeed.git

Then restart. No model files.

Where people get burned

This is the node people love to hate, and it's worth knowing why before you blame the pack.

• Windows. torch.compile isn't officially supported there. The community fix is Triton wheels from woct0rdho's triton-windows repo, and it's a genuinely painful install - one release-thread commenter called it "a btch," then posted a step-by-step including editing a build.py typo. If you're on Windows and this fights you, the honest move is the README's: delete the compile node, keep Apply First Block Cache. You still get a big chunk of the speedup.
• Run with --gpu-only. Compilation fights model offloading. The README recommends launching ComfyUI with comfy launch -- --gpu-only (or the equivalent flag in your launcher).
• FP8 models won't compile on pre-Ada GPUs. If you're on a 3090/3060 and compiling an fp8 model, it fails; use FP16/BF16 weights or drop the compile node. (The 30-series has no fp8 hardware acceleration to begin with - see the quantization notes in the KB's concepts doc.)
• Recompiling on every resolution change. Enable dynamic, or debug with TORCH_LOGS=recompiles_verbose in your launch environment to see why it recompiles.

When the stars align - Linux, modern NVIDIA card, fp16 - this node is a genuine, repeatable speedup and one of the few compile wrappers that doesn't make you choose between LoRAs and speed.