[CI/Build] custom build backend and dynamic build dependencies

[dtrifiro]

The rationale for this is that the current build setup uses different methods in each Dockerfile:

• python setup.py bdist_wheel
• python setup.py develop
• python setup.py install
• pip install -e ./vllm

as well as using different approaches for installing build requirements: using requirements-build.txt, pip install-ing the expected dependencies or relying on the build dependencies defined in pyproject.toml (see discussion here)

As the first three methods above are deprecated, one might expect modern PEP517/PEP518 style builds to work (e.g. pip install git+https://github.com/vllm-project/vllm).

This PR attempts solve these issues by:

• adding a custom build backend _custom_backend/vllm.py to dynamically resolve build dependencies at build time, based on the value of VLLM_TARGET_DEVICE, consolidating build depedency requirements in a single place.
• builds will now happen in an isolated environment unless pip install --no-build-isolation or python -m build --no-isolation are used.
  -Get rid of torch in requirements-build.txt (required torch version is computer per-device by the custom build backend)
• modifying Dockerfiles to use the PEP517/518 isolated build environment (when possible).

[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 consists a small and essential subset of CI tests to quickly catch errors. You can run other CI tests on top of default ones by unblocking the steps in your fast-check build on Buildkite UI.

Once the PR is approved and ready to go, please make sure to run full CI as it is required to merge (or just use auto-merge).

To run full CI, you can do one of these:

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

🚀

[youkaichao]

why do we need build isolation? vllm build needs to build against pytorch, and it does not make sense to install pytorch (can be complicated) in an isolated environment and build against it.

I'd like to specify the build dependency in pyproject.toml, get rid of the requirements.txt, while still doing non-isolated build.

it looks strange that pip does not support this out of the box.

[dtrifiro]

@youkaichao

why do we need build isolation? vllm build needs to build against pytorch, and it does not make sense to install pytorch (can be complicated) in an isolated environment and build against it.

As long as the build-time and run-time torch dependencies match, there's no issue with this.

I'd like to specify the build dependency in pyproject.toml, get rid of the requirements.txt, while still doing non-isolated build.
it looks strange that pip does not support this out of the box.

We can do this using pip install --no-build-isolation or python -m build --no-isolation, although you will have to install every build dependency beforehand.

[youkaichao]

As long as the build-time and run-time torch dependencies match, there's no issue with this.

it does not make sense for vllm. in our case, the build will build against pytorch, with binary dependency. and then it needs to run with that pytorch. I don't see any benefit w.r.t. isolated build, while it introduces additional cost of unnecessarily installing pytorch again.

and as i mentioned, installing pytorch in an isolated environment can be complicated, or even impossible. users might bring their own custom build, and the pytorch might come directly from the base container.

since you are building a custom build backend here, I assume you can disable the isolated build by default, and still read the build time dependency and use pip to install them if they are not installed (e.g. for cmake etc)

[youkaichao]

print the list in a nicer way?

[dtrifiro]

Ended up removing this altogether, before removal it looked like this:

$ python -m build  -v --wheel --installer=uv                                                                                                                                                                       
* Creating isolated environment: venv+uv...
* Using external uv from /usr/bin/uv
* Installing packages in isolated environment:
  - setuptools
  - setuptools-scm
> /usr/bin/uv pip install setuptools-scm setuptools
< Using Python 3.12.8 environment at: /tmp/build-env-t84pkm2n
< Resolved 3 packages in 3ms
< warning: Failed to hardlink files; falling back to full copy. This may lead to degraded performance.
<          If the cache and target directories are on different filesystems, hardlinking may not be supported.
<          If this is intentional, set `export UV_LINK_MODE=copy` or use `--link-mode=copy` to suppress this warning.
< Installed 3 packages in 16ms
<  + packaging==24.2
<  + setuptools==75.8.0
<  + setuptools-scm==8.1.0
* Getting build dependencies for wheel...
vllm build-backend: resolved build dependencies to:
setuptools>=61
setuptools-scm>=8
cmake>=3.26
ninja
packaging
setuptools
setuptools-scm
wheel
torch==2.5.1
* Installing packages in isolated environment:
  - cmake>=3.26
  - ninja
  - packaging
  - setuptools
  - setuptools-scm
  - setuptools-scm>=8
  - setuptools>=61
  - torch==2.5.1
  - wheel
> /usr/bin/uv pip install torch==2.5.1 ninja cmake>=3.26 setuptools-scm wheel setuptools setuptools>=61 setuptools-scm>=8 packaging
[...]

which ended up duplicating a lot of information

[youkaichao]

are these files still required?

[dtrifiro]

Yes, these are runtime dependencies, not build time.

[mergify]

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

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

[dtrifiro]

Does anybody know if there's a specific reason on why this was added here instead of being added to requirements-cpu.txt?

One potential issue could be that requirements-cpu.txt also is used by ppc and arm Dockerfiles, although this could fixed by adding

intel_extension_for_pytorch==2.5.0; platform_machine == "x86_64"

This does not solve the issue when using AMD processors, but this is currently when building Dockerfile.cpu

[dtrifiro]

I want to stress out this change: I think it's better to explicitly set the ROCm target device rather than inferring it based on the value of torch.version.hip. Dockerfile.rocm has been updated accordingly.

[dtrifiro]

async-engine-inputs-utils-worker-test failure seems unrelated