Bernini-R Compile Model

Bernini-R edits are slow, and one of the few legit speed levers that doesn't touch quality is torch.compile - the JIT compiler that traces your model and fuses kernels, worth a real chunk of time per step on the 14B model. BerniniR_CompileModel is where this pack handles that, and it's smarter about it than most: it stores compile config on your model handle, understands Windows's limitations, and keeps its compile cache isolated from torch's global one so it can't nuke other projects' artifacts.

How it works

This node doesn't compile anything. It stamps a config onto your BERNINI_MODEL_HANDLE, and the actual compilation happens when the sampler loads the model. That's why the ordering is flexible - ModelLoader → CompileModel → LoadLoRA → sampler works, and so does putting LoRA before compile. The utils/wan_compile.py helper handles the platform stuff behind the scenes: on Windows, the aggressive reduce-overhead and max-autotune modes are automatically downgraded to default, because cudagraphs and autotune are unreliable there.

The inputs that matter

• model_handle - from BerniniR_ModelLoader. Required, obviously.
• compile_mode - none (eager, default), default, reduce-overhead, max-autotune, max-autotune-no-cudagraphs. Start with default. On Windows the two fancy modes silently downgrade to it anyway, which the README says outright.
• fullgraph - requires zero graph breaks in the trace. The tooltip warns it will likely fail with custom attention ops, which this pack injects. Leave it off unless you know you have a clean graph.
• dynamic_shapes - true by default, letting the compiled graph handle variable-length sequences. If you get weird recompile churn, that's this doing its job.

Optional:

• purge_cache - deletes Bernini-R's isolated compile cache before compiling. Flip it after a code update, or when compiled output looks stale.

What comes out

A model_handle with compile config attached - same type in, same type out. Wire it into the sampler just like you would straight from the loader.

The two gotchas that will actually bite you

1. Silent fallback on Windows. The pack sets torch._dynamo.config.suppress_errors = True, which means a failed compile hides the failure and falls back to eager mode. The output will be correct - it just won't be faster, and nothing will tell you. Check the console for Inductor cache warnings, or disable compile and test eager first so you have a baseline to compare against.

2. The cache is now isolated, on purpose. Earlier versions deleted torch's global inductor cache on every start, which wiped compile artifacts for every other project on the machine. Now it lives at %TEMP%/bernini_r_inductor_cache (override with BERNINI_COMPILE_CACHE_DIR), auto-cleared only when the code version changes. To force a purge: enable purge_cache on this node, or set BERNINI_PURGE_COMPILE_CACHE=1 before launching ComfyUI.

One honest recommendation

TeaCache and compile can be combined - the pack restores the eager transformer forward when a compiled model is also TeaCache-accelerated, so the block-skipping hooks actually take effect. But if you're on Windows and your clip is short, honestly, measure before you bother. The startup compile cost can eat the savings on a 20-step clip. Where compile really pays is the long, multi-window generation where the traced graph gets reused across hundreds of steps.