LoRA Report

Almost every "my LoRA doesn't work" thread ends the same way: someone tells you to check the base model, check the trigger word, drop the weight to 0.7, and you do all of it and the LoRA still does nothing. LoRA Report is for the case the checklist can't explain, because the LoRA is compatible, is loaded, and part of it silently isn't landing.

The specific failure it was built for: fused q/k/v checkpoints - MOSS-Image, Flux 3 - versus LoRAs trained on separate q, k and v projections. To apply one to the other, ComfyUI patches thirds of the fused qkv weight with an offset. Whether that happens depends on the LoRA's key names matching ComfyUI's internal map, and bypass mode can't apply offset patches at all. Get either wrong and the q/k/v part of your LoRA does nothing, quietly. The image still changes a bit, so you assume it worked and that the LoRA is just weak.

LoRA Report reads the model's own patch list after the loader, so it shows what will run rather than what was meant to.

The fields

model is the model coming out of your LoRA loader(s) - that's the whole input. sample_blocks is a string of block numbers to measure q/k/v movement in, default 0, 21, 41, i.e. early, middle, late. lora_name is a dropdown with a (none) default; set it to a LoRA file and the report also tells you which of that file's keys this model can't place. That's the part most people miss, and it's the one that catches a LoRA built for a different architecture.

Two outputs: model, passed through unchanged, and report, a STRING. The node is an output node, so it runs when you queue and the report appears in the node's own preview text. Wire report into a Save Text node if you want it somewhere you can keep.

What's in the report

Three things, grouped. First, which weights the LoRA patched, per part and block - proj.q across blocks 0–40, for instance, or proj.qkv[k] when a patch lands on the k third of a fused weight. That naming is the giveaway: if you expected q, k and v all through your model and you only see proj.q, the fused mapping didn't happen.

Second, the adapter types and strengths in play, counted. Multiple loaders stacking silently is a real thing, and this makes the count visible.

Third, how far it moved q, k and v in the blocks you sampled. This is a delta measurement against the base weights, not a guess.

Which leads to the trick the author suggests, and it's a good one: load the same LoRA into a fused checkpoint and a split one - MOSS-Image and something with separate projections, or two checkpoint formats of the same model - and compare the numbers for the same blocks. They should match. If the fused one moves q and the q third of qkv by different amounts, or the k slice is untouched, you've found your missing LoRA.

Install

Part of the same pack:

comfy node install comfyui-nynxz-nodes

Or search Nynxz in ComfyUI Manager, or clone it:

cd ComfyUI/custom_nodes
git clone https://github.com/Nynxz/ComfyUI-NynxzNodes
cd ComfyUI-NynxzNodes
pnpm install && pnpm build

Restart afterwards. No extra Python dependencies - it reads structures ComfyUI already builds. The frontend build only matters for the pack's editor nodes, but do it anyway so you're not debugging a half-installed pack later.

Reading it like a human

Don't panic at a long list. The question you're asking is narrow: did the parts I care about get patched, with the strength I asked for? If the answer is yes and the image still ignores the LoRA, it's not a patching problem and you should go back to the ordinary checklist - wrong base, missing trigger word, weight too high.

If the answer is no, check what you loaded before you check the LoRA. A LoRA can be perfectly fine and simply not fit a fused checkpoint's key layout; the report will show the keys it couldn't place, which is a much faster answer than regenerating with a different seed twelve times.