Skip to content

Conversation

@Mr-Neutr0n
Copy link

Summary

Fixes #589

restore_lora() clones weights from data_restore but never deletes the attribute afterwards. Since merge_lora() stores data_restore on every weight tensor, each merge/restore cycle accumulates cloned tensor copies that are never freed, effectively doubling GPU/CPU memory usage over repeated cycles.

Changes:

  • Delete data_restore after restoring weights -- Added del curr_layer.weight.data_restore immediately after the weight restoration clone in restore_lora(). This frees the stored tensor copy so it can be garbage collected, preventing memory from accumulating across merge/restore cycles.

  • Fix misleading loop condition -- Changed while len(layer_infos) > -1: to while True: in both merge_lora() and restore_lora(). The original condition len(layer_infos) > -1 is always true (since len() is always >= 0), making it a disguised infinite loop. The loop already has explicit break logic when layer_infos is exhausted, so while True: accurately reflects the intended control flow.

Test plan

  • Verify that merge_lora() followed by restore_lora() correctly restores original weights (functional correctness preserved)
  • Verify that after restore_lora(), weight tensors no longer have the data_restore attribute (hasattr(layer.weight, 'data_restore') returns False)
  • Verify that repeated merge/restore cycles do not increase memory usage over time
  • Verify that a subsequent merge_lora() call after restore_lora() correctly re-creates data_restore (since hasattr check in merge_lora will be False again)

In restore_lora(), the data_restore attribute stored on weight tensors
was never cleaned up after restoring weights. Each merge/restore cycle
accumulated cloned tensor copies, effectively doubling GPU memory usage
over time.

Changes:
- Delete data_restore attribute after restoring weights in restore_lora()
  to free the stored tensor copy immediately
- Fix misleading loop condition `while len(layer_infos) > -1` (always
  true since len() >= 0) to `while True` in both merge_lora() and
  restore_lora(), relying on the existing explicit break logic

Fixes modelscope#589
@gemini-code-assist
Copy link

Summary of Changes

Hello @Mr-Neutr0n, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a significant memory leak issue within the LoRA merging and restoration process by ensuring that temporary weight data is properly released. It also improves code readability by clarifying the intent of an infinite loop structure. These changes enhance the stability and efficiency of LoRA operations, particularly in scenarios involving multiple merge/restore cycles.

Highlights

  • Memory Leak Fix: Implemented deletion of the data_restore attribute after weight restoration in restore_lora() to prevent accumulation of cloned tensors and mitigate memory leaks during repeated LoRA merge/restore cycles.
  • Loop Condition Clarity: Modified the while loop condition in both merge_lora() and restore_lora() from len(layer_infos) > -1 to True to accurately reflect the intended infinite loop with explicit break statements.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Changelog
  • facechain/merge_lora.py
    • Updated the while loop condition in the merge_lora function for better clarity.
    • Updated the while loop condition in the restore_lora function for better clarity.
    • Added a line to explicitly delete the data_restore attribute after restoring weights in the restore_lora function to prevent memory accumulation.
Activity
  • No specific activity (comments, reviews, progress) has been recorded for this pull request yet.
Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature Command Description
Code Review /gemini review Performs a code review for the current pull request in its current state.
Pull Request Summary /gemini summary Provides a summary of the current pull request in its current state.
Comment @gemini-code-assist Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help /gemini help Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

  1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution.

Copy link

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

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 introduces two key improvements. Firstly, it addresses a memory leak in restore_lora by ensuring the data_restore attribute on weight tensors is deleted after the weights are restored. This prevents memory from accumulating across repeated merge and restore cycles. Secondly, it improves code readability by replacing a confusing while len(layer_infos) > -1: loop condition with a more explicit while True:, which accurately reflects the loop's control flow. The changes are correct and well-targeted. Overall, this is a good pull request that improves both correctness and maintainability.

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.

FACT版本疑似内存泄露

1 participant