[Doc] Create a new "Usage" section

[DarkLight1337]

Some of the pages under "Serving" and "Models" aren't really related to their parent section. This PR creates a new "Usage" section to accommodate these pages.

@simon-mo can you help set up redirects as requested in #10428? Done

[github-actions]

👋 Hi! Thank you for contributing to the vLLM project.
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 do one of these:

• Add ready label to the PR
• Enable auto-merge.

🚀

[DarkLight1337]

cc @ywang96 since I have significantly modified the docs for VLMs.

[russellb]

First, thank you for using git mv ! It's really common for people to not do that and accidentally lose the git history of the file.

There are two things I'm thinking about when deciding on groupings of content:

• who is the audience? (someone running vLLM, someone interacting with it via the API, using it via Python, someone working on the vLLM code, probably others)
• what problem are they trying to solve?

In this PR, I thought maybe you wanted "Serving" to focus more on "someone running vLLM", but that doesn't seem right. There are deploying docs that stay, but. then the doc on environment variables that a deployer would set got moved.

How would you describe the intended audience and scope of each section?

There are some in the PR that make a lot of sense to move around. A couple examples are "Adding a New Model" and "Enabling Multimodal Inputs". Those are more like "Design" to me. The audience is "people working on the vLLM code," and the content for that audience has been shifted to the end of the docs recently.

[simon-mo]

+1 i think we can expand the scope for broader refactoring of the doc tree, but okay to keep it scoped smaller.

[DarkLight1337]

First, thank you for using git mv ! It's really common for people to not do that and accidentally lose the git history of the file.

Actually, I didn't use it. The diffs were small enough that Git was able to detect that automatically 😅 Thanks for telling me about this though.

In this PR, I thought maybe you wanted "Serving" to focus more on "someone running vLLM", but that doesn't seem right. There are deploying docs that stay, but. then the doc on environment variables that a deployer would set got moved.

How would you describe the intended audience and scope of each section?

vLLM supports both offline and online inference. I intend the Usage section to contain docs that apply to both. On the other hand, the Serving section focuses on online inference only.

There are some in the PR that make a lot of sense to move around. A couple examples are "Adding a New Model" and "Enabling Multimodal Inputs". Those are more like "Design" to me. The audience is "people working on the vLLM code," and the content for that audience has been shifted to the end of the docs recently.

I agree that those two pages should be moved elsewhere. It's not really about "Design" though, maybe we can add a new Tutorials section? In any case it's outside the scope of this PR.

[russellb]

First, thank you for using git mv ! It's really common for people to not do that and accidentally lose the git history of the file.

Actually, I didn't use it. The diffs were small enough that Git was able to detect that automatically 😅 Thanks for telling me about this though.

Oh, I see. GitHub was smart enough to detect it and show it that way in the UI, but git does not see it as a move. Run git log docs/source/usage/compatibility_matrix.rst and you'll see what I mean. The history is a single commit now.

It's up to you if you feel like this is worth fixing.

In this PR, I thought maybe you wanted "Serving" to focus more on "someone running vLLM", but that doesn't seem right. There are deploying docs that stay, but. then the doc on environment variables that a deployer would set got moved.
How would you describe the intended audience and scope of each section?

vLLM supports both offline and online inference. I intend the Usage section to contain docs that apply to both. On the other hand, the Serving section focuses on online inference only.

Yeah, I guess I don't know how to decide what would go under Serving and what would go under Usage.

There are some in the PR that make a lot of sense to move around. A couple examples are "Adding a New Model" and "Enabling Multimodal Inputs". Those are more like "Design" to me. The audience is "people working on the vLLM code," and the content for that audience has been shifted to the end of the docs recently.

I agree that those two pages should be moved elsewhere. It's not really about "Design" though, maybe we can add a new Tutorials section? In any case it's outside the scope of this PR.

That's fine. I actually like how it is now that I look again. All of the content under "Models" groups together nicely.

[DarkLight1337]

Oh, I see. GitHub was smart enough to detect it and show it that way in the UI, but git does not see it as a move. Run git log docs/source/usage/compatibility_matrix.rst and you'll see what I mean. The history is a single commit now.

I'm not too bothered by this, since git blame -C still includes previous commits to the original file.

[DarkLight1337]

Does this look good to you now?

[russellb]

Does this look good to you now?

I'm not opposed to it. Definitely don't let me block it.

I'm still not sure I understand it, though:

Yeah, I guess I don't know how to decide what would go under Serving and what would go under Usage.

but please feel free to proceed if you'd like. It can always be changed further.

[DarkLight1337]

Yeah, perhaps it would be clearer as we make further changes down the line.

@simon-mo can you stamp this?