大模型批量推理适合什么场景？离线任务怎么用好 Batch 接口？
面试怎么回答
Batch 接口是一次提交大量请求、在时间窗口内异步完成，价格通常明显低于实时接口，也不占实时配额，适合分类打标、抽取、摘要、批量 Embedding、跑评测和模型升级后的历史回刷，不适合用户在等的交互和多轮 Agent 任务。设计上每条请求带业务主键加任务版本作为自定义 ID，按接口限制分批提交，调度任务轮询状态、下载结果，结构化输出加 Schema 校验后幂等写入结果表，失败的 ID 收集重提并设上限。整个流程放进调度系统，下游 SLA 考虑完成窗口。全量前先用小样本人工检查效果，共享的系统提示放前面利用缓存，记录每批成本和模型、提示词版本。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
很多数据团队用大模型做离线任务：给 100 万条商品评论打情感标签、从 50 万份工单里抽取问题类型、为几千张表生成描述。如果用在线接口一条条调，又慢又贵还容易被限流。主流模型提供方都有批量推理（Batch）接口，面试官问这题，想看你会不会把大模型调用当成一个离线批处理任务来设计。
Batch 接口的特点
- 一次提交大量请求（通常是一个文件），在一定时间窗口内（比如 24 小时内）异步完成；
- 价格通常明显低于实时接口；
- 不占用或较少占用实时接口的速率配额；
- 代价是不保证实时返回。
适合的场景
- 对时效不敏感的离线处理：分类、打标、抽取、摘要、翻译；
- 批量生成 Embedding；
- 评测：跑一遍完整的评测集；
- 数据回刷：提示词或模型升级后，重新处理历史数据。
不适合：用户在等待结果的在线交互、需要多轮工具调用的 Agent 任务。
任务设计
- 准备输入：每条请求带上唯一的自定义 ID（比如业务主键 + 任务版本），结果回来后靠它关联；
- 分批提交：按接口限制拆成多个批次文件，记录每个批次的状态；
- 状态跟踪：调度任务定期查询批次状态，完成后下载结果；
- 结果处理：解析结果，校验格式（结构化输出 + Schema 校验），写入结果表；
- 失败处理：部分请求会失败或格式不合格，收集失败的 ID 重新提交，设置重试上限；
- 幂等写入：结果按业务主键和任务版本覆盖写入，重复处理不会产生重复数据。
和调度系统结合
- 把「提交 → 等待 → 下载 → 解析 → 写入」做成调度系统里的一组任务，下游依赖结果表；
- 由于完成时间不确定，下游的 SLA 要考虑这个窗口；对时效有要求的部分，可以走实时接口作为补充。
成本和质量控制
- 先用小样本（比如 1000 条）跑一遍，人工检查效果和格式，再全量提交，避免一个提示词错误浪费整批费用；
- 用提示词缓存：所有请求共享相同的系统提示，放在前面；
- 记录每批的 Token 用量和成本；
- 结果表记录模型版本和提示词版本，便于以后对比和回刷。