mingyi456

/

SRPO-DF11

like 1

Hi, regarding other DF11 models working, can I ask which other DF11 models work? Because as far as I know, the model you linked is the only "official" DF11 model that works with ComfyUI. The other official DF11 compressions are all in multiple shards, so they will only work in diffusers.

Do my other DF11 Flux models, like mingyi456/shuttle-jaguar-DF11, work for you? Honestly, I am not sure about what could be the problem in your case, because the only thing I did was run the provided compression script, with the option save_single_file set as True, and tested that the output model works with diffusers. I do not know if I have to do anything else to specifically make sure it works with ComfyUI, besides saving it as a single file, and from a quick glance at the source code for the DF11 node, it does not seem the case to me.

I only just started setting up ComfyUI a few hours ago, and I have never used it before (which is why I put the disclaimer saying that I have not tested ComfyUI on the model card), so it will take quite a while for me to diagnose your issue.

Actually, never mind. I realized the naming of the state_dict keys are completely different, so actually none of my models are currently compatible with ComfyUI. There should be a way to translate all these keys over, but I will need to research and learn how to do that, as well as figure out the exact mapping of the keys.

vs

Actually, never mind. I realized the naming of the state_dict keys are completely different, so actually none of my models are currently compatible with ComfyUI. There should be a way to translate all these keys over, but I will need to research and learn how to do that, as well as figure out the exact mapping of the keys.

mingyi456 - thanks for your reply, I put in a request for more info with the DFloat11 HF, lets see what they share:
https://huggingface.co/DFloat11/FLUX.1-Krea-dev-DF11-ComfyUI/discussions/1

@mingyi456 You're absolutely correct about the state_dict key naming differences! I've analyzed this issue with local ComfyUI testing and can confirm:

The Problem:
Your DF11 models use diffusers-style key naming (transformer_blocks.X.attn.to_q, single_transformer_blocks.X.proj_out) while ComfyUI expects Flux-style naming (double_blocks.X.img_attn.qkv, single_blocks.X.linear1).

Technical Details:

• Working DF11 model (Krea): Uses ComfyUI-compatible keys like double_blocks.0.img_attn.qkv.bias
• Your models: Use diffusers keys like transformer_blocks.3.attn.add_k_proj.bias
• ComfyUI's model_config_from_unet() returns None for unrecognized key patterns
• This causes the 'NoneType' object has no attribute 'set_inference_dtype' error

Solution Needed:
A key translation layer that maps between diffusers and ComfyUI naming conventions. The DFloat11 team needs to either:

1. Provide models with ComfyUI-compatible key names (like the official Krea model)
2. Update the ComfyUI-DFloat11 node to handle key translation
3. Document the conversion process for community contributors

Your models work perfectly in diffusers - this is purely a ComfyUI integration issue.

also updated the discussion here: https://huggingface.co/DFloat11/FLUX.1-Krea-dev-DF11-ComfyUI/discussions/1

ComfyUI tensor structure from the working flux1-krea-dev-df11.safetensors:
✅ 19 double_blocks (0-18) with 12 keys each
✅ 38 single_blocks (0-37) with 9 keys each
✅ 6 embedder types: final_layer, guidance_in, img_in, time_in, txt_in, vector_in
✅ DF11 keys unchanged: encoded_exponent, gaps, luts, sign_mantissa, split_positions, output_positions
Key Insights:
Double blocks are dual-pathway: img_attn/img_mlp + txt_attn/txt_mlp
Single blocks are unified: linear1/linear2 + modulation.lin
QKV attention is combined: Multiple diffusers keys → single ComfyUI qkv.bias
Embedders follow clear patterns: time/guidance/vector handling

I have bad news and good news.

The bad news is that naive translation and remapping of the keys by the name (which is already nontrivial for me) does not work. The DF11 keys, which corresponds to the compressed weights, are different, not because the weights are different, but because they are expected to be uncompressed into a different "arrangement" of weights (in this case, it is basically a torch.cat() or a torch.chunk() operation, but this is enough to mess up everything). So directly converting the compressed weights on-the-fly, or even offline, will be extremely tricky, especially for someone inexperienced like me.

The good news is that I managed to figure out a way to compress the model into a ComfyUI-compatible format, by starting with the uncompressed weights: https://huggingface.co/mingyi456/SRPO-DF11-ComfyUI

By the way, thanks for bringing this issue to my attention. Previously, I always assumed that simply saving the compressed model as a single file was enough to make it work with ComfyUI.

PS: It will be great if you could tone down your pasting of LLM generated text, because LLM outputs (especially with some styles of prompting) are often full of unnecessary fluff, biases and even hallucinations. Please try to summarize any potential insights you obtained from your LLM in your own words (i.e. not simply asking the LLM to summarize its responses), and clearly mention the source of your information.