一句话：批处理 API 是一个“不着急、慢慢来”的调用入口——你把成千上万条请求打包提交，服务方在后台错峰慢慢跑，跑完再让你整批取回结果，价格通常比同步接口低一大截。
它到底怎么运作
平时调模型是“一问一答”：发出请求，连接挂着，几秒后拿到答案，这叫同步接口（synchronous API）。批处理更像寄物流，而不是打车。打车是随叫随走、按表计价，贵但快；物流是你把几十个包裹攒上货车，排上队统一发车，便宜，但哪天到只能看运气。
具体操作上，你通常提交一个任务文件（常见格式是每行一条请求，各带一个自定义 ID），服务方返回一个任务编号。之后你轮询任务状态，等它从“排队中”变成“已完成”，再下载结果文件，用 ID 把答案对回原来的问题。
低价的原因很直白：这批请求不占用实时算力，可以被调度到低谷时段，厂商的成本本来就低。至于折扣力度，各家不同，常见是同步价格的一半左右，具体以官方页面为准。代价则是延迟——可能几分钟就跑完，也可能跑上若干小时，一般会有一个最长处理窗口的承诺，但单条请求何时返回不保证。
和相邻概念的区别
| 同步接口 | 批处理 API | |
|---|---|---|
| 响应时间 | 秒级 | 分钟到小时级 |
| 价格 | 标准价 | 明显更低 |
| 调用方式 | 一次一条，实时返回 | 打包提交、轮询、整批取回 |
| 适合谁 | 用户正在等着 | 用户不在等 |
它和流式输出（streaming）不是一回事：流式解决“第一个字多快出现”，批处理解决“每条请求多便宜”。它也不等于异步接口——异步只是不阻塞，批处理的核心是一次提交一大批。
什么能扔进去，什么绝对不能
适合的：给历史客服对话批量打标签、几千份合同跑一遍信息抽取、离线评测集跑分、数据集翻译清洗、夜里生成第二天的推荐理由、给存量内容补摘要。共同点是：没人盯着等，晚几小时不影响业务。
不能用的：任何有人盯着转圈圈的地方——聊天机器人的回复、实时客服、交互式 Agent 的工具调用、下单风控、在线搜索排序。还有个容易踩的坑：如果一条请求的输入依赖上一条的输出（多轮链式推理），要么整条链一次性打包提交，要么干脆别用，否则反复轮询的等待会吞掉省下的那点钱。
一句话记住：批处理是拿“到达时间的不确定性”换“确定的成本下降”，前提是这份不确定性有人替你兜着。