LoKR adapter loads successfully but has no effect (silent key mismatch in _load_lokr_adapter)

[koda-dernet]

Describe the bug

When loading a LoKR (LyCORIS) adapter via the Gradio UI, the adapter appears to load successfully (user sees "LoKr loaded from ...") but the generated audio is identical to the base model -- the adapter has no audible effect.

The root cause is in _load_lokr_adapter() in acestep/core/generation/handler/lora/lifecycle.py (line 120):

lycoris_net.apply_to()
decoder._lycoris_net = lycoris_net
lycoris_net.load_weights(weights_path)   # <-- return value ignored
return lycoris_net

lycoris_net.load_weights() returns information about matched/unmatched keys, but the return value is completely discarded. If keys in the saved weights file do not match the freshly created LyCORIS network (due to LyCORIS version differences, module naming differences, etc.), all weights silently fail to load. The adapter structure is injected (hooks are installed via apply_to()), but all parameters remain at their initialization values -- which for LoKR means effectively an identity transformation (no visible effect on output).

No warning or error is logged. The user sees the success message and has no indication anything went wrong.

To Reproduce

1. Train a LoKR adapter using a training tool (e.g., Side-Step) that uses a different LyCORIS version or environment
2. Load the trained lokr_weights.safetensors in the Gradio UI via the "Load LoRA" button
3. Generate audio -- output is unchanged from base model
4. The UI shows a green success message

Expected behavior

• If load_weights() fails to match any/most keys, a warning should be logged and the user should be notified that the adapter weights were not loaded
• Ideally, the number of matched vs expected keys should be logged (e.g., "Loaded 0/128 LoKR weight keys -- adapter may have no effect")

Suggested fix

Check the return value of lycoris_net.load_weights() and log diagnostics:

load_result = lycoris_net.load_weights(weights_path)

# LyCORIS load_weights returns info about matched keys
expected = len(list(lycoris_net.parameters()))
if expected > 0:
    logger.info(f"LoKr weights loaded from {weights_path} ({expected} parameters)")

# If load_result indicates mismatches, warn the user
if load_result and hasattr(load_result, '__len__') and len(load_result) == 0:
    logger.warning(
        f"LoKr load_weights matched 0 keys from {weights_path} -- "
        "the adapter will have no effect. Check LyCORIS version compatibility."
    )

Desktop (please complete the following information):

• OS: Linux (Ubuntu 24.04)
• Python: 3.12
• LyCORIS: 3.0.1.post2
• CUDA: 12.8

Additional context

The _load_lokr_config() function (lines 26-64 in the same file) also has extensive silent fallback behavior -- if metadata parsing fails for any reason, it returns a default LoKRConfig() without warning the user. This could compound the issue if the config doesn't match what was used during training.

Related: the LoRA (PEFT) loading path at line 201 uses PeftModel.from_pretrained() which handles key matching internally and would raise on mismatches, so this issue is specific to the LoKR/LyCORIS path.

[coderabbitai]

🔗 Related PRs

#530 - Support local LoKr safetensors in adapter loader [merged]
#571 - Enable multi-LoRA stacking with per-adapter scaling (addresses #338) [merged]
#583 - fix: differentiate LoRA adapters in UUID and load LM codes on JSON im… [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!