在线推理与批处理可以共享同一算力池，但不能把两类任务视为同一种负载。在线请求面向实时交互，重点是延迟稳定、并发可控；批处理通常处理可积压任务，更关注单位时间的整体吞吐。若只追求设备利用率，批任务可能挤占在线服务所需资源；若始终为在线业务预留过多容量，又会让闲置算力难以利用。共享的核心因此不是“放在一起跑”，而是明确谁能使用资源、何时让出资源，以及服务降级时如何处置。
先划定服务边界
调度策略应先区分服务等级。在线推理需要明确延迟和错误率要求，并设置资源保障；批处理则可以使用剩余容量，或在负载较低时增加并发。批任务可暂停、延后或拆分执行，在线请求通常不适合因资源争抢而长时间等待。若两者共用资源却没有优先级和隔离机制，批处理的吞吐提升可能直接转化为在线延迟抖动。
资源保障不一定意味着永久划出一块闲置设备。也可以通过配额、并发限制和动态调度，在保障在线服务底线的同时，把暂时空出的资源交给批任务。但“可借用”必须配套“可收回”：在线负载上升时，系统要能及时限制或暂停批处理，否则弹性只存在于规划图上。
让调度服从负载变化
共享池需要同时观察在线请求积压、延迟表现和批任务完成进度，而不是仅按设备利用率决策。在线负载升高时，优先保护交互服务；负载回落后，再提高批处理资源占用。对可拆分的批任务，还应考虑任务切片与恢复成本，避免频繁中断造成重复计算，反而降低有效吞吐。
批处理的批量合并也需要边界。合并请求有助于提高资源利用率，但等待更多请求会增加处理时延；因此适合对完成时间较宽松的任务，不应不加区分地套用于在线请求。实际策略应根据模型、请求长度和负载波动验证，而不能只凭理论峰值判断。
用生产负载验证共享收益
验证时，应在接近实际的请求组合下同时运行在线与批处理任务，观察在线延迟、错误与限流情况，并核对批任务的有效完成量。还要测试高峰到来时资源能否及时回收、批任务中断后能否续跑，以及故障切换是否改变模型版本或服务质量。
如果在线服务的保障边界无法说明，或批任务无法被限制和恢复，共享算力就可能把成本节省转化为服务风险。合理的目标不是让每台设备始终满载，而是在可接受的在线体验下，稳定提高整体有效产出。