夜间CI测试¶

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

背景¶

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

如何触发¶

1. 发布评论¶

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

注释	效果
`/nightly`	运行所有夜间测试
`/nightly all`	运行所有夜间测试（同上）
`/nightly test1 test2 ...`	仅运行指定名称的测试
`/nightly <tests> --aop_enabled`	运行指定测试并启用 AOP 二分/分类

Note

只有仓库的**贡献者**（Triage角色）和**维护者**（Write角色）才能触发/nightly命令。如果您没有此权限，请让维护者为您发布评论。您可以在项目的治理页面或通过查看 CODEOWNERS 文件找到维护者和贡献者列表。

2. 等待结果¶

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

PR运行与计划运行的区别¶

	Scheduled / Manual Dispatch	PR-triggered
触发方式	Cron（每日）或 `workflow_dispatch`	`/nightly` 评论
测试代码	预构建的夜间镜像	你 PR 的 HEAD 提交（源码全新安装）
测试范围	所有测试	可通过 `/nightly <names>` 配置
vLLM + vllm-ascend	来自镜像	从源码检出并安装
测试矩阵	来自主分支的矩阵 YAML	来自 PR 分支的矩阵 YAML

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

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

测试矩阵数据源¶

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

.github/workflows/configs/nightly_config.yaml

该文件以a2:和a3:作为顶层键组织（每个SoC一个）。在每个 SoC下，测试按执行形态分组（单节点、多节点、双节点、多卡、精度），每个组包含一个test_config（或精度相关的nightly / pr_only）列表，其条目包含name以及下游可复用工作流使用的字段（os、tests、config_file_path、size等）。

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

添加新的夜间测试用例¶

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

在.github/workflows/configs/nightly_config.yaml的相应部分下追加一个条目。每个条目至少需要：
name：在/nightly <name>过滤器中使用的唯一标识符
os（用于单节点/多卡pytest+yaml测试）或推断出的runner
tests:（pytest目录）或config_file_path:（YAML驱动的模型配置）之一
size（仅多节点/双节点）
添加实际的测试文件（tests/e2e/nightly/...下的pytest模块或 tests/e2e/nightly/.../configs/中的YAML模型配置）。
打开一个PR。一旦CI通过，您可以在**不**合并PR的情况下，针对真实的NPU 硬件验证新条目——请参阅下面的*示例*。

可用的测试名称¶

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

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

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

测试名称	描述
`test_custom_op_multi_card`	自定义算子测试（多卡）
`qwen3-vl-32b-instruct-w8a8`	Qwen3-VL-32B-Instruct W8A8
`qwen3-32b-int8`	Qwen3-32B INT8 量化
`Qwen3.5-27B-w8a8-A2`	Qwen3.5-27B W8A8
`Qwen3.5-397B-A17B-w4a8-mtp`	Qwen3.5-397B-A17B W4A8 + MTP

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

测试名称	描述
`multi-node-qwen3-235b-dp`	Qwen3-235B-A22B，2节点 DP
`multi-node-GLM-5.1-w8a8-A2`	GLM-5.1 W8A8，2节点
`multi-node-Kimi-K2.5-W4A8-A2`	Kimi-K2.5 W4A8，2节点

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

测试名称	描述	范围
`accuracy-group-1`	Qwen3-VL-8B、Qwen3-8B、Qwen2-Audio-7B 等	nightly
`accuracy-group-2`	ERNIE-4.5、Molmo-7B、Llama-3.2-3B 等	nightly
`accuracy-group-3`	Qwen3-30B-A3B、Qwen3-VL-30B-A3B 等	nightly
`accuracy-group-4`	Qwen3-Next-80B-A3B、Qwen3-Omni-30B-A3B 等	nightly
`pr-accuracy-group-1`	gemma-3-4b-it、internlm3-8b-instruct 等	pr_only
`pr-accuracy-group-2`	Qwen2.5-Math-RM-72B、Hunyuan-A13B-Instruct	pr_only

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

A3 工作流 (`.github/workflows/schedule_nightly_test_a3.yaml`)¶

多节点测试 (a3.multi_node.test_config，4 节点)：

测试名称	描述
`multi-node-deepseek-v3.2-W8A8-EP`	DeepSeek-V3.2-W8A8，EP，4节点

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

