Feature Request ： Add support for 'qwen2' text model architecture

[tinydream96]

Hi! Thanks for the great work on this node.

I am trying to use Qwen2.5-7B (e.g., qwen2.5-7b-instruct-q4_k_m.gguf) as a CLIP/Text Encoder for the TwinFlow model. However, loading this GGUF fails because the architecture string in the file is 'qwen2', which is currently not in the allowlist.

Error Message:
ValueError: Unexpected text model architecture type in GGUF file: 'qwen2'

Proposed Fix: I manually modified loader.py locally and it works perfectly. Here are the changes needed:
Add "qwen2" to TXT_ARCH_LIST:

TXT_ARCH_LIST = {"t5", "t5encoder", "llama", "qwen2vl", "qwen3", "qwen3vl", "qwen2"}
Add "qwen2" to the check in gguf_clip_loader:

elif arch in {"llama", "qwen2vl", "qwen3", "qwen3vl", "qwen2"}:
Enable llama permutation for "qwen2" (since it shares the architecture):

if arch == "llama" or arch == "qwen2":
sd = llama_permute(sd, 32, 8)

Could you please add official support for this? Thanks!

[jdfhasdfgasdf]

I came across this issue too and found this post. Dev, how did you leave qwen2 out of your code? Your ComfyUI-GGUF is 2 years old. I had to manually fix your bugs and code. Come on lol. Tiny Dream? More like Big Nightmare.

[city96]

Dev, how did you leave qwen2 out of your code?

I don't think anything officially uses qwen2, so we only really have the qwen2vl version added. What model would this be for? So I can test it against the safetensors variant before adding it.
(also, I think the arch is the same as the VL one, so kinda odd that it needs the permute while that one didn't?)

Your ComfyUI-GGUF is 2 years old.

And the readme is still the crappy half-assed one from day1. I don't really have any excuses, there's way too much stuff like that in this repo that needs fixing

[jdfhasdfgasdf]

I don't think anything officially uses qwen2, so we only really have the qwen2vl version added. What model would this be for? So I can test it against the safetensors variant before adding it. (also, I think the arch is the same as the VL one, so kinda odd that it needs the permute while that one didn't?)

I was testing Lumina-Next-SFT (Lumina-2) using Qwen2.5-7B-Instruct (GGUF) as the text encoder.

The GGUF identifies as "qwen2". I manually patched the architecture list and the permute logic to get it to load, but that's where I hit the TODO roadblocks in your loader.py.

It seems without a clean way to pass the vocab_size and a less "janky" (as you wrote) dequantization method, these 7B encoders are hitting a wall of errors, critical tensor shape mismatches and dimensionality conflicts (e.g., embedding size mismatches like 1536 vs 4096).

It’s up to you if you want to bridge that gap, but that’s the specific use case currently blocked.

Newer high-parameter models like Lumina-Next and certain TwinFlow implementations are officially adopting Qwen2/2.5-based text encoders because they significantly outperform the older T5-XXL benchmarks in prompt comprehension.

Without the "qwen2" string and the corresponding llama-style permutation, these state-of-the-art weights are currently unusable in GGUF format. Adding this support ensures the repo stays compatible with the new 2026 model standards.

[patrickwilliamwalker]

I'm getting Unexpected architecture type in GGUF file: 'qwen2vl' from the unetloader node.

You sure it's been added?