5000 个 task 一夜跑完：
怎么大批量、可比较地跑 agent？
先弄清楚：每个概念是什么
- Queue 和 worker
- task 排进 queue，worker 逐个取走去跑。像取号机和柜台，开几个柜台就是几个并发。
- Rate limit
- 模型 API 每分钟允许的请求数和 token 数，超了返回 429。常用 token bucket 守住它，桶里按固定速度补令牌，请求拿不到令牌就等。
- 断点续跑
- 每个 task 跑完就写一条结果，重启时跳过已有结果的 task。
- 可比较
- 两个方案的分数能直接相减的前提。model 版本、image、seed 和 task 列表都一样，只有被比较的那一处不同。
看图：task 怎么流过这套系统
30 秒回答
I'd start with the arithmetic. 5,000 tasks in eight hours is about ten per minute, so with fifteen-minute runs I need roughly 160 in parallel. Each worker pulls a task from a queue and runs it in its own sandbox, so runs don't share state. The real bottleneck is usually the model API's rate limit, so I throttle with a token bucket and retry with backoff. Every finished task writes one result row, so a crash resumes instead of restarting. And I pin the model version, the image and the task list, so every variant runs under the same conditions.
先算账
一夜按 8 小时算，是 480 分钟。5000 ÷ 480 ≈ 每分钟 10.4 个 task。每个 run 按 15 分钟算，10.4 × 15 ≈ 160 个并发。15 分钟是假设，面试时先问面试官。顺序跑要 5000 × 15 分钟 = 1250 小时，约 52 天。
再算 rate limit。假设每个 run 用 20 万 token，5000 个 run 是 10 亿 token，平摊下来约每分钟 208 万 token。API 的额度低于这个数时，加机器没有用。
Version chain
| 版本 | 做法 | 还剩的问题 |
|---|---|---|
| v1 一个 loop | 顺序跑 | 要 52 天 |
| v2 Queue + worker | 约 160 个 worker 从 queue 取 task，各起一个 sandbox，跑完销毁 | API 返回 429；进程挂了整批重来 |
| v3 Rate limit + 断点续跑 | token bucket 限流，失败后退避重试；每个 task 写一条结果，重启时跳过已完成的 | 两个方案的分数不能直接比 |
| v4 可比较 | 固定 model 版本、image、seed；各方案跑同一批 task | GPU 上计时的 task 互相干扰 |
| v5 GPU 排队（推断） | 编译和正确性检查并发跑；计时独占一张 GPU，排队跑 | 计时的总时长由 GPU 数量决定 |
v5 是推断。两个 run 同时用一张卡计时，时间就不准。CUDA Agent 也把 CPU 上的编译和 GPU 上的测量分开（见 怎么公平地 benchmark）。
隔离见 sandbox，重试和 checkpoint 见 tool 失败与重试，结果的字段见 observability，分数差多少才算数见 noise floor。
必答点
- 先算账：每分钟约 10 个 task，每个 run 15 分钟，要约 160 个并发
- 每个 worker 一个 sandbox，不共享状态
- 瓶颈常是模型 API 的 rate limit，用 token bucket 限流
- 每个 task 写一条结果，重启时跳过已完成的
- 固定 model 版本、image、seed 和 task 列表
- GPU 上的计时独占一张卡，编译可以并发（推断）
追问
为什么要限制 agent 的并发数？（百度原题）
模型 API 的 rate limit 和机器的 CPU、memory 都有上限。并发超过上限后请求大面积失败，重试又把负载推得更高。
有的 run 卡住不结束，怎么办？
每个 run 设 timeout 和步数上限，超时就记成失败，把 worker 让出来（见 tool 失败与重试）。
来源牛客：蚂蚁 Agent 日常一面 · 牛客：字节火山方舟 Managed Agent 一面 · 牛客：小红书 Agent 开发一面 · 牛客：百度 Agent（「为什么需要限制 Agent 的并发数？」）· CUDA Agent（编译和测量分离）· ml-八股 08 第 32 题