Nodes/ComfyUI LC Modelbuilder Nodes/LC Model Fingerprint πŸ”
ComfyUI Node

LC Model Fingerprint πŸ”

Did Someone Bake That LoRA Into This Checkpoint? Now You Can Check

By lonecatone23Β·Created 25 days agoΒ·Updated 3 days agoΒ· 4
LC Model Fingerprint πŸ”
  • model
  • reference
  • report
  • chart
β—„lora_namenoneβ–Ί

What this is for

Two questions come up constantly once you start collecting checkpoints. Is this finetune actually built on the base I think it is? And is there a LoRA buried in this file that nobody told me about?

LC Model Fingerprint πŸ” answers both by putting two loaded models side by side and comparing the weights themselves. No metadata, no model card, no library to build first. The one you're checking goes in model; the one you think it came from goes in reference. It reads every layer both have in common and prints a verdict: bit-identical weights, the same model at a different precision, a finetune that stayed close, a block merge (with a chart showing which blocks came from where), or not related.

The lora_name socket is the party trick. Give it a LoRA file and the base model it was made for, and it compares the LoRA's change against this checkpoint's change from that base. If they line up, the LoRA is in there, merged at roughly the strength it reports. That's a very specific kind of peace of mind in an ecosystem where "v6 final" files appear weekly and nobody documents anything, and where merge recipes are exactly what makes whole categories of models converge on the same faces.

How it works

Every weight of both models' diffusion halves gets compared with cosine similarity, one layer at a time, so two big files don't need to be doubled in memory on top of what ComfyUI already holds. Biases and norms are skipped - too small to tell you anything, and they inflate the score.

Quantized weights are decoded to full precision first, and here's the part worth knowing: the threshold for "the same" adapts to what each file is stored as. At bf16, identical weights read 0.9999 or above. At int8 or fp8, rounding pulls them down and the floor drops to 0.999. At 4-bit or Q4 and below it drops to 0.99. Under 0.97 counts as "not related". Without that, an fp8 copy would look suspiciously different from its own bf16 source.

The LoRA check is a different calculation: it reconstructs each LoRA layer's actual delta (up Γ— down Γ— alpha / rank) and correlates that against checkpoint βˆ’ reference, layer by layer, weighting by how much each layer moves. A correlation of 0.5 or better with a strength estimate of 0.1 or more means it's in there; 0.2 to 0.5 with a smaller strength means "probably, weakly, or mixed with other changes"; below that, not found.

Inputs and outputs

model (required) - the checkpoint you're checking. Any precision, GGUF too, provided you have the loader for it.

reference (optional, but without it the node just prints the model's family and tells you to connect one) - the parent you suspect.

lora_name (optional, needs a reference) - the LoRA you think was merged in. And the reference has to be the base that LoRA was made for, not just something similar.

Outputs are report - the verdict with the numbers behind it, also printed to the console - and chart, an IMAGE with one bar per block: green for the same weights, yellow for close, red for different. The bar scale is zoomed to the lowest value and the range is printed in the chart title, so a wall of 0.998 bars still shows its differences. Wire it to Preview Image. With a LoRA selected the chart flips to a per-block match chart, which is the quickest way to see whether the thing was baked in evenly or only in the late face blocks.

Install

ComfyUI Manager β†’ search LC Modelbuilder. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/lonecatone23/ComfyUI_LC_ModelBuilder_nodes

Restart, hard-refresh the browser (Ctrl+Shift+R), and check that __init__.py sits directly in custom_nodes/ComfyUI_LC_ModelBuilder_nodes/ - a nested folder is the classic reason nothing shows up. No requirements.txt: this runs on ComfyUI's own stack, and install.py only matters for the pack's face scorer.

Where it bites

Two big models at once. It reads one layer at a time, but both models still have to be loaded to be wired in - two 12B bf16 checkpoints is a 50 GB problem that pages to system RAM on most machines. Use an fp8 or GGUF reference if you only want to know whether something is Turbo-derived.

A LoRA loader upstream poisons the reading. The node evaluates each weight as the model actually uses it, patches included - so a LoRA Loader sitting between your checkpoint and this node gets read as part of the checkpoint. Test the raw model.

A light LoRA looks like a different precision. A LoRA merged at very low strength can read as "the same model, stored at a different precision" - the node says so itself and points you at the LoRA check. Trust the LoRA check for that question.

Different families give you nothing to compare. Cross-architecture files report "no layers in common"; reshaped layers report "the shared layers all have different shapes". Correct answers, not bugs.

It's weights, not provenance. 0.97+ proves the numbers came from the same place, not that anyone had permission to publish them. And a 50/50 merge of two similar parents reads as "built on the reference", because it largely is.

CategoryLC Modelbuilder

Inputs (3)

NameTypeDefaultDescription
modelMODELThe checkpoint you are checking. Load it with your usual loader (any precision, GGUF too).
referenceoptMODELThe model you think it came from. Needed to compare, and as the base for the LoRA check.
lora_nameoptCOMBOnoneA LoRA you think was merged into the checkpoint. Needs the reference: the base model the LoRA was made for.

Outputs (2)

NameTypeDescription
reportSTRINGWhat was found, in plain words, with the numbers behind it.
chartIMAGESimilarity per block (green = the same weights, yellow = close, red = different). With a LoRA: how strongly it shows per block.