Krea2 Diagnostic
When Krea2 editing fails, this node reads the model out loud
- model
Every ComfyUI pack that reimplements a model's forward pass eventually ships a debug node, and this is molbal's. Krea2DiagnosticNode does one thing: it takes a MODEL, inspects the diffusion model inside it, and dumps the findings to your console. That's it - no outputs, no image, nothing visible in the UI. It exists for the moments when a Krea2 workflow that should work doesn't, and you need to know whether the problem is your graph or the model you loaded.
Why you'd reach for it
Two specific situations where this earns its place:
"Is this actually a Krea2 model?" The Krea2ModelPatcher assumes a specific single-stream DiT structure. If you grabbed a checkpoint from a mirror or a quantized conversion that changed things, the patch will fail in ways that read like a python stack trace, not a diagnosis. This node prints the DiT's class name and module, its named children, and its forward signature - so you can confirm it's the Krea2 architecture before you blame the patcher. It also explicitly reports whether the DiT has _unpack_context, which is a hook the patch relies on.
"Did the patch actually take?" Run it on the patched model and check the printed forward signature. The unpatched Krea2 forward takes (x, timesteps, context, ...); once Krea2ModelPatcher has done its thing, the signature shows the extra ref_latents keyword. That single line is the difference between "your refs are being ignored" and "your refs are being consumed" - and it's the most common failure mode in this whole pack.
It's also handy if you're experimenting with GGUF or FP8 Krea2 variants (molbal is the person behind the Krea2 GGUF conversions, so this fits his own workflow): you can confirm a conversion preserved the module structure before running a long sampling session.
The inputs and outputs
The schema is the smallest in the pack: one required model (MODEL), no outputs, flagged as an output node. You wire a model in, hit run, and read the terminal. There are no knobs to turn and nothing to tune.
The console dump is organized and genuinely readable:
- the DiT type and module
- its named children (you should see the single-stream blocks)
- non-module attributes, values truncated for sanity
- the forward signature
- the first block's structure
- whether
_unpack_contextexists
Installing it
Standard pack install, no extra dependencies beyond what ComfyUI already has (einops ships with it):
cd ComfyUI/custom_nodes
git clone https://github.com/molbal/ComfyUI-Krea2-MultiRef
Restart ComfyUI, or use ComfyUI Manager → Custom Nodes Manager → search ComfyUI-Krea2-MultiRef → install. Remember the model files are yours to source - Krea2 checkpoint plus the Qwen3-VL text encoder and Qwen-Image VAE - and you need ComfyUI 0.25.0+ for native krea2 support.
The gotcha that catches everyone
Because it's an output node with no image output, new users add it, run the workflow, and see nothing change in the UI - and assume it's broken. It isn't. The output goes to print(), so it lands in the ComfyUI console or the terminal where you launched the server. If you're on a remote or a wrapper UI that hides the log, you'll think it does nothing. That's the node working as intended.
One more thing worth knowing: this is a diagnostic, not a fix. It won't tell you why your edit looks bad - it tells you whether the machinery the edit depends on is even present. Combined with the patched-model signature check, it's usually enough to point you at the real culprit.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | — |
Outputs (0)
No outputs