测试名称	描述
`multi-node-deepseek-r1-w8a8-longseq`	DeepSeek-R1-W8A8 长序列，2节点
`multi-node-qwen3-dp`	Qwen3-235B-A22B，2节点 DP
`multi-node-qwenw8a8-2node-eplb`	Qwen3-235B-W8A8，EPLB，2节点
`multi-node-dpsk3.2-2node`	DeepSeek-V3.2-W8A8，2节点
`multi-node-qwenw8a8-2node-longseq`	Qwen3-235B-W8A8 长序列，2节点
`multi-node-qwen-disagg-pd`	Qwen3-235B 分离式 PD，2节点
`multi-node-qwen-vl-disagg-pd`	Qwen3-VL-235B 分离式 PD，2节点
`multi-node-deepseek-v3.1`	DeepSeek-V3.1-BF16，2节点
`multi-node-deepseek-v3.2-W8A8-EP`	DeepSeek-V3.2-W8A8，EP，4节点
`multi-node-glm-5.2`	GLM-5.1-W8A8，2节点

单节点测试 (a3.single_node.test_config)：

测试名称	描述
`mtpx-deepseek-r1-0528-w8a8`	MTP-X + DeepSeek-R1-0528-W8A8
`deepseek-r1-0528-w8a8`	DeepSeek-R1-0528-W8A8
`kimi-k2-thinking`	Kimi-K2-Thinking
`qwen3-vl-235b-a22b-instruct-w8a8`	Qwen3-VL-235B-A22B-Instruct-W8A8
`deepseek-r1-0528-w8a8-prefix-cache`	DeepSeek-R1-0528-W8A8 前缀缓存
`deepseek-v3-2-w8a8`	DeepSeek-V3.2-W8A8
`glm-4.7-w8a8`	GLM-4.7 W8A8
`kimi-k2.5`	Kimi-K2.5
`qwen3-235b-a22b-w8a8`	Qwen3-235B-A22B-W8A8
`Qwen3.5-397B-A17B-w8a8-mtp`	Qwen3.5-397B-A17B W8A8 + MTP
`MiniMax-M2.5-w8a8-QuaRot-A3`	MiniMax-M2.5 W8A8 + QuaRot
`Qwen3.5-27B-w8a8-A3`	Qwen3.5-27B W8A8
`Qwen3.5-122B-A10B-W8A8-A3`	Qwen3.5-122B-A10B W8A8
`DeepSeek-V4-Flash-W8A8-A3`	DeepSeek-V4-Flash W8A8

多卡测试 (a3.multi_card.test_config)：

测试名称	描述
`qwen3-30b-acc`	Qwen3-30B 精度测试
`qwen3-30b-a3b-w8a8`	Qwen3-30B-A3B-W8A8
`qwen3-32b-int8`	Qwen3-32B-Int8
`qwen3-32b-int8-prefix-cache`	Qwen3-32B-Int8 前缀缓存
`Qwen3-30B-A3B-W4A8-llm-compressor`	Qwen3-30B-A3B W4A8（通过 llm-compressor）
`Qwen3-30B-QuaRot`	Qwen3-30B QuaRot + eagle3
`Qwen3-32B-QuaRot`	Qwen3-32B QuaRot + eagle3

Warning

A3 资源池的最大并发度为 5×16 NPU。多节点测试以 max-parallel: 2 运行，以避免资源耗尽。在 A3 上运行 /nightly all 会排队大量任务——尽可能优先指定具体的测试名称。

示例¶

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

/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 钩子（二分定位）¶

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

/nightly all --aop_enabled

启用后，工作流将：

捕获测试结果（通过/失败）。
分类失败为环境相关（网络、基础设施）或代码相关。
二分定位 真正的代码失败，以精确定位有问题的提交。

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

添加新测试用例——操作示例¶

要将 my-new-test 添加到 A2 单节点部分：

编辑 .github/workflows/configs/nightly_config.yaml，在 a2.single_node.test_config 下追加：

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

在同一 PR 中提交新的 pytest 文件 (test_my_new.py)。
从 PR 触发：

/nightly my-new-test

工作流将：

pr_nightly_command.yml 读取你 PR 的 nightly_config.yaml 并解析 my-new-test → 仅调度 A2。
Nightly-A2 在 main 上调度，但 generate-a2-matrix 检出你的 PR 提交并从矩阵中读取新条目。
single-node-tests 为 my-new-test 运行一个矩阵任务， should_run=true。可重用工作流检出你的 PR 代码（通过 vllm_ascend_ref）并运行你的 pytest。

故障排除¶

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

检查评论是否以 /nightly 精确开头，斜杠前没有前导空格或额外字符。
确认您至少拥有仓库的 Triage 权限；未经授权用户的评论将被忽略。
修复问题后如需重新触发，只需推送一个新提交——工作流将自动复用已有的 /nightly 评论。

只运行了部分测试，并非我期望的那些。

测试名称区分大小写，必须与 name 中的 .github/workflows/configs/nightly_config.yaml 字段完全匹配（参见上表）。
对于 PR 触发的运行，矩阵从您 PR 的 nightly_config.yaml 加载，而非主分支。如果某个名称不在您的 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