Nodes/RocM Ninodes/ROCMLoRALoader
ComfyUI Node

ROCMLoRALoader

A LoRA loader that cleans up after itself

By iGavroche·Created 11 months ago·Updated 4 days ago· 43
ROCMLoRALoader
  • model
  • clip
  • MODEL
  • CLIP
lora_name
strength_model1.00
strength_clip1.00

A LoRA is a tiny adapter file that patches a model's behavior - style, character, concept - and in ComfyUI you apply it with a loader that fuses it into your MODEL and CLIP. This is the ROCm Ninodes pack's version of that loader, and its entire personality is summed up in its class docstring: "aggressive memory management to prevent fragmentation." On an AMD card with limited VRAM, the moment you stack a couple of LoRAs on a big model is exactly when memory pressure spikes, and this node treats that as the enemy.

The inputs

Standard LoRA-loader surface, which is good - there's no learning curve if you've used the stock node:

  • model - the MODEL to patch.
  • lora_name - dropdown from your loras folder.
  • strength_model (default 1.0, −10 to 10) - how hard the LoRA bites into the model. This is the one you'll actually tweak; on newer architectures people often run 1.0+ rather than the old SDXL 0.5–0.8 habit.
  • strength_clip (default 1.0) - the same strength applied to the text encoder.
  • clip (optional) - pass your CLIP in and the output CLIP comes back LoRA-patched too.

Outputs are MODEL and CLIP, wired straight back into your sampler and text encoders. Leave clip unconnected and the CLIP output passes through clean.

The mechanism

Under the hood it's ComfyUI's native LoRA application - comfy.sd.load_lora_for_models, the exact same call the stock LoadLoRA node makes. What's different is all the memory hygiene around it: it reports allocated vs. reserved memory and fragmentation before and after, runs a gentle cleanup before and after the load, and if the load throws, it does an emergency cleanup before re-raising so you're not left with a half-loaded state. It's verbose - the console gets a play-by-play of your VRAM - but that verbosity is the point: you can see the memory cost of applying a LoRA, which on a tight AMD card is the difference between understanding an OOM and being confused by one.

Install

Ships in the ROCm Ninodes pack: ComfyUI Manager → search "ROCm Ninodes," or

cd ComfyUI/custom_nodes
git clone https://github.com/iGavroche/rocm-ninodes.git

Restart, under ROCm Ninodes → Loaders. Light deps (numpy, Pillow, psutil, gguf, safetensors), no model downloads - it reads whatever's in your loras folder. The one real prerequisite is the same as the rest of the pack: a working ROCm PyTorch install.

The honest take

If you're not memory-constrained, this is a LoRA loader with extra logging - stock ComfyUI's is perfectly fine and this adds nothing to the math. But "extra logging + cleanup around the load" is exactly the kind of thing that rescues an AMD workflow that OOMs every third run. One genuine caution: on GGUF-quantized models, LoRA application anywhere is slow (each layer dequantizes, patches, requantizes), and this node inherits that tax like every loader - the community advice there is to drop a quant level to make room, not to hunt for a faster loader. And remember, if the CLIP output looks wrong, the LoRA's strength_clip isn't zeroed - some LoRAs are model-only and punish the text encoder if you crank both strengths.

CategoryROCm Ninodes/Loaders

Inputs (5)

NameTypeDefaultDescription
modelMODELThe model to apply LoRA to
lora_nameCOMBOLoRA file to load
strength_modelFLOAT1.00-10–10Strength of LoRA effect on model
strength_clipFLOAT1.00-10–10Strength of LoRA effect on CLIP
clipoptCLIPCLIP model to apply LoRA to

Outputs (2)

NameTypeDescription
MODELMODEL
CLIPCLIP