[bugfix] fix multi-LoRA load assertion failure on idle adapter slots#136
Conversation
There was a problem hiding this comment.
Code Review
This pull request modifies the checkpoint loading logic in gpt_bridge.py to only validate missing keys for the active adapter when in multi-LoRA mode. The reviewer identified a potential issue where the substring check for the adapter name could cause false positives (e.g., matching layer indices if the adapter name is a number) and suggested a more robust check that explicitly targets the PEFT suffix structures.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
There was a problem hiding this comment.
Pull request overview
Fixes a false AssertionError when reloading PEFT/LoRA checkpoints in multi-adapter (multi-slot) setups by narrowing the missing_keys assertion to only the adapter slot being loaded, rather than all idle adapter slots.
Changes:
- Update
_set_module()’s PEFTmissing_keysfiltering to validate only keys forself._adapter_name. - Add clarifying comments explaining expected missing keys for idle LoRA slots during load.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
326d6ec to
ca7d56c
Compare
In multi-LoRA mode (e.g. 5 slots: lora_0~lora_4), save() only persists the active adapter (lora_0). When load() is called, the missing_keys check incorrectly asserts that ALL LoRA slots must be present in the checkpoint, causing an AssertionError for idle slots (lora_1~4). Fix: narrow the missing_keys filter to only validate keys belonging to the current adapter slot (self._adapter_name), since other slots being absent from the checkpoint is expected behavior. Reproduction: 1. Start Megatron backend with multi-LoRA config (5 slots) 2. Train and call model.save(name) 3. Call model.load(name) -> AssertionError on lora_1~4 missing keys
ca7d56c to
fcfb24a
Compare
Problem
In multi-LoRA mode (e.g. 5 adapter slots:
lora_0-lora_4),save()only persists the active adapter's weights (e.g.lora_0). Whenload()is called to reload a checkpoint, themissing_keysassertion inGPTBridge._set_module()incorrectly checks ALL LoRA-related keys, causing anAssertionErrorbecause idle slots (lora_1-lora_4) are naturally not in the checkpoint.Root Cause
The filter at line 273-276 only checks if a key contains
.lora_A./.lora_B./.modules_to_save., but does not distinguish between the adapter being loaded vs other idle slots:Fix
Add
f'.{self._adapter_name}.' in kto only validate keys belonging to the current adapter slot being loaded:This is safe because:
self._adapter_nameidentifies the target slot (e.g.lora_0)Reproduction
model.save(name)model.load(name)-> AssertionError on lora_1~4 missing keysAffected Versions
Tested on mcore-bridge 1.1.0 ~ 1.5.1 (logic unchanged across versions).