夜间 CI 测试¶

本文档说明如何在 Ascend NPU 硬件（A2/A3）上针对您自己的 PR 代码触发夜间硬件 CI 测试，而无需等待预定的夜间运行。

背景¶

默认情况下，夜间 CI 测试按固定计划使用预构建的夜间镜像运行。贡献者可以通过结合 GitHub 标签和评论命令，自助地直接针对其 PR 更改触发这些测试。

如何触发¶

1. 发表评论¶

在 PR 中发表以下评论之一，以指定要运行的测试。评论本身就会触发工作流——无需标签。

2. 等待结果¶

GitHub Actions 将触发 Nightly-A2 或 Nightly-A3 工作流。只有与过滤器匹配的测试才会被调度，从而节省硬件资源。

PR 运行与计划运行之间的差异¶

当检测到 PR 运行时（is_pr_test: true），工作流还会：

1. 卸载容器中所有现有的 vllm 软件包。
2. 从源码检出特定的 vllm 版本以及您 PR 的 vllm-ascend 提交。
3. 从源码安装所有依赖。
4. 安装 aisbench 基准测试套件。

测试矩阵数据来源¶

夜间测试用例集合（其名称、运行器、测试路径、模型配置）在单个数据文件中声明：

.github/workflows/configs/nightly_config.yaml

该文件以 a2: 和 a3: 顶级键组织（每个 SoC 一个）。在每个 SoC 下，测试按执行形态（single-node、multi-node、double-node、multi-card、accuracy）分组，每个组包含一个 test_config（或 accuracy 的 nightly / pr_only）列表，其条目带有 name 以及下游可复用工作流使用的字段（os、tests、config_file_path、size 等）。

Nightly-A2 和 Nightly-A3 工作流都会在运行时动态读取此文件——工作流 YAML 中没有硬编码的测试矩阵。/nightly <name> 斜杠命令通过遍历 PR 分支中的同一文件来解析名称，因此新添加的条目可以在合入 main 之前先在 PR 上运行验证。

添加新的夜间测试用例¶

要添加新的测试用例（无需修改工作流 YAML）：

1. 在 .github/workflows/configs/nightly_config.yaml 的相应部分下追加一个条目。每个条目至少需要：
2. name：用于 /nightly <name> 过滤器的唯一标识符
3. os（用于 single-node / multi-card 的 pytest+yaml 测试）或 runner（自动推断）
4. tests:（pytest 目录）或 config_file_path:（由 YAML 驱动的模型配置）二者之一
5. size（仅 multi-node / double-node）
6. 添加实际的测试文件（tests/e2e/nightly/... 下的 pytest 模块或 tests/e2e/nightly/.../configs/ 下的 YAML 模型配置）。
7. 打开 PR。一旦 CI 通过，您就可以无需合并 PR 即可在真实 NPU 硬件上验证新条目 —— 请参阅下面的 示例。

可用测试名称¶

您可以传递给 /nightly 的测试名称对应于 .github/workflows/configs/nightly_config.yaml 中匹配部分下的 name 字段。下表反映了该文件的当前内容。

A2 工作流（.github/workflows/schedule_nightly_test_a2.yaml）¶

单节点测试（a2.single_node.test_config）：

多节点测试（a2.multi_node.test_config）：

精度测试（a2.accuracy.nightly 和 a2.accuracy.pr_only）：

pr-accuracy-group-* 条目仅在 /nightly（PR 触发）运行中执行；计划任务中的 /nightly all 会跳过它们。

A3 工作流（.github/workflows/schedule_nightly_test_a3.yaml）¶

多节点测试（a3.multi_node.test_config，4 节点）：

双节点测试（a3.double_node.test_config，2 节点，在多节点测试之后运行）：

单节点测试（a3.single_node.test_config）：

多卡测试（a3.multi_card.test_config）：

示例¶

针对你的 PR 运行所有可用的夜间测试：

/nightly

仅运行自定义算子多卡测试：

/nightly test_custom_op_multi_card

同时运行两个指定测试（每个 SoC 一个）：

/nightly test_custom_op_multi_card mtpx-deepseek-r1-0528-w8a8

