[V1] Refactor parallel sampling support #13774
Conversation
markmc
requested review from
WoosukKwon,
robertgshaw2-redhat,
njhill,
ywang96,
comaniac and
alexm-redhat
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 🚀 |
|
Nice work cleaning this up!
We should verify that this overhead is negligible with a quick benchmark |
|
This pull request has merge conflicts that must be resolved before it can be |
markmc
force-pushed
the
parallel-sampling-refactor
branch
from
1aed2ed to
75e9d49
Compare
The initial implementation went to great efforts to add parallel sampling as a wrapper at the highest layer of abstraction possible. This resulted in a lot of tricky code to post-process RequestOutputs to aggregate them where necessary. Instead, it probably makes sense to implement parallel sampling at the layer that actually creates RequestOutput objects - i.e. in OutputProcessor. To do this, we simply need to allow for fanning out child requests in LLMEngine.add_request(), passing details of the fan-out to OutputProcessor. This adds some overhead to the n=1 case (see SingularSamplingRequest) in return for significantly less overhead and complication in the parallel sampling case. Signed-off-by: Mark McLoughlin <[email protected]>
Address PR feedback from Nick. Signed-off-by: Mark McLoughlin <[email protected]>
Fixes: TypeError: RequestOutput.__init__() missing 1 required positional argument: 'outputs' Signed-off-by: Mark McLoughlin <[email protected]>
Signed-off-by: Mark McLoughlin <[email protected]>
Keeping the output aggregator on RequestState was just a silly refactoring mistake - it clearly needs to be on the parent request since we are aggregating across child requests. Also address some PR feedback from Nick to make the logic here less confusing. Signed-off-by: Mark McLoughlin <[email protected]>
Now that we're not returning a RequestOutput for all finished requests, we need to perform finished request handling even without a RequestOutput now. Signed-off-by: Mark McLoughlin <[email protected]>
Based on excellent PR feedback from Nick. Signed-off-by: Mark McLoughlin <[email protected]>
Move all the logic for child request output aggregating into parallel_sampling.ParentReq. Signed-off-by: Mark McLoughlin <[email protected]>
markmc
force-pushed
the
parallel-sampling-refactor
branch
from
0153a5b to
60fa08d
Compare
The initial implementation in #10980 went to great efforts to add parallel sampling as a wrapper at the highest layer of abstraction possible. This resulted in a lot of tricky code to post-process
RequestOutputsto aggregate them where necessary.Instead, it probably makes sense to implement parallel sampling at the layer that actually creates
RequestOutputobjects - i.e. inOutputProcessorTo do this, we simply need to allow for fanning out child requests in
LLMEngine.add_request(), passing details of the fan-out toOutputProcessor.This adds some overhead to the
n=1case (seeSingularSamplingRequest) in return for significantly less overhead and complication in the parallel sampling case.