[Attention] MLA with chunked prefill

[LucasWilkinson]

Need to do more benchmarking to see if this makes sense to be on by default in V0, but lays the groundwork for a V1 implementation. (#13111 may help performance)

lm_eval --model vllm --model_args pretrained=deepseek-ai/DeepSeek-V2-Lite-Chat,tensor_parallel_size=2,dtype=auto,gpu_memory_utilization=0.9,trust_remote_code=True,max_model_len=16384,enable_chunked_prefill=False --task gsm8k --num_fewshot=5 --limit 100

vllm (pretrained=deepseek-ai/DeepSeek-V2-Lite-Chat,tensor_parallel_size=2,dtype=auto,gpu_memory_utilization=0.9,trust_remote_code=True,max_model_len=16384,enable_chunked_prefill=False), gen_kwargs: (None), limit: 100.0, num_fewshot: 5, batch_size: 1
|Tasks|Version|     Filter     |n-shot|  Metric   |   |Value|   |Stderr|
|-----|------:|----------------|-----:|-----------|---|----:|---|-----:|
|gsm8k|      3|flexible-extract|     5|exact_match|↑  | 0.66|±  |0.0476|
|     |       |strict-match    |     5|exact_match|↑  | 0.66|±  |0.0476|


lm_eval --model vllm --model_args pretrained=deepseek-ai/DeepSeek-V2-Lite-Chat,tensor_parallel_size=2,dtype=auto,gpu_memory_utilization=0.9,trust_remote_code=True,max_model_len=16384,enable_chunked_prefill=True --task gsm8k --num_fewshot=5 --limit 100


vllm (pretrained=deepseek-ai/DeepSeek-V2-Lite-Chat,tensor_parallel_size=2,dtype=auto,gpu_memory_utilization=0.9,trust_remote_code=True,max_model_len=16384,enable_chunked_prefill=True), gen_kwargs: (None), limit: 100.0, num_fewshot: 5, batch_size: 1
|Tasks|Version|     Filter     |n-shot|  Metric   |   |Value|   |Stderr|
|-----|------:|----------------|-----:|-----------|---|----:|---|-----:|
|gsm8k|      3|flexible-extract|     5|exact_match|↑  | 0.66|±  |0.0476|
|     |       |strict-match    |     5|exact_match|↑  | 0.66|±  |0.0476|

Shout-out to @pathorn for assisting with hardening this PR

Future work:

• Allocate the worst case result of self.kv_b_proj(kv_c_normed) in the profile run
• [Attention] MLA with chunked prefill #12639 (comment)
• Improved algo for allocating workspace amongst batch elements
• Improve how the workspace is allocated

[github-actions]

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

🚀

[mergify]

This pull request has merge conflicts that must be resolved before it can be
merged. Please rebase the PR, @LucasWilkinson.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[mergify]

This pull request has merge conflicts that must be resolved before it can be
merged. Please rebase the PR, @LucasWilkinson.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[tlrmchlsmth]

Removed the V1 tag because although it does move some code out of the v1 flash attention backend, I didn't want anyone to get the impression that this PR adds support for MLA

[tlrmchlsmth]

Future work: this is generally useful across all kernels and we should probably factor these checks out into a helper function. Something like this:

namespace detail {
// Get device from either Tensor or optional<Tensor>
inline std::optional<torch::Device> get_device(const torch::Tensor& tensor) {
    return tensor.device();
}

inline std::optional<torch::Device> get_device(const std::optional<torch::Tensor>& maybe_tensor) {
    return maybe_tensor.has_value() ? std::optional(maybe_tensor.value().device()) 
                                  : std::nullopt;
}
} // namespace detail

template <typename First, typename... Rest>
void check_same_device(const First& first, const Rest&... rest) {
    auto first_device = detail::get_device(first);
    if (!first_device.has_value()) return;
    
    ([&](const auto& tensor) {
        auto device = detail::get_device(tensor);
        if (device.has_value()) {
            TORCH_CHECK(*device == *first_device, "All tensors must be on the same device");
        }
    }(rest), ...);
}

[LucasWilkinson]

agreed, that would be nice, ill work on a separated PR

[tlrmchlsmth]

Here we are allocating workspace used for the decompressed KV cache. This is going to happen during the profile run -- @WoosukKwon do you see any issues with doing that here?

To me it seems fine for lack of an official way to allocate workspace like this. If we leave it here, I would tighten up the comment a bit (remove the 1st person)

[tlrmchlsmth]

Overall looks really good, great work. Concerns are mainly on the memory/workspace/profile run issues which we all know are really hard to get right:

• I still have a question about where the best spot to allocate the workspace is, but I think what's happening here is OK. Unless people spot issues with this that I don't see, I don't think this should be a blocker.
• I wonder if it would be better to detect if we are in the profile run and allocate temporary tensors of size equal to the upper limit on the workspace required, instead of what we are doing now. It sounds like there might be an edge case where we run out of memory, and if so we should address before landing

[LucasWilkinson]

@tlrmchlsmth

I wonder if it would be better to detect if we are in the profile run and allocate temporary tensors of size equal to the upper limit on the workspace required, instead of what we are doing now. It sounds like there might be an edge case where we run out of memory, and if so we should address before landing

this should be addressed by: 1c59597

without this commit I get:

model weights take 84.11GiB; non_torch_memory takes 5.13GiB; PyTorch activation peak memory takes 0.19GiB; the rest of the memory reserved for KV Cache is 36.41GiB.

with it I get:

model weights take 84.11GiB; non_torch_memory takes 5.13GiB; PyTorch activation peak memory takes 1.17GiB; the rest of the memory reserved for KV Cache is 35.42GiB.

[mergify]

This pull request has merge conflicts that must be resolved before it can be
merged. Please rebase the PR, @LucasWilkinson.

https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/syncing-a-fork

[LucasWilkinson]

NOTE: @pathorn found a bug when stress testing R1, will notify here when resolved

https://vllm-dev.slack.com/archives/C08AD2B5HH8/p1739521144253459?thread_ts=1739486497.566799&cid=C08AD2B5HH8

Edit: should be resolved by 920ecc6#diff-00753a3c1f378f8b8c60e9eb10b94c3cbbfcea74fca6e66712e5d4ae360f6741

[tlrmchlsmth]

Looks great - definitely feel good about the profile_run now

[tlrmchlsmth]

🎉