LoHa Loader (Custom) 🌀

LoHa is a different mathematical beast from a plain LoRA. Where LoRA approximates a weight update as a low-rank product, LoHa uses a Hadamard (element-wise) product of two low-rank pairs - fewer parameters, more expressive, and historically favored for style capture and generalization. Most of the time ComfyUI loads these fine automatically. But there's a documented ComfyUI issue where the built-in LyCORIS auto-detection can silently mis-route a LoHa file through the plain LoRA path - technically running, mathematically wrong. This node exists to give you the real Hadamard math, explicitly, instead of gambling on auto-detection.

How it works

The engine computes the actual LoHa delta - ΔW = (W1a @ W1b) ⊙ (W2a @ W2b) - and applies it through ComfyUI's own ModelPatcher.add_patches() API. No state_dict surgery. strength scales the applied delta uniformly (1.0 = full effect as embedded in the file's own alpha/rank scaling, 0.0 = none, negative inverts).

The honest part is in the failure handling. Any key in the file that isn't a recognizable LoHa key (*.hada_w1_a, *.hada_w1_b, *.hada_w2_a, *.hada_w2_b) is skipped and counted, and reported in the summary output. This node will never silently fall back to treating an unrecognized key as something else. And a real limitation to know going in: only Linear-style 2D weights are supported - Conv2d (4D) layers are not implemented. Real LoHa files often include both, and the Conv2d layers will be skipped, with the counts in summary. That means for many files the effect is partial. Always read the summary before assuming a merge fully applied.

Inputs and outputs

• model - the MODEL to patch.
• loha_name - picked from ComfyUI's LoRA folder registry (so the file must live under ComfyUI/models/loras/).
• strength - the dial, −5 to 5.
• model - the patched model, wire into your sampler chain.
• summary - read this. It tells you what applied and - critically - what got skipped.

The workflow that makes sense

Confirm the format before loading. The pack's LyCORIS Format Inspector reads the file's actual tensor key names (header-only, fast) and tells you whether it's really LoHa - because misidentifying a LoHa as a plain LoRA means applying the wrong math entirely. So the loop is: Format Inspector → LoHa Loader → read the summary → sample. And apply it before other model-patching nodes if you can - patch order matters and the loader computes against whatever weights it's given.

Why bother when ComfyUI sometimes loads these automatically? Because "sometimes." The core auto-detection has a documented open issue where LyCORIS files get silently routed through the wrong merge path. This loader makes the format explicit, applies the right math, and tells you what it couldn't apply. That's the whole value proposition.

Install

Nothing beyond ComfyUI's stack:

cd ComfyUI/custom_nodes
git clone https://github.com/TensorVizion/OmniNodes

Restart, find it under TensorVizion/Model (ComfyUI Manager, search "OmniNodes", also works).

Troubleshooting

• The file is a plain LoRA, not LoHa. The loader will skip most keys and tell you so. Run the Format Inspector first - that's exactly the trap these nodes exist to catch.
• Summary shows Conv2d layers skipped. Expected for now; the effect is partial. If the file is mostly attention/Linear layers, the bulk still applies.
• "LoRA not found" - the file isn't in ComfyUI's loras search path. Drop it in ComfyUI/models/loras/ and restart.

If you only ever load plain LoRAs, you don't need this node. If you're dealing with actual LoHa files - style-heavy adapters, mostly - it's the difference between trusting auto-detection and knowing the math is right.