[Core] Prefill Only Tokens Without KV Cache in Batch Requests (Disagg Prefill)

[Shaoting-Feng]

This ticket is part of [RFC]: Disaggregated Prefilling and KV Cache Transfer Roadmap #10818, with the following issue: "Adaptivity and Fault Tolerance: [Perf] If not all KV caches in the batch are received, only perform prefilling on those tokens without KV cache."

When there are multiple requests in a batch, the decode node may only receive the KV cache for some of them from the prefill node. Previously, in such cases, the decode node would perform prefilling for all requests in the batch, even if it had already received the KV cache for some requests.

This PR rebuilds the model input when the KV cache for some requests in the batch is missing, thereby preventing prefilling on those requests.

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

🚀

[Shaoting-Feng]

@ShangmingCai @youkaichao @comaniac
Could I get a review when you have time? Thanks!

[ShangmingCai]

cc @KuntaiDu

[ShangmingCai]

Some quick questions:
If we don't bypass all requests and only execute forward for the requests that fail to receive KVCache, will those ready requests that manage to receive KVCache be scheduled to the decode step directly, or do they still need to wait for the requests in the same batch before entering the decode stage together?

Also, it would be better to perform chunked prefill requests on the decode node rather than the normal prefill forward pass. Before chunked prefill is compatible, could you provide a benchmark result to compare the cost and benefit of partial rebuilt and forward?

[KuntaiDu]

If we don't bypass all requests and only execute forward for the requests that fail to receive KVCache, will those ready requests that manage to receive KVCache be scheduled to the decode step directly, or do they still need to wait for the requests in the same batch before entering the decode stage together?

I guess the current PR implements the latter case: it will delay those ready-to-decode request and do prefill on those fail-to-receive-kv-cache requests. Chunked prefill is indeed a better solution for this.

Also, it would be better to perform chunked prefill requests on the decode node rather than the normal prefill forward pass.

@ShangmingCai It's a bit concerning to always use chunked prefill on decoding nodes, as it may delay the starting time of the request. This is because that chunked prefill must enumerate all input token chunks using multiple scheduler steps before being able to start decoding, which introduces roughly # of scheduling steps * inter-token-latency overhead. A potential solution is to let the orchestrator to help forward the KV cache in chunk granularity instead of in request granuarity (as in current vLLM), but this solution is probably outside the scope of vLLM project itself though.

[Shaoting-Feng]

Before chunked prefill is compatible, could you provide a benchmark result to compare the cost and benefit of partial rebuilt and forward?

Thanks for your review. The main benefit of partial rebuild and forward is a reduction in TTFT, while the cost is a slight increase in code complexity. I can write a benchmark script to measure TTFT under different numbers of lost requests in a batch and compare the results with and without my feature enabled.

[mergify]

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

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

[github-actions]

This pull request has been automatically marked as stale because it has not had any activity within 90 days. It will be automatically closed if no further activity occurs within 30 days. Leave a comment if you feel this pull request should remain open. Thank you!

[github-actions]

This pull request has been automatically closed due to inactivity. Please feel free to reopen if you intend to continue working on it. Thank you!