allow loras to be implicitly evicted and loaded based on max_loaded_loras

[glenliu21]

Motivation

This PR implements the feature in #10266.

Modifications

This PR introduces two new features:

• max_loaded_loras is no longer a hard limit. That is, if a LoRA adapter is loaded and causes the limit to be exceeded, then the LRU LoRA adapter will be evicted. Furthermore, pinned LoRA adapters can't be implicitly evicted.
• Now that LoRA adapters can be implicitly evicted, to be consistent I also added functionality for LoRA adapters to be implicitly loaded. That is, if generate is called with a LoRA adapter that was previously loaded but now evicted, it will be reloaded. Note that LoRA adapters that haven't been explicitly loaded and then unloaded cannot be implicitly loaded.

Accuracy Tests

Modified existing tests and added new unit tests.

Checklist

• Format your code according to the Format code with pre-commit.
• Add unit tests according to the Run and add unit tests.

[gemini-code-assist]

Summary of Changes

Hello @glenliu21, I'm Gemini Code Assist¹! 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 introduces a dynamic LoRA adapter management system that allows for implicit eviction and reloading of LoRAs based on usage and a configurable maximum loaded limit. This change aims to improve resource utilization and flexibility by transforming the max_loaded_loras setting from a strict limit into a dynamic cache size, ensuring that frequently used LoRAs are readily available while less used ones are swapped out as needed.

Highlights

• Implicit LoRA Eviction: The max_loaded_loras limit is no longer a hard constraint. If loading a new LoRA adapter exceeds this limit, the Least Recently Used (LRU) LoRA adapter will be automatically evicted to make space. Pinned LoRA adapters are exempt from this implicit eviction.
• Implicit LoRA Loading: LoRA adapters that were previously loaded and then implicitly evicted can now be automatically reloaded when a generate call requests them. This ensures a seamless experience for users without requiring explicit re-loading.
• LRU Cache Implementation: The internal LoRA registry now uses an OrderedDict to maintain the LRU order, facilitating efficient identification and eviction of the least recently used adapters.
• Enhanced Test Coverage: Existing unit tests have been modified, and new tests added, to thoroughly validate the implicit eviction and reloading mechanisms, including scenarios involving pinned LoRA adapters and max_loaded_loras limits.

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. ↩

[gemini-code-assist]

Code Review

This pull request introduces an LRU caching mechanism for LoRA adapters, allowing them to be implicitly evicted and reloaded based on the max_loaded_loras setting. The changes are mostly well-implemented, using an OrderedDict for LRU tracking and adding logic for eviction and implicit reloading. I've found a critical issue in the eviction logic that could lead to exceeding the configured maximum number of loaded LoRAs. Additionally, there are some debug log statements that should be removed from the production code. The tests have been updated to cover the new functionality, which is great.

[glenliu21]

/gemini review

[gemini-code-assist]

Warning

You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again!

[glenliu21]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces a valuable feature for managing LoRA adapters by allowing them to be implicitly evicted and reloaded based on an LRU policy and a max_loaded_loras limit. The implementation is well-structured, using an OrderedDict for the LRU cache and refactoring the adapter loading/unloading logic for clarity and reuse. The accompanying tests are thorough and cover various scenarios, including eviction, reloading, and handling of pinned adapters, which is excellent.

My main feedback is to address a potential race condition in the implicit reloading logic within generate_request. I've provided a specific suggestion to make the implementation more robust by handling the return value of load_lora_adapter.

[glenliu21]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces implicit LoRA adapter eviction and loading based on max_loaded_loras. It modifies LoRARegistry to use an OrderedDict for LRU management, adds methods for finding unregistered LoRAs and identifying the LRU LoRA, and updates TokenizerManager to handle implicit loading and unloading. The changes also include modifications to existing tests and the addition of new unit tests to ensure the correctness of the new features. I have provided review comments to address potential issues and improve the code.

[lifuhuang]

x-posting one open topic from our Slack thread:

I think the change is reasonable, however, one part I have been debating myself is regarding where we should implement the eviction logic -- should it be in main process (tokenizer process) or TP worker process.
For GPU eviction, the LRU logic is introduced by @Connor Li in TP worker.
For CPU eviction (in your PR), the LRU logic is in tokenizer process.
This is unideal because it introduced duplication in code/logic. Ideally we should have a single LRU logic and generalize it such that it can handle for both CPU and GPU. But at the same time, I am also aware that this MIGHT be a price we have to pay to sacrifice aesthetic value for better perf (I believe a large portion of the complexity was introduced by my prev change to support async lora loading 😐)
I was hoping to think more carefully about this and see if we can find a design that to some extent achieve both maintainability and perf, but I haven't got a chance to really think it through

Perhaps we can continue our discussion in Slack.