[bug]: Z-Image, Qwen-Image and Anima LoRA converters ignore `.alpha` and drop DoRA magnitudes on lora_A/lora_B layers

快速结论：该问题出现在使用 InvokeAI 加载 Z-Image、Qwen-Image 或 Anima 的 LoRA 转换器（A/B 键 LoRA，即 lora_A/lora_B 键）时：如果 LoRA 文件把 .alpha 放在 lora_A/lora_B 键上，或文件包含 DoRA 幅度（.dora_scale、PEFT .lora_magnitude_vector[.weight]、ai-toolkit .magnitude），加载后会静默忽略 alpha 和 DoRA 幅度。优先排查文件是否属于这类键名结构，以及 InvokeAI 版本是否包含 .alpha、DoRA 修复。

适用环境：InvokeAI 手动开发版（manual dev checkout），main 分支提交 0ddc9df91b；操作系统 Windows；明确不依赖具体 GPU（可在 CPU 上复现）。Issue 未确认 Python、CUDA、PyTorch 版本，不补充。

最快修复方案：暂无确认的一步修复方案。按 Issue 状态，升级到包含 #10156（.alpha 修复）和 #10245（DoRA 幅度映射）的 InvokeAI 版本，可优先尝试。

注意事项：.alpha 与 DoRA 幅度最初是分两个 PR 修复的，#10156 只解决 alpha，#10245 才映射 DoRA 幅度。量化 transformer 方面，#10245 支持 int8/int4-convrot、nvfp4、fp8 的 DoRA，但 Bitsandbytes NF4 和 LLM.int8 仍不能跑 DoRA。评论中提到的 --bake-alpha 和 loraspectra 工具属于第三方变通做法，非 InvokeAI 官方修复，具体效果需自行验证。

问题场景

在 InvokeAI 中加载 Z-Image、Qwen-Image 或 Anima 基底的 LoRA 文件时触发。典型文件包括：ComfyUI 风格的 diffusion_model.* 键（Z-Image、Anima）、Qwen-Image 的裸原生键，以及这三种基底上的 A/B DoRA 文件。OneTrainer 默认 rank 16、alpha 1，如果这类文件加载后强度异常，会表现为高于训练强度。Issue 评论中还给出了一个真实 Anima DoRA 文件（rank 32、.alpha 为 16、带 dora_scale），加载后所有层都变成普通 LoRALayer、scale 为 1.0 而非 0.5。

报错原文

[bug]: Z-Image, Qwen-Image and Anima LoRA converters ignore `.alpha` and drop DoRA magnitudes on lora_A/lora_B layers

Z-Image    scale=1.0000 (expected 0.0625)  with dora_scale -> LoRALayer
Qwen-Image scale=1.0000 (expected 0.0625)  with dora_scale -> LoRALayer
...

not compatible with DoRA patches

其中 not compatible with DoRA patches 出现在量化 transformer 上；前两行是 Issue 复现脚本在 main 上的输出，说明 alpha 被替换为 rank 值、dora_scale 未生效。该问题多数情况下不抛异常，而是静默给出错误的强度或退化为普通 LoRA。

原因分析

以下路径在重建 A/B 层时只读取 lora_A.weight 和 lora_B.weight，并用函数参数 alpha（传入 None）替换层内原有的 alpha，于是 alpha 回落到 rank、缩放比变为 1：

z_image_lora_conversion_utils._get_lora_layer_values
qwen_image_lora_conversion_utils._normalize_lora_keys
anima_lora_conversion_utils._get_lora_layer_values

因此当训练 alpha 小于 rank 时，LoRA 会按 rank / alpha 倍过强应用。同时，dora_scale 和 PEFT 的 lora_magnitude_vector.weight 都被丢弃；_group_by_layer 中按 rsplit 分组的分支恰好能把 lora_magnitude_vector.weight 归到正确的层上，所以文件能正常加载，DoRA 幅度却被静默丢失。而 lora_down/lora_up 分支保留 alpha 和幅度，未带 .alpha 的 diffusers/PEFT 文件又把缩放折进了 lora_B，这些情况不受影响。

环境排查

确认 InvokeAI 版本/分支：Issue 基于 main 的 0ddc9df91b，需判断是否含 #10156 与 #10245。
确认 LoRA 文件的键名结构：是否为 lora_A/lora_B 形式，是否带 .alpha，是否带 .dora_scale、.lora_magnitude_vector[.weight] 或 .magnitude。
确认基底模型类型：Z-Image、Qwen-Image、Anima。
如使用量化 transformer，确认量化方式：int8/int4-convrot、nvfp4、fp8 在 #10245 后支持 DoRA；Bitsandbytes NF4 和 LLM.int8 仍不支持。
Issue 中未给出 Python、CUDA、PyTorch、显卡要求，无需作为排查项。

解决步骤

判断是否命中该问题：运行 Issue 中的复现脚本（构造带 .alpha 和可选 dora_scale 的 lora_A/lora_B 状态字典，调用 Z-Image、Qwen-Image、Anima 三个转换函数）。
检查输出：scale 若为 1.0000 而非预期的 0.0625，说明 .alpha 被忽略；带 dora_scale 的层若打印为 LoRALayer 而非 DoRA 层，说明 DoRA 幅度被丢弃。
升级 InvokeAI 到包含 #10156 的版本，先解决 .alpha 问题；再升级到包含 #10245 的版本，解决 DoRA 幅度映射及量化 transformer 的 DoRA 兼容问题。
使用真实文件交叉验证：例如 Issue 评论中的 Anima DoRA 文件，修复后应运行在 scale 0.5，而不是 1.0。
（可选，仅在无法升级时）可优先尝试在加载前将 .alpha 折算进 A/B 权重，并统一改写为 .alpha = rank，使忽略 alpha 的加载器也得到相同更新幅度；第三方工具 loraspectra 的 --bake-alpha 可做这一步，属于社区变通方案。
（可选，针对旧版本的 DoRA 键兼容）可优先尝试用第三方工具将 .magnitude 或 .lora_magnitude_vector.weight 改写为 .dora_scale，该做法来自评论中的第三方工具，非官方保证。

验证方法

重新运行复现脚本，确认 plain 层 scale 为 0.0625（alpha 1 / rank 16），带 dora_scale 的层输出为 DoRA 层类型而非 LoRALayer。再用真实文件加载：Anima 的 Cap sleeves 文件在 rank 32、alpha 16 下应显示 scale 0.5；在 Anima-2.9B 上分别以 bf16 和 int8_convrot 加载，确认 DoRA 幅度生效且量化路径不再报 not compatible with DoRA patches。