pottokao

/

Qwen-Image-2.1-Text-Encoder-Heretic

Like 53

You're right — this repo won't load in ComfyUI, and that was my fault for tagging it comfyui. I've removed that tag (and added it to the GGUF repo, which is usable there), so the next person shouldn't hit this.
This one is the HF transformers checkpoint (bf16, 4 shards + config/tokenizer) — for transformers / diffusers / vLLM, or as the base for your own quantization. ComfyUI text encoders use a different key layout: the model.language_model. prefix gets dropped when a Qwen-Image text encoder is repacked for ComfyUI, so a genuine HF checkpoint won't load even if you drop it into models/text_encoders/.
For ComfyUI, use one of these instead. All three keep the vision tower, which 2.1 needs since it's also an edit model:
Repo
File
Loader
…-Text-Encoder-Heretic-NVFP4
qwen3vl_8b_nvfp4_heretic.safetensors
CLIPLoader, type qwen_image
…-Text-Encoder-Heretic-W4A8
qwen3vl_8b_w4a8_heretic.safetensors
CLIPLoader, type qwen_image
…-Text-Encoder-Heretic-GGUF
qwen3vl_8b_heretic-Q4_K_M.gguf + mmproj-…-f16.gguf
CLIPLoaderGGUF (ComfyUI-GGUF custom node)
One more gotcha that looks like "the model is broken": you need a ComfyUI new enough to know QwenImage21. 0.34.2 doesn't, 0.36.0 does. If TextEncodeQwenImage21 isn't in your node list, that's the reason, not the file.
NVFP4 is the one I run daily. W4A8 matches the official Comfy-Org packing bit-for-bit if you'd rather stay on the stock format.
Thanks for asking — it surfaced a real problem with how I'd tagged things.

What's the point of this when the model already does hilariously degenerate things no questions asked?

All I've ever seen with these abliterations is that they successfully make all outputs worse, so I do wonder.

Fair challenge, and you're right about the cost. Let me separate this into two core points:
​First, if the model truly had no refusal mechanism, I wouldn't have been able to ablate anything. The math and empirical data prove this direction exists in the weights—dropping a benchmark from 100/100 to 5/100 simply isn't possible if there's no refusal vector to begin with. However, a text encoder doesn't output a literal "I can't do this"; it outputs embeddings. Its version of refusal in image generation manifests as prompt softening, concept drift, or silently dropping elements (which is exactly that loss of exact control I mentioned is fatal for professionals).
​Second, there is no free lunch—this ablation has a definitive cost. Just like quantization inherently degrades model performance, orthogonalizing a specific feature direction comes with unavoidable loss. That cost is measured precisely by KL divergence. In my trials, the Pareto front was strictly monotonic: every fraction of refusal removed is paid for in KL.
​The cost is exactly measured, and the mathematical mechanism is real; it's just that the tangible, in-domain benefit is currently below my measurement floor. That is the honest position. I would much rather state this upfront than oversell the 5/100 metric or pretend that ablation comes without a price.

"Also, while it doesn't outright refuse, it does politely rewrite the prompt. For a professional image worker like me, this lack of control is exactly what's fatal."