Model Ablation Analyzer (Heatmap)

The diff viewer in this pack tells you where two models differ. Model Ablation Analyzer (Heatmap) asks a stranger question: which part of the model is actually responsible for this specific image? It's a sensitivity analysis. It samples your image, then - block by block - reverts part of the model toward a reference and re-samples. The more the output changes, the more important that block was. If you've ever wanted proof instead of folklore about which layers "do the style" and which "do the anatomy," this is the closest thing to a measurement.

It's the heaviest node in galigali-san/ComfyUI-ModelDumpster (experimental, MIT, no install deps), and it's SDXL-only like its siblings. The author bundles a ready-made example workflow in the repo, which is a good thing, because this node has a real learning curve.

How the ablation works

The math is simple and brutal:

1. Fix a noise (from your seed) and sample once with your model - that's the baseline.
2. For each block (or each element within every block, depending on granularity), clone the model and patch that group's weights back toward the reference model - model_ref - using revert_strength. At 1.0, that block is fully replaced by the reference's weights.
3. Sample again with the same noise. The only variable is the one block you touched.
4. Importance = how much the output latent moved, normalized so the biggest mover is 1.0.

Because the noise never changes, any output difference is attributable to that one reverted block. That's the whole trick, and it's why the results are actually interpretable - unlike a lot of attribution tools, you can point at a number and know exactly what produced it.

The choice of model_ref defines what your question means. Reference a plain SDXL base and you're measuring "what does this fine-tune contribute, block by block." Reference a different fine-tune and you're measuring "what separates these two on this prompt." The README suggests a vanilla SDXL base, and that's the most useful default.

The inputs that matter

There are a lot of inputs, but you only genuinely set a handful:

• model / model_ref - your model, and the reference to revert toward. Both loaded from checkpoint loaders.
• positive / negative - your prompt conditioning, wired from CLIP Text Encode nodes.
• latent - VAE-encode the image you want to analyze, or feed an empty latent. denoise (default 0.5) controls how much noise you put on it to explore; VAE-encoded images with denoise 0.5 is the usual starting point.
• granularity - element drills down to attention/FF/norm level (slow), block merges them per block (fast). Start with block.
• steps - default 1, and the tooltip says it plainly: 1 is the fastest sensitivity analysis; raising it gets closer to real generation but gets slower.
• seed, cfg, sampler_name, scheduler, revert_strength - the sampler settings mirror a KSampler; revert_strength (default 1.0) is how much you swap toward the reference.

What you get out

Three outputs: report (a text matrix plus the top-15 most influential block:element groups), heatmap_json (the machine-readable version), and baseline_latent - the baseline sample itself. Wire that last one through VAEDecode and you see exactly what image you just analyzed, which is a nice sanity check. The heatmap renders in-node with the same block×element layout as Model Diff Viewer.

One important distinction from the README: this is not DAAM-style word-to-image attribution. DAAM shows where in the image a token fired. This shows which structure drove the output - a different axis entirely.

Installing and running it

cd ComfyUI/custom_nodes
git clone https://github.com/galigali-san/ComfyUI-ModelDumpster

Restart, done - no extra Python deps. Or find ComfyUI-ModelDumpster in ComfyUI Manager. The node sits in advanced/model_analysis, and there's a working example at example_workflows/Model_Ablation_example.json in the repo - drag it in and swap the checkpoint names for your own.

Common issues

• It is GPU-hungry, and this is not a joke. Every measured group is one full sampling run. At element granularity on SDXL that's roughly a hundred-plus samples per analysis, even at 1 step. The README's warning is the actual instructions: start with granularity=block, steps=1, and a decent GPU. On CPU you will age visibly.
• Reference matters. Revert toward a model that's too similar and every block looks unimportant; toward something too different and everything glows red. Base SDXL is the sane starting point.
• SDXL only, same as the other analysis nodes here.

The verdict: it's slow, it's experimental, and it's genuinely informative. If you're deciding what to merge or trying to understand what a fine-tune actually bought you, an hour of ablation beats a week of guessing.