invoke-ai/InvokeAI · warning · NotAMatchError

state dict does not look like a Qwen2.5-VL/Qwen2-VL checkpoi

Error message

state dict does not look like a Qwen2.5-VL/Qwen2-VL checkpoint

What it means

`NotAMatchError` raised when the safetensors header reads fine but `_has_qwen_vl_keys(keys)` finds none of the expected Qwen2.5-VL/Qwen2-VL key patterns. The file is a valid safetensors checkpoint — just not one this config class recognizes, so the prober moves on to other config classes.

Source

Thrown at invokeai/backend/model_manager/configs/qwen_vl_encoder.py:152

    def from_model_on_disk(cls, mod: ModelOnDisk, override_fields: dict[str, Any]) -> Self:
        raise_if_not_file(mod)

        raise_for_override_fields(cls, override_fields)

        # Only safetensors checkpoints are supported as single-file Qwen VL encoders.
        # Reject other extensions cheaply before attempting to read keys.
        if mod.path.suffix != ".safetensors":
            raise NotAMatchError(f"expected a .safetensors file, got {mod.path.suffix or '(no suffix)'}")

        # Read only the key index — a 7GB fp8 encoder weighs ~7GB on disk, but we
        # only need the key names to classify it, not the tensor data.
        try:
            keys = _read_safetensors_keys(mod.path)
        except Exception as e:
            raise NotAMatchError(f"could not read safetensors header: {e}") from e

        if not _has_qwen_vl_keys(keys):
            raise NotAMatchError("state dict does not look like a Qwen2.5-VL/Qwen2-VL checkpoint")

        return cls(**override_fields)

View on GitHub (pinned to 0b6a024f2f)

Solutions

Confirm the file actually contains Qwen2.5-VL/Qwen2-VL encoder weights; if not, no fix is needed — it is expected to match a different config class
If it IS a Qwen VL encoder, inspect the key names (`safe_open(...).keys()`) and compare against the matcher's patterns; it may use a novel prefix from a conversion tool
Re-export the checkpoint from official weights to restore canonical key names
Ensure you are installing the full encoder, not a LoRA/delta that shares the extension but not the keys

Example fix

// before: merged checkpoint with keys like "encoder.layers.0..."
// after: re-derive from upstream so keys are "model.layers..." (canonical Qwen2-VL naming)

Defensive patterns

Strategy: validation

Validate before calling

from safetensors import safe_open
from pathlib import Path

def keys_look_like_qwen_vl(path: Path) -> bool:
    with safe_open(path, framework="pt") as f:
        return any("visual" in k or "model.layers" in k for k in f.keys())

Try / catch

try:
    cfg = QwenVLTextEncoderConfig.from_model_on_disk(mod, override_fields)
except NotAMatchError as e:
    if "does not look like a Qwen" in str(e):
        print("File is valid safetensors but not a Qwen VL encoder — expected for other model types")
    raise

Prevention

Keep non-Qwen checkpoints out of auto-import folders for this config, or expect them to be skipped
Re-export merged/quantized checkpoints from canonical upstream weights
Inspect keys with safe_open when classification fails unexpectedly

When it happens

Trigger: Single-file `.safetensors` probing where the state dict belongs to a different architecture (SD UNet, T5, CLIP, LoRA, VAE) or uses key naming the matcher does not cover (e.g. a re-keyed/merged checkpoint).

Common situations: Dumping many checkpoints into the auto-import folder and letting the classifier sort them (non-Qwen files legitimately produce this), merged checkpoints with stripped prefixes, quantization formats that rename keys.

Related errors

AI-assisted analysis of invoke-ai/InvokeAI@0b6a024f2f (2026-08-29). Data as JSON: /api/errors/5149083d31e3235f. Report an issue: GitHub.