Prhub

#52328 [CI] Shard Quantization job into 4 parallel shards (≤30 min target)

原始 PR 作者 khluu 合并时间 2026-08-15 06:11 文件变更 1 提交数 1 评论 0 代码增减 +4 / -3

执行摘要

Quantization CI 拆 4 并行分片,关键路径提速 3 倍

Quantization 测试是 CI 中最长尾的作业之一,单 Job 墙钟约 71 - 75 min(90 天统计 68 / 73 / 75 min),远超 30 min 的分片目标。PR body 明确提出“Shard the long-pole Quantization CI job (single job, ~71–75 min wall ...) into 4 parallel Buildkite shards so each shard lands ≤30 min”,以缩短 quantization 相关 PR 的 CI 反馈周期,并延续 CI-overhaul 的 sharding 系列:一个长尾 Job 一个 PR。

推荐快速浏览而非精读:改动只有 1 个 YAML 文件,逻辑直白,但验证数据(分片墙钟、覆盖并集、GPU 分钟数)完整,可作为 CI 分片 PR 的标杆示例。值得关注的设计决策包括:不移动测试文件而是用 pytest-shard 切片;保留 key 使定向触发不受影响;用实测最差片耗时(23.1 min)决定超时(40 min)与并行度(4 片),避免过度拆分。CI 维护者可据此评估是否对剩余长尾 Job 采用同样模式。

讨论亮点

该 PR 没有实际 Git review 评论:claude[bot] 仅提示“This pull request is from a fork — automated review is disabled”,维护者可评论 @claude review 触发一次性审查;comments_count 与 review_comments_count 均为 0。PR body 中记录了作者对 Kevin 关于固定开销问题(Kevin's Q2)的回应:每分片重复支付约 1 min 的容器/环境准备与收尾开销,4 分片最差片 23.1 min,距离 30 min 目标留约 7 min 余量,因此不需要 5 分片;同时 GPU 总耗时 64.07 GPU-min 与单 Job 基线相当,拆片没有膨胀资源消耗。

实现拆解

  1. 变更入口是 .buildkite/test_areas/quantization.yaml 中的 Quantization step:新增 parallelism: 4,让 Buildkite 并行启动 4 个实例,这是分片的机制基础。
  2. 将步骤 label 改为 Quantization %N,让 Buildkite 用 0/1/2/3 区分分片;key 保持 quantization 不变,确保 VLLM_CI_ONLY_STEP_KEYS=quantization 的定向触发仍然有效。
  3. 在 pytest 命令尾部追加 --shard-id=$$BUILDKITE_PARALLEL_JOB --num-shards=$$BUILDKITE_PARALLEL_JOB_COUNT,由 pytest-shard 在收集阶段按 nodeid 哈希把 tests/quantization 切成互不相交的 4 片;没有移动任何测试文件。
  4. 超时收紧:timeout_in_minutes 从 75 降到 40,依据分片实测最差 23.1 min 留出约 17 min 余量。
  5. 验证与配套:定向 CI Build #83897 实测 4 片墙钟 17.03 / 13.43 / 10.52 / 23.10 min,全部 < 30 min;4 片节点 ID 并集为 536,与 pytest 报告的 536 selected 一致,两两交集为 0,证明无缺失无重复。本 PR 不涉及 Python 源码和测试文件改动,因此没有额外的代码级测试配套。
文件 模块 状态 重要度
.buildkite/test_areas/quantization.yaml CI 配置 modified 3.81

分析完成后,这里会展示 LLM 生成的相对完整源码片段和详细注释。

评论区精华

分片数量与固定开销权衡 设计

PR body 回应 Kevin 关于固定开销的疑问(Kevin's Q2):每分片重复支付约 1 min 容器 / 环境准备与收尾开销;4 分片最差片 23.1 min,距 30 min 目标留约 7 min 余量,因此 5 分片不必要。

结论:选择 4 分片,每片超时降至 40 min;GPU 总耗时 64.07 GPU-min 与单 Job 基线相当,拆片不膨胀资源消耗。 · 已解决

风险与影响

  • 分片均衡性风险:pytest-shard 基于 nodeid 哈希均衡切分,依赖测试用例耗时的相对均匀;新增用例或个别用例变慢后可能出现某一片明显超时,需要重新评估并行度或改用更细粒度分配。
  • 超时收紧风险:timeout_in_minutes 从 75 收紧到 40,虽有实测余量,但测试集持续膨胀时可能偶发超时,需监控分片耗时趋势。
  • 资源池竞争:4 个并发实例同时占用 h200_35gb 设备,可能加剧 CI GPU 资源池竞争;PR 数据显示 GPU 总分钟数与单 Job 持平,但调度侧仍需观察排队影响。
  • 平台依赖:实现依赖 Buildkite 环境变量(BUILDKITE_PARALLEL_JOB / BUILDKITE_PARALLEL_JOB_COUNT),若未来迁移 CI 平台需要同步改造此步骤。
  • 影响范围:只修改了 CI 配置,不触碰运行时代码,因此不存在推理路径回归风险。
  • 对开发者:Quantization 相关 PR 的 CI 关键路径由约 71 min 降至 23.1 min,反馈周期缩短约 3 倍,迭代速度明显提升。
  • 对 CI 系统:Quantization step 从单实例变为 4 并行实例,单步耗时和整体占用窗口缩短;key 与 source_file_dependencies 保持不变,定向触发和触发逻辑均不受影响。
  • 对团队:本 PR 是 CI-overhaul 分片系列的一环,提供了“parallelism + pytest-shard + 保留 key”的可复制模式,为后续长尾 Job 分片提供参考;影响面仅限 .buildkite/test_areas/quantization.yaml。
pytest-shard 分片不均衡 CI 超时收紧 并行 GPU 资源占用 CI 平台依赖 Buildkite

关联 Issue

未识别关联 Issue

当前没有检测到明确关联的 Issue 链接,后续同步到相关引用后会出现在这里。

完整报告

参与讨论