[Klaud Cold] Update gptoss-fp4-mi325x-vllm vLLM ROCm image to v0.21.0

[functionstackx]

Summary

Update vLLM ROCm image from v0.17.0 (70d old) to v0.21.0

Recipes touched: `gptoss-fp4-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=26009953602
see unofficial run visualizer at https://inferencex.semianalysis.com/evaluation?unofficialRun=26009953602

[claude]

LGTM — straightforward vLLM ROCm image version bump for a single recipe, with corresponding changelog entry.

Extended reasoning...

Overview

This PR bumps the gptoss-fp4-mi325x-vllm recipe's image from vllm/vllm-openai-rocm:v0.17.0 to v0.21.0 (a single-line change in .github/configs/amd-master.yaml) and adds a matching entry to perf-changelog.yaml. Only one recipe is touched.

Security risks

None. These are benchmark config files (image tag + changelog text), not production code or auth/permissions changes.

Level of scrutiny

Low. This is a mechanical image version bump on a perf benchmark recipe, with no logic changes. The target version v0.21.0 is already in use elsewhere in the same file (kimik2.5-*-vllm, minimaxm2.5-*-vllm, gptoss-fp4-mi355x-vllm), so it's a well-validated image tag in this repo.

Other factors

The bug hunting system found no issues. The full-sweep-enabled label means the sweep itself will validate the new image works for this recipe before merge — if the image is broken, CI will catch it. Changelog format matches the existing pattern in the file.

[functionstackx]

Diagnosis

All 11 failed jobs landed on the same broken node chi-mi325x-pod1-121.ord.vultr.cpe.ice.amd.com. The enroot squashfs import fails with enroot-aufs2ovlfs: failed to set capabilities: Operation not permitted (repeated 30+ times per job), leaving the container image missing ([ERROR] No such file or directory: /nfsdata/sa/gharunner/gharunners/squash/vllm_vllm-openai-rocm_v0.21.0.sqsh). The benchmark script never starts — this is a node-level infrastructure issue, not an OOM or code bug.

The 8 successful jobs ran on healthy nodes (018, 019, 020, 027) and completed normally. The successful tp=8 benchmark shows 223.71 GiB available KV cache memory with --gpu-memory-utilization 0.95, confirming no memory pressure.

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

No code fix needed

This failure is caused by node chi-mi325x-pod1-121 being unable to run enroot container imports (capability-setting permission error). The fix is infrastructure-level: either repair or exclude that node from the Slurm partition. Re-running the sweep should schedule failed jobs on healthy nodes and pass.

Note: the --gpu-memory-utilization 0.90 fix from PR #1403 (mi300x sibling) is not needed here — mi325x has sufficient headroom at 0.95 based on successful runs.

[github-actions]

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

[github-actions]

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

[functionstackx]

/reuse-sweep-run

[github-actions]

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