Mistral Batch API支持把大量请求异步排队处理，官方文档显示单批可容纳大规模请求，并适用于聊天、嵌入、FIM、审核、OCR、分类和语音转写等端点。批处理可降低成本，但不适合用户正在等待的实时请求。真正的难点是请求唯一标识、状态恢复、部分失败和结果对账。
哪些任务适合批处理
历史文档分类、知识库嵌入、离线摘要、内容审核、OCR归档和评测适合批量运行。在线客服、支付前检查和即时交互仍使用实时接口。
按模型和端点拆批，一批只做一种稳定任务。先用小样本确认格式、质量和费用，再扩大规模，避免百万条输入一起失败。
设计可对账输入
每条请求设置唯一custom_id，关联内部业务对象和版本。输入文件保存校验和、生成时间和总行数，上传后记录文件ID与批任务ID。
请求体通过Schema预检查，过长、缺字段和敏感数据在本地拦截。不要依赖返回顺序匹配结果，只通过custom_id对账。
状态与失败恢复
处理QUEUED、RUNNING、SUCCESS、FAILED、TIMEOUT和CANCELLED等状态。轮询使用退避，任务完成后比较成功、失败和总数。
只重试失败项，生成新的批次并保留父任务ID。写入数据库使用幂等键，防止重复下载或重跑造成重复记录。
安全、质量与成本
输入文件按最小数据原则生成，完成后按保留策略删除。日志不保存完整敏感文本，API密钥使用专用服务账号。
抽样人工检查结果，并监控空输出、格式错误和模型拒绝。计算总费用、成功条数和返工成本，不能只看折扣。模型升级前用同一批样本对比。
进一步实施要点
批任务的输入文件和输出文件应进入独立生命周期管理：上传前加密保存，运行中限制读取账号，下载完成后验证文件校验和，并根据业务政策自动删除。调度器还要限制同一租户同时运行的批次数，防止一个大客户占满额度。对OCR或审核任务，结果需保存原始页码与对象ID，人工抽检发现问题时可以直接回到对应输入，而不是重新搜索整个文件。
落地检查清单
- 实时与离线任务分开路由。
- 每条请求使用稳定custom_id。
- 失败项单独重试且写入幂等。
- 完成后对账、抽检并清理临时文件。
