[Feature][Refactor][CLI] Rename guided to structured outputs, and --structured-outputs-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.

I also remove all previous guided_decoding options in preparation for v0.10.0

This is the first of many to move all guided_decoding -> structured_output namespace.

Signed-off-by: Aaron Pham contact@aarnphm.xyz
Co-authored-by: Nick Hill nhill@redhat.com

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

🚀

[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

[hmellor]

This is a good PR, I just have a lot of comments about how some things don't fit in well with the design of the rest of the configs. With a few relatively simple changes it can fit right in.

[hmellor]

Should this method be renamed to structured output too?

[aarnphm]

This is not user facing, and it is in v0, so probably not needed to rename it here now (given that the code path for v0 still calls it guided_decoding)

[russellb]

I personally find CLI arguments that take a JSON string pretty horrendous and don't like this trend in vLLM. It's a sign we're over-extending simple CLI arguments. We need a proper configuration file that supports structured, hierarchical data. I don't consider the current "yaml" config support to count, since it's just the same as the CLI args, including JSON blob values.

I don't have time to take on such a project, but I'd prefer to see efforts put in that direction than this direction.

[DarkLight1337]

#18208 made it simpler to specify JSON-like args.

[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

[aarnphm]

fyi @hmellor @DarkLight1337: this PR will be breaking, for people who installed from main, given that I didn't include the deprecated options. The reason being I felt like this is a good time to do this anw in preparation for 0.10.0

If we decided to have a 0.9.3, then we should def delay this PR.

[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