[Bugfix] Fix host and port join for ipv6 in bench serve

[scottzh8]

Purpose

Fix IPv6 address formatting in the benchmark client (vllm bench serve).

Previously, when using --host :: or other IPv6 addresses, the benchmark client would construct invalid URLs like http://:::8000/v1/completions, causing aiohttp to fail with
ValueError: Invalid URL: port can't be converted to integer.
This PR fixes the issue by using the existing join_host_port() utility from vllm.utils.network_utils, which properly wraps IPv6 addresses in brackets per RFC 3986 (e.g.,
http://[::]:8000/v1/completions).

Test Plan

Manual testing with different host formats:

# Test IPv4 (should work as before)
vllm bench serve --host 127.0.0.1 --port 8000 --model <model> --num-prompts 10

# Test IPv6 wildcard (previously broken, now works)
vllm bench serve --host :: --port 8000 --model <model> --num-prompts 10

# Test IPv6 loopback (previously broken, now works)
vllm bench serve --host ::1 --port 8000 --model <model> --num-prompts 10

# Test hostname (should work as before)
vllm bench serve --host localhost --port 8000 --model <model> --num-prompts 10

Test Result

Before fix:
$ vllm bench serve --host :: --port 8000 --model deepseek-ai/DeepSeek-R1-0528 ...
Traceback (most recent call last):
  ...
  File "/home/scottzh/oss/.venv/lib/python3.12/site-packages/yarl/_parse.py", line 134, in split_netloc
    port = int(port_str)
           ^^^^^^^^^^^^^
ValueError: invalid literal for int() with base 10: '::8000'
...
aiohttp.client_exceptions.InvalidUrlClientError: http://:::8000/v1/completions

After fix:
$ vllm bench serve --host :: --port 8000 --model deepseek-ai/DeepSeek-R1-0528 ...
Using base_url: http://[::]:8000
Using api_url: http://[::]:8000/v1/completions
Starting initial single prompt test run...
[benchmark proceeds successfully]

[gemini-code-assist]

Code Review

This pull request correctly fixes an issue with IPv6 address formatting when constructing the benchmark server URL by using the join_host_port utility. This is a good improvement. While reviewing, I noticed a related potential issue in the URL construction logic that could also lead to invalid URLs if the endpoint path is not formatted with a leading slash. I've added a suggestion to make the URL construction more robust.

[gemini-code-assist]

The current string concatenation for api_url is brittle. If a user provides an endpoint without a leading slash (e.g., v1/completions instead of the default /v1/completions), it will result in an invalid URL like http://localhost:8000v1/completions. It's better to construct the URL more robustly to ensure there is always a single slash between the base URL and the endpoint path. My suggestion also reuses the base_url variable, making the code slightly more DRY.

Suggested change

	api_url = f"http://{host_port}{args.endpoint}"
	base_url = f"http://{host_port}"
	base_url = f"http://{host_port}"
	api_url = f"{base_url}/{args.endpoint.lstrip('/')}"

[heheda12345]

@codex review

[chatgpt-codex-connector]

Codex Review: Didn't find any major issues. Swish!

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[heheda12345]

LGTM!