Skip to content

[Hardware][TPU] Add supports_async_scheduling() method to Executor interface so that it can be extended for Executor implementations.#36924

Merged
DarkLight1337 merged 5 commits intovllm-project:mainfrom
gxd3:gxd3/async-sched-executors-platform-override
Mar 18, 2026
Merged

[Hardware][TPU] Add supports_async_scheduling() method to Executor interface so that it can be extended for Executor implementations.#36924
DarkLight1337 merged 5 commits intovllm-project:mainfrom
gxd3:gxd3/async-sched-executors-platform-override

Conversation

@gxd3
Copy link
Copy Markdown
Contributor

@gxd3 gxd3 commented Mar 12, 2026

[Hardware][TPU] Add supports_async_scheduling() method to Executor interface so that it can be extended for Executor implementations

Purpose

TPU-inference has a custom Executor class that we want to make compatible with async scheduling.
In TPU-inference's custom Executor implementation, we plan to override supports_async_scheduling() to True.

Test Plan

This PR should have no behavior change.
Added a unit test.

Test Result

unit test passed.

…can be extended for different Platforms

Signed-off-by: Guangxiang Du <gxd@google.com>
Copy link
Copy Markdown
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

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

Code Review

This pull request introduces a new executors_supports_async_scheduling() method to the Platform interface, which allows different platforms to specify which distributed executor backends are compatible with asynchronous scheduling. This change replaces a hardcoded list of executors in VllmConfig with a call to this new method, making the system more extensible for platforms like TPU. The default implementation preserves the existing behavior, and a unit test has been added to verify this. The changes are well-structured and correctly implemented.

@github-actions
Copy link
Copy Markdown

👋 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 ask your reviewers to trigger select CI tests on top of fastcheck CI.

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.

If you have any questions, please reach out to us on Slack at https://slack.vllm.ai.

🚀

@jikunshang
Copy link
Copy Markdown
Collaborator

I understand your requirement and what you want, I just feel a little strange.
I think vLLM doesn't provide any mechanism to extend Executor class for OOT/plugin yet.
you can say whether a platform support async scheduling or whether an executor support async scheduling, while platform X executor support async scheduling doesn't make much sense to me.
I prefer to add a support_async_scheduling interface in Executor class. but I know it need some reflection to create executor object later, that's why you didn't do such thing.

@gxd3 gxd3 requested a review from njhill as a code owner March 13, 2026 19:28
@mergify mergify bot added the v1 label Mar 13, 2026
@gxd3 gxd3 changed the title [Hardware][TPU] Add executors_supports_async_scheduling() method to Platform so that it can be extended for different Platforms [Hardware][TPU] Add supports_async_scheduling() method to Executor interface so that it can be extended for Executor implementations. Mar 13, 2026
@gxd3
Copy link
Copy Markdown
Contributor Author

gxd3 commented Mar 13, 2026

Thank you, Kunshang for the quick review!
It's a great point, I updated as suggested, moving support_async_scheduling to Executor interface.
Please take another look again,
Thanks!

…ew comment suggested

Signed-off-by: Guangxiang Du <gxd@google.com>
@gxd3 gxd3 force-pushed the gxd3/async-sched-executors-platform-override branch from 29a415c to 2e1ca56 Compare March 13, 2026 19:41
"uni",
"external_launcher",
)
executor_supports_async_sched = Executor.get_class(
Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

I am not certain whether we should do this here.
cc @njhill @LucasWilkinson PTAL

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Yeah it is kind of circular but I'm not sure what the alternative is.

@Lumosis
Copy link
Copy Markdown
Contributor

Lumosis commented Mar 17, 2026

Hi @mgoin @robertgshaw2-redhat! Could you take a look? This is blocking TPU multi-host perf optimization.

Copy link
Copy Markdown
Member

@njhill njhill left a comment

Choose a reason for hiding this comment

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

Thanks @gxd3 this looks reasonable to me!

"uni",
"external_launcher",
)
executor_supports_async_sched = Executor.get_class(
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Yeah it is kind of circular but I'm not sure what the alternative is.

Signed-off-by: Guangxiang Du <gxd@google.com>
@gxd3
Copy link
Copy Markdown
Contributor Author

gxd3 commented Mar 17, 2026

Thanks @gxd3 this looks reasonable to me!

Thanks Nick for the review!
Updated the PR as your suggestion, PTAL,
Thank you!

@njhill njhill added the ready ONLY add when PR is ready to merge/full CI is needed label Mar 17, 2026
@jikunshang jikunshang added the ready-run-all-tests Trigger CI with all tests for wide-ranging PRs label Mar 18, 2026
@jikunshang
Copy link
Copy Markdown
Collaborator

I add run full ci label, in case any corner case break.

@DarkLight1337 DarkLight1337 merged commit a0dd199 into vllm-project:main Mar 18, 2026
52 checks passed
wendyliu235 pushed a commit to wendyliu235/vllm-public that referenced this pull request Mar 18, 2026
…terface so that it can be extended for Executor implementations. (vllm-project#36924)

Signed-off-by: Guangxiang Du <gxd@google.com>
fxdawnn pushed a commit to fxdawnn/vllm that referenced this pull request Mar 19, 2026
…terface so that it can be extended for Executor implementations. (vllm-project#36924)

Signed-off-by: Guangxiang Du <gxd@google.com>
SouthWest7 pushed a commit to SouthWest7/vllm that referenced this pull request Mar 27, 2026
…terface so that it can be extended for Executor implementations. (vllm-project#36924)

Signed-off-by: Guangxiang Du <gxd@google.com>
khairulkabir1661 pushed a commit to khairulkabir1661/vllm that referenced this pull request Mar 27, 2026
…terface so that it can be extended for Executor implementations. (vllm-project#36924)

Signed-off-by: Guangxiang Du <gxd@google.com>
Monishver11 pushed a commit to Monishver11/vllm that referenced this pull request Mar 27, 2026
…terface so that it can be extended for Executor implementations. (vllm-project#36924)

Signed-off-by: Guangxiang Du <gxd@google.com>
Signed-off-by: Monishver Chandrasekaran <monishverchandrasekaran@gmail.com>
JiantaoXu pushed a commit to JiantaoXu/vllm that referenced this pull request Mar 28, 2026
…terface so that it can be extended for Executor implementations. (vllm-project#36924)

Signed-off-by: Guangxiang Du <gxd@google.com>
vrdn-23 pushed a commit to vrdn-23/vllm that referenced this pull request Mar 30, 2026
…terface so that it can be extended for Executor implementations. (vllm-project#36924)

Signed-off-by: Guangxiang Du <gxd@google.com>
Signed-off-by: Vinay Damodaran <vrdn@hey.com>
EricccYang pushed a commit to EricccYang/vllm that referenced this pull request Apr 1, 2026
…terface so that it can be extended for Executor implementations. (vllm-project#36924)

Signed-off-by: Guangxiang Du <gxd@google.com>
Signed-off-by: EricccYang <yangyang4991@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ready ONLY add when PR is ready to merge/full CI is needed ready-run-all-tests Trigger CI with all tests for wide-ranging PRs v1

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants