核心要点

  • 能定调目标:离线批量推理优化吞吐(throughput)而非单条延迟,可接受较高 per-request 延迟换总体效率

  • 能给出核心手段:用大 batch + Continuous Batching(连续批处理)让 GPU 持续满载,避免传统静态 batch 的等待空泡

  • 能做数据侧优化:按序列长度排序聚批,减少 padding 浪费;过滤超长异常样本

  • 能讲规模化与稳健性:多副本/多 GPU 数据并行扩吞吐,记录进度做断点续跑应对长任务中断

标准回答

目标定位

离线批量推理(如批量打标、数据清洗、评测生成)以吞吐优先、延迟不敏感,因此设计取舍与在线服务相反:尽量把 GPU 喂满。

核心优化

  • 大 batch + Continuous Batching:请求一旦完成立即换入新请求,而非等整批结束,消除静态批处理的尾部等待空泡,vLLM 等引擎原生支持。
  • 长度排序聚批:把长度相近的样本放到同一批,减少 padding 导致的算力浪费;对输出长度差异大的任务尤为重要。
  • 多副本并行:用多 GPU/多进程做数据并行,线性扩展总吞吐。

工程稳健性

大规模任务跑时长,需记录已完成 id、定期写检查点,支持断点续跑;失败请求单独重试,避免整批重算。

常见误区

⚠️ 常见踩坑

套用在线服务的"低延迟、小 batch"思路——离线场景应追求吞吐,盲目压延迟会让 GPU 利用率低;另一误区是忽略 padding,长度差异大的请求不排序聚批会浪费大量算力。

追问

追问 1Continuous Batching 相比静态 batching 好在哪?

静态 batching 要等一批里最慢的请求生成完才能换批,短请求被长请求拖住,GPU 出现空泡。Continuous Batching 在每个 decode step 动态调度,已结束的序列立刻释放、新请求即时填入,使 GPU 持续满载,吞吐显著提升。

追问 2批量任务跑到一半中断怎么办?

提前设计断点续跑:以输入 id 为键,每完成一批就把结果落盘并记录已处理集合;重启时跳过已完成项,仅处理剩余与失败重试项。配合幂等写入避免重复,长任务才不会因单点中断而全部重算。

延伸学习

与本题相关的知识库文章、术语、工具与行业资讯。