invoke-ai/InvokeAI · error · NotAMatchError

unrecognized token vector length {token_vector_length}

Error message

unrecognized token vector length {token_vector_length}

What it means

NotAMatchError raised by LoRA_LyCORIS_Config_Base._get_base_or_raise when a state dict that passed the generic LyCORIS LoRA key heuristics yields a token vector length that is not 768, 1024, 1280, or 2048, and whose UNet structure does not look like an SDXL UNet LoRA. InvokeAI uses lora_token_vector_length(state_dict) to infer the base model (SD1/SD2/SDXL) from text-encoder cross-attention shapes; a length outside the known set means the library cannot determine which base-model config this LoRA belongs to, so it refuses to match.

Source

Thrown at invokeai/backend/model_manager/configs/lora.py:669

            raise NotAMatchError("model looks like an Anima LoRA, not a Stable Diffusion LoRA")

        # If we've gotten here, we assume that the model is a Stable Diffusion model
        token_vector_length = lora_token_vector_length(state_dict)
        if token_vector_length == 768:
            return BaseModelType.StableDiffusion1
        elif token_vector_length == 1024:
            return BaseModelType.StableDiffusion2
        elif token_vector_length == 1280:
            return BaseModelType.StableDiffusionXL  # recognizes format at https://civitai.com/models/224641
        elif token_vector_length == 2048:
            return BaseModelType.StableDiffusionXL
        # Some SDXL LoRAs (e.g. self-attention-only "slider" LoRAs) target only the UNet
        # and lack the cross-attention / text-encoder keys that lora_token_vector_length()
        # needs. Fall back to detecting SDXL from the UNet's deep transformer-block structure.
        elif _state_dict_looks_like_sdxl_unet_lora(state_dict):
            return BaseModelType.StableDiffusionXL
        else:
            raise NotAMatchError(f"unrecognized token vector length {token_vector_length}")


class LoRA_LyCORIS_SD1_Config(LoRA_LyCORIS_Config_Base, Config_Base):
    base: Literal[BaseModelType.StableDiffusion1] = Field(default=BaseModelType.StableDiffusion1)


class LoRA_LyCORIS_SD2_Config(LoRA_LyCORIS_Config_Base, Config_Base):
    base: Literal[BaseModelType.StableDiffusion2] = Field(default=BaseModelType.StableDiffusion2)


class LoRA_LyCORIS_SDXL_Config(LoRA_LyCORIS_Config_Base, Config_Base):
    base: Literal[BaseModelType.StableDiffusionXL] = Field(default=BaseModelType.StableDiffusionXL)


class LoRA_LyCORIS_FLUX_Config(LoRA_LyCORIS_Config_Base, Config_Base):
    base: Literal[BaseModelType.Flux] = Field(default=BaseModelType.Flux)

View on GitHub (pinned to 0b6a024f2f)

Solutions

  1. Check the actual token vector length printed in the message: if it is a recognizable value for a different architecture (e.g. 4096 for Flux), the LoRA is for an unsupported base model and cannot be imported as an SD LoRA.
  2. Update InvokeAI to the latest version — new base-model detectors (Flux, Z-Image, Krea-2, etc.) are added over time and may now classify this file.
  3. If the model is a known SDXL slider/text-encoder-less LoRA, verify _state_dict_looks_like_sdxl_unet_lora should match: the state dict must contain SDXL UNet transformer-block keys; re-export/retrain with standard key naming if it does not.
  4. Pass an explicit base/override in the model config (or use 'base_model' override fields when installing) to skip base inference.
  5. Validate the file integrity (re-download the safetensors/checkpoint) in case truncation produced malformed tensors.

Example fix

// before: installing via scan with no hints
ModelOnDisk(path) -> LoRA_LyCORIS_Config_Base.from_model_on_disk(mod, {})
// after: provide explicit base override so _get_base_or_raise is skipped
from_model_on_disk(mod, {"base": BaseModelType.StableDiffusionXL, "variant": ModelVariantType.Normal})
Defensive patterns

Strategy: validation

Validate before calling

from invokeai.backend.model_manager.load.model_util import lora_token_vector_length
from invokeai.backend.model_manager.configs.lora import _state_dict_looks_like_sdxl_unet_lora

sd = load_file("model.safetensors")
tvl = lora_token_vector_length(sd)
if tvl not in (768, 1024, 1280, 2048) and not _state_dict_looks_like_sdxl_unet_lora(sd):
    print(f"Unsupported LoRA: token vector length {tvl}, not an SDXL UNet LoRA")

Type guard

from typing import Any

def is_supported_sd_lora(state_dict: dict[str, Any]) -> bool:
    tvl = lora_token_vector_length(state_dict)
    return tvl in (768, 1024, 1280, 2048) or _state_dict_looks_like_sdxl_unet_lora(state_dict)

Try / catch

from invokeai.backend.model_manager.configs.base import NotAMatchError

try:
    config = LoRA_LyCORIS_Config_Base.from_model_on_disk(mod, {})
except NotAMatchError as e:
    logger.warning("LoRA import skipped: %s", e)
    config = None

Prevention

When it happens

Trigger: Scanning/importing a LoRA file where lora_token_vector_length() computes an unusual embedding size (typically None or an unexpected number) because the file lacks text-encoder/cross-attention keys (e.g. self-attention-only 'slider' LoRAs) or uses a novel architecture, and _state_dict_looks_like_sdxl_unet_lora() also fails to match.

Common situations: Installing a text-encoder-less SDXL slider LoRA from Civitai, a LoRA trained for an unsupported/newer base model (e.g. SD3.5, Pony variants with odd text encoders, Flux LoRAs missing the recognized Kohya/diffusers format markers), a corrupted or truncated safetensors file, or a merged checkpoint that still carries LoRA keys.

Related errors


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