Trackio 这次迁 CI，最该看的不是“快了 30%”这句话。
更反常的点是：一个开源 ML 项目，终于可以把 GPU 测试放进普通 PR 工作流里，而不是丢给夜间任务、手动流程，或者维护者本地机器。
Hugging Face 没有把 GitHub Actions 整套换掉。GitHub 仍然负责触发、排队、状态回传。HF Jobs 接过的是真正干活的 runner。换句话说，控制面还在 GitHub，机器去了 Hugging Face。
迁移的不是控制面，是 runner
Trackio 把 GitHub Actions 工作流的一部分，通过 huggingface/jobs-actions 跑到 HF Jobs 上。
桥接链路有几步：GitHub App 收到 workflow job queued 事件；dispatcher Space 验证 webhook；看到 hf-jobs-* 标签后启动 HF Job；这个 Job 临时注册成 GitHub self-hosted runner；任务跑完，runner 销毁。
这套东西听起来绕，本质很简单：GitHub 发号施令，HF Jobs 出机器。
| 项目 | 原来 | 迁移后 | 结果 |
|---|---|---|---|
| CPU CI | GitHub ubuntu-latest | HF Jobs CPU + Playwright 镜像 | 约 1m40s → 约 1m10s |
| GPU CI | GitHub 托管 runner 没有直接 GPU 基线 | hf-jobs-t4-small | 约 45s，低于 1 美分 |
| 控制平面 | GitHub Actions | 仍是 GitHub Actions | PR 触发和状态回传不变 |
| 执行后端 | GitHub-hosted runner | HF Jobs 临时 runner | 按需启动，跑完销毁 |
这里要克制。
30% 提速只对应 Trackio 这次 CPU 任务、依赖结构和镜像选择。不能推成“所有 CI 迁过去都会快”。
低于 1 美分也只对应这次 t4-small、约 45 秒的 GPU 检查。它说明 GPU CI 可以很便宜地跑一次，不等于 GPU 测试从此没有成本。
最相关的读者其实很窄：维护 ML/AI 开源项目的人、需要 CUDA 测试的团队、反复被自定义镜像和依赖安装拖慢的仓库。
普通 Web 项目当然也能试，但收益没那么硬。它们缺的通常不是 GPU，也不是 CUDA 环境，而是更稳定的流水线管理。
GPU CI 的价值，是把测试从“偶尔跑”变成“经常跑”
GitHub Actions 的优点是省心。写 runs-on: ubuntu-latest，机器就来了。
但这台机器是通用机器。通用意味着稳定，也意味着不贴身。
ML 项目的 CI 最怕不贴身。它会碰 CUDA、驱动、浏览器依赖、模型下载、数据集缓存，还有一堆系统包。Trackio 原先用裸 ubuntu:22.04 时，需要现场装依赖。换成 Microsoft Playwright 镜像后，CPU 任务才跑出差距。
所以真正的变量不是“HF 比 GitHub 快”。
真正的变量是：镜像能不能贴合任务，硬件能不能按需选择，runner 能不能短命干净。
GPU 更关键。过去很多 ML 项目不是不想测 GPU，而是 GPU runner 不顺手。要么成本高，要么维护麻烦，要么只能放到人工流程里。
hf-jobs-t4-small 这类标签接进 GitHub Actions 后，GPU 测试可以变成 PR 里的普通 job。哪怕只是 smoke test，也已经改变质量边界。
“工欲善其事，必先利其器。”这句话放在这里不玄。对 ML 项目来说，器不是编辑器，是 CI 里那块可调度的 GPU。
开源维护者可以先做一件很具体的事：挑一两个 CUDA 相关测试，做成低成本 GPU smoke test，不要一上来迁完整条流水线。
技术负责人也该调整评估口径。别只问“CI 能不能跑”。要问“哪些测试必须在 GPU 上跑，哪些镜像该预构建，哪些 job 适合临时 runner”。
该不该迁，看三笔账
这次方案做对了一点：它没有要求开发者抛弃 GitHub Actions。
开发者不用重写整套 CI。把部分 job 的 runs-on 换成 hf-jobs-cpu-upgrade、hf-jobs-t4-small 这类标签，就能把执行后端切过去。
但灵活不是免费的。
| 账本 | 收益 | 代价 | 该观察什么 |
|---|---|---|---|
| 硬件账 | CPU/GPU 可按需选择 | 成本结论依赖任务时长和规格 | GPU job 排队时间、单次成本、失败重跑成本 |
| 镜像账 | 依赖可提前固化 | 镜像维护变成新工作 | 镜像更新频率、构建失败率、缓存效果 |
| 安全账 | runner 跑完销毁，更干净 | GitHub App、HF token、runner token 都要治理 | 权限范围、token 生命周期、dispatcher Space 可用性 |
短生命周期 runner 很有吸引力。跑的时候注册，跑完就消失。它比长期挂一台自建 GPU runner 更干净，也更适合开源项目。
可这条链路多了新风险面。GitHub webhook、dispatcher Space、HF Job、runner 注册 token，任何一环不稳，任务都可能卡住。
我不太买账的是把它包装成“CI 新选择”的泛泛说法。说轻了。
它更像 ML 项目 CI 的分水岭：通用 runner 还能跑基础检查，但涉及模型、CUDA、浏览器依赖和日志抓取的任务，开始有理由迁到更贴近 AI 工作负载的平台上。
对团队来说，比较稳的动作不是全量迁移，而是分层迁移。
基础 lint、类型检查、普通单测继续留在 GitHub-hosted runner。GPU smoke test、自定义镜像测试、需要更好日志抓取的 job，先放到 HF Jobs 试运行。
接下来最该看的变量也很具体：GPU job 是否稳定排队，dispatcher Space 是否可靠，成本在多次重跑后是否仍可接受，密钥治理会不会吃掉节省下来的时间。
如果这些变量站得住，HF Jobs 就不只是“另一个 runner”。它会让 ML 项目重新设计 CI。测试从 CPU 舒适区往外走，硬件账、质量账和安全账会一起进流水线。