执行摘要

• 一句话：回滚 torch-abi 队列迁移，修复 CI 失败
• 推荐动作：值得 CI/构建维护者精读：它清楚展示了 Buildkite 中 device 与 queue 的语义差异（0 GPU 计算不等于可以使用 CPU 镜像），以及用构建历史做根因证据的方法。对普通开发者只需知道 torch-abi 审计必须运行在 CUDA 镜像环境，不要再次把它移到 CPU 队列。设计上值得借鉴的是作者对 soft_fail 步骤与 hard_fail 步骤的不同处理策略：crcr-report 依赖未配置的环境变量，但靠 soft_fail 与 allow_dependency_failure 兜底，不阻塞合并。

功能与动机

PR body 明确说明："Both steps are 0-GPU in compute, but the queue determines the image the docker plugin runs them in — and both need the CUDA wheel/environment, not the CPU one"。#54326 将 torch-stable-abi-audit 移到 small_cpu_queue_premerge 后，每次构建都会在 CPU 镜像中运行，CPU wheel 自带的 _C_AVX2.abi3.so / _C_AVX512.abi3.so 不在 check-torch-abi.py 的 allowlist 里，导致构建 86214/86224/86228/86246/86250 失败，而迁移前 gpu_1_queue + CUDA 镜像的构建 86222 通过。本 PR 的目标是恢复 torch-abi 审计的绿色状态，而不是全量回滚 #54326。

实现拆解

1. 定位失败步骤：在 .buildkite/test_areas/torch_abi.yaml 中，torch-stable-abi-audit 步骤因 #54326 被标记 device: cpu-small 并依赖 image-build-cpu，开始在 small_cpu_queue_premerge 上运行，构建 86214/86224/86228/86246/86250 全部失败，而迁移前 gpu_1_queue 上的构建 86222 通过。
2. 根因确认：虽然步骤配置为 0 GPU 计算，Buildkite 的 device 只决定机器类型，队列才决定 docker plugin 拉取的镜像；cpu-small 队列对应 -cpu 镜像，其中 CPU wheel 自带 _C_AVX2.abi3.so / _C_AVX512.abi3.so，不在 .buildkite/check-torch-abi.py 的 allowlist 中，审计脚本因此报错。
3. 配置回滚：修改 .buildkite/test_areas/torch_abi.yaml，把 depends_on 从 image-build-cpu 改回 image-build，并删除 device: cpu-small 行，使步骤回到默认 gpu_1_queue 与 CUDA 镜像路径；source_file_dependencies 与 commands 保持不变。
4. 保留其余改动：#54326 中对 2/4-GPU 步骤的 device: l4 标注（迁移到 EKS）不受影响；crcr-report 按 reviewer 决策保留在 cpu-small，它属于 soft_fail + allow_dependency_failure，最坏情况只需后续在 small-cpu agents 上补配 BUILDKITE_API_TOKEN / CRCR_CALLBACK_URL。
5. 验证方式：仅做了 YAML 解析检查，核心证据是构建历史对比；合并后下一次触发该步骤的构建应恢复绿色。没有新增测试或脚本，属于纯配置修复。

关键文件：

• .buildkite/test_areas/torch_abi.yaml（模块 CI 配置；类别 config；类型 configuration）: 这是本 PR 唯一变更文件，直接决定 torch-abi 审计的 CI 路由：恢复 depends_on: image-build 并移除 device: cpu-small，让步骤回到 gpu_1_queue + CUDA 镜像，修复 CPU 镜像下的持续失败。

关键符号：未识别

评论区精华

本 PR 没有人类 review 评论，仅 claude[bot] 自动提示仓库配置为人工 review，可 @claude review 触发一次性审查。实质的“讨论”集中在 PR body 的 Notes for reviewers 中：crcr-report 有意保留在 cpu-small，这是 reviewer 决策（soft_fail + allow_dependency_failure，最坏情况是后续在 small-cpu agents 上补配 BUILDKITE_API_TOKEN / CRCR_CALLBACK_URL）；作者声明本修复由 Kimi Code 辅助完成，并搜索确认当前没有重复 PR；作者还指出 #52635 正在把 CPU extension 迁移到 stable ABI，可能让 CPU-wheel 审计最终通过，届时可重新评估队列迁移。这些要点为后续 CI 演进留下可追踪的线索。

• 仅 claude[bot] 自动审查提示，无人工讨论 (other): 无实质技术讨论；设计要点由 PR body 承载：crcr-report 有意留在 cpu-small（soft_fail + allow_dependency_failure），#52635 完成后可重新评估队列迁移。

风险与影响

• 风险：
  1. 镜像依赖链恢复：depends_on: image-build 意味着 torch-abi 审计要等 CUDA 镜像构建成功才能运行，若镜像构建失败会级联跳过该步骤，这是原始行为，不算新增风险。
  2. GPU 队列占用：步骤重新回到 gpu_1_queue，虽然本身 0 GPU 计算，但会占用 GPU 队列的调度位置，可能轻微增加该队列排队时间；这是以 CI 资源换正确性的明确取舍。
  3. 缺少自动化回归保护：本次修复只靠构建历史证据（86222 通过 vs 86214 等失败）验证，没有新增测试；未来如果有人再次按“0 GPU 计算”的理由调整队列，同一类失败可能复发。#52635 完成后 CPU-wheel 审计若可通过，现有回滚决策需要重新评估。
  4. crcr-report 的隐性依赖：它保留在 cpu-small，但依赖 BUILDKITE_API_TOKEN / CRCR_CALLBACK_URL 环境变量，当前靠 soft_fail 兜底；若将来改为 hard_fail，需要先补配环境。
     - 影响：影响范围集中在 CI 门禁：torch-stable-abi-audit 在每次相关构建中从“必失败”恢复为“可通过”，消除 torch-abi 相关 PR 的噪声性红叉；对 vLLM 的运行时、模型、前端等模块没有任何影响。#54326 的其他改动（2/4-GPU 步骤的 device: l4 标注与 EKS 迁移）不受影响；crcr-report 的 cpu-small 路由保持原样。对团队而言，这是 CI 可靠性的恢复性修复，也明确了“队列决定镜像”的约束应纳入后续 CI 调整的检查清单。
     - 风险标记：CI 队列语义陷阱, 依赖 image-build 级联, 无自动化回归保护

关联脉络

• 暂无明显关联 PR