-
-
Notifications
You must be signed in to change notification settings - Fork 16.3k
Log KV cache GiB usage and warn when max_num_seqs exceeds capacity #38408
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
Open
ashishkamra
wants to merge
1
commit into
vllm-project:main
Choose a base branch
from
ashishkamra:log-kv-cache-memory-gib
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The calculation for
_blocks_per_requestseems incorrect for models with multiple KV cache groups (e.g., hybrid models). It appears to returnnum_groups * cdiv(max_model_len, block_size)instead of justcdiv(max_model_len, block_size).This will cause
get_max_concurrency_for_kv_cache_configto underestimate the maximum concurrency by a factor ofnum_groups, and the new logging forneeded_kv_byteswill overestimate the required memory by the same factor.The number of blocks required for a sequence should be independent of the number of KV cache groups, as blocks from the pool are allocated per sequence, and each block from the pool serves all groups (via memory sharing across layers).
A simpler and more correct implementation would calculate the blocks needed per layer for a single sequence, assuming all groups share the same block size.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I double-checked this path, and the current _blocks_per_request math is intentional for hybrid KV configs.
In vLLM, blocks are consumed per KV cache group for a request, so for hybrid models the request block demand is the sum across groups (e.g., full-attn blocks + sliding-window blocks), not just cdiv(max_model_len, block_size) from one representative group.
That is why _blocks_per_request computes:
which simplifies to cdiv(sum_group_memory, page_size) (the num_layer_per_group factor cancels). This preserves existing concurrency semantics.
There is an existing test that reflects this behavior:
tests/v1/core/test_kv_cache_utils.py:1405 (kv_cache_config_hybrid_model) expects concurrency 3 for num_blocks=(1024 + 129) * 3, i.e., blocks/request is 1024 + 129, not 1024.
Also, the recent fix in this PR separates byte accounting for logging (_kv_cache_bytes_per_block) so UniformType no longer overcounts GiB, while keeping concurrency math unchanged.