[Feature]: Migration plan for ROCm 7.14 / TheRock production release (containers + wheels)

[raravind007]

[Feature]: Migration plan for ROCm 7.14 / TheRock production release (containers + wheels)

🚀 The feature, motivation and pitch

AMD released ROCm 7.14 on 2026-07-15 — the first production release built on TheRock, AMD's new open-source build and release system. The 7.9–7.13 preview train is complete, and AMD's release notes explicitly encourage users on the legacy packaging line (7.2.x and older) to migrate:

• Release blog: https://rocm.blogs.amd.com/ecosystems-and-partners/rocm-7.14-blog/README.html
• TheRock: https://github.com/ROCm/TheRock
• Release notes: https://rocm.docs.amd.com/en/docs-7.14.0/about/release-notes.html
• Transition guide: https://rocm.docs.amd.com/en/docs-7.14.0/about/transition-guide-TheRock.html

Current state in vLLM upstream

vLLM's ROCm support is currently straddling both packaging worlds:

• Container path (legacy): docker/Dockerfile.rocm_base on main pins BASE_IMAGE=rocm/dev-ubuntu-22.04:7.2.3-complete, i.e. the legacy (non-TheRock) packaging line, with PyTorch built from the ROCm fork release/2.11 branch and pinned Triton / flash-attention / AITER (v0.1.16.post3) / MORI (v1.1.0) builds on top.
• Wheel path (already TheRock): the ROCm vLLM wheels at wheels.vllm.ai/rocm/ pull in TheRock-published rocm-sdk-core / rocm-sdk-libraries-gfx<target> wheels as transitive dependencies.

Now that TheRock is the production line, it would help downstream consumers (distributions, enterprise inference stacks, CI systems that build vLLM from source) to have a public plan for converging on it.

What this issue is asking for

Not an immediate version bump — rather, a tracking issue / statement of direction from maintainers and the AMD upstream team on:

1. Base image: Is a TheRock-based equivalent of rocm/dev-ubuntu-22.04:*-complete planned/available for Dockerfile.rocm_base? TheRock introduces a different packaging model (ROCm Core SDK + optional expansion SDKs, runfile installer, pip wheels) rather than the monolithic -complete apt install, so this is likely not a one-line change.
2. PyTorch pairing: ROCm 7.14 validates against PyTorch 2.12 (which also switches the PyTorch Profiler to rocprofiler-SDK as its ROCm backend). What's the plan for moving the Dockerfile.rocm_base PyTorch build from the ROCm fork release/2.11 branch, and does the ROCm/pytorch fork build cleanly against TheRock layouts?
3. Dependency pins: Do the current Triton, flash-attention, AITER, and MORI pins build and pass against 7.14/TheRock, or do they need coordinated bumps?
4. Convergence with the wheel path: Should the container build move toward the same rocm-sdk-* wheel approach the pip path already uses (which would unify the two install stories), or stay on OS packages?
5. Timeline: Which vLLM release is targeted to be the first validated against ROCm 7.14, for both main and the release Docker images (vllm/vllm-openai-rocm)? Note that vLLM upstream is already at v0.25.1 as of this writing, two minor releases ahead of the v0.23.0 that ROCm 7.14 packages, so there's already a version gap to close on top of the ROCm-version gap.
6. GPU coverage: Any expected changes to the supported PYTORCH_ROCM_ARCH set (currently gfx90a;gfx942;gfx950;gfx1100;gfx1101;gfx1200;gfx1201;gfx1150;gfx1151) when moving to TheRock builds?

Why now

• AMD's 7.14 release notes ship vLLM 0.23.0 packaged as deployment-ready inside the ROCm distribution, so the AMD-side integration clearly exists; upstream visibility on the convergence plan would help everyone else align.
• Downstream consumers (Linux distributions, enterprise inference products, wheel-building pipelines) need lead time to plan their own migrations off the legacy 7.2.x line, and the vLLM base image pin is the anchor for that planning.
• TheRock's fully open, pure-CMake build and public CI are a good fit for vLLM's recent push to make ROCm a first-class, continuously validated platform.

Alternatives

• Keep the container path on the legacy 7.2.x line until it reaches EOL and only then migrate — but this delays the benefits of TheRock's nightly releases and public CI, and leaves the container and wheel paths on divergent ROCm packaging indefinitely.
• Track this in ROCm/TheRock instead (there is an ecosystem: vLLM label there) — happy to move/cross-link if maintainers prefer that as the canonical location.

Additional context

Related: TheRock issues labeled ecosystem: vLLM: https://github.com/ROCm/TheRock/labels/ecosystem%3A%20vLLM

cc AMD upstream maintainers (feel free to tag the folks driving the ROCm first-class-platform work).

Before submitting a new issue...

• Make sure you already searched for relevant issues and read the documentation.

[github-actions]

CC @hongxiayang @tjtanaa @vllmellm @giuseppegrossi for ROCm-related issue