[RFC] Remove mandatory ray installation

[yewentao256]

Requesting changes as this is a breaking change. We should add a deprecation warning for a couple of releases before removing the optional dependency, since it breaks --distributed-executor-backend ray

Let's additionally discuss the deprecation in an RFC first + with the community

Originally posted by @tlrmchlsmth in #33351 (review)

vLLM v1 PP can run via the multiprocessing backend; Ray is only required when users explicitly choose the Ray executor backend. Keeping Ray as a default dependency on CUDA/ROCm causes confusion and unnecessarily pulls Ray into environments that don’t use it.

[Yuyz0112]

We would strongly benefit from making Ray an optional dependency.

Our production setup looks like this:

• Ray (and Ray Serve) is used as the orchestration layer.
• vLLM runs inside each Serve replica.
• We do NOT use vLLM's Ray-based distributed executor.

In this architecture, vLLM does not need Ray at runtime.

However, because vLLM currently declares Ray as a dependency, we run into version coupling issues:

• Ray cluster versions must be strictly aligned across driver and workers.
• vLLM evolves very quickly and may require newer Ray versions.
• We prefer to keep Ray pinned for cluster stability.
• Installing a new vLLM version can unintentionally upgrade Ray.

[yewentao256]

@tlrmchlsmth What's your thought?

[tlrmchlsmth]

@Yuyz0112 that that is a compelling argument and something I hadn't considered.

The other arguments in favor of making ray optional are that it avoids potential security vulnerabilities from the dependency, and slightly decreases the size of vLLM's dependencies.

@eicherseiji and @kouroshHakha should weigh in as well

[kouroshHakha]

I am 100% onboard with this. We currently have a very hard to satisfy circular dependency: ray serve / data llm depends on vllm, vllm depends on ray. We should remove vllm's pinned dependency on ray. Having said that, we should still keep the Ray CI pinned to some latest ray release so that the integration is always tested. At the same time we should make sure ray's dependency graph is fully compatible with vllm's dependency graph and can be satisfied together. Hopefully the CI on vllm + this work could address that.