[Feature][CLI] Unify configuration for structured outputs via --structured-output-config

[aarnphm]

This PR introduces the args --structured-output-config as a way to unify all related structured outputs config in one CLI field.
This would help simplify general UX for specifying custom options with backends.

This means all previous arguments are considered deprecated, and --structured-output-config should be used going forward (v0.10.x)

This is the first of many to move all guided_decoding -> structured_output namespace. I plan to finish this migration by v0.10.x
for both OpenAI and all path within vLLM codebase.

Signed-off-by: Aaron Pham contact@aarnphm.xyz

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

🚀

[aarnphm]

question for @hmellor:

For CLI do we want to add a deprecated=True to add_argument instead? right now I will just include notice in docstring

[hmellor]

Oh that's neat, yeah I'd prefer adding deprecated=True to the argument rather than changing the docstring when we are deprecating args.

[aarnphm]

I will open a separate PR for this then

[hmellor]

Not a full review but I've left some initial comments.

I'm not a huge fan of using JSON to bundle what could be separate arguments. As it is right now, each argument is listed and clearly described (which we get for free because we documented it in the dataclass anyway).

If you bundle it into JSON:

• the documentation and --help text won't look as nice
• you'll have to maintain separate documentation explaining all the args in the dataclass
• it will become out of sync with the dataclass documentation

edit: After speaking to @aarnphm offline, I'm going to try adding the Config classes to the API reference directly. And then the JSON arg could reference that directly with no duplication or missing of information.

[mergify]

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

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, @aarnphm.

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

[hmellor]

@aarnphm I've made #17485 to add API docs for configs

[mergify]

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

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, @aarnphm.

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