[V1][TPU] TPU-optimized top-k implementation (2nd try) #15891
Conversation
hyeygit
requested review from
WoosukKwon,
alexm-redhat,
comaniac,
njhill,
robertgshaw2-redhat and
ywang96
as code owners
|
👋 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 🚀 |
|
cc @NickLucche fyi |
Previously we found that using torch.topk resulted in significant speed up for TPU. Turns out that's not a viable solution because the return shape of torch.topk depends on k, which means an XLA recompilation is triggered everytime k changes. Additionally, we realized that torch.scatter was the main bottleneck for the original top-k impl on TPU. This PR circumvents both problems by using a threshold-based approach to find the top-k set. The algorithm is nearly identical to that of top-p; see vllm-project#15736 for more details. Signed-off-by: Hyesoo Yang <hyeygit@gmail.com>
Signed-off-by: Hyesoo Yang <hyeygit@gmail.com>
|
I think we can get this one in as a commit in #15489. We can probably close this. |
@NickLucche Sounds good. Could you also patch ae7bc73 to your PR? Thanks! |
2 participants
Previously we found that using torch.topk resulted in significant
speed up for TPU. Turns out that's not a viable solution because the
return shape of torch.topk depends on k, which means an XLA recompilation
is triggered everytime k changes.
Additionally, we realized that torch.scatter was the main bottleneck for
the original top-k impl on TPU. This PR circumvents both problems by using
a threshold-based approach to find the top-k set. The algorithm is nearly
identical to that of top-p; see #15736 for more details.
Benchmark
Sampling microbenchmark yields similar result as in the top-p PR, with "Running 32 elapsed time" averaging ~5 ms (down from 500 ms pre-optimization).
End-to-end serving benchmark with both top-k and top-p enabled show that on TPU (v6e-1) running Llama3.1-8B, the TPU-optimization here (along with the top-p PR) yields 23X speed up.