# PR #34204 完整报告

- 仓库：`sgl-project/sglang`
- 标题：[AMD][CI] Swap the AMD PR gate to ROCm 7.2 and demote ROCm 7.0 to a daily shadow
- 合并时间：2026-08-12 18:31
- 原文链接：http://prhub.com.cn/sgl-project/sglang/pull/34204

---

# 执行摘要

- 一句话：AMD PR 门禁切换至 ROCm 7.2，7.0 降为每日影子
- 推荐动作：该 PR 值得精读，尤其是 CI 门禁迁移策略、shadow 套件设计、任务归类和超时调整的实践。关注点：
 1) 从 7.0 重新生成 7.2 工作流以减少漂移的做法值得借鉴；
 2) 通过拆分 PR（如 Triton 安装）解耦风险和依赖；
 3) 将慢速夜间任务纳入 PR 门禁但缩短超时并修复退出码掩盖问题。

# 功能与动机

PR body 指出 ROCm 7.2 是 AMD 的发展方向，但 PR 门禁、夜间测试、发布裁剪和 CI 报告仍默认 ROCm 7.0，需要统一默认并保留 7.0 作为回退 shadow。提交记录中也提到 DeepSeek-V4 回归只能在次日被发现，且 Pro 任务在定时运行中退出 0 掩盖失败。

# 实现拆解

1. 重新生成 `pr-test-amd-rocm720.yml` 作为 PR 门禁：从 `pr-test-amd.yml` 重新生成，归一化 job id、`--rocm-version rocm720`、额外套件 `rocm_version` 和两个 DeepSeek-V4 任务，恢复 `runner_arch` 及按架构区分的超时和任务名。
2. 将 `pr-test-amd.yml` 降级为每日 17:30 UTC 的 ROCm 7.0 shadow：移除 `pull_request` 触发，与 `nightly-test-amd.yml` 协同触发，并移除所有 `max-parallel` 限制以追求覆盖率。
3. DeepSeek-V4 任务纳入 stage-C 门禁：`stage-c-dsv4-flash-fp4-fp8-amd-mi35x-rocm720` 和 `stage-c-dsv4-pro-fp4-amd-mi35x-rocm720`，超时从 300/480 分钟降至 60 分钟，并修复 Pro 任务在定时运行时吞掉退出码的问题。
4. 路由默认 AMD 路径至 7.2：`release-branch-cut.yml`、`bot-bump-sglang-version.yml` 调用 7.2 夜间套件；`amd-ci-job-monitor.yml` 和 `ci_failures_analysis.py` 默认报告 7.2，7.0 显式命名为 shadow。
5. 配套脚本调整：`amd_ci_install_dependency.sh` 根据容器 HIP 版本决定是否安装 AITER 固定的 Triton；`query_job_status.py` 默认 workflow 改为 `pr-test-amd-rocm720.yml`；`pr-test-amd-extra.yml` 默认 `rocm_version` 改为 `rocm720`。

关键文件：
- `.github/workflows/pr-test-amd-rocm720.yml`（模块 CI 工作流；类别 infra；类型 infrastructure）: 成为 AMD PR 门禁的核心工作流，从 7.0 版本重新生成并归一化差异，新增 DeepSeek-V4 任务和 runner_arch 支持。
- `scripts/ci_monitor/ci_failures_analysis.py`（模块 CI 监控；类别 source；类型 core-logic；符号 SGLangFailuresAnalyzer, get_recent_runs）: CI 失败分析脚本默认 workflow 从 7.0 切到 7.2，并补充排除 7.2 teardown 任务，确保报告反映门禁栈。
- `scripts/ci/amd/amd_ci_install_dependency.sh`（模块 安装脚本；类别 infra；类型 infrastructure）: 根据容器 HIP 版本决定是否安装 AITER 的 Triton，解决 ROCm 7.2 基础镜像 Triton 不匹配问题，并在 setup.py 之前前置安装以避免吞错。
- `.github/workflows/pr-test-amd.yml`（模块 CI 工作流；类别 infra；类型 infrastructure）: 降级为 ROCm 7.0 每日 shadow，移除 pull_request 触发和 max-parallel 限制，成为门禁的回退验证。
- `.github/workflows/amd-ci-job-monitor.yml`（模块 CI 工作流；类别 infra；类型 infrastructure）: CI 监控报告默认改为 7.2，7.0 显式命名为 Shadow，避免监控混淆两个栈。
- `scripts/ci/utils/query_job_status.py`（模块 CI 工具；类别 infra；类型 infrastructure；符号 main）: 查询脚本默认 workflow 改为 7.2，避免手动执行时误查 7.0 数据。
- `.github/workflows/pr-test-amd-extra.yml`（模块 CI 工作流；类别 infra；类型 infrastructure）: 额外套件默认 rocm_version 改为 rocm720，并显式传递 --rocm-version，确保 PR 事件下使用 7.2 容器。

