-
-
Notifications
You must be signed in to change notification settings - Fork 5.7k
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
[V1][Spec Decode] Ngram Spec Decode #12193
Conversation
👋 Hi! Thank you for contributing to the vLLM project. 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:
🚀 |
This pull request has merge conflicts that must be resolved before it can be |
Signed-off-by: LiuXiaoxuanPKU <[email protected]>
bd10281
to
4dec71d
Compare
Some benchmark results: The median TTFT/TPOT looks ok for w/o SD ngram branch and main branch, but it does slow down the main a bit. My guess is because of the change for delayed CPU <-> GPU synchronization. Detailed setting in doc. |
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 @LiuXiaoxuanPKU I think it's looking a lot better!
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.
@LiuXiaoxuanPKU Thanks for the work! I think we are almost there. Left some comments, mostly regarding the code style.
vllm/v1/worker/gpu_model_runner.py
Outdated
if seq_len >= req_state.num_tokens: | ||
# We don't rewind the generator state for requests now | ||
# because spec decode only supports greedy decoding for now. |
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.
Could you please explain more?
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.
It's not related, deleted.
But here, my main concern is how does spec decode handle seeding, rejected tokens might affect the generator state? Need more time to think about it and refer to V0.
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 fix!
@LiuXiaoxuanPKU Could you take a look at the failed tests? I'll approve the PR once the tests are green! |
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.
@LiuXiaoxuanPKU Thanks for the great work! It's been quite a long journey. Really appreciate for all the work!
@LiuXiaoxuanPKU Just wanted to double check. Is the PR ready for merge? |
This PR tries to add ngram spec decode to V1. Design doc: here.
Major changes:
_spec_token_ids
inRequest
to track speculated tokens.model_runner
:3.1 Change the
_prepare_input
to also return the logits of speculated tokens.3.2 Change the
_prepare_input
to add speculated tokens as input tokens.3.3 Change the
execute_model
to generate multiple tokens per call. Concretely, it will add more than one tokens toinput_batch
andreq_state
.What is missing
Tasks out of the scope of this PR
[Update]
I will move the following two features into following PRs:
Minor: There is a minimal example/test in
tests/v1/e2e/test_basic_specdecode.py
. You can check it for the current use and check correctness withpytest -s tests/v1/e2e/test_basic_specdecode.py
.Followup work: