vLLM 0.30.0 CPU packages raise glibc requirements, affecting older Linux deployments

A CPU package compatibility issue was reported the day after vLLM released version 0.30.0 on September 22. The Ubuntu 22.04 and RHEL 9.6 environments listed in the report use glibc 2.35 and 2.34, respectively, and cannot install the new prebuilt packages. Inference services retaining their existing Linux base images therefore face an upgrade obstacle before model loading even begins. [Issue report](https://github.com/vllm-project/vllm/issues/58270)

The official release assets confirm that the tags for both Linux CPU architectures changed from manylinux_2_34 in 0.29.0 to manylinux_2_39 in 0.30.0. The CUDA and XPU assets in the same release remain tagged 2_28 and 2_34, respectively, so the impact should be limited to the corresponding CPU distributions. This does not establish that all backends have raised their minimum requirements. [New release assets](https://github.com/vllm-project/vllm/releases/expanded_assets/v0.30.0), [Previous release assets](https://github.com/vllm-project/vllm/releases/expanded_assets/v0.29.0)

Under the Python packaging specification, the version after manylinux indicates the minimum supported glibc version; Python, ABI, and platform compatibility each have separate tags. A package using the stable Python ABI therefore cannot necessarily bypass system library constraints. Simply switching Python virtual environments does not remove this platform requirement. [Compatibility specification](https://packaging.python.org/en/latest/specifications/platform-compatibility-tags/)

The report links the change to native AMX-FP8 attention support. The related pull request does require newer binutils to assemble the new instructions and adjusts the build image and compiler. This illustrates the release tradeoffs involved in supporting new hardware instructions, but maintainers have yet to clarify whether raising the minimum compatibility baseline was intentional. [Technical proposal](https://github.com/vllm-project/vllm/pull/49410)

Another deployment detail is that, at the time of review, the official CPU documentation still constructed download URLs for the latest version using the old platform tag. Scripts that follow the documentation to automatically fetch the latest release should first check the actual asset names. Changing the URL to use the new tag only corrects the filename; it does not make the package compatible with older systems. [Installation documentation](https://docs.vllm.ai/en/latest/getting_started/installation/cpu/)

Engineering teams can first verify installation in an image matching their production environment, then assess whether to pin the existing version, update the runtime environment, or build from source. Building from source still requires separate checks of toolchain and hardware requirements. At the time of review, the issue remained open with no maintainer response. The key developments to watch are whether packages with a lower minimum requirement will be issued and whether the documentation will be brought into sync with the release assets.