Nightly CI 测试

Nightly CI 测试#

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

背景#

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

如何触发#

1.发布评论#

首先，在 PR 中发布以下评论之一，以指定要运行的测试：

评论

效果

/nightly

运行所有 nightly 测试

/nightly all

运行所有 nightly 测试（与上同）

/nightly test1 test2 ...

仅运行指定名称的测试

2.添加标签#

发布评论后，为 PR 添加 nightly-test 标签。添加标签才是实际触发工作流的操作——此时工作流会读取现有评论以找到 /nightly 命令。

备注

只有仓库的贡献者（Triage 角色）和维护者（Write 角色）可以添加标签。如果您没有此权限，请让维护者为您添加标签。您可以在项目的治理页面或通过查看 CODEOWNERS 文件找到维护者和贡献者列表。

重要

评论必须在添加标签之前发布。如果您先添加标签，工作流将找不到 /nightly 评论并跳过所有测试。

3.等待结果#

GitHub Actions 将触发 Nightly-A2 或 Nightly-A3 工作流。只有与筛选条件匹配的测试会被分发，从而节省硬件资源。

PR 触发与定时运行的区别#

定时/手动触发

PR 触发

触发方式

Cron（每日）或 workflow_dispatch

标签 nightly-test + /nightly 评论

测试的代码

预构建的 nightly 镜像

您的 PR 的 HEAD 提交（从源码全新安装）

测试范围

所有测试

可通过 /nightly <名称> 配置

vLLM + vllm-ascend

来自镜像

从源码检出并安装

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

  1. 卸载容器中任何已有的 vllm 包。

  2. 从源码检出特定的 vllm 版本以及您 PR 中的 vllm-ascend 提交。

  3. 从源码安装所有依赖。

  4. 安装 aisbench 基准测试套件。

可用的测试名称#

您可以传递给 /nightly 的测试名称对应于工作流矩阵中的 name 字段。

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

单节点测试：

测试名称

描述

test_custom_op

自定义算子测试（单卡）

test_custom_op_multi_card

自定义算子测试（多卡）

qwen3-32b

Qwen3-32B 模型测试

qwen3-next-80b-a3b-instruct

Qwen3-Next-80B-A3B-Instruct 模型测试

qwen3-32b-int8

Qwen3-32B INT8 量化测试

accuracy-group-1

精度测试：Qwen3-VL-8B、Qwen3-8B、Qwen2-Audio-7B 等。

accuracy-group-2

精度测试：ERNIE-4.5、InternVL3_5-8B、Molmo-7B、Llama-3.2-3B 等。

accuracy-group-3

精度测试：Qwen3-30B-A3B、Qwen3-VL-30B-A3B 等。

accuracy-group-4

精度测试：Qwen3-Next-80B-A3B、Qwen3-Omni-30B-A3B 等。

多节点测试：

测试名称

描述

multi-node-deepseek-dp

DeepSeek-R1-W8A8，2 节点 DP

multi-node-qwen3-235b-dp

Qwen3-235B-A22B，2 节点 DP

备注

A2 工作流中的 doc-test 任务仅在 schedule 或 workflow_dispatch 事件上运行——即使在 PR 触发的运行中使用 /nightly all，它也不会运行。

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

多节点测试（优先运行，单节点测试等待这些完成后执行）：

测试名称

描述

multi-node-deepseek-pd

DeepSeek-V3，2 节点 PD 分离

multi-node-qwen3-dp

Qwen3-235B-A22B，2 节点 DP

multi-node-qwenw8a8-2node

Qwen3-235B-W8A8，2 节点

multi-node-qwenw8a8-2node-eplb

Qwen3-235B-W8A8 带 EPLB，2 节点

multi-node-dpsk3.2-2node

DeepSeek-V3.2-W8A8，2 节点

multi-node-qwen3-dp-mooncake-layerwise

Qwen3-235B-A22B 带 Mooncake 分层，2 节点

multi-node-deepseek-r1-w8a8-longseq

DeepSeek-R1-W8A8 长序列，2 节点

multi-node-qwenw8a8-2node-longseq

Qwen3-235B-W8A8 长序列，2 节点

multi-node-deepseek-V3_2-W8A8-cp

DeepSeek-V3.2-W8A8 上下文并行，2 节点

multi-node-qwen-disagg-pd

Qwen3-235B 分离式 PD，2 节点

multi-node-qwen-vl-disagg-pd

Qwen3-VL-235B 分离式 PD，2 节点

multi-node-kimi-k2-instruct-w8a8

Kimi-K2-Instruct-W8A8，2 节点

multi-node-deepseek-v3.1

DeepSeek-V3.1-BF16，2 节点

multi-node-deepseek-v3.2-W8A8-EP

DeepSeek-V3.2-W8A8 带 EP，4 节点

单节点测试（在多节点测试完成后运行）：

测试名称

描述

qwen3-30b-acc

Qwen3-30B 精度测试

deepseek-r1-0528-w8a8

DeepSeek-R1-0528-W8A8

deepseek-r1-w8a8-hbm

DeepSeek-R1-W8A8 HBM

deepseek-v3-2-w8a8

DeepSeek-V3.2-W8A8

glm-5-w4a8

GLM-5-W4A8

glm-4.7-w8a8

GLM-4.7-W8A8

kimi-k2-thinking

Kimi-K2-Thinking

kimi-k2.5

Kimi-K2.5

minimax-m2-5

MiniMax-M2.5

mtpx-deepseek-r1-0528-w8a8

MTP-X + DeepSeek-R1-0528-W8A8

qwen3-235b-a22b-w8a8

Qwen3-235B-A22B-W8A8

qwen3-30b-a3b-w8a8

Qwen3-30B-A3B-W8A8

qwen3-next-80b-a3b-instruct-w8a8

Qwen3-Next-80B-A3B-Instruct-W8A8

qwen3-32b-int8

Qwen3-32B-Int8

qwen3-32b-int8-prefix-cache

Qwen3-32B-Int8 前缀缓存

deepseek-r1-0528-w8a8-prefix-cache

DeepSeek-R1-0528-W8A8 前缀缓存

custom-multi-ops

自定义多卡算子测试

警告

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

示例#

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

/nightly

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

/nightly test_custom_op

同时运行两个指定的测试：

/nightly test_custom_op qwen3-32b

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

故障排查#

添加标签后工作流未启动。

  • 确保 /nightly 评论是在添加标签之前发布的。如果先添加了标签，请移除它，然后在发布评论后重新添加。

  • 检查评论是否以 /nightly 精确开头，斜杠前没有前导空格或多余字符。

  • 修复问题后重新触发，只需推送一个新的提交——工作流会自动重用现有的 /nightly 评论。

只运行了部分测试，不是预期的那些。

  • 测试名称区分大小写，并且必须与工作流矩阵中的 name 字段完全一致（参见上表）。

  • 在 GitHub Actions 中检查 parse-trigger 任务的输出，查看解析后的 test_filter 值。

工作流使用的是定时镜像，而不是我的 PR 代码。

  • 确认工作流是由 pull_request 事件（标签或推送）触发的，而不是 workflow_dispatch。

  • parse-trigger 任务的日志中会显示 is_pr_event——请检查其值。

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

  • 对于大多数问题，GitHub Actions 的标准输出弹出日志就足够了（该日志始终代表第一个节点的日志）。

  • 如果第一个节点的日志不再足以提供有效的日志信息，请查看任务摘要以下载对应测试的日志归档，其中包含框架侧日志和每个节点的 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