关键符号：未识别

## 关键源码片段

### `scripts/ci_monitor/ci_failures_analysis.py`

CI 失败分析脚本默认 workflow 从 7.0 切到 7.2，并补充排除 7.2 teardown 任务，确保报告反映门禁栈。

```python
# 核心变更：排除 7.2 teardown 任务，避免将其误判为失败
self.excluded_jobs = [
    "check-changes",
    "pr-test-finish",  # Nvidia workflow teardown
    "pr-test-amd-finish",  # AMD workflow teardown（ROCm 7.0 shadow）
    "pr-test-amd-rocm720-finish",  # 默认 AMD ROCm 7.2 teardown
    "call-gate",
    "pr-gate",
    "check-all-jobs",
]

# 所有 AMD workflow 过滤统一指向 7.2 门禁
pr_test_amd_scheduled_runs = analyzer.get_recent_runs(
    limit=pr_test_scheduled_limit,
    workflow_filter=["pr-test-amd-rocm720.yml"],
    filters={"branch": "main"},
)

```

### `scripts/ci/amd/amd_ci_install_dependency.sh`

根据容器 HIP 版本决定是否安装 AITER 的 Triton，解决 ROCm 7.2 基础镜像 Triton 不匹配问题，并在 setup.py 之前前置安装以避免吞错。

```bash
# 根据镜像 HIP 版本决定是否安装 AITER 的 Triton（ROCm 7.0 用基础镜像自带版）
IMAGE_HIP_VERSION=$(docker exec ci_sglang python3 -c 'import torch; print(torch.version.hip or "")')
case "${IMAGE_HIP_VERSION}" in
  7.0*) INSTALL_AITER_TRITON="false" ;;
  7.*) INSTALL_AITER_TRITON="true" ;;
  *)
    echo "[CI-AITER-CHECK] ERROR: Unsupported or empty HIP version: '${IMAGE_HIP_VERSION}'"
    exit 1
    ;;
esac

# 重建 AITER 前先装 Triton：setup.py 会吞错误，放在这里可 fail closed
if [[ "${INSTALL_AITER_TRITON}" == "true" ]]; then
  docker exec ci_sglang bash -c "
    set -euo pipefail
    cd /sgl-workspace/aiter
    test -f .github/scripts/install_triton.sh
    bash .github/scripts/install_triton.sh
  "
fi

```

# 评论区精华

该 PR 无 review 评论。唯一审核人 HaiShaw APPROVED。提交记录中体现了多次设计权衡，例如：将 Triton 安装拆分为独立 PR #34364，避免镜像变更阻塞门禁切换；DeepSeek-V4 任务名增加所属 stage 和 runner 标识，提升可观测性；AITER Triton 安装前置，避免 setup.py 吞错导致静默失败。

- 暂无高价值评论线程

# 风险与影响

- 风险：风险点包括：
 1) `pr-test-amd-rocm720.yml` 之前作为非门禁 side workflow 已漂移，重新生成后仍需验证是否与现有 PR 覆盖一致；
 2) ROCm 7.0 shadow 不再有 PR 门禁，若 7.0 回归将延迟到每日感知；
 3) DeepSeek-V4 任务纳入 PR 门禁后，每次 PR 增加约 18 分钟 × 2 任务成本，`linux-mi35x-gpu-8` 峰值并发从 3 升至 5，可能加剧 GPU runner 资源竞争；
 4) `ci_failures_analysis.py` 将默认 workflow 指向 7.2，若 7.2 出现系统性崩溃，分析报告可能失真；
 5) `amd_ci_install_dependency.sh` 根据 HIP 版本决策 Triton 安装，若基础镜像变化可能产生误判。
 - 影响：影响范围：AMD CI 基础设施、CI 监控报告、发布流程、版本 bump 机器人验证链路。对开发者：AMD PR 门禁覆盖 ROCm 7.2，新增两个 DeepSeek-V4 任务；对系统：GPU runner 并发压力增加，7.0 降级为每日 shadow，回退能力保留但响应变慢；对团队：需要关注 7.2 门禁的稳定性，若 7.2 不稳定需快速回切。
 - 风险标记：核心 CI 门禁变更 , GPU 并发压力增加 , ROCm 7.0 降级为每日 shadow, 依赖 AITER Triton 安装逻辑

# 关联脉络

- PR #34324 unknown: PR body 提到拾取了 #34324 的 stage-C max-parallel: 2 变更，说明该 PR 与 34324 在同一 CI 工作流有耦合。
- PR #34364 unknown: 提交记录提到将 ROCm 7.2 Triton 安装拆分为 #34364，本 PR 只做门禁切换，两者相互独立。