Analyze LoRA Effect on Diffusion Model

This node generates nothing. It answers a question you have probably asked while staring at a LoRA that is doing absolutely nothing: is this thing even touching this model?

It applies a LoRA to a base diffusion model transiently, measures patched − original tensor by tensor, and hands you Markdown reports plus two CSV strings. No merged checkpoint, no delta file, no sampler run. If you have cranked a LoRA from 0.4 to 1.0 hoping to see a difference and couldn't tell, this tells you whether there was anything there at all.

Why you'd reach for it

LoRAs are architecture-bound, but the failure is usually quieter than an error. A LoRA from the wrong family can load fine and map onto keys that mean something else, so you get a real patch with no visible effect. This node lists unmapped LoRA groups and unused source tensors separately, which is the closest thing to a straight answer for "is this the wrong LoRA for this base?".

The other uses are more practical: seeing how hard a LoRA hits each block before you bake it into a merge, checking that a LoRA you just trained moved the layers it should, and figuring out which blocks to aim at when you're setting per-layer values on a merge or an extraction. It is also the honest way to compare strengths - run it at 0.6 and at 1.0 and diff the same block table instead of trusting your eyes across two seeds.

How it works

It streams. One base tensor plus the adapter tensors it needs are loaded at a time through Unified Efficient Loader's low-memory path (batch_size=1, prefetch 1), the LoRA is applied using ComfyUI's own weight adapter - so alpha/rank normalization, DoRA reconstruction, LoCon handling and set_weight replacement semantics are the same ones inference uses - and the difference is computed in FP32. Only scalar statistics and a bounded top-differences list survive each unit; no whole model or LoRA dictionary is ever built.

Unchanged floating tensors stay in the metrics, so the global numbers describe the impact on the base model you selected, not just the layers the LoRA touched. Reports go global → blockwise (block names approximated from the key hierarchy's first numeric component) → layerwise, with both parameter-weighted and equal-layer averages. The second report is diagnostics from the similarity, alignment and consensus stages of Consensus-Weighted Blending - the pack's merge algorithm - stopping deliberately before merge weighting. Useful if you merge with CWB, harmless otherwise.

Inputs and outputs that matter

• execution_mode - ANALYZE does the work; DOCUMENTATION ONLY loads no model data at all and returns the reference text. Handy for previewing the report layout without waiting on two files.
• model_a - the LoRA, from your loras folder.
• model_b - the base, and note the list it comes from: diffusion models, not checkpoints. A full checkpoint sitting in models/checkpoints will not appear here.
• strength - −10 to 10, default 1. This is the variable you're usually testing.
• top_weight_differences - how many single largest parameter changes are listed; default 20, 0 disables the list without affecting the per-layer tables.
• process_device - cuda or cpu. A CUDA out-of-memory retries just that work unit on CPU and the reports list the fallbacks.
• force_clear_cache - on by default: garbage collection plus a cleared CUDA allocator cache after every unit. Less retained memory, slower analysis.
• exclude_patterns plus glob_patterns and include_mode - filters on base tensor keys, applied before loading. Include mode is how you keep a run to the dozen blocks you care about.

Outputs are all strings: comparison_report, cwb_report and documentation go to a Show Text or Save Text node, and layerwise_metrics_csv and layerwise_cwb_csv are CSV text you save with a .csv filename - the node writes no files itself.

Install

Same pack as everything else here, so the install is shared. ComfyUI Manager → search Model Utility Toolkit (registry id comfyui-modelutils), or:

cd ComfyUI/custom_nodes
git clone https://github.com/silveroxides/ComfyUI-ModelUtils
python -m pip install -r ComfyUI/custom_nodes/ComfyUI-ModelUtils/requirements.txt

Restart afterwards. unifiedefficientloader is the dependency that matters - it is what keeps the per-tensor streaming bounded instead of a full-model load. No model downloads, no API keys. The pack targets ComfyUI's newer V3 node schema, so an old install fails on import before anything else goes wrong.

Troubleshooting and cost

It is slow, and it should be. You are reading a base model in FP32, tensor by tensor, plus a gc pass each unit. On a 12B model expect a coffee break, not a spinner. Trim it with include_mode and a pattern, or turn force_clear_cache off if you have headroom.

Quantized bases are rejected rather than lied about. Tensors carrying quantization metadata get reported and left out of the numeric metrics: encoded storage values are not comparable weights. A Q8 GGUF matches fp16 in output, but its stored numbers are a different representation, so a "difference" between them would be meaningless.

A failed patch fails the run. Application errors raise rather than recording zero impact, which is the point: if you get a clean report, the LoRA really did apply.

FP32 arithmetic is not the same as saved dtype. The analysis does not simulate rounding to bf16 or fp16, so treat the numbers as the shape of the effect, not a bit-exact forecast.

The CSVs are text, so wire them into a text-saving node and name the file .csv; nothing lands on disk otherwise. And if what you wanted was a baked checkpoint with the LoRA inside it, this is the wrong node - use the pack's merge nodes.