Doesn't Work
RuntimeError: Error(s) in loading state_dict for ChromaRadiance:
While copying the parameter named "distilled_guidance_layer.norms.0.scale", whose dimensions in the model are torch.Size([5120]) and whose dimensions in the checkpoint are torch.Size([10240]), an exception occurred : ('The size of tensor a (5120) must match the size of tensor b (10240) at non-singleton dimension 0',)....
Make sure you're on the latest comfy lodestone recently committed some changes.
https://github.com/comfyanonymous/ComfyUI/commit/b9fb542703085c58f082b4a822329fb6670e8016
I just generated 50 plus images with the latest release with no technical issues.
I did git pull a day ago, doesn't load
I just generated that right now using this:
https://huggingface.co/lodestones/Chroma1-Radiance/blob/main/latest_x0.safetensors
If you post the full stack trace so we can see what line number the exception occurs on we would be able to tell what is happening.
Maybe it's to blame https://github.com/calcuis/gguf or/and https://huggingface.co/stduhpf/Chroma1-Radiance-gguf
I would presume so.
I'd probably go with https://github.com/city96/ComfyUI-GGUF instead the calcuis one.
The way the calcuis one is managing the source code is a bit... odd.
Like look at file:
https://github.com/calcuis/gguf/blob/main/gguf_connector/y.py
This is its content...
from gguf_comfy import downloader
They have a PDF processor that loads GGUF via llama then it extracts the contents.
https://github.com/calcuis/gguf/blob/main/gguf_connector/pp.py
Lots of odd stuff in that repository.
Got the same error message with city96's nodes here. Probably just those GGUF's in particular being incompatible, given that stduhpf has some other experimental/incompatible-with-comfy GGUF's in his repo too.
The calcuis nodes OOM'd on everything the last time I tried and their readme is a bit weird, but converting PDF's to run them through LLM's is a very common thing to do.
@zootkitty @vanzal I deleted city96's nodes for a reason, I want calcuis's ones, at least because it gets some updates, supports cow GGUF, has various nodes
If it's not the metadata it could also be because the norm scales are in BF16 in my models, and the GGUF nodes expect it to always be f32?
Edit: I'm now pretty sure that's it. If I convert the models while forcing the scales to be f32 type, I can load it with city96's node. This makes the model about 90kB bigger with for no performance gains, which is not terrible, but I think it would be best to report this issue to the maintainers of the ComfyUI nodes.
It is the norm scales being BF16, I just tested it and saw the exception.
2025-12-17 07:29:03.523 [Warning] [ComfyUI-0/STDERR] File "ComfyUI/comfy/model_base.py", line 308, in load_model_weights
2025-12-17 07:29:03.523 [Warning] [ComfyUI-0/STDERR] m, u = self.diffusion_model.load_state_dict(to_load, strict=False)
2025-12-17 07:29:03.523 [Warning] [ComfyUI-0/STDERR] ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2025-12-17 07:29:03.523 [Warning] [ComfyUI-0/STDERR] File "ComfyUI/venv/lib/python3.12/site-packages/torch/nn/modules/module.py", line 2629, in load_state_dict
2025-12-17 07:29:03.523 [Warning] [ComfyUI-0/STDERR] raise RuntimeError(
2025-12-17 07:29:03.523 [Warning] [ComfyUI-0/STDERR] RuntimeError: Error(s) in loading state_dict for ChromaRadiance:
2025-12-17 07:29:03.523 [Warning] [ComfyUI-0/STDERR] While copying the parameter named "distilled_guidance_layer.norms.0.scale", whose dimensions in the model are torch.Size([5120]) and whose dimensions in the checkpoint are torch.Size([10240]), an exception occurred : ('The size of tensor a (5120) must match the size of tensor b (10240) at non-singleton dimension 0',).
Also this GGUF Worked for me and has the scales in f32.
https://huggingface.co/silveroxides/Chroma-Misc-Models/blob/main/Chroma1-Radiance-2025-11-28/Chroma1-Radiance-2025-11-28-Q4_0.gguf
That wasn't meant for you to use it was for stduhpf so he has a working GGUF conversion template to go by.
This one should work with ComfyUI.
Works, thanks
The main conversion code should already keep 1D tensors in FP32 (this logic is from llama.cpp, though here we need it because quantized tensors can't be loaded into parameters directly, and BF16 is treated as being a quantized format).
Anyway, pushed a fix for that here for externally converted models, so the original ones should load now as well.