Repository navigation
fix: skip metadata alpha for LoRAs with baked_scale - #2202
Conversation
|
No actionable comments were generated in the recent review.
 |
| Layer / File(s) | Summary |
|---|---|
Condition alpha parsing on baked_scale src/model/adapter/lora.hpp |
init_params skips alpha metadata parsing when baked_scale is present. |
Priority:
Estimated code review effort: 2 (Simple) | ~5 minutes
Change: Bug fix
Suggested reviewers: leejet
Merge Risk: 
2598e
-
No concrete merge-blocking risk was established for this metadata handling change.
Pre-merge checks: 
-
Check name Status Explanation Resolution Docstring Coverage Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 1 files. Write docstrings for the functions missing them to satisfy the coverage threshold. -
Check name Status Explanation Title check The title "fix: skip metadata alpha for LoRAs with baked_scale" states the main change. The raw summary says LoraModel::init_params now skips parsing metadata alpha when baked_scale is present, which … Linked Issues check Check skipped because no linked issues were found for this pull request. Out of Scope Changes check Check skipped because no linked issues were found for this pull request. Description check The description follows the template's Summary, Related Issue / Discussion, Additional Information, and Checklist sections. It explains the problem: the LoRA loader applies file-level alpha metadata a… Full details: Title check
-
Explanation
The title "fix: skip metadata alpha for LoRAs with baked_scale" states the main change. The raw summary says LoraModel::init_params now skips parsing metadata alpha when baked_scale is present, which matches the title. The title is short, specific, and uses a conventional fix: prefix.
Full details: Description check
-
Explanation
The description follows the template's Summary, Related Issue / Discussion, Additional Information, and Checklist sections. It explains the problem: the LoRA loader applies file-level alpha metadata a second time when a converted LoRA already has alpha folded into lora_B and includes baked_scale. It names the affected file, the metadata values, the rank range, and the scope of the change (skip metadata alpha only when baked_scale is present). It gives hardware, model, settings, and before/after behavior, plus the contribution-guidelines box checked. Gaps: no screenshots or sample output are provided, and the author states they cannot attach the frames, so the visual result rests on a verbal description. The description also says a 'follow-up to
#2159' without a clear link to the issue. Those gaps are minor, so the description is mostly complete.
-
-
Finishing Touches
-
🧪 Generate unit tests (beta)
-
- Create a new PR
-
- Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
Comment @coderabbitai help to get the list of available commands.
|
Thanks. |
Summary
Since #2159 the LoRA loader uses the file-level
alphametadata when a tensor has no alpha or scale of its own. Some converted MiniMax-H3 LoRAs store bothalphaandbaked_scalein the metadata: the converter has already folded alpha / rank intolora_B(lora_up) and kept the originalalphaonly as a note. sd.cpp then appliesalpha / ranka second time.I hit this with
minimax_h3_ref2v_lightx2v_turbo_4step_v0.1_resized_avg_rank_20_bf16.safetensorsfrom Kijai/MiniMax-H3_comfy:alpha = 8,baked_scale = 0.0625,conversion = "... alpha folded into lora_B ...".alphatensors, ranks from 2 to 164 (the file is rank-resized)So every layer gets an extra factor of 8 / rank, anywhere between 0.05 and 4, and the video comes out broken.
Other files in the same repo with both keys:
minimax_h3_fl2v_lightx2v_turbo_4step_v1.0_768p_resized_avg_rank_31_bf16(alpha 128) andminimax_h3_fl2v_lightx2v_turbo_8step_v1.0_resized_avg_rank_24_bf16(alpha 8). LoRAs withoutbaked_scalebehave exactly as before.The change skips the metadata alpha only when
baked_scaleis present.Related Issue / Discussion
Follow-up to #2159.
Additional Information
Windows 11, GTX 1080 8 GB, CUDA 12.4. MiniMax-H3 Ref2VA Q3_K, Qwen3-VL-32B Q2_K_M text encoder, fp16 VAE, 320x576, 39 frames, seed 42,
--steps 4 --scheduler simple --cfg-scale 1 --params-backend disk --max-vram cuda0=6 -t 1, LoRA at 1.0.uses metadata alpha 8 when tensor alpha/scale is absent; the frames are smeared and the face is ghosted, with no clean frame in the clipI can't attach the frames: I'm in the EU, and the MiniMax-H3 license does not cover displaying its outputs from here. The difference is not subtle, though. On master no frame of the clip is usable, the face is smeared and doubled from start to end; with the fix it is a normal, sharp turbo video. Anyone outside the excluded territories can check it quickly with the Kijai file above and the settings listed here.
Timing is the same with and without the fix (sampling 180.7 s vs 181.5 s).
I found this while running an agentic research workflow (AI agents) aimed at making MiniMax-H3 faster on my GTX 1080, and the measurements were also taken with AI help.
Checklist