question on converstion
first, thanks for all the sdnq pre-quants you're publishing.
and most of them "just work" out-of-the-box
but why modify keys and change transformers layout here? it causes a divergence from already published vendor pipeline for both diffusers and as used in other apps. it not only complicates loading (two different transformer classes for original model and for prequant model), but also causes incompatibilities for any trained loras.
and changes dont stop there as text-encoder class is modified from qwen35model to qwen35textmodel?
and one more ask - when creating a modular pipeline, please expose latent unpack method as a separate block, not just as internal thing inside final vae decode as there are many reasons to want unpacked latents for each step, for example to generate live preview during generation.
oh I didn't know you were using them, the reason is that I wanted to be prepared if it was going to get added to diffusers, I can revert it to the original layout, that's not a problem. The reason for the qwen3.5 model was because originally this model wasn't supposed to be used with the vision tower which saves some VRAM but I found it It is pretty good with it right out of the box. I can pretty much revert them all back to the original one if you want.
about the latent unpack, I can do it to, do you need it for the ones I already did?
I found out that I did the model card wrong too which maybe caused the confusion, this model is a quantization of this one: https://huggingface.co/OzzyGT/MOSS_Image_Base_diffusers and not the original one
I'm going to do this change today, I'll re-quantize the MOSS models with the original layout
oh I didn't know you were using them
i avoid making duplicates if solution already exists, take a look at https://github.com/vladmandic/sdnext/blob/dev/data/reference-quantized.json and you'll see quite a few of your models.
I can pretty much revert them all back to the original one
no need, whatever is already released we already have a handler for it, this was more of a future-proof statement.
and changing an already published model is never a good thing as we'd never know what to expect from day-to-day.
the reason is that I wanted to be prepared if it was going to get added to diffusers
that is THE major painpoint with diffusers in general. if diffusers team works with model vendor pre-release and the very first model variant that gets released is diffuser-standard, all good as there is no divergence.
but for most models, diffusers implementation is AFTER the model has already been released. and as a result any finetunes or loras trained on the original model will not work with diffusers code or model variant. diffusers may not care about civitai that much, but community does - and if they cant use a finetune or lora, they will switch to a different solution. so we end up implementing massive on-the-fly conversion methods to support both - which should not be necessary.
oh ok, I'll do it for the next ones then, better for me since it required a planning for a fallback, I'll revert the changes.
I understand and agree with your last point but that's not my decision or role in diffusers and it is something that diffusers has from a long time before I joined the team, I'll let them know but I think you already made that point clear in some of the PRs. I will do it as you suggested with the ones I do since I want them to be used in apps like sd.next as easy as possible.
off-topic, just saw your article https://huggingface.co/blog/OzzyGT/prediction-preview-images-withd-modular-diffusers - you might be interested in https://huggingface.co/SD-Next/MicroDecoder
yeh I saw it after I made that article I haven't tested it but seems pretty cool, I'll test it and do another one when I have more models to do the preview blocks.