Model Diff Viewer (Heatmap)
Where two SDXL models actually differ, in one heatmap
- model1
- model2
- report
- heatmap_json
You've been there: two checkpoints that are supposed to be different, same prompt, and you can feel that the outputs differ - but you have no idea which part of the model is doing it. Model Diff Viewer (Heatmap) answers that at the weight level. It takes two SDXL checkpoints, compares their UNets key by key, and paints the difference as a block×element heatmap. Dark cells mean "basically identical," red means "these two weights went in completely different directions."
It's from the galigali-san/ComfyUI-ModelDumpster pack, a grab-bag of experimental model-analysis nodes. The author's own framing is worth quoting: it's a collection that "might not be highly practical" and exists so you can experiment freely. That's honest. This node is a research instrument, not a daily-driver - but if you're into merging, it's a genuinely useful one.
What it's for
Most models on CivitAI are merges, not fine-tunes: weighted averages of existing checkpoints, no training involved. The catch is that a blind 50/50 blend dilutes both parents. This node is the "look before you leap" step - you see where two models differ before you decide what to mix, instead of merging everything and hoping. Feed it your fine-tune and the base it came from, and the heatmap shows you exactly which blocks the fine-tune actually touched.
How it works
The node grabs the UNet state dict from each model (the diffusion_model.* weights), flattens every tensor to CPU fp32, and scores each matching key. Two metrics:
relative_l2(default): ‖A−B‖ divided by the larger of ‖A‖, ‖B‖. 0 = identical, 1 = completely different.cosine: 1 − cosine similarity between the two tensors.
Per-key scores get aggregated into a matrix of 19 blocks × 6 elements. The elements are the familiar merge-surgery groups - attn1, attn2, ff, norm, proj, other - across IN00–08, M00, and OUT00–08. That layout is SDXL-only; there are no IN09–11 rows because SD1.5's extra blocks don't exist in SDXL.
The in-node UI has tabs. ALL shows the six-element matrix; clicking attn1 or ff drills into sub-elements like to_q/to_k/to_v or net.0/net.2. There's a PNG save button, and the layout puts input blocks left, output blocks right, BASE/M00 along the bottom - the arrangement you'll recognize from the merging world.
The inputs and outputs that matter
Just three inputs, and really only one you'll touch:
model1/model2- the two checkpoints, wired from any checkpoint loader.metric- leave it onrelative_l2unless you have a reason not to; cosine is there for when you care about direction more than magnitude.
Outputs are two strings: report, a text matrix plus the top 20 most-different individual keys, and heatmap_json, which is the machine-readable payload you feed into the pack's Diff → Recipe node to auto-generate a merge recipe. That's the node's real endgame - the viewer alone is pretty, the viewer-plus-recipe is a workflow.
Installing it
The pack has zero extra dependencies, which is refreshing. Either:
- ComfyUI Manager → install custom node → search ComfyUI-ModelDumpster, or
cd ComfyUI/custom_nodes && git clone https://github.com/galigali-san/ComfyUI-ModelDumpster
Then restart ComfyUI. No requirements.txt, no torch version fights. It lives in the advanced/model_analysis category.
Common issues
- SDXL only. Diff two SD1.5 or Flux checkpoints and you'll get a report, but the heatmap layout simply doesn't know those blocks - keys that don't map to IN00–08/M00/OUT00–08 get counted but not shown.
- RAM, not VRAM. The comparison happens on the CPU, so both checkpoints are loaded in memory at once while it runs. Two SDXL models is roughly 13 GB of RAM in fp16. Budget accordingly.
- It's UNet-only. The diff never touches CLIP or VAE. If two checkpoints differ mostly in their text encoder, this node will call them near-identical.
- All dark? Either the models genuinely barely differ (you might be diffing two copies of the same checkpoint - check
n_keysin the report), or you're comparing apples to oranges.
One honest caveat: at 0 search impressions this is a niche tool with a niche audience. But for the person who wants to know what a merge changed before committing a multi-GB checkpoint to a blend, there isn't much else that shows you the answer this directly.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| model1 | MODEL | — | |
| model2 | MODEL | — | |
| metric | COMBO | 2 options: relative_l2, cosine |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| report | STRING | — |
| heatmap_json | STRING | — |