[bug]: Qwen2.5-1.5B-Instruct model not recognized as `text_llm`

[lstein]

Is there an existing issue for this problem?

• I have searched the existing issues

Install method

Invoke's Launcher

Operating system

Linux

GPU vendor

Nvidia (CUDA)

GPU model

No response

GPU VRAM

No response

Version number

6.12.0.post1

Browser

No response

System Information

No response

What happened

Following the instructions in PR #8899 I used the Model Manager to install Qwen/Qwen2.5-1.5B-Instruct. It was identified as a Qwen3 Encoder and could not be used as a prompt expander.

What you expected to happen

I expect the Model Type to be identified as Text LLM as indicated in the PR. When I manually tried to set the Model Type to "Text LLM" it failed with the error message "Model Update Failed."

How to reproduce the problem

No response

Additional context

No response

Discord username

lstein

[Pfannkuchensack]

Diagnosis of Issue #9090

Root Cause

When probing Qwen2.5-1.5B-Instruct, two configs match simultaneously:

Config	Verdict	Why it matches
TextLLM_Diffusers_Config	✅ correct	Checks for *ForCausalLM + tokenizer files
Qwen3Encoder_Qwen3Encoder_Config	❌ wrong	Accepts diffusers dirs with config.json at root and class name Qwen2ForCausalLM / Qwen3ForCausalLM / Qwen2VLForConditionalGeneration

matches_sort_key assigns both the default value 3, and Qwen3Encoder_Qwen3Encoder_Config appears earlier in CONFIG_CLASSES — so it wins the tie-break.

Second Bug: "Model Update Failed"

When the user manually tries to switch the type to Text LLM, the update endpoint likely re-validates against the old Qwen3Encoder_* config, which requires a mandatory variant field. That field doesn't get stripped during the type switch, so validation fails. Needs verification in the update endpoint.

Proposed Fix (backend probe logic)

Qwen3Encoder_Qwen3Encoder_Config should reject the match when the directory looks like a standalone causal LM:

If config.json is at the root AND tokenizer files (tokenizer.json / tokenizer_config.json) are also at the root → it's a complete LLM (TextLLM), not a "standalone text_encoder download" from a larger pipeline.

The standalone-subfolder download normally does not contain tokenizer files, so this heuristic cleanly separates the two cases.

---

i will make a PR for a fix.