Skip to content

[bugfix] fix multi-LoRA load assertion failure on idle adapter slots#136

Merged
Yunnglin merged 1 commit into
modelscope:mainfrom
Yunnglin:fix/multi-lora-load-missing-keys
Jun 25, 2026
Merged

[bugfix] fix multi-LoRA load assertion failure on idle adapter slots#136
Yunnglin merged 1 commit into
modelscope:mainfrom
Yunnglin:fix/multi-lora-load-missing-keys

Conversation

@Yunnglin

@Yunnglin Yunnglin commented Jun 25, 2026

Copy link
Copy Markdown
Contributor

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). When load() is called to reload a checkpoint, the missing_keys assertion in GPTBridge._set_module() incorrectly checks ALL LoRA-related keys, causing an AssertionError because idle slots (lora_1 - lora_4) are naturally not in the checkpoint.

AssertionError: incompatible_keys.missing_keys: ['blocks.0.attn.qkv.lora_A.lora_1.weight', ...]

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:

missing_keys = [
    k for k in incompatible_keys.missing_keys
    if '.lora_A.' in k or '.lora_B.' in k or '.modules_to_save.' in k
]

Fix

Add f'.{self._adapter_name}.' in k to only validate keys belonging to the current adapter slot being loaded:

missing_keys = [
    k for k in incompatible_keys.missing_keys
    if ('.lora_A.' in k or '.lora_B.' in k or '.modules_to_save.' in k)
    and f'.{self._adapter_name}.' in k
]

This is safe because:

  • Each adapter is saved/loaded independently
  • self._adapter_name identifies the target slot (e.g. lora_0)
  • If the checkpoint is incomplete for the target adapter, the assert still fires correctly
  • Idle slots being absent from checkpoint is expected behavior, not an error

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

Affected Versions

Tested on mcore-bridge 1.1.0 ~ 1.5.1 (logic unchanged across versions).

Copilot AI review requested due to automatic review settings June 25, 2026 04:25

@gemini-code-assist gemini-code-assist Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread src/mcore_bridge/bridge/gpt_bridge.py

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 PEFT missing_keys filtering to validate only keys for self._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.

Comment thread src/mcore_bridge/bridge/gpt_bridge.py
@Yunnglin Yunnglin force-pushed the fix/multi-lora-load-missing-keys branch from 326d6ec to ca7d56c Compare June 25, 2026 04:29
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
@Yunnglin Yunnglin force-pushed the fix/multi-lora-load-missing-keys branch from ca7d56c to fcfb24a Compare June 25, 2026 04:33
@Yunnglin Yunnglin merged commit 141776e into modelscope:main Jun 25, 2026
1 check passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants