HALO Model Debug
What dtype did your model actually load as? One node, zero guessing
- model
- MODEL
Here's a sentence that should be boring but isn't: your model runs in a specific number format, and on AMD ROCm that format can quietly destroy your image. Half-precision math - fp16 and especially bf16 - is where NaN values are born, and the first thing you need when debugging black output is to know what your model is actually running as. That's all HALO Model Debug does, and honestly that's all it needs to do.
ComfyUI loads checkpoints in whatever precision the loader decides, often bf16 on newer hardware. On the AMD Strix Halo APUs this pack was built for - and on ROCm more generally - bf16 is a known source of NaN. But you can't tell what dtype you got just by looking at the node graph. This node peeks inside and tells you.
How it works
It reaches into the loaded model (model.model.diffusion_model), grabs the first parameter it finds, and prints its dtype and device to the ComfyUI console. Then it applies the pack's rule of thumb:
- bf16 → warns:
may cause NaN on ROCm!and suggests loading fp32 or using--force-fp32 - fp32 →
✓ Model is in fp32 - fp16 → reports it without alarm
The model passes through untouched. Nothing is converted, nothing is modified - this is a thermometer, not a thermostat.
Inputs and outputs
- model (
MODEL, required) - wire this straight off a checkpoint loader, UNET loader, or LoRA stack. - Output:
MODEL, identical, passed through.
Place it as CheckpointLoader → HALO Model Debug → sampler model input. Since it doesn't touch the data, you can splice it in and out freely.
Installation
Ships in the HALO Debug Pack with four sibling nodes. ComfyUI Manager → search "HALO Debug Pack", or:
cd ComfyUI/custom_nodes
git clone https://github.com/bkpaine1/halo_pack
Restart, and the nodes land under the HALO category. Zero dependencies beyond what ComfyUI already has - the pack is a single __init__.py with no requirements file and no models to download.
Where people get burned
- It reports, it doesn't fix. If the node tells you the model is bf16 and you're on ROCm getting black images, that's your culprit - but this node won't change a thing. You fix it at launch with
--force-fp32(a real ComfyUI flag, and the README's own recommendation), or by loading the model at a different precision. - The answer is in the terminal, not the UI. If your launcher hides the console, you'll see nothing and assume the node is dead.
- It inspects the diffusion model specifically. The check looks at
diffusion_modelparameters; for models that don't expose that structure, it printsCould not inspect modeland moves on. That's a limitation, not a bug.
This is the least glamorous node in the pack and possibly the most diagnostic. Before you go reinstalling drivers or blaming the VAE, spend ten seconds confirming whether the model even loaded in the precision you assumed. It's saved me exactly that kind of false start.
Inputs (1)
| Name | Type | Default | Description |
|---|---|---|---|
| model | MODEL | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| MODEL | MODEL | — |