Kubernetes Job 跑批推理：完成任务比常驻服务更重要

Kubernetes Job 跑批推理：完成任务比常驻服务更重要

不是所有 AI 推理都需要常驻在线服务。离线摘要、批量打标、历史数据清洗、报表生成、向量补全，更适合用 Kubernetes Job 或 CronJob 执行。很多团队把所有推理都塞进在线服务，导致队列复杂、资源长期占用、失败恢复不清。跑批推理的目标不是低延迟，而是可恢复、可追踪、可控成本地完成任务。

Kubernetes Job 很适合承载这类一次性或周期性 AI 任务。

一、先区分在线和离线

flowchart TD
  A[AI Task] --> B{Need Realtime?}
  B -->|Yes| C[Online Service]
  B -->|No| D[Kubernetes Job]
  D --> E[Batch Processing]
  E --> F[Result Store]

在线服务追求响应时间和可用性，离线任务追求吞吐、成本和恢复能力。比如用户点击后等待回答，应该走在线服务；每天凌晨给 10 万条反馈打标签，就应该走 Job。把两类任务混在一起，会让在线服务被离线流量拖慢。

任务分类还影响资源策略。离线任务可以使用低优先级、可抢占节点、夜间资源，甚至排队等待；在线服务则需要稳定容量和快速扩容。

二、Job 要有幂等输入

apiVersion: batch/v1
kind: Job
metadata:
  name: batch-embedding-20260703
spec:
  backoffLimit: 3

Job 可能失败重试，也可能被节点驱逐后重跑。输入必须可幂等处理。比如每条数据有唯一 ID，处理结果写入时使用 upsert，已经完成的记录跳过。不要让 Job 重试一次就重复写结果或重复扣费。

可以把任务切分成分片，每个分片记录状态。这样失败时只重跑失败分片，而不是整个批次从头开始。批量越大，分片状态越重要。

三、资源申请要现实

resources:
  requests:
    cpu: "4"
    memory: "16Gi"
  limits:
    nvidia.com/gpu: "1"

跑批推理经常需要 GPU，但不是所有任务都需要最高规格。Embedding 补全、轻量分类、重排任务可能用 CPU 或小 GPU 就够。资源申请要基于实际 profile，不要所有 Job 都默认占一张昂贵卡。

还要设置并发上限。CronJob 如果上一次没跑完，下一次又启动，可能造成任务堆叠。concurrencyPolicy、队列锁和任务状态表都能避免重复批处理。

四、结果和日志要分开

{
  "job_id": "batch_0703",
  "processed": 100000,
  "failed": 83,
  "output_uri": "s3://bucket/result/batch_0703"
}

Job 的业务结果应该写到结果存储，日志只用于排查。不要把大量推理输出打到容器日志里，既贵又难查。日志里记录进度、错误样本 ID、模型版本和统计信息即可。

失败样本要单独保存。跑批任务很少需要 100% 全部成功才有价值，但失败样本必须可重试、可人工检查。最终报告里要写清处理总数、成功数、失败数和失败原因分布。

五、总结

Kubernetes Job 适合离线 AI 跑批推理。关键是区分在线离线任务，设计幂等输入、合理资源申请、并发控制、结果存储和失败样本管理。

不是所有推理都要常驻服务。对跑批任务来说，稳定完成、可恢复、成本可控，比秒级响应更重要。