QA 验收测试#

.github/workflows/ops-test.yaml 是 FlagGems 的全量算子 QA 验收测试工作流。 它会在所有已支持的硬件后端上运行精度与性能测试套件，并将结果上传到 op-monitor 看板。本文介绍该工作流的测试环境、测试配置，以及本地复现方法。

1. 测试环境#

每个后端都在挂载了真实加速卡的自托管 runner 上，通过专属容器运行。 容器镜像、挂载的目录以及运行时选项均按后端单独配置，以保证容器内可以 正常使用各厂商自己的驱动栈与 SDK。

.github/configs/backends/config.yaml 中当前启用的后端如下：

每个后端配置还会设置：

• runner_labels：该任务绑定的自托管 runner 标签。
• container_volumes / container_options：主机挂载目录（/data、/home、 /tmp）以及容器参数，例如 --privileged、--ipc=host，以及厂商专属的 设备/加速卡参数（如 Nvidia 上的 --gpus all）。
• test_gpus / force_test_gpus：要测试的设备编号；部分厂商（如 KunLunXin） 会跳过编号为 0 的设备，部分厂商会强制使用固定的设备列表而不依赖可用性探测。
• gpu_check_script：各厂商专属的脚本（如 tools/gpu_check_nvidia.sh）， 会在测试开始前等待出现满足空闲显存要求的设备。
• output_base_dir：测试结果归档在 runner 主机上的存放位置。

在容器内，工作流会以 test extra 安装 FlagGems（pip install .[test]）， 对应 pyproject.toml 中声明的 pytest、coverage、pandas、openpyxl 等用于测试与报告生成的依赖。

2. 测试配置#

后端选择#

.github/configs/backends/config.yaml 是总开关：它列出了全部后端以及 各自是否 enabled。工作流的 prepare job 会读取该文件，为每个启用的 后端加载对应的 .github/configs/backends/<NAME>.yaml，并据此构建 job 矩阵。workflow_dispatch 的 vendors 输入可以进一步将矩阵缩小到指定的 厂商子集（逗号分隔、大小写不敏感），例如 Ascend,Nvidia。

算子选择#

算子列表来自 conf/operators.yaml，其中每个算子条目都声明了自己所处的 stages（alpha、beta、stable、removed）。tools/run_tests.py 通过 --stages 过滤（默认 stable）；工作流将其封装为 ops 输入：

• 留空（定时任务或手动触发不填写时的默认值）-> 对应 --stages all， 即测试所有阶段的算子。
• 填写以逗号分隔的算子 ID 列表（如 abs,sum,add）-> 对应 --ops <list>，仅测试指定算子。

Enflame（S60）是个例外：它不使用 --stages all，而是从 runner 上固定的 /data/flaggems/ops_list.txt 文件读取 --op-list-file。

结果发布#

两个 workflow_dispatch 输入控制一次运行的副作用：

• upload_log：留空时会通过 secrets.OPMON_URL / secrets.OPMON_UPLOAD_KEY 将结果归档发布到 op-monitor；填写任意值则跳过“Publish results to op-monitor”步骤。
• send_feishu：留空时会通过 .github/scripts/notify_feishu.py 发送飞书 通知；填写任意值则跳过该步骤。

3. 本地复现方法#

该工作流本质上是对 tools/run_tests.py 以及几个报告生成脚本的封装， 因此只要本机已安装好目标加速卡及其驱动/SDK，就可以直接执行相同的步骤 来复现测试。

1. 以 test extra 安装 FlagGems：

pip install .[test]

2. 确认加速卡处于空闲状态且有足够的空闲显存（CI 中由各厂商的 gpu_check_script，例如 tools/gpu_check_nvidia.sh，自动等待）。 确定要测试的设备编号，例如 0,1,2,3。

3. 清理可能存在的 Triton/FlagGems 缓存，然后运行测试调度器。以下命令 与工作流中“Run ops tests”步骤一致：

rm -rf ~/.triton/cache && rm -rf ~/.flaggems

# Run every stable-stage operator on 4 devices, mirroring the "ops: all" case.
python3 tools/run_tests.py \
    --gpus 0,1,2,3 \
    --stages all \
    --dump-output \
    --output logs_results_$(date +%Y%m%d_%H%M)

如果想复现 ops 输入指定算子（而非全量阶段）的场景，可以改用 --ops 参数传入逗号分隔的算子列表，对应工作流中非空的 ops 输入：

python3 tools/run_tests.py --gpus 0,1,2,3 --ops "abs,sum,add" --dump-output

4. 生成与 CI 任务相同的汇总产物（算子标签、CSV 以及 HTML 报告）：

OUTPUT_DIR=logs_results_<date>_<time>
python3 tools/add_labels.py "${OUTPUT_DIR}"
python3 tools/psum_text -o "${OUTPUT_DIR}/result.csv"  "${OUTPUT_DIR}"
python3 tools/psum_html -o "${OUTPUT_DIR}/result.html" "${OUTPUT_DIR}"

5. 查看 ${OUTPUT_DIR}/summary.json 获取汇总的通过/失败结果，或打开 ${OUTPUT_DIR}/result.html 查看可读性更好的报告。每个算子还会生成 独立的 <op_name>/accuracy_result.json 和 <op_name>/performance_result.json，若传入 --dump-output，还会生成 对应的 stdout/stderr 日志。

如果不在本地复现，而是想在 CI 中触发同样的运行，可以手动分发该工作流 （Actions -> ops-test -> Run workflow），并填写上文介绍的输入项： branch、vendors、ops、upload_log、send_feishu。

关于 tools/run_tests.py 底层所调用的 pytest 选项，请参阅 测试 Python 算子。