运行单个精度组（包含其所有模型）：

/nightly accuracy-group-1

运行单个精度模型（仅运行组中的该模型）：

/nightly accuracy-group-1/Qwen3-8B

修复问题后重新触发：只需推送一个新提交。synchronize 事件 会重新运行工作流，并自动获取现有的 /nightly 评论——无需 发布新评论。

AOP 钩子（Bisect）¶

在任何 /nightly 命令中添加 --aop_enabled 以启用 AOP 流水线：

/nightly all --aop_enabled

启用后，工作流将：

1. 捕获测试结果（通过 / 失败）。
2. 分类失败是环境相关（网络、基础设施）还是代码相关。
3. 二分查找真正的代码失败，以定位问题提交。

这对于夜间回归的自动化根因分析非常有用。

添加新测试用例 — 示例¶

要将 my-new-test 添加到 A3 多卡部分：

1. 编辑 .github/workflows/configs/nightly_config.yaml，在 a3.multi_card.test_config 下追加：

  - name: my-new-test
    os: linux-aarch64-nightly-a3-4
    tests: tests/e2e/nightly/single_node/ops/multicard_ops_a3/test_my_new.py

1. 在同一 PR 中提交新的 pytest 文件（test_my_new.py）。

2. 从 PR 触发：

/nightly my-new-test

工作流将：

• pr_nightly_command.yml 读取你 PR 的 nightly_config.yaml，并解析 my-new-test → 仅调度 A3。
• Nightly-A3 在 main 上被调度，但 setup-vars 会检出你的 PR 提交，并从矩阵中读取新条目。
• multi-card-tests 为 my-new-test 运行一个矩阵任务，且 should_run=true。可复用工作流会检出你的 PR 代码（通过 vllm_ascend_ref）并运行你的 pytest。

故障排查¶

我发布评论后工作流没有启动。

• 检查评论是否恰好以 /nightly 开头，斜杠前没有前导空格或 其他字符。
• 确认你在仓库中至少具有 Triage 权限；未授权 用户的评论会被忽略。
• 修复问题后重新触发时，只需推送一个新提交——工作流将 自动复用现有的 /nightly 评论。

只运行了部分测试，而不是我预期的测试。

• 测试名称区分大小写，并且必须与 .github/workflows/configs/nightly_config.yaml 中的 name 字段 完全匹配（参见上表）。
• 对于 PR 触发的运行，矩阵从你的 PR 的 nightly_config.yaml 加载，而不是 main。如果某个名称不在你的 PR 文件中，它不会 被识别，调度将被跳过。
• 在 GitHub Actions 中检查 parse-trigger 任务的输出，查看解析后的 test_filter 值。

工作流使用了计划任务镜像运行，而不是我的 PR 代码。

• 确认工作流是由 repository_dispatch（斜杠命令）触发的， 而不是单纯的 workflow_dispatch。pr_nightly_command.yml 工作流才是 实际调度 schedule_nightly_test_a2.yaml / _a3.yaml 的工作流，并且 vllm_ascend_ref 指向你的 PR SHA。

我新增的测试未被识别。

• 请确认 .github/workflows/configs/nightly_config.yaml 下的条目是格式正确的 YAML。name 字段为必填项，并且必须在 SoC 的相应部分中唯一。
• 矩阵会从您的 PR 分支加载，因此请确保该文件已提交到发布 /nightly 评论的同一分支。

如何获取更详细的日志以定位多节点测试中的问题

• 对于大多数问题，GitHub Actions 的 stdout 弹出日志已经足够（该日志始终表示第一个节点的日志）。
• 如果第一个节点的日志已不足以提供有效的日志信息，请查看您的作业摘要，以下载对应测试的日志归档。该归档包含每个节点的框架侧日志和 plog 信息，结构如下：

.
├── node0
│   ├── root
│   │   └── ascend
│   │       └── log
│   └── var
│       └── log
│           └── vllm-deepseek-v3-0f233d-0_logs.txt
└── node1
    ├── root
    │   └── ascend
    │       └── log
    └── var
        └── log
            └── vllm-deepseek-v3-0f233d-0-1_logs.txt