Spring Batch 跑 AI 离线任务批处理也要限流和断点一、离线任务也会打爆下游企业后端常用 Spring Batch 做数据同步、报表、清洗和批处理。接入 AI 后离线任务可能要批量摘要、分类、向量化、审核。很多人以为离线任务不影响在线体验但如果它批量调用模型、数据库或对象存储一样会打爆下游。AI 离线任务要像在线服务一样设计限流、断点和恢复。二、先拆 Job 和 Stepflowchart TD A[Job 启动] -- B[读取数据] B -- C[调用模型] C -- D[结果校验] D -- E[写入结果] E -- F[记录进度]每个 Step 都要有事务边界、重试策略和失败处理。模型调用这一步尤其要控制并发。batch_ai_job: chunk_size: 50 model_qps_limit: 20 retry_attempts: 2 checkpoint: truechunk_size不要只按数据库写入调要结合模型调用耗时和成本。三、断点续跑很关键public class AiItemProcessor implements ItemProcessorDocument, AiResult { Override public AiResult process(Document item) { return callModel(item); } }Spring Batch 自带 JobRepository可以记录执行状态。不要绕开它自己写一个大循环否则任务失败后很难知道处理到哪里。写入结果时要保证幂等。重复跑一个 chunk不应该产生重复记录或重复扣费。可以用文档 ID、模型版本和任务 ID 做唯一键。四、离线任务要避开高峰批量 AI 任务最好有调度窗口。在线高峰期模型服务已经忙离线任务还冲进去会让在线用户变慢。batch_window: allowed_hours: 01:00-06:00 pause_when_online_p95_ms_above: 1200如果在线服务 SLO 被破坏离线任务应该自动暂停或降速。批任务晚点完成通常比在线服务不可用更能接受。还要记录成本。每个 Job 消耗多少 token、调用多少次模型、失败重试多少次都应该能查。离线任务一旦规模化账单增长会很快。最后批处理输出要抽样验收。AI 结果不是写入成功就代表正确摘要、分类、标签都需要质量抽检。任务还要支持暂停。模型供应商异常、在线流量升高、成本预算即将耗尽时批处理系统应该能暂停当前 Job保留进度等条件恢复后继续。batch_pause_policy: pause_on_model_error_rate: 0.05 pause_on_cost_budget_percent: 90 resume_manually: true成本预算是 AI 批任务的新约束。传统批处理更多关注时间窗口和数据库压力AI 批处理还要关注 token 花费和模型配额。还要给每次 Job 生成报告处理总数、成功数、失败数、重试数、模型成本、抽检通过率。没有报告离线任务跑完只是“看起来完成”并不能证明结果可用。最后失败数据要能重放。只重跑失败记录而不是整批重跑可以节省大量成本。批处理任务的监控也有其特殊性。在线服务关注 QPS、延迟、错误率而批处理更关注吞吐量、进度、预计完成时间和资源消耗。Spring Batch 提供了 Job Execution 和 Step Execution 的元数据可以用来构建监控面板当前处理的 item 数、跳过数、失败数、每秒处理速率、剩余时间估算。这些数据对于判断任务是否正常运行、何时能完成、是否需要人工介入非常关键。特别是对于运行时间可能长达数小时的 AI 批处理任务没有进度可见性会让人很不放心。AI 批处理还需要考虑模型抖动问题。在线服务通常假设模型 API 的可用性是稳定的但批处理任务运行时间长更容易遇到模型服务重启、限流、版本切换等事件。设计时需要在 Step 层面支持优雅降级如果模型调用连续失败超过阈值可以暂停任务并通知管理员而不是一直重试直到耗尽重试次数。也可以在任务定义时设置可接受的部分失败率比如 10000 条数据处理失败了 50 条是否仍然认为任务成功这个阈值需要根据业务场景来定。五、总结Spring Batch 跑 AI 离线任务时要设计 chunk、限流、断点续跑、幂等写入、调度窗口和质量抽检。离线不等于随便跑。批处理也要保护下游和在线体验。