夜间测试中不同 job 在同一硬件类型上并行运行导致资源争抢和测试排队不稳定，PR body 明确指出需要排队而非并行，并通过 concurrency.group 实现。

此 PR 为典型的 CI 基础设施优化，值得阅读以了解如何通过 concurrency group 和 max-parallel 控制 CI 并发。建议合并后持续观察 nightly 运行时间，必要时微调超时设定。

1. 添加 per-hardware concurrency group：为每个硬件类型的 job 添加 concurrency.group 字段，取值如 nightly-hw-h100，设置 cancel-in-progress: false，使得同一硬件类型的 job 按队列顺序串行执行。
2. 限制矩阵 job 分区并发：在 general-8-gpu-h200、general-8-gpu-b200、multimodal-server-1-gpu、multimodal-server-2-gpu 等矩阵 job 中添加 max-parallel: 2，确保同一 workflow 内最多同时运行 2 个分区。
3. 调整 timeout-minutes 为实际运行时间的约 2 倍：基于最近 5 次夜间运行的实际时长，将多个 job 的 timeout-minutes 收紧或放宽，例如 kernel-1-gpu 从 240 降到 60，text-perf-2-gpu 从 180 降到 30，同时 general-4-gpu 从 30 升到 60 以提供缓冲。

1. 串行执行可能延长整个夜间流程的总耗时：虽然单硬件类型内 job 排队避免了资源争抢，但最坏情况下 H100 系列总耗时约 22 小时，串行执行不会增加总耗时（原本也无法并行），但可能延长单次运行时间窗口，需监控是否影响其他依赖流程。
2. 超时调整无安全余量：部分 job 超时设为最大运行时间的约 2 倍，若未来测试复杂度增加，可能出现超时失败，需定期复审。
3. 未覆盖所有 job：某些 job 未加入 concurrency group（如 nightly-test-kernel-8-gpu-h200 已加入，但 nightly-test-general-8-gpu-h200 也已加入），但需检查是否有遗漏。

直接影响 nightly CI 稳定性，减少因并行资源争抢导致的不确定失败。对开发者而言，夜间测试结果将更可预测，但总运行时间可能略有增加。对系统管理员而言，降低了 runner 过载风险。