[Misc] Recompute scheduler upgrade to vLLM 0.18.0#7675
[Misc] Recompute scheduler upgrade to vLLM 0.18.0#7675yiz-liu merged 3 commits intovllm-project:mainfrom
Conversation
Summary of ChangesHello, 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 focuses on upgrading the Highlights
🧠 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. Using Gemini Code AssistThe 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
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 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. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request refactors the RecomputeScheduler to improve handling of waiting requests, particularly for asynchronous KV transfers and paused states. It introduces a new skipped_waiting queue and a more robust mechanism for promoting blocked requests, while also updating the _update_waiting_for_remote_kv method and adding logic for PauseState. The encoder cache allocation logic for encoder-decoder models has been refined by correctly calculating num_encoder_tokens for waiting requests. However, a critical bug was identified where the num_encoder_tokens calculation for cross-attention block allocation is missing for RUNNING requests, which will lead to incorrect KV cache allocation in encoder-decoder models and needs to be addressed.
| # Determine if we need to allocate cross-attention blocks. | ||
| num_encoder_tokens = 0 | ||
| if ( | ||
| self.is_encoder_decoder | ||
| and request.has_encoder_inputs | ||
| and encoder_inputs_to_schedule | ||
| ): | ||
| num_encoder_tokens = sum( | ||
| request.get_num_encoder_embeds(i) | ||
| for i in encoder_inputs_to_schedule | ||
| ) |
There was a problem hiding this comment.
The logic to calculate num_encoder_tokens for cross-attention block allocation has been added for WAITING requests. However, this same logic is missing for RUNNING requests. The allocate_slots call for running requests (around line 327) is not passed num_encoder_tokens. This will result in incorrect KV cache allocation for running requests in encoder-decoder models. A similar logic to calculate and pass num_encoder_tokens should be added for the RUNNING requests loop to fix this bug.
|
👋 Hi! Thank you for contributing to the vLLM Ascend project. The following points will speed up your PR merge:
If CI fails, you can run linting and testing checks locally according Contributing and Testing. |
<!-- Thanks for sending a pull request! BEFORE SUBMITTING, PLEASE READ https://docs.vllm.ai/en/latest/contributing/overview.html --> ### What this PR does / why we need it? cherry-pick from #7675 . The current RecomputeScheduler is aligned to Scheduler in vLLM v0.16.0. Since upstream vLLM has upgraded to v0.18.0, we also need to upgrade RecomputeScheduler to pick up missing updates. ### Does this PR introduce _any_ user-facing change? <!-- Note that it means *any* user-facing change including all aspects such as API, interface or other behavior changes. Documentation-only updates are not considered user-facing changes. --> ### How was this patch tested? <!-- CI passed with new added/existing test. If it was tested in a way different from regular unit tests, please clarify how you tested step by step, ideally copy and paste-able, so that other reviewers can test and check, and descendants can verify in the future. If tests were not added, please describe why they were not added and/or why it was difficult to add. --> --------- Signed-off-by: Angazenn <supperccell@163.com>
What this PR does / why we need it?
The current RecomputeScheduler is aligned to Scheduler in vLLM v0.18.0. Since upstream vLLM has upgraded to v0.18.0, we also need to upgrade RecomputeScheduler to pick up missing updates.
Does this PR introduce any user-facing change?
How was this patch tested?