-
-
Notifications
You must be signed in to change notification settings - Fork 8.7k
[V1] Partial prefill skip for layers reusing shared KV cache #19719
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
base: main
Are you sure you want to change the base?
Conversation
Warning You have reached your daily quota limit. Please wait up to 24 hours and I will start processing your requests again! |
👋 Hi! Thank you for contributing to the vLLM project. 💬 Join our developer Slack at https://slack.vllm.ai to discuss your PR in #pr-reviews, coordinate on features in #feat- channels, or join special interest groups in #sig- channels. Just a reminder: PRs would not trigger full CI run by default. Instead, it would only run 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 either: Add 🚀 |
My concern is whether this optimization is too model specific. It works for models that the first k layers have kv cache. Does it work for models that every m layers share the same kv cache like Hunyuan? |
It only works for the case where the first k layers have kv cache as you said. For general KV sharing cases, it should also apply for last N layers that reuse the KV cache (ie there are no other layers afterwards that have its own KV cache). So I agree it will not apply to a majority of models, but then I'm not sure if there is a better way to implement this kind of functionality. |
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 took a quick pass on this PR.
And I'm curious about your plan to support piecewise cuda graph. We need cuda graph for num_total_tokens in the first few layers, and num_decode_tokens in the following layers.
vllm/envs.py
Outdated
@@ -128,6 +128,7 @@ | |||
VLLM_TOOL_PARSE_REGEX_TIMEOUT_SECONDS: int = 1 | |||
VLLM_SLEEP_WHEN_IDLE: bool = False | |||
VLLM_MQ_MAX_CHUNK_BYTES_MB: int = 16 | |||
VLLM_V1_KV_SHARING_SKIP_PREFILL: bool = False |
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 prefer to add it as a cli arg.
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.
done
@@ -602,6 +620,11 @@ def forward( | |||
# Profiling run. | |||
return output | |||
|
|||
if (self.kv_sharing_target_layer_name is not None |
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.
This branch is not true for hunyuan-style kv sharing.
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.
added logic to detect which layers are 'eligible' for this prefill skip optimization
This pull request has merge conflicts that must be resolved before it can be |
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 would really like to try to keep build
signature of the metadata builders as simple as possible so hopefully we can create some nice unit testing infrastructure in the future. Do we really need to add decode_only_common_attn_metadata
to the build
call signature? can we make the kv sharing layers a different KVSpec and have separate build calls at this level:
vllm/vllm/v1/worker/gpu_model_runner.py
Lines 691 to 709 in 257ab95
for kv_cache_group_id, kv_cache_group_spec in enumerate( | |
self.kv_cache_config.kv_cache_groups): | |
# Prepare for cascade attention if enabled & beneficial. | |
common_prefix_len = 0 | |
builder = self.attn_metadata_builders[kv_cache_group_id] | |
if self.cascade_attn_enabled: | |
common_prefix_len = self._compute_cascade_attn_prefix_len( | |
num_scheduled_tokens, | |
scheduler_output. | |
num_common_prefix_blocks[kv_cache_group_id], | |
kv_cache_group_spec.kv_cache_spec, | |
builder, | |
) | |
attn_metadata_i = (builder.build( | |
common_prefix_len=common_prefix_len, | |
common_attn_metadata=common_attn_metadata, | |
)) |
we should probably be doing this for local attention too but that was added before we had the hybrid-KV cache (which enabled different build calls for different layer groups). We should probably migrate local attention to a scheme like this too
self, | ||
common_prefix_len: int, | ||
common_attn_metadata: CommonAttentionMetadata, | ||
decode_only_common_attn_metadata: Optional[ |
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.
is there a reason we need to pass decode_only_common_attn_metadata
as a separate arg; is there a reason we can't just use a different build
call at the gpu model runner level? i.e. here-ish:
vllm/vllm/v1/worker/gpu_model_runner.py
Lines 691 to 709 in 257ab95
for kv_cache_group_id, kv_cache_group_spec in enumerate( | |
self.kv_cache_config.kv_cache_groups): | |
# Prepare for cascade attention if enabled & beneficial. | |
common_prefix_len = 0 | |
builder = self.attn_metadata_builders[kv_cache_group_id] | |
if self.cascade_attn_enabled: | |
common_prefix_len = self._compute_cascade_attn_prefix_len( | |
num_scheduled_tokens, | |
scheduler_output. | |
num_common_prefix_blocks[kv_cache_group_id], | |
kv_cache_group_spec.kv_cache_spec, | |
builder, | |
) | |
attn_metadata_i = (builder.build( | |
common_prefix_len=common_prefix_len, | |
common_attn_metadata=common_attn_metadata, | |
)) |
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.
yea I initially had a separate build()
call at the model runner level, but I needed to set this as a property of attention metadata for all different backends, and they don't share a common schema. So I thought I could pass the info and let each backend decide what to do with it.
But I do agree that your approach is a better abstraction, will follow up on that
vllm/v1/worker/gpu_model_runner.py
Outdated
decode_only_common_attn_metadata = None | ||
if envs.VLLM_V1_KV_SHARING_SKIP_PREFILL: | ||
decode_only_common_attn_metadata = ( | ||
compute_decode_only_common_attn_metadata( |
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.
should we move this logic into metadata builder?
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.
moved this logic to flash attn metadata builder
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.
sorry I think I missed this so not sure what the code looked like at this point but I think ideally we would keep this common metadata manipulation outside of the metadata builders so we can naturally just support all the backends (assuming we can keep a clean build interface). This is important for blackwell where FlashInfer has the best perf. I actually want to do something similar for local-attention since that could also be done via pure CommonAttentionMetadata manipulation and would enable iRoPe for FlashInfer.
see: #19719 (comment)
541f2a5
to
a9783c3
Compare
@LucasWilkinson @heheda12345 ready for a review! |
@@ -196,16 +198,83 @@ def __init__(self, runner: "GPUModelRunner", kv_cache_spec: AttentionSpec, | |||
# populated on first build() call. | |||
self.aot_sliding_window: Optional[tuple[int, int]] = None | |||
|
|||
def build_skip_prefill( |
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.
seems like this could be a common utility function that operates on CommonAttentionMetadata
generically instead of inside FlashAttentionMetadataBuilder
; so we could make it generic for all attention backends
num_reqs = common_attn_metadata.num_reqs | ||
num_actual_tokens = common_attn_metadata.num_actual_tokens | ||
max_query_len = common_attn_metadata.max_query_len | ||
|
||
max_seq_len = int(self.runner.seq_lens_np[:num_reqs].max()) | ||
query_start_loc = common_attn_metadata.query_start_loc | ||
query_start_loc_np = common_attn_metadata.query_start_loc_np | ||
if query_start_loc_np is None: |
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.
nit: can we make this non-optional? not necessarily needed for this PR but id eventually like to break the dependency on the runner in the metadata builders
vllm/v1/attention/backends/utils.py
Outdated
@@ -43,6 +44,12 @@ class CommonAttentionMetadata: | |||
max_query_len: int | |||
"""Longest query in batch""" | |||
|
|||
decode_indices: Optional[torch.Tensor] = None | |||
"""indices used for decoding""" |
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.
Id prefer if we could keep CommonAttentionMetadata
cleaner; i.e. not have anything that is overly specific to given attention scheme/model. It will make attention unit testing and benchmarking a bit easier to setup
If it's possible I think id prefer for these layers to be part of different KVCacheSpec group; then we might be able to handle the prefill filtering at that level. i.e. we could do something like
for kv_cache_group_id, kv_cache_group_spec in enumerate(
self.kv_cache_config.kv_cache_groups):
....
builder = self.attn_metadata_builders[kv_cache_group_id]
common_attn_metadata_ = common_attn_metadata
if instance(kv_cache_group_spec, SharedKVSpec):
common_attn_metadata_ = filter_prefills(common_attn_metadata)
attn_metadata_i = (builder.build(
common_prefix_len=common_prefix_len,
common_attn_metadata=common_attn_metadata_,
))
Where filter_prefills
is basically build_skip_prefill
Something like this (maybe the KVCacheSpec is the right thing here and we should have an additional way to group attention layers but I think its reasonable) would allow us to be backend agnostic which will be important for Blackwell were we want to eventually default to FlashInfer
@heheda12345 do you have opinions on this?
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 agree. Then does this kv cache grouping strategy make sense @sarckk @LucasWilkinson
- Only send layers that has its own kv cache to
get_kv_cache_config
so that kv_cache_manager doesn't need to be aware of any kv sharing logic (Achieved by [V1] Support cross-layer KV sharing #18212) - On worker side, add layers with kv sharing but cannot enable this partial prefill skip optimization to the group that it shares kv with (Achieved by [V1] Support cross-layer KV sharing #18212) , as these layers should use the attention metadata without prefill skip.
- Create new kv cache groups for layers that enables this optimization as Lucas mentioned. Layers share kv with different kv cache groups should be put into different new groups.
In that case, this spec shouldn't be called SharedKVSpec but some thing more concrete for case 3.
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 think this makes sense
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.
Thanks for the great job! Added some comments.
self.residual[:num_decodes].copy_(first_residual[decode_indices]) | ||
self.hidden_states[:num_decodes].copy_( | ||
first_hidden_states[decode_indices]) | ||
positions[:num_decodes].copy_(positions[decode_indices]) | ||
|
||
second_hidden_states, second_residual = self.second_layer_group( | ||
positions[:num_decodes], | ||
self.hidden_states[:num_decodes], | ||
self.residual[:num_decodes], | ||
) |
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.
Agreed that we should avoid reimplementing these logic for each model.
As #18212 lacks an example, I believe people will refer to this test to implement new kv-sharing models. Therefore, if you want to left it to a future PR, can you:
- Add another model that uses kv-sharing logic but don't enable the optimization in this PR, to serve as an example that you suggest people to add a new model at this moment. It should also be a useful test.
- Add notes for it is WIP and don't copy the code here to a new model.
# NOTE(sarckk): Due to cudagraph padding, decode_indices may have | ||
# trailing repeated indices. Attention output is only valid at the | ||
# last index in this case. | ||
last_index_mask = decode_indices == decode_indices[-1] |
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.
Why is it valid at the last index? I think the output of the last batch is second_hidden_states[num_decode - 1].
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'm doing this because with CUDA graph capture, I'm padding num_decode
so they are aligned with the graph captures sizes here. For example, if the original decode_indices
was [0,19,22]
then we might pad it to [0,19,22,22]
where the last index is repeated for padding.
During attention, the index [22] would originally have any attention applied without any padding, e.g. for query_len of 1 and kv_len of 3, the masking (True
is the masked positions) might look like:
[False, False, False]
but with padded query [22,22], the causal mask would look like:
[[False, False, True],
[False, False, False]]
so only the last position gives the correct output. I also have a simple example in https://gist.github.com/sarckk/ffd59338994ca6f3863f0119aa09784d
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.
Thanks to piece-wise cuda graph, I think we only need to build attention metadata as if there is no padding as the attention part is executed in eager mode.
vllm/forward_context.py
Outdated
@@ -96,6 +96,9 @@ class ForwardContext: | |||
dp_metadata: Optional[DPMetadata] = None | |||
skip_cuda_graphs: bool = False | |||
|
|||
decode_indices: Optional[torch.Tensor] = None | |||
"""indices used for decoding""" |
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.
Can you find a better name? I think you want to include "the last prefill token" + "all decode tokens" in this tensor. And is it possible to hide it in the attention metadata for kv sharing?
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.
maybe generation_indices
? although the value is equal to logits_indices
right now, I wanted to differentiate it from logits_indices
as generation_indices
eventually would not contain the last token for partial prefill chunks while logits_indices
does.
what do you mean by hiding it in attention metadata for kv sharing?
) -> FlashAttentionMetadata: | ||
prefill_skipped_attn_metadata = None | ||
if common_attn_metadata.decode_indices is not None: |
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.
if common_attn_metadata.decode_indices is not None: | |
if self.cache_config.kv_sharing_skip_prefill: |
Prefer this straight-forward condition.
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.
we need the original condition because common_attn_metadata.decode_indices
may still be None
even if kv_sharing_skip_prefill
is set, if all requests are on decode
@@ -435,6 +505,8 @@ def __init__( | |||
raise NotImplementedError( | |||
"FlashAttention does not support fp8 kv-cache on this device.") | |||
|
|||
self.kv_sharing_skip_prefill = False |
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.
Add a note on it may be updated to True
by gpu model runner. And can we remove this after putting these layers to a different kv cache group?
vllm/v1/attention/backends/utils.py
Outdated
@@ -43,6 +44,12 @@ class CommonAttentionMetadata: | |||
max_query_len: int | |||
"""Longest query in batch""" | |||
|
|||
decode_indices: Optional[torch.Tensor] = None | |||
"""indices used for decoding""" |
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 agree. Then does this kv cache grouping strategy make sense @sarckk @LucasWilkinson
- Only send layers that has its own kv cache to
get_kv_cache_config
so that kv_cache_manager doesn't need to be aware of any kv sharing logic (Achieved by [V1] Support cross-layer KV sharing #18212) - On worker side, add layers with kv sharing but cannot enable this partial prefill skip optimization to the group that it shares kv with (Achieved by [V1] Support cross-layer KV sharing #18212) , as these layers should use the attention metadata without prefill skip.
- Create new kv cache groups for layers that enables this optimization as Lucas mentioned. Layers share kv with different kv cache groups should be put into different new groups.
In that case, this spec shouldn't be called SharedKVSpec but some thing more concrete for case 3.
This pull request has merge conflicts that must be resolved before it can be |
May be unrelated to this PR. We also need an elegant way to skip preparing kv for layers that don't need them.
|
@sarckk Here is a PR for v0 YOCO optimization. #20702 Though it is simplified due to ignoring chunked prefill and cuda graph, you can take a look and check whether there are anything you can learn. vllm/vllm/attention/backends/differential_flash_attn.py Lines 757 to 999 in 875e85b
vllm/vllm/model_executor/models/phi4flash.py Lines 561 to 571 in 875e85b
|
Signed-off-by: Yong Hoon Shin <yhshin@meta.com>
Signed-off-by: Yong Hoon Shin <yhshin@meta.com>
Signed-off-by: Yong Hoon Shin <yhshin@meta.com>
Signed-off-by: Yong Hoon Shin <yhshin@meta.com>
Signed-off-by: Yong Hoon Shin <yhshin@meta.com>
Signed-off-by: Yong Hoon Shin <yhshin@meta.com>
Signed-off-by: Yong Hoon Shin <yhshin@meta.com>
Signed-off-by: Yong Hoon Shin <yhshin@meta.com>
Signed-off-by: Yong Hoon Shin <yhshin@meta.com>
Signed-off-by: Yong Hoon Shin <yhshin@meta.com>
Signed-off-by: Yong Hoon Shin <yhshin@meta.com>
This pull request has merge conflicts that must be resolved before it can be |
Motivation
KV cache techniques like SwiftKV reduce computation required during prefill. This is harder to implement in V1 where the scheduler groups tokens for prefill and decode in the same batch. This PR adds instrumentation to support prefill compute savings in V1 in KV cache sharing setups where KV sharing is used such that certain tokens can be skipped during prefill (as KV target layers have already populated the necessary key/value tensors required for decoding).
Example
Let's say we have a 24 layer model where first 12 layers allocate their own KV caches and next 12 layers re-use the shared KV cache of its corresponding KV target layer. Then given input prompt sequence of N tokens, we can skip prefill for N-1 tokens for the last 12 layers, because the key/value tensors used for decoding is already populated in the KV caches of the first 12 layers. Because vLLM v1 scheduler does not distinguish prefill/decode and employs continuous batching, we can instead perform forward on the last 12 layers with a reduced input size.
For example, if we have request 0 and request 1 with 4 prompt tokens each, then we might have tokens batched as such:
For the first 12 self-attention layers, we can do forward with the full input
[0, 1, 2, 3, 4, 5, 6, 7]
, while for the last 12 cross-attention layers, we can do forward with the last token for each request[3,7]
, as these are the only positions where valid logits are required to sample output tokens from.Frontend changes
This PR adds a new
--kv-sharing-skip-prefill
arg which is added to theCacheConfig
. This causes FlashAttention backend to compute an extra set of metadata assuming prefill skip, but changes are still required on model side to take advantage of this.Attention metadata
Attention metadata needs to be changed to account for the different query offsets and max lengths in the shared KV layers for which N-1 tokens are skipped during prefill.
Correctness Test
Unit test show outputs are roughly equivalent with and without this optimization (exact numerics will differ as batched mm op will yield slightly different results depending on batch size)
Perf comparison
Set up: single batch and input length of 8192. Using compile+piecewise cuda graph
TestQwen2ForCausalLM
model forward trace with optimization (enable_kv_sharing_truncated_prefill=True
)second layer group takes 9.7ms
Trace without optimization (
enable_kv_sharing_truncated_prefill=False
)second layer group takes 16.6ms