Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[V1] Do not allocate beyond the max_model_len #10730

Merged
merged 3 commits into from
Nov 28, 2024
Merged

Conversation

WoosukKwon
Copy link
Collaborator

This PR fixes a bug in V1 KV cache manager that allocates more than max_model_len // block_size blocks for a request. This is not only inefficient but also illegal because the block table has a fixed shape of [max_num_reqs, max_model_len // block_size].

Copy link

👋 Hi! Thank you for contributing to the vLLM project.
Just a reminder: PRs would not trigger full CI run by default. Instead, it would only run fastcheck CI which starts running only a small and essential subset of CI tests to quickly catch errors. You can run other CI tests on top of those by going to your fastcheck build on Buildkite UI (linked in the PR checks section) and unblock them. If you do not have permission to unblock, ping simon-mo or khluu to add you in our Buildkite org.

Once the PR is approved and ready to go, your PR reviewer(s) can run CI to test the changes comprehensively before merging.

To run CI, PR reviewers can do one of these:

  • Add ready label to the PR
  • Enable auto-merge.

🚀

Copy link
Collaborator

@comaniac comaniac left a comment

Choose a reason for hiding this comment

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

Otherwise LGTM. Also where do we reject too long requests? Seems like the scheduler doesn't do that?

vllm/v1/core/kv_cache_manager.py Show resolved Hide resolved
vllm/v1/core/kv_cache_manager.py Show resolved Hide resolved
@WoosukKwon
Copy link
Collaborator Author

where do we reject too long requests? Seems like the scheduler doesn't do that?

@comaniac You're right. V1 doesn't have it now.

@comaniac
Copy link
Collaborator

where do we reject too long requests? Seems like the scheduler doesn't do that?

@comaniac You're right. V1 doesn't have it now.

I see. We could add that later. Meanwhile could you add a TODO in this PR as a reminder?

Signed-off-by: Woosuk Kwon <[email protected]>
@WoosukKwon
Copy link
Collaborator Author

I see. We could add that later. Meanwhile could you add a TODO in this PR as a reminder?

@comaniac Good point. Added. PTAL.

@WoosukKwon WoosukKwon requested a review from comaniac November 28, 2024 04:30
@WoosukKwon WoosukKwon added the ready ONLY add when PR is ready to merge/full CI is needed label Nov 28, 2024
Signed-off-by: Woosuk Kwon <[email protected]>
@WoosukKwon WoosukKwon enabled auto-merge (squash) November 28, 2024 06:47
@WoosukKwon WoosukKwon disabled auto-merge November 28, 2024 08:13
@WoosukKwon WoosukKwon merged commit a79b122 into main Nov 28, 2024
44 of 46 checks passed
@WoosukKwon WoosukKwon deleted the v1-fix-mem-alloc branch November 28, 2024 08:13
afeldman-nm pushed a commit to neuralmagic/vllm that referenced this pull request Dec 2, 2024
sleepwalker2017 pushed a commit to sleepwalker2017/vllm that referenced this pull request Dec 13, 2024
BKitor pushed a commit to BKitor/vllm that referenced this pull request Dec 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready ONLY add when PR is ready to merge/full CI is needed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants