[Klaud Cold] Update kimik2.5-int4-mi325x-vllm vLLM ROCm image to v0.21.0

[functionstackx]

Summary

Update vLLM ROCm image from v0.18.0 (52d old) to v0.21.0

Recipes touched: `kimik2.5-int4-mi325x-vllm`

Test plan

• full-sweep-enabled sweep passes.

🤖 Generated with Claude Code

[github-actions]

Thanks for the contribution! For vLLM & SGLang, please ensure that your recipes is similar to the official vLLM recipes and/or the SGLang cookbook

• https://docs.sglang.io/cookbook/intro
• https://recipes.vllm.ai/

If it is not, please create a PR first before we can merge your single node PR into the master branch. Let's ensure that the documentation is first class such that the entire ML community can benefit from your hard work! Thank you

• https://github.com/vllm-project/recipes
• https://github.com/sgl-project/sglang/tree/main/docs_new

PR authors are responsible for ensuring that after merging, all GitHub Action jobs fully pass. A lot of the time, failures are just flakes and simply re-running the failed jobs will fix it. If re-running failed jobs is attempted, PR authors are responsible for ensuring it passes. See GitHub's docs on re-running failed jobs: https://docs.github.com/en/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs#re-running-failed-jobs-in-a-workflow

As a rule of thumb, generally, PR authors should request a review & get a PR approval from the respective companies' CODEOWNERS before requesting a review from core maintainers.

If additional help is needed, PR authors can reach out to core maintainers over Slack.

[github-actions]

Thanks for the contribution! For vLLM & SGLang, please ensure that your recipes is similar to the official vLLM recipes and/or the SGLang cookbook

• https://docs.sglang.io/cookbook/intro
• https://recipes.vllm.ai/

If it is not, please create a PR first before we can merge your single node PR into the master branch. Let's ensure that the documentation is first class such that the entire ML community can benefit from your hard work! Thank you

• https://github.com/vllm-project/recipes
• https://github.com/sgl-project/sglang/tree/main/docs_new

PR authors are responsible for ensuring that after merging, all GitHub Action jobs fully pass. A lot of the time, failures are just flakes and simply re-running the failed jobs will fix it. If re-running failed jobs is attempted, PR authors are responsible for ensuring it passes. See GitHub's docs on re-running failed jobs: https://docs.github.com/en/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs#re-running-failed-jobs-in-a-workflow

As a rule of thumb, generally, PR authors should request a review & get a PR approval from the respective companies' CODEOWNERS before requesting a review from core maintainers.

If additional help is needed, PR authors can reach out to core maintainers over Slack.

[github-actions]

Thanks for the contribution! For vLLM & SGLang, please ensure that your recipes is similar to the official vLLM recipes and/or the SGLang cookbook

• https://docs.sglang.io/cookbook/intro
• https://recipes.vllm.ai/

If it is not, please create a PR first before we can merge your single node PR into the master branch. Let's ensure that the documentation is first class such that the entire ML community can benefit from your hard work! Thank you

• https://github.com/vllm-project/recipes
• https://github.com/sgl-project/sglang/tree/main/docs_new

PR authors are responsible for ensuring that after merging, all GitHub Action jobs fully pass. A lot of the time, failures are just flakes and simply re-running the failed jobs will fix it. If re-running failed jobs is attempted, PR authors are responsible for ensuring it passes. See GitHub's docs on re-running failed jobs: https://docs.github.com/en/actions/how-tos/manage-workflow-runs/re-run-workflows-and-jobs#re-running-failed-jobs-in-a-workflow

As a rule of thumb, generally, PR authors should request a review & get a PR approval from the respective companies' CODEOWNERS before requesting a review from core maintainers.

If additional help is needed, PR authors can reach out to core maintainers over Slack.

[github-actions]

see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=26009957188
see unofficial run visualizer at https://inferencex.semianalysis.com/evaluation?unofficialRun=26009957188

[claude]

LGTM, simple image version bump aligning kimik2.5-int4-mi325x-vllm with its mi355x/mi300x siblings already on v0.21.0.

Extended reasoning...

Overview

This PR bumps the vLLM ROCm image for the kimik2.5-int4-mi325x-vllm recipe from v0.18.0 to v0.21.0 in .github/configs/amd-master.yaml, and adds a corresponding entry to perf-changelog.yaml. Two-line YAML change plus a changelog entry.

Security risks

None. This is a container image tag update in benchmark/recipe configuration; no auth, crypto, or permission paths are touched.

Level of scrutiny

Low. This is a mechanical version bump following the same pattern as recent similar PRs (e.g., #1458). The new version (v0.21.0) is already in use by the sibling kimik2.5-int4-mi355x-vllm and kimik2.5-int4-mi300x-vllm recipes in the same file, so this just brings mi325x into alignment.

Other factors

• No bugs surfaced by the bug-hunting system.
• The PR is labeled full-sweep-enabled, so CI will exercise the new image.
• The perf-changelog entry correctly references PR #1468 and the touched config key.

[functionstackx]

Diagnosis

Not OOM -- the failures are caused by enroot import failing to create the squashed container image on the mi325x cluster. During enroot-aufs2ovlfs conversion, the tool cannot set file capabilities on the NFS-backed storage (/nfsdata/sa/gharunner/gharunners/squash/), producing dozens of enroot-aufs2ovlfs: failed to set capabilities: Operation not permitted errors and exiting with code 34. The .sqsh file is never created, so the subsequent srun --container-image=... fails with [ERROR] No such file or directory: /nfsdata/sa/gharunner/gharunners/squash/vllm_vllm-openai-rocm_v0.21.0.sqsh. All 7 failed jobs show the identical pattern. The benchmark script (kimik2.5_int4_mi325x.sh) is never reached.

This is a cluster infrastructure issue, not a code issue -- the v0.21.0 ROCm image triggers setcap calls that fail on the mi325x NFS mount. The v0.18.0 image apparently had fewer/no files requiring capabilities. Sibling PRs #1467 (gptoss-fp4-mi325x) and #1469 (minimaxm2.5-fp8-mi325x) have the same failure on the same cluster.

Failed run: https://github.com/SemiAnalysisAI/InferenceX/actions/runs/26009958929

No code fix pushed

This cannot be resolved by adjusting --gpu-memory-utilization or other vLLM flags -- the container never starts. Potential infra-level fixes:

1. Mount NFS with user_xattr support, or grant runners CAP_SETFCAP
2. Switch mi325x squash storage to local disk (like mi355x uses /var/lib/squash/)
3. Use ENROOT_ALLOW_SUPERUSER=y or add retry logic to runners/launch_mi325x-amds.sh line 27

[github-actions]

see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=26009958929
see unofficial run visualizer at https://inferencex.semianalysis.com/evaluation?unofficialRun=26009958929

[github-actions]

see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=26010694652
see unofficial run visualizer at https://inferencex.semianalysis.com/evaluation?unofficialRun=26010694652

[functionstackx]

/reuse-sweep-run

[github-actions]

see unofficial run visualizer at https://inferencex.semianalysis.com/inference?unofficialRun=26013870761
see unofficial run visualizer at https://inferencex.semianalysis.com/evaluation?unofficialRun=26013870761