[Misc] Improve cli help show

[reidliu41]

Seems better to show help without the detected info.

$ vllm -h
INFO 03-25 08:08:46 [__init__.py:239] Automatically detected platform cpu.   <<<<
usage: vllm [-h] [-v] {chat,complete,serve,bench} ...

vLLM CLI

positional arguments:
  {chat,complete,serve,bench}

[github-actions]

👋 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.

🚀

[DarkLight1337]

Rather than change the platform behavior, I think a cleaner solution would be to avoid importing them too early in the first place inside vllm.engine.arg_utils.py.

[reidliu41]

yeah, but seems not just one from vllm.platforms import current_platform that may cause the issue

• so common to use vllm.platforms, maybe more later..
• also if fixed, it might easier to trigger again if someone don't know the change.

[youkaichao]

i think the problem is we are importing too many things in vllm/__init__.py , and people are used to run from vllm import LLM.

maybe we can follow the same approach as vllm/envs.py and vllm/platforms/__init__.py , to introduce a module level __getattr__ for lazy import on every attribute access.

[youkaichao]

we can move this line to utils.py, to avoid duplicating it. you might also want to consider -v for showing the version.

[reidliu41]

updated

[mergify]

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

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

[mergify]

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

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

[reidliu41]

@youkaichao hi, sorry to bother you , could you please help to take a look again?

[reidliu41]

hi @russellb seems reviewer is quite busy, if you have time, could you please help to take a look?

[davidxia]

looks like #15128 might be more mature and comprehensive?

[Chen-0210]

@davidxia @reidliu41 Hi, I believe some parts of your PR are definitely necessary. That said, my own PR doesn’t fully optimize vllm --version, but it does cover most of the groundwork. I’ve just been quite busy recently and haven’t had a chance to finish it up. Once it’s merged, it might affect your changes. Would you mind waiting another day or two? I should be able to finish mine soon. I just need to resolve some conflicts.

[reidliu41]

@davidxia yes

@Chen-0210 thanks for your feedback. I think is ok.