AUTOMATIC1111/stable-diffusion-webui · error · AssertionError

Could not find a module type (out of {', '.join([x.class

Error message

Could not find a module type (out of {', '.join([x.__class__.__name__ for x in module_types])}) that would accept those keys: {', '.join(weights.w)}

What it means

Raised in networks.py when, after grouping a LoRA file's weight keys by target sd module, no registered network module type (NetworkModuleLoRA, NetworkModuleHada, NetworkModuleFull, IA3, LoHa/LoKr, etc.) accepts the key set. Each module type's create_module inspects weights.w and returns None if the expected key patterns (lora_down.weight, hada_w1_a, lora_mid.weight, etc.) are absent; if every candidate refuses, the bundle is unloadable.

Source

Thrown at extensions-builtin/Lora/networks.py:254

        if sd_module is None:
            keys_failed_to_match[key_network] = key
            continue

        if key not in matched_networks:
            matched_networks[key] = network.NetworkWeights(network_key=key_network, sd_key=key, w={}, sd_module=sd_module)

        matched_networks[key].w[network_part] = weight

    for key, weights in matched_networks.items():
        net_module = None
        for nettype in module_types:
            net_module = nettype.create_module(net, weights)
            if net_module is not None:
                break

        if net_module is None:
            raise AssertionError(f"Could not find a module type (out of {', '.join([x.__class__.__name__ for x in module_types])}) that would accept those keys: {', '.join(weights.w)}")

        net.modules[key] = net_module

    embeddings = {}
    for emb_name, data in bundle_embeddings.items():
        embedding = textual_inversion.create_embedding_from_data(data, emb_name, filename=network_on_disk.filename + "/" + emb_name)
        embedding.loaded = None
        embedding.shorthash = BundledTIHash(name)
        embeddings[emb_name] = embedding

    net.bundle_embeddings = embeddings

    if keys_failed_to_match:
        logging.debug(f"Network {network_on_disk.filename} didn't match keys: {keys_failed_to_match}")

    return net

View on GitHub (pinned to 82a973c043)

Solutions

Update the webui (and built-in Lora extension) to the latest version so newer key formats are recognized
Verify the file integrity: re-download the LoRA and check its sha256 if published; open it with a safetensors metadata viewer and confirm each lora_down.weight has a matching lora_up.weight
Re-export/re-merge the LoRA with kohya's scripts so key names follow the standard '<prefix>.lora_down.weight' convention
If you control the file, strip foreign keys (optimizer states, 'alpha' mismatches) leaving only recognized pairs

Example fix

# before: incomplete key set in file: model.diff_model.x.lora_up.weight without lora_down.weight

# after: sanitize the safetensors so every lora_up has its lora_down pair
from safetensors.torch import load_file, save_file
sd = load_file('bad.safetensors')
clean = {k: v for k, v in sd.items() if '.lora_down.weight' in k or '.lora_up.weight' in k or 'alpha' in k}
ups = {k.rsplit('.lora_up.weight',1)[0] for k in clean if '.lora_up.weight' in k}
downs = {k.rsplit('.lora_down.weight',1)[0] for k in clean if '.lora_down.weight' in k}
clean = {k: v for k, v in clean.items() if k.rsplit('.',2)[0] in (ups & downs) or 'alpha' in k}
save_file(clean, 'clean.safetensors')

Defensive patterns

Strategy: try-catch

Validate before calling

# pre-check the file's key set before load
from safetensors import safe_open
SUFFIX_SETS = [('lora_down.weight','lora_up.weight'), ('hada_w1_a','hada_w1_b','hada_w2_a','hada_w2_b')]
def lora_keys_plausible(path):
    keys = []
    with safe_open(path, framework='pt') as f:
        keys = list(f.keys())
    for down, up in SUFFIX_SETS:
        if any(k.endswith(down) for k in keys) and any(k.endswith(up) for k in keys):
            return True
    return False

Try / catch

try:
    net = networks.load_networks(shared.sd_model, [network_on_disk])
except AssertionError as e:
    if 'Could not find a module type' in str(e):
        quarantine(corrupt_lora_path)  # move aside, notify user, continue batch
    else:
        raise

Prevention

Re-download LoRAs from the original source rather than trusting cached files
Validate safetensors integrity (hash) before adding to the models/LoRA folder
Update webui when adopting LoRAs from new trainer versions

When it happens

Trigger: A LoRA file with partially corrupt or truncated key sets, e.g. lora_up.weight present but lora_down.weight missing so every module type returns None; keys for exotic algorithms (e.g. LoCon variants, DyLoRA 'dyn_up'/'dyn_down') from a newer/older trainer than the webui understands; a file where extra non-standard suffix keys got grouped with the LoRA keys.

Common situations: Downloading a LoRA produced by a newer trainer (kohya-ss with new algorithms like LoRA-FA,dora components) while running an older webui; interrupted downloads leaving half-written safetensors; merging tools that emit non-standard key names; mismatches after webui extension updates.

Related errors

AI-assisted analysis of AUTOMATIC1111/stable-diffusion-webui@82a973c043 (2026-08-14). Data as JSON: /api/errors/a4fa42084ca1e05a. Report an issue: GitHub.