推理任务调度和训练任务调度有明显差异。训练任务通常关注资源占用和完成时间，推理任务则面对在线请求、SLA、突发流量和用户体验。调度策略既要保证低延迟，也要提高资源利用率。
在推理平台中，副本数、批处理、路由、模型加载、显存占用和弹性伸缩会互相影响。某个策略看似提高吞吐，可能会增加排队延迟；某个策略降低延迟，又可能造成 GPU 利用率下降。
相关主题可以结合 模型推理、算力调度、AI基础设施 一起阅读。本文重点放在平台能力、工程边界和可落地的治理思路上，避免只停留在概念解释。
推理调度首先要明确服务目标
不同推理服务的目标不同。交互式问答关注低延迟，批量内容处理关注吞吐，低频模型关注成本，高频模型关注稳定性。没有目标分层，平台很难为所有模型设置统一调度策略。
服务目标应转化为可观测指标，例如 P95 延迟、P99 延迟、错误率、吞吐、队列等待、冷启动时间和单位请求成本。
只有指标清楚，调度策略才有验证依据。
路由策略影响延迟和稳定性
推理请求需要被路由到合适的模型版本和副本。路由可以按负载、版本、租户、模型类型和资源水位决策。
简单轮询在负载均衡场景下容易实现，但在多模型、多版本和异构资源池中不够精细。某些副本可能显存紧张，某些副本刚启动尚未预热，某些版本处于灰度阶段。
推理调度应把路由状态和模型状态结合起来，而不是把所有副本视为完全一样。
批处理是吞吐和延迟的取舍
批处理能提高 GPU 吞吐，但会引入等待窗口。窗口越大，批次越容易凑齐，吞吐越高；窗口越小，延迟越低，但资源利用率可能下降。
不同模型应配置不同批处理策略。对实时请求，批处理窗口需要很短；对准实时和离线请求，可以允许更大批次。
平台应观察平均批大小、批处理等待时间和执行时间，避免批处理策略只凭经验配置。
弹性伸缩要考虑模型冷启动
普通服务扩容后很快可用，但推理副本需要加载模型、预热缓存和占用显存。大模型冷启动可能需要较长时间，扩容不能立即缓解流量峰值。
因此推理平台需要最小副本、热池、预热和容量预测。对于核心模型，保留热副本比完全按需启动更稳定。
弹性指标也不能只看 CPU 或 QPS，还要看队列长度、P95 延迟、GPU 利用率和显存水位。
成本控制不能牺牲核心 SLA
推理成本优化常常通过提高批处理、共享 GPU、降低副本和按需加载实现。但这些策略都可能影响延迟和可用性。
平台应按服务等级区分策略。核心在线模型优先保证 SLA，低频模型可以接受更高冷启动成本，批处理任务可以优先追求吞吐。
成本治理的关键是分层，而不是全局压缩资源。
推理调度需要闭环观测
调度策略是否有效，需要通过延迟、吞吐、成本、错误率和资源利用率一起判断。单独看任何一个指标都可能误导。
例如吞吐提升但 P99 延迟恶化，说明批处理窗口可能过大；成本下降但错误率上升，说明资源压缩影响稳定性。
推理调度的成熟度体现在能针对不同模型设置差异化策略，并持续用数据校准。
常见问题
推理任务调度和训练任务调度最大的区别是什么？
推理任务更关注在线延迟、请求路由和弹性伸缩；训练任务更关注资源占用、队列公平和失败恢复。
批处理一定会提高推理效果吗？
批处理通常提高吞吐，但可能增加延迟，需要按场景设置窗口和批大小。
推理扩容为什么有时不生效？
可能因为模型加载和预热时间较长，新副本不能立即承接流量。
小结
推理任务调度的建设重点，不是把所有能力一次性堆满，而是先把任务、资源、环境和指标之间的关系理清楚。只有问题可解释、策略可验证、结果可复盘，平台能力才会持续变强。
转载请注明出处：https://www.cloudnative-tech.com/p/8424/
