feat(vllm-tensorizer): Upgrade vLLM version and Resolve Related Build Compatibility Issues

[JustinPerlman]

This PR focuses on updating the vLLM version being used within the vllm-tensorizer Docker image and resolving the various bugs and compatibility issues that arose from this upgrade.

Key Changes:

• Updated Base Image: Switched to ghcr.io/coreweave/ml-containers/torch-extras:es-compute-12.0-67208ca-nccl-cuda12.9.0-ubuntu22.04-nccl2.27.3-1-torch2.7.1-vision0.22.1-audio2.7.1-abi1. This moves from torch:base to torch:nccl for CUDA development tools and aligns with PyTorch 2.7.1 and CUDA 12.9.0.
• Upstream vLLM: Updated vLLM source to pull from the official vllm-project/vllm.git repository (v0.9.1), rather than CoreWeave's vLLM fork
• Build Compatibility: Resolved various compilation errors, including:
  • FileNotFoundError: .../nvcc and CUDA::nvToolsExt not found by ensuring correct torch:nccl base image.
  • PyTorch version expected errors by integrating use_existing_torch.py to handle vLLM's PyTorch version expectations.
  • Out-of-memory issues during Flash Attention compilation by setting MAX_JOBS=16.
  • Dockerfile Hygiene: Improved Dockerfile clarity by consistently uppercasing AS keywords.

[arsenetar]

How does the result of this build compare to the offical vllm image? Do we have all the same libraries etc? https://github.com/vllm-project/vllm/blob/main/docker/Dockerfile.

The CI here needs updates to build new version without manually specifying the version of base images to use.

I would also like to move to rename this to vllm-openai to align with the vllm project upstream image.

[Eta0]

@JustinPerlman I think the way to go here to better gather the different workflow variables in one place (vLLM version, base image version, etc.) is to move to a matrix build strategy even if the matrix only has a single element. We can work on this together, as there is a template I put together for doing this.

[Eta0]

@arsenetar, about this:

The CI here needs updates to build new version without manually specifying the version of base images to use.

What would you see as not manually specifying it? Automatically pulling the most recent image from main? Currently the only build in this repository that does that is torch-extras and it has some issues in practice, mainly that we often have changes in downstream images that require corresponding changes in the torch base image that will in turn require a new branch, so hardcoding it to look for images from main doesn't work very well for development

[arsenetar]

What would you see as not manually specifying it? Automatically pulling the most recent image from main? Currently the only build in this repository that does that is torch-extras and it has some issues in practice, mainly that we often have changes in downstream images that require corresponding changes in the torch base image that will in turn require a new branch, so hardcoding it to look for images from main doesn't work very well for development

I would expect the CI to set the ARG for the base image, there are likely reasons where we will want to build a matrix of versions similarly to the other torch images. Minimally that is something that should be changed to set that up for the CI to define/allow passing that.

With respect to upstream images breaking things and requiring updates, that is somewhat expected to happen. There is a difference between development and builds that should be considered validated released. This repo's package structure does not really help delineate the differences.

[github-actions]

@JustinPerlman Build complete, success: https://github.com/coreweave/ml-containers/actions/runs/15714183890
Image: ``

[Eta0]

How does the result of this build compare to the offical vllm image? Do we have all the same libraries etc?

As far as I can tell, the only libraries we don't install that they do are ffmpeg libsm6 libxext6 libgl1, which is a bit of a strange set. I'm not sure we really need those, but if it comes up, we can add them. We also don't install uv to replace pip.

[arsenetar]

As far as I can tell, the only libraries we don't install that they do are ffmpeg libsm6 libxext6 libgl1, which is a bit of a strange set. I'm not sure we really need those, but if it comes up, we can add them. We also don't install uv to replace pip.

Out of all of that I could only think of ffmpeg as being of value if it's used by libraries for the multimodal.

[Eta0]

I would also like to move to rename this to vllm-openai to align with the vllm project upstream image.

This would create a new package listing alongside vllm-tensorizer in the repo package list, so I'd prefer not to rename it unless there's value added by doing so.

[github-actions]

@Eta0 Build complete, success: https://github.com/coreweave/ml-containers/actions/runs/15718383514
Image: ``

[sangstar]

Tested; LGTM.