Skip to content

[V1] AsyncLLM data parallel #13923

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

Merged
merged 65 commits into from
Mar 27, 2025
Merged

[V1] AsyncLLM data parallel #13923

merged 65 commits into from
Mar 27, 2025

Conversation

njhill
Copy link
Member

@njhill njhill commented Feb 26, 2025

The engine core client starts an engine core proc per dp rank and load balances requests between them. A dummy request is sent to idle ranks when the global req count goes from 0->1, and when each engine finishes all requests it will continue in an idle forward loop.

Working for single node:

vllm serve -dp 2 ...

I aimed to keep the data parallel logic isolated as much as possible (in subclasses of the core engine and client) to avoid adding complexity/overhead to the more common default dp=1 case.

Follow-on after this PR:

  • Multi-node
  • Balance based on waiting queue lengths rather than in-flight counts
  • Make it work with API server scale-out

Copy link

👋 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 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 either: Add ready label to the PR or enable auto-merge.

🚀

@mergify mergify bot added the v1 label Feb 26, 2025
Signed-off-by: Nick Hill <[email protected]>
Signed-off-by: Nick Hill <[email protected]>
Signed-off-by: Nick Hill <[email protected]>
Signed-off-by: Nick Hill <[email protected]>
Signed-off-by: Nick Hill <[email protected]>
Signed-off-by: Nick Hill <[email protected]>
Signed-off-by: Nick Hill <[email protected]>
Signed-off-by: Nick Hill <[email protected]>
Signed-off-by: Nick Hill <[email protected]>
Signed-off-by: Nick Hill <[email protected]>
Signed-off-by: Nick Hill <[email protected]>
Signed-off-by: Nick Hill <[email protected]>
Signed-off-by: Nick Hill <[email protected]>
@v-lmn
Copy link

v-lmn commented Mar 3, 2025

how to test,I mean how to run the server,I think we need two command right?
terminal 1 command 1
terminal 2 command 2
can you complete the command line

Copy link

mergify bot commented Mar 3, 2025

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

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

@mergify mergify bot added the needs-rebase label Mar 3, 2025
Copy link
Member

@youkaichao youkaichao left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the DP-related part looks good to me.

cc @robertgshaw2-redhat I'm not familiar with the frontend processing part, maybe Robert can take a look?

@njhill
Copy link
Member Author

njhill commented Mar 3, 2025

how to test,I mean how to run the server,I think we need two command right?
terminal 1 command 1
terminal 2 command 2
can you complete the command line

@v-lmn no for single node you can run a single command, with --data-parallel=N. Multi-node isn't added yet but when it is, that will require a different command to be run on the other node(s).

…gine

# Conflicts:
#	vllm/v1/core/scheduler.py
#	vllm/v1/engine/core.py
#	vllm/v1/engine/core_client.py
@mergify mergify bot removed the needs-rebase label Mar 3, 2025
njhill added 2 commits March 3, 2025 08:12
Signed-off-by: Nick Hill <[email protected]>
Signed-off-by: Nick Hill <[email protected]>
Copy link

mergify bot commented Mar 3, 2025

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

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

Signed-off-by: Nick Hill <[email protected]>
Comment on lines 18 to 20
if not current_platform.is_cuda():
pytest.skip(reason="V1 currently only supported on CUDA.",
allow_module_level=True)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if DP works on TPU or AMD GPUs, but modify this reason string since V1 works there at least experimentally?

vllm/vllm/engine/arg_utils.py

Lines 1669 to 1675 in d0cfec7

# No support for device type other than CUDA, AMD (experiemntal) or
# TPU (experimental) so far.
if not (current_platform.is_cuda_alike() or current_platform.is_tpu()):
_raise_or_fallback(
feature_name=f"device type={current_platform.device_type}",
recommend_to_remove=False)
return False

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could actually use supports_v1 now that this PR has landed (probably only want to turn tests on for CUDA and RoCM though)

#15417

@pytest.mark.asyncio
async def test_load(monkeypatch, output_kind: RequestOutputKind):
with monkeypatch.context() as m, ExitStack() as after:
m.setenv("VLLM_USE_V1", "1")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove this now that V1 is on by default?

outputs=outputs,
scheduler_stats=self.make_stats(),
)
if self.include_finished_set:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1

Copy link

mergify bot commented Mar 27, 2025

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

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

@mergify mergify bot added the needs-rebase label Mar 27, 2025
Copy link
Collaborator

@tlrmchlsmth tlrmchlsmth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left a few minor comments. The PR still looks very good and would be great to get it landed soon.

@mergify mergify bot removed the needs-rebase label Mar 27, 2025
@njhill
Copy link
Member Author

njhill commented Mar 27, 2025

Thanks @tlrmchlsmth! Have addressed those comments. Also had to make some additional adjustments to ensure compatibility with @youkaichao's offline multi-node scenario added in #15484.

njhill added 2 commits March 27, 2025 09:45
Signed-off-by: Nick Hill <[email protected]>
Copy link

mergify bot commented Mar 27, 2025

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

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

@mergify mergify bot added the needs-rebase label Mar 27, 2025
njhill added 2 commits March 27, 2025 10:59
Signed-off-by: Nick Hill <[email protected]>
# Conflicts:
#	vllm/v1/core/sched/scheduler.py
@mergify mergify bot removed the needs-rebase label Mar 27, 2025
@simon-mo simon-mo merged commit 15dac21 into vllm-project:main Mar 27, 2025
53 of 59 checks passed
@njhill njhill deleted the multi-engine branch March 28, 2025 00:32
local_dp_rank = vllm_config.parallel_config.data_parallel_rank_local

assert dp_size > 1
assert 0 <= local_dp_rank <= dp_rank < dp_size
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why do we need this check?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not strictly needed, I just thought it might be good here to verify that the config is in a coherent state.

from vllm.platforms import current_platform
if current_platform.is_cuda_alike():
from vllm.platforms.cuda import device_id_to_physical_device_id
tp_size = vllm_config.parallel_config.tensor_parallel_size
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you can use world_size to be general, not just tp_size

@simon-mo simon-mo mentioned this pull request Mar 29, 2025
66 tasks
lengrongfu pushed a commit to lengrongfu/vllm that referenced this pull request Apr 2, 2025
kylesayrs pushed a commit to neuralmagic/vllm that referenced this pull request Apr 2, 2025
Signed-off-by: Nick Hill <[email protected]>
Signed-off-by: Kyle Sayers <[email protected]>
Alex4210987 pushed a commit to LeiWang1999/vllm-bitblas that referenced this pull request Apr 5, 2025
lulmer pushed a commit to lulmer/vllm that referenced this pull request Apr 7, 2025
Signed-off-by: Nick Hill <[email protected]>
Signed-off-by: Louis Ulmer <[email protected]>
nishith-fujitsu pushed a commit to nishith-fujitsu/vllm that referenced this pull request Apr 9, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ci/build documentation Improvements or additions to documentation ready ONLY add when PR is ready to merge/full CI is needed v1
Projects
None yet
Development

Successfully merging this pull request may close these issues.