[bug]: Anima kohya LoRAs: layers outside the DiT blocks are not applied
Maintainers usually reply within 2 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 85/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- python, pytorch
- Domain
- backend, machine-learning
Research direction
Start in invokeai/backend/patches/lora_conversions/anima_lora_conversion_utils.py at _convert_kohya_unet_key (line 80). Read the function and the provided repro script to see which keys stay flattened. Add mapping for final_layer_linear, final_layer_adaln_modulation_1, t_embedder_1_linear_1, x_embedder_proj_1 to their dotted forms. Run the snippet to confirm the layers list matches the expected dotted names.
Written by the indexing model from the issue text.
Description
Is there an existing issue for this problem?
- I have searched the existing issues
Install method
Manual (dev checkout)
Operating system
Windows
GPU vendor
Not GPU-specific (reproduced on CPU)
GPU model
No response
GPU VRAM
No response
Version number
main at 0ddc9df91b
What happened
In an Anima kohya LoRA, the layers outside the DiT blocks are never applied. _convert_kohya_unet_key (invokeai/backend/patches/lora_conversions/anima_lora_conversion_utils.py:80) only un-flattens blocks_N_… (and the llm_adapter_ prefix). Every other key keeps its flattened name: final_layer_linear, final_layer_adaln_modulation_1/2, t_embedder_1_linear_1/2, x_embedder_proj_1. The resulting dotted patch never resolves them, and each one logs "Failed to find module for LoRA layer key".
The LoRA still loads and works, just without those layers. That makes it weaker than trained, and the only signal is the per-layer warnings.
What you expected to happen
Non-block kohya keys map to final_layer.linear, final_layer.adaln_modulation.1, t_embedder.1.linear_1, x_embedder.proj.1 and so on, as the block keys do. A kohya parsing tree like the Krea-2 one (kohya_key_utils) would cover them.
How to reproduce the problem
import torch
import invokeai.backend.model_manager.load # noqa: F401
from invokeai.backend.patches.lora_conversions.anima_lora_conversion_utils import lora_model_from_anima_state_dict
def lora(prefix: str) -> dict:
return {f"{prefix}.lora_down.weight": torch.randn(4, 64), f"{prefix}.lora_up.weight": torch.randn(64, 4)}
sd = {}
for k in ("blocks_0_self_attn_q_proj", "final_layer_linear", "final_layer_adaln_modulation_1", "t_embedder_1_linear_1", "x_embedder_proj_1"):
sd |= lora(f"lora_unet_{k}")
print(list(lora_model_from_anima_state_dict(sd, alpha=None).layers))
Output on main:
['lora_transformer-blocks.0.self_attn.q_proj', 'lora_transformer-final_layer_linear', 'lora_transformer-final_layer_adaln_modulation_1', 'lora_transformer-t_embedder_1_linear_1', 'lora_transformer-x_embedder_proj_1']
Additional context
In a LoRA trained on every layer these are 6 of 454 layers (about 1 % of the trained weights).
Found while checking every LoRA layout OneTrainer writes (b08db37) against main: OneTrainer's own savers run on meta-device models of the real architectures, then identification, LoRALoader and LayerPatcher module resolution on the InvokeAI model.
Discord username
No response
- Dominant language
- TypeScript
- Stars
- 28.8k
- Forks
- 3.1k
- Avg merge
- 3d 4h
- Merged PRs (30d)
- 161
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from invoke-ai/InvokeAI
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 2 days
-
bug
Difficulty 1/5 Under an hour Newbie friendliness 85/100
Maintainers usually reply within 2 days
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Maintainers usually reply within 2 days
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 2 days
-
[enhancement]: Bump PyPatchMatch to latestPossibly taken @dunkeroni claimed this 11 days ago. Openenhancement
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
invoke-ai/InvokeAI#9826 · 2 reactions · 1 assignee ·
Maintainers usually reply within 2 days
All issues in invoke-ai/InvokeAI
Similar issues
-
e2e-failure ready-to-code
Difficulty 2/5 1-3 hours Newbie friendliness 79/100
redhat-developer/rhdh-plugin-export-overlays#4580 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
devdotfast/whiteboard#1415 · 1 comment ·
Maintainers usually reply within 1 day
-
area/sessions comp/desktop desktop/sessions P2 type/bug
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
NousResearch/hermes-agent#145383 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
Maintainers usually reply within 1 day
-
enhancement p2 setup
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 1 day