[Hardware][AMD][Perf][Bugfix] Update ROCr and clr in base image

[mawong-amd]

Purpose

This PR updates ROCR and CLR in the ROCm 7.2.3 vLLM base image to backport in some bugfixes for graph replay (which was segfaulting under replay of complex graphs under some workloads) and for kernel dispatch latency under some stream dependencies.

In particular, the latter fix improves decode performance measurably on a few workloads (particularly --async-scheduling and ModelRunner V2):

1. DeepSeek V4, ISL=1024, OSL=512, TP=8, gfx950. This translates to about 20% TPOT improvement in the best case at concurrency 1, shrinking to 9% at concurrency 64.
2. Kimi K3, ISL=1024, OSL=512, TP=8, gfx950. This translates to about 13% TPOT improvement in the best case at concurrency 1, shrinking to 4% at concurrency 64.

Test Plan

GSM8K was measured on a number of models and configs on both gfx950 and gfx942 and in line with numbers before the runtime change. Also, full AMD CI will be triggered on this PR.

Test Result

There should not be any regressions in AMD CI caused by this PR.

---

Essential Elements of an Effective PR Description Checklist

• The purpose of the PR, such as "Fix some issue (link existing issues this PR will resolve)".
• The test plan, such as providing test command.
• The test results, such as pasting the results comparison before and after, or e2e results
• (Optional) The necessary documentation update, such as updating supported_models.md and examples for a new model.

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[benenzhu]

Use a rocm repo not the personal ones will be better?

Or update the base image of rocm/dev-ubuntu-22.04:7.2.3-complete to rocm/dev-ubuntu-22.04:7.14.0-full

[mawong-amd]

It's not so simple to do a full migration to ROCm 7.14: that also brings in newer hipBLASLt, RCCL, etc, all of which needs to be verified for performance and numerical accuracy. See #49925 which has been a work in progress for a while.

The ROCm 7.2.4 runtimes are essentially the ROCm 7.2.3 runtimes with some bolt-on fixes/improvements and are drop-in safe. On top of ROCm 7.2.4, the runtime here also carries an incipient fix with large performance implications for some stream dependencies. With that in mind, it makes sense to bring it in as soon as possible, after appropriate testing on vLLM workloads.

[AndreasKaratzas]

This is actually an emergency patch. We have agreed to a proper follow up PR. So we will merge this for now and soon we'll redirect to the official rocm repo.

[stefanskiasan]

Data point from a different workload, in case it helps calibrate expectations: we overlaid exactly the two libraries this PR builds (libamdhip64.so.7.2.53211-c7e40e1, libhsa-runtime64.so.1.18.0, taken from vllm/vllm-openai-rocm:nightly 2026-09-02) onto a 7.2.3-based image and measured full GLM-5.3 (glm_moe_dsa, MXFP4 experts, fp8 KV, sparse MLA via the ROCm AITER path, MTP k=3, FULL cudagraphs) at TP4 on MI355X, same instance, same night, stock runtime vs. backport:

	decode bs=1	throughput 64 users	mean TPOT
stock 7.2.3 runtime (instance b)	121 / 122 tok/s	617 / 634 tok/s	45.6 / 44.6 ms
backport (instance b)	118 / 115 tok/s	619 / 630 tok/s	45.1 / 44.3 ms
stock 7.2.3 runtime (instance a)	124 / 120 tok/s	617 / 604 tok/s	45.5 / 46.6 ms
backport (instance a)	120 / 122 tok/s	570* / 615 tok/s	46.2 / 45.4 ms

(*coincided with a 235 MB/s model download on the host.) So no measurable change for this TP4 / sparse-MLA / MTP configuration — the DeepSeek-V4 TP8 gains presumably come from the stream-dependency pattern that our path does not have. Correctness unchanged (needle tests to 900k tokens, perplexity). Not a complaint, just a "your mileage may vary" for TP4 setups.