GitHub Actions 触发自动化性能测试需明确触发时机、准备可执行命令、保障执行环境并记录比对结果：支持 pull_request、schedule、workflow_dispatch 和 Dependabot 事件；测试命令须命令行可调用且结果可量化；GPU 等场景需自托管 runner 并固定软硬件版本；最终输出指标、比对基线、生成报告并自动反馈。
GitHub Actions 触发自动化性能测试，核心在于把性能测试脚本封装进工作流，并通过合适的事件、环境和资源配置来稳定执行。它不是“开箱即用”的功能，而是靠明确的触发逻辑 + 可复现的测试命令 + 合适的硬件/软件环境共同实现。
明确触发时机：按需选择事件类型
性能测试通常耗时较长、资源占用高，不建议每次 push 都跑。更合理的做法是：
- 仅在特定分支合并前验证：例如 pull_request 针对 main 或 release/* 分支，确保新功能或优化不会拖慢整体性能
- 定时回归：用 schedule 触发每日/每周全量性能基准测试，监控长期趋势（如 cron: '0 2 * * 0' 表示每周日凌晨2点运行）
- 手动触发：配合 workflow_dispatch，允许团队成员按需启动深度性能分析（比如发布前最后一轮压测）
- 依赖更新后触发：结合 Dependabot 的 pull_request 事件，在关键依赖（如 PyTorch、ROCm、Node.js）升级后自动跑性能比对
准备可执行的性能测试命令
性能测试本身必须是命令行可调用、结果可量化、失败可判定的。常见形式包括：
- 运行已有的压测脚本：如
python benchmarks/bench_sglang.py --model llama-3-8b --batch-size 32 - 调用标准工具：如
autocannon -u http://localhost:3000/api/health -d 30或locust -f load_test.py --headless -u 100 -r 10 -t 2m - 执行带计时和指标采集的构建+运行流程：如先
make build-benchmark-image，再docker run --rm benchmark-runner:latest --mode=throughput - 集成覆盖率与性能双校验：在 pytest 中启用
--benchmark-only插件，用pytest --benchmark-compare对比历史基线
保障执行环境满足性能测试要求
普通 GitHub 托管 runner 往往无法满足真实性能测试需求，尤其涉及 GPU、低延迟网络或大内存场景：
- 避免使用 ubuntu-latest 跑 GPU 性能测试：官方 runner 没有 AMD/NVIDIA GPU，ROCm 或 CUDA 性能测试必须用自托管 runner（如配备 MI250 或 A100 的云实例）
- 固定软硬件版本：在 container 或 runner 环境中显式指定内核、驱动、ROCm/CUDA、Python 版本，防止因环境漂移导致性能数据波动
-
预留足够资源：Docker 容器需挂载
/dev/kfd和/dev/dri（ROCm），或/dev/nvidia*（CUDA）；设置--shm-size 16G、--cpus 8、--memory 32g等参数保证稳定性 -
隔离干扰：禁用无关服务、关闭 CPU 频率调节（
sudo cpupower frequency-set -g performance）、绑定 CPU 核心（taskset -c 0-7）提升结果一致性
记录、比对与反馈结果
光跑完不够，关键是要让性能数据“说话”：
- 把关键指标（如 QPS、P99 延迟、GPU 利用率、内存峰值）输出为 JSON 或 CSV，用
actions/upload-artifact@v4保存归档 - 用
codecov/action或自定义脚本将本次结果与主干基线比对，超阈值（如 P99 上升 >5%）则标记 job 失败 - 把性能报告生成 HTML 页面，通过
peaceiris/actions-gh-pages推送到 gh-pages 分支，供团队随时查看趋势图 - 在 PR 中自动评论性能变化摘要（如 “本次修改使 SGLang 吞吐下降 3.2%，建议检查 attention kernel 实现”），需搭配
actions/github-script实现
