[Core][Doc][CI/Build][Bugfix][Profiling] Multi-replica routing polices, prefix caching, uv, and a much faster and lighter Vidur

[nitinkedia7]

We are excited to open-source a ton of development in Vidur 🎉

Changelog

• Add documentation:
  • How to run Vidur for different models, GPU SKUs, workloads, etc.?
  • How to run Vidur Config Explorer aka 100s of simulations in parallel?
• Support replica wise metrics e.g. prefill_e2e_time_replicawise to show difference in TTFT across replicas.
• Implement and refine several routing policies, see vidur/scheduler/global_scheduler.
• Port prefix caching support from vllm_v1 and the vllm_v1 replica scheduler.
• Switch to uv from mamba.
• Several quality-of-life enhancements:
  • Reproducibility of output
  • 4X reduction in RAM usage per simulation,
  • high context (128K), number of requests (~25k), QPS support.

---

PR Checklist (Click to Expand)

Thank you for your contribution to Vidur! Before submitting the pull request, please ensure the PR meets the following criteria. This helps Vidur maintain the code quality and improve the efficiency of the review process.

PR Title and Classification

Only specific types of PRs will be reviewed. The PR title is prefixed appropriately to indicate the type of change. Please use one of the following:

• [Bugfix] for bug fixes.
• [CI/Build] for build or continuous integration improvements.
• [Doc] for documentation fixes and improvements.
• [Model] for adding a new model or improving an existing model. Model name should appear in the title.
• [Profiling] For changes on the profiling module.
• [Core] for changes in the core simulator logic
• [Misc] for PRs that do not fit the above categories. Please use this sparingly.

Note: If the PR spans more than one category, please include all relevant prefixes.

Code Quality

The PR need to meet the following code quality standards:

• Pass all linter checks. Please use make format to format your code.
• The code need to be well-documented to ensure future contributors can easily understand the code.
• Please add documentation to docs/source/ if the PR modifies the user-facing behaviors of Vidur. It helps user understand and utilize the new features or changes.

Notes for Large Changes

Please keep the changes as concise as possible. For major architectural changes (>500 LOC), we would expect a GitHub issue (RFC) discussing the technical design and justification. Otherwise, we will tag it with rfc-required and might not go through the PR.

Thank You

Finally, thank you for taking the time to read these guidelines and for your interest in contributing to Vidur. Your contributions make Vidur a great tool for everyone!

[JiinnW]

Hi, I find the file how_to_run.md invisible now. Did someone mistakenly delete it?