Nodes/KJNodes for ComfyUI/Patch Model Patcher Order
ComfyUI Node Runs on cloud

Patch Model Patcher Order

A deprecated LoRA + torch.compile fix

By kijai·Created 3 years ago·Updated a day ago· 2,908
Patch Model Patcher Order
  • model
  • MODEL
patch_orderweight_patch_first
full_loadauto

Short version: don't use this node. It's deprecated, it's non-functional, and its own description tells you so - "NO LONGER NECESSARY OR FUNCTIONAL, keeping node for backwards compatibility. Use the TorchCompileModelAdvanced to use LoRA with torch.compile." A 0% click-through rate on 307 impressions is the community voting with its mouse, correctly. This page exists so that when you find this node in an old workflow, you know exactly what to do (delete it) and why.

What it used to solve

There was a real problem here once. ComfyUI applies model patches in a certain order - weight patches (like LoRAs) and object patches (like a torch.compile wrapper) both modify the model, and the order they're applied in matters. If torch.compile wrapped the model before the LoRA weights were patched in, you'd get a compiled graph that didn't include your LoRA, or a recompile storm, or an outright failure. PatchModelPatcherOrder let you force the sequence - apply weight patches first, or object patches first - so LoRAs and torch.compile could coexist.

You can still see the old controls on the node: patch_order (object_patch_first or weight_patch_first) and full_load (enabled/disabled/auto). Those were the levers. They don't do anything meaningful anymore, because ComfyUI's model patcher and the compile tooling moved on and handle the ordering themselves.

What to use instead

The description hands you the answer: TorchCompileModelAdvanced. If your actual goal is running a LoRA together with torch.compile - which is a legitimately useful combo, since compile gives per-step speedups and LoRAs give you control - that's the current node for it. It's built to handle the patch ordering internally, so you don't have to reason about it. torch.compile itself has a startup cost (it JITs the model on first run) but pays it back in faster steps, and it shows up all over Wan and Flux acceleration stacks for exactly that reason.

Installing it

It comes with kijai's KJNodes pack, but there is no reason to install anything for this node. If you already have KJNodes, it sits unused in the KJNodes/deprecated bucket.

  • ComfyUI Manager - search KJNodes for ComfyUI, install, restart.
  • Manual - cd ComfyUI/custom_nodes && git clone https://github.com/kijai/ComfyUI-KJNodes, then pip install -r requirements.txt, and restart.

Common issues

The only issue with this node in 2026 is finding it in a workflow and not realizing it's dead weight. If you loaded an old graph and it's got a Patch Model Patcher Order node in the model chain, it's not helping and it's not hurting - it's just inert. Pull it out. If you were relying on it to make LoRA-plus-compile work, that reliance is the actual bug; wire in TorchCompileModelAdvanced instead and your LoRA and compile will get along.

This is the normal lifecycle of a fast-moving ecosystem node: kijai wrote it to paper over a rough edge in ComfyUI, ComfyUI later fixed the rough edge properly, and the node stays around only so old workflows don't error on load. That's the whole reason it's kept - backwards compatibility, nothing more.

CategoryKJNodes/deprecated

Inputs (3)

NameTypeDefaultDescription
modelMODEL
patch_orderCOMBOweight_patch_firstPatch the comfy patch_model function to load weight patches (LoRAs) before compiling the model
full_loadCOMBOautoDisabling may help with memory issues when loading large models, when changing this you should probably force model reload to avoid issues!

Outputs (1)

NameTypeDescription
MODELMODEL