[TEST] Docker Image Updates Available - 2026-05-21

## Docker Image Updates Available New release tags have been detected on Docker Hub within the last 7 days. ### Updates Found | Image | New Tag | New Version | Current Version | Published | |-------|---------|-------------|-----------------|-----------| | `lmsysorg/sglang` | `v0.5.13-cu130` | v0.5.13 | v0.5.12 | 2026-05-19 | | `vllm/vllm-openai` | `v0.22.0` | v0.22.0 | v0.21.0 | 2026-05-18 | ### Self-Hosted Runner Snapshot _Source: https://inferencex-ci-tracker.vercel.app/api/ci at 2026-05-21T00:02:23Z_ | SKU | Total | Busy | Idle | Offline | Pressure | Available | |-----|-------|------|------|---------|----------|-----------| | `b200` | 12 | 10 | 2 | 0 | busy | yes | | `b300` | 18 | 0 | 18 | 0 | busy | yes | | `gb200` | 3 | 0 | 3 | 0 | clear | yes | | `gb300` | 7 | 3 | 4 | 0 | steady | yes | | `h100` | 19 | 0 | 19 | 0 | clear | yes | | `h200` | 18 | 5 | 13 | 0 | steady | yes | | `mi300x` | 8 | 7 | 1 | 0 | backlogged | yes | | `mi300x-disagg` | 1 | 1 | 0 | 0 | backlogged | no | | `mi325x` | 9 | 0 | 0 | 9 | clear | no | | `mi355x` | 9 | 0 | 9 | 0 | clear | yes | **Allowed SKUs for this run:** `gb200,h100,mi355x` ### Submission Staleness (single-node configs) _Source: https://inferencex.semianalysis.com/api/v1/submissions at 2026-05-21T00:02:23Z. Sorted oldest-first — older = higher priority for refresh._ <details> <summary>Show staleness table</summary> | Config | Days since | |--------|------------| | `dsr1-fp8-gb200-dynamo-sglang-disagg` | 167 | | `dsr1-fp4-gb200-dynamo-trt-disagg` | 167 | | `gptoss120b-fp4-mi355x-atom` | 127 | | `qwen3.5-fp8-b300-sglang` | 34 | | `glm5.1-fp4-mi355x-sglang` | 30 | | `gptoss120b-fp4-mi300x-vllm` | 30 | | `glm5.1-fp4-mi355x-atom` | 27 | | `dsv4-fp8-mi355x-sglang` | 26 | | `dsv4-fp4-b200-sglang` | 25 | | `dsv4-fp4-b300-sglang-mtp` | 24 | | `dsv4-fp8-mi355x-vllm` | 23 | | `dsv4-fp4-b300-sglang` | 22 | | `minimaxm2.5-fp4-mi355x-atom` | 21 | | `glm5-fp8-mi355x-atom` | 20 | | `qwen3.5-fp4-mi355x-atom` | 20 | | `dsv4-fp8-h200-sglang` | 19 | | `dsv4-fp8-h200-sglang-mtp` | 18 | | `minimaxm2.5-fp8-mi355x-atom` | 18 | | `dsv4-fp4-b300-trt` | 16 | | `dsv4-fp4-b200-trt` | 15 | </details> --- @claude Please update the configurations: 1. Update image tags in `.github/configs/nvidia-master.yaml` and/or `.github/configs/amd-master.yaml` 2. Add entries to `perf-changelog.yaml` documenting the version changes 3. For each eligible config-key, push a branch and actually open a PR — do not stop at the "Create a pull request for ..." remote hint that `git push` prints. Run `gh pr create` (or the equivalent MCP tool) and verify the returned PR URL. Link every PR back to this issue in a comment. **Pre-flight research (required before opening any PR):** For each image being bumped, read the upstream release notes for every version between the current tag and the new one — vLLM at `https://github.com/vllm-project/vllm/releases` (or `gh api repos/vllm-project/vllm/releases`), SGLang at `https://github.com/sgl-project/sglang/releases`. You are looking for two specific failure modes that have bitten prior runs: 1. **Suffix convention changes.** The default CUDA/ROCm build can shift between versions, which changes which Docker tag to pick. Concrete example: vLLM v0.21.0 promoted CUDA 13 to the default build, so the bare `v0.21.0` tag *is* the cu13 image and no `v0.21.0-cu13` tag exists — mechanically reusing the old suffix would point at a 404. Before settling on a tag, confirm it actually exists on Docker Hub (`curl -sf https://hub.docker.com/v2/repositories/<repo>/tags/<tag>/`) and that its build matches the runner's accelerator. If the convention shifted, use the new correct tag and call it out explicitly in the PR body. 2. **CLI flag deprecations or removals.** Server flags get removed between minors and the container exits with an error on startup, so this only surfaces during the e2e run. Concrete example: vLLM removed `--disable-log-requests` (silent-by-default; passing it now errors). Before opening the PR, `grep -rn` the repo for the launch flags actually passed to this image (check launch scripts, sbatch recipes, and any per-config templates — not just the master config). For every flag in use, check the release notes between current and new version for deprecations/removals/renames. If a flag was removed or renamed, fix it in the same PR and add a perf-changelog entry noting the flag change. If a flag has no replacement and is load-bearing, skip the config-key and explain in your wrap-up comment. List the release-notes URLs you consulted in the PR body so reviewers can audit the research. PRs that bump a tag without evidence of this check will be rejected. **Required PR label:** Every PR you open from this issue MUST carry the `full-sweep-enabled` label. Apply it at creation time via `gh pr create --label full-sweep-enabled` (or add it immediately after with `gh pr edit <num> --add-label full-sweep-enabled`). Do not skip this — downstream automation keys off the label. **PR title / commit message formatting:** Multi-line titles and bodies MUST use a heredoc, not `\n` escapes and not `$'...'` ANSI-C quoting. A prior run produced commits literally starting with `$` and containing `\n\n` as text because of mis-quoted ANSI-C strings. Use this pattern instead: ```bash git commit -m "$(cat <<'EOF' Update qwen3.5-bf16-b300-sglang-mtp SGLang image to v0.5.11-cu130 Ref #<this issue's number> EOF )" gh pr create --title "Update qwen3.5-bf16-b300-sglang-mtp SGLang image to v0.5.11-cu130" \ --label full-sweep-enabled \ --body "$(cat <<'EOF' Updates the SGLang image tag for `qwen3.5-bf16-b300-sglang-mtp` to v0.5.11-cu130. Ref #<this issue's number> EOF )" ``` PR titles must be a single line (no newlines). Bodies should contain real newlines (use a heredoc), not the literal characters `\n`. Never put `$` in front of a quoted message string. **Runner gating:** Only open PRs for config-keys whose runner SKU is in the allowed list (`gb200,h100,mi355x`). The runner SKU is the hardware segment in the config-key (e.g. `dsr1-fp4-b200-sglang` → `b200`). For any config-key whose SKU is not in the allowed list, skip it and list the skipped keys plus the reason (not clear / all-offline / no idle capacity) in a single comment on this issue. **Single-node only:** Skip any config-key whose master-config entry has `multinode: true` or otherwise targets a multinode runner. Only update single-node configurations. **Per-SKU cap (max 5):** For each allowed SKU, work on at most 5 config-keys. If a SKU has more than 5 eligible config-keys, pick 5 in alphabetical order and list the deferred remainder in your wrap-up comment on this issue so a future run can pick them up. **Sequential execution per SKU:** Within a single SKU, process config-keys one at a time. For each config-key: open the PR, dispatch its e2e test (`mcp__github__run_workflow` against `e2e-tests.yml` on the PR branch), poll with exponential backoff until the run reaches a terminal state (success/failure/cancelled), then move on to the next config-key for that SKU. Do not dispatch the next e2e run for the same SKU until the previous one has finished. Different SKUs may be processed in parallel since they target disjoint hardware, but each SKU's queue must stay serial. One PR per config-key — do not bundle multiple config-keys into one PR even when they share a framework or image family. **Exception — MTP pairs:** When a config-key and its `-mtp` sibling exist for the same model/precision/runner/framework (e.g. `qwen3.5-fp4-b300-sglang` and `qwen3.5-fp4-b300-sglang-mtp`), bundle both into one PR. Treat the pair as a single unit for the per-SKU cap (counts as 1, not 2) and the sequential e2e queue. If only one side of the pair is present in the updates, open a PR for just that one. If Docker Hub lists multiple variants for the same base version (e.g. `cu128` vs `cu130`, `rocm70` vs `rocm72`), pick the variant whose suffix matches what the config-key's current image entry already uses — don't switch CUDA/ROCm minor versions in this update.