[Klaud Cold] Remove dsv4-fp8-mi355x-sglang recipe

[functionstackx]

Summary

Removes the dsv4-fp8-mi355x-sglang recipe (and its orphan launch script benchmarks/single_node/dsv4_fp8_mi355x.sh). The current sglang ROCm MI355X image lineage cannot serve the DSV4-Pro-FP8 checkpoint without errors.

Why

Bump PR #1470 tried to advance the image from rocm/sgl-dev:deepseek-v4-mi35x → lmsysorg/sglang-rocm:v0.5.12-rocm720-mi35x-20260517. Every sweep job on the new image failed at server boot:

ValueError: Downcasting not allowed: target.dtype=torch.float8_e4m3fn,
loaded_weight.dtype=torch.bfloat16
File ".../sglang/srt/models/deepseek_v4.py:1544"
File ".../sglang/srt/utils/parameter.py:73 copy_with_check"

DSV4-Pro-FP8 has some bf16 layers (shared-expert / embedding); the old rocm/sgl-dev:deepseek-v4-mi35x was a custom build that tolerated this, the generic v0.5.12 ROCm MI355X release added a strict downcast check that we can't satisfy without an upstream change.

Path forward: if we re-introduce dsv4-fp8 on mi355x later, we'll either need (a) a re-bake of the custom image, (b) an upstream sglang change relaxing the downcast check, or (c) a DSV4 checkpoint that's pure fp8 with no bf16 layers. None of those are immediate, so leaving the recipe in place creates a permanently-FAILED config in every cron sweep — better to remove it cleanly.

Diff

• .github/configs/amd-master.yaml: drop dsv4-fp8-mi355x-sglang block (lines 1709-1727)
• benchmarks/single_node/dsv4_fp8_mi355x.sh: deleted (no remaining recipe references it)

Other dsv4-mi355x recipes (dsv4-fp4-mi355x-sglang, dsv4-fp4-mi355x-atom, dsv4-fp8-mi355x-vllm, dsv4-fp8-mi355x-atom) are untouched.

Test plan

• YAML loads (python3 -c "import yaml; yaml.safe_load(open('.github/configs/amd-master.yaml'))").
• No other config / script / doc references dsv4-fp8-mi355x-sglang or dsv4_fp8_mi355x.sh.
• Admin-merging without sweep (recipe removal — nothing to benchmark).

🤖 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.

[claude]

LGTM — clean removal of a permanently-failing recipe and its orphan launch script.

Extended reasoning...

Overview

This PR removes the dsv4-fp8-mi355x-sglang recipe block from .github/configs/amd-master.yaml and deletes its launch script benchmarks/single_node/dsv4_fp8_mi355x.sh. The motivation is sound and clearly explained: the upstream sglang ROCm MI355X image added a strict downcast check that rejects DSV4-Pro-FP8's bf16 layers, and the prior custom image is no longer being maintained, so this recipe was permanently failing in cron sweeps.

Security risks

None. This is a configuration removal — no auth, crypto, permissions, or input handling involved.

Level of scrutiny

Low. Pure deletion of a failing benchmark recipe and its orphan script. The change is mechanical, the blast radius is contained to one cron-sweep configuration, and the only externally-visible effect is one fewer (broken) job in the sweep.

Other factors

I verified the test plan claims: outside the deleted lines, the only remaining dsv4-fp8-mi355x references are in perf-changelog.yaml (historical log entries — appropriate to leave) and a comment referencing dsv4_fp8_mi355x_vllm.sh, which is a separate vllm script that still exists on disk. No orphan references to the deleted artifacts remain. Other dsv4-mi355x recipes (fp4-sglang, fp4-atom, fp8-vllm, fp8-atom) are untouched as advertised. No bugs reported by the bug hunting system.