在线推理和离线推理都使用模型做预测或生成，但它们面对的业务目标不同。在线推理通常直接服务用户请求，离线推理更多用于批量处理、周期任务或异步分析。
如果平台把两者当成同一种任务，就容易出现策略错配：在线任务为了吞吐牺牲延迟，离线任务为了低延迟浪费资源。区分在线和离线推理，是设计推理平台资源策略的前提。
对比两者时，应从延迟目标、架构形态、批处理、资源调度、观测指标和成本模型几个维度看。
相关主题可以结合 模型推理、模型部署、AI基础设施 一起阅读。本文重点放在推理与部署的工程边界、稳定性指标和平台化治理方法上，避免只停留在概念解释。
目标差异决定架构差异
在线推理优先关注低延迟、高可用和稳定响应，用户等待时间直接影响体验。离线推理更关注整体吞吐、任务完成时间和单位成本。
因此在线推理通常需要常驻服务、弹性伸缩、限流和快速回滚；离线推理更适合任务队列、批处理和资源复用。
目标不同，决定了两类推理不应共用完全相同的调度策略。
在线推理更依赖服务治理
在线推理需要处理实时请求，必须关注路由、超时、重试、熔断、灰度和观测。任何长尾延迟都可能影响用户体验。
服务副本需要保持健康，核心模型通常要有最小副本和热池。
在线场景下，稳定性通常比极致资源利用率更重要。
离线推理更适合批量优化
离线推理可以把大量请求合并处理，更容易通过批处理提高 GPU 吞吐。任务可以排队，也可以在低峰期运行。
离线任务对单个请求延迟不敏感，但对整体完成时间、失败重试和资源成本敏感。
离线推理的优化重点是吞吐和成本，而不是每个请求的即时响应。
资源调度方式不同
在线推理需要稳定副本和快速扩容，资源策略要考虑冷启动和峰值流量。离线推理可以通过队列、优先级和批处理更灵活地利用空闲资源。
如果离线任务长期占用高价值 GPU，可能挤压在线服务；如果在线服务过度预留，也会降低资源利用率。
平台应通过资源池分层和优先级规则，把两类任务的边界划清。
观测指标不能混用
在线推理重点看 P95/P99 延迟、错误率、可用性、队列等待和用户体验指标。离线推理更关注吞吐、任务完成时间、失败率和单位成本。
如果只用统一指标评估，两类任务都会被误判。例如离线任务延迟高未必是问题，在线任务吞吐高也不一定健康。
观测指标必须服务场景目标，而不是为了统一而统一。
平台设计要支持混合场景
现实中很多平台同时承载在线和离线推理。关键不是强行拆成两套平台，而是在同一平台中建立任务类型、资源池、队列和策略边界。
在线服务应有稳定容量和保护策略；离线任务可以利用空闲资源，但在资源紧张时应可让渡。
当平台能按场景差异调度和观测，在线与离线推理才能在同一基础设施上协同运行。
任务入口不同
在线推理通常由用户请求、业务系统或实时 API 触发，入口强调稳定、低延迟和可用性。离线推理通常由调度任务、批处理作业或数据管道触发，入口强调任务管理和吞吐。
入口不同会影响整套架构选择。在线推理需要网关、路由、限流和服务发现；离线推理更需要队列、任务状态、失败重试和结果归档。
不要因为二者都调用模型，就忽略任务入口和治理方式的差异。
批处理策略不同
在线推理也可以使用动态批处理，但窗口必须很短，不能明显影响用户体验。离线推理则可以使用更大的批次，甚至通过排队等待来提高 GPU 吞吐。
如果把离线批处理策略直接用于在线服务，会造成长尾延迟；如果把在线低延迟策略用于离线任务，又会浪费资源。
批处理策略应跟随场景目标，而不是跟随模型类型本身。
失败处理方式不同
在线推理失败时，通常需要快速降级、重试、切换版本或返回可控错误，因为用户正在等待。离线推理失败时，可以暂停任务、重试分片或等待资源恢复。
这种差异决定了在线推理更依赖服务治理，离线推理更依赖任务编排和状态管理。
失败处理方式不同，是在线和离线推理架构差异的重要来源。
成本优化重点不同
在线推理成本优化要守住延迟和可用性底线，不能为了利用率牺牲核心体验。离线推理成本优化空间更大，可以利用低峰资源、批处理和队列调度。
平台应允许离线任务使用空闲资源，但在在线服务资源紧张时让渡。这样既能提高整体利用率，又不会影响关键链路。
在线与离线协同的关键，是资源边界清楚、优先级明确、指标分开评估。
混合平台的设计建议
如果同一平台同时承载在线和离线推理，建议先在任务类型上做显式区分。提交任务时就声明在线服务、批量任务、低频按需或实验任务，后续调度、观测和成本统计才能分开。
资源层可以保留共享底座，但要有优先级和回收规则。在线服务拥有稳定容量，离线任务可以使用空闲资源；资源紧张时，离线任务应让渡给在线链路。
这种设计能兼顾利用率和稳定性。平台不需要为每类任务建一套孤立系统，但必须让不同任务的目标和边界清楚。
选择架构时的判断问题
判断一个推理任务更接近在线还是离线，可以先问几个问题：用户是否在等待结果，是否有明确 SLA，失败后能否稍后重试，是否可以批量处理，结果是否需要立即返回业务系统。
如果用户正在等待，且延迟直接影响体验，就应按在线推理治理；如果任务可以排队、分片和重试，就更接近离线推理。很多场景介于两者之间，需要按服务等级拆分。
这种判断比简单按模型大小分类更可靠。大模型也可能做离线推理，小模型也可能承接关键在线请求，真正决定架构的是业务目标和交付时效。
小结
在线推理和离线推理的区别，最终会落到架构、资源和指标选择上。在线场景优先保障响应和稳定性，离线场景优先提升吞吐和成本效率；平台需要允许两类任务共用底座，但不能混用同一套治理目标。
常见问题
在线推理和离线推理最本质的区别是什么？
在线推理面向实时请求，核心目标是稳定响应、低延迟和可用性；离线推理面向批量任务，核心目标是吞吐、成本和任务完成效率。两者都可能使用同一类模型和 GPU 资源，但调度目标、失败处理、观测指标和资源策略不同。把离线任务直接按在线服务方式运行，成本会偏高；把在线请求按离线批处理方式处理，又会伤害用户体验。
两类推理能不能共用一套平台？
可以共用底层资源池、镜像管理、模型仓库和观测基础设施，但上层治理目标要分开。在线推理需要服务健康、路由、灰度、P95/P99 和弹性策略；离线推理更关注任务队列、批大小、失败重试、资源抢占和单位成本。如果平台只提供一种运行模式，最终往往会让某一类场景被迫适配不合适的机制。
离线推理为什么更适合关注吞吐和成本？
离线任务通常不直接面对用户实时交互，允许在一定时间窗口内完成，因此可以通过更大的批处理、排队调度、低峰运行和资源复用来降低成本。它关注的是单位时间处理量、任务完成时间、失败重试成本和资源利用率，而不是每个请求的毫秒级响应。这样的目标差异决定了离线推理不应简单套用在线服务的扩缩容和告警策略。
混合场景下如何避免在线任务被离线任务影响？
关键是资源和优先级隔离。可以通过独立队列、节点池、配额、抢占策略、时间窗口和路由规则，把在线请求的最低容量和延迟目标保护起来。离线任务可以利用低峰资源或可抢占资源，但不能无边界占用显存和计算能力。观测上也要能区分在线与离线的资源水位，否则平台只看到整体利用率高，却看不到在线体验被挤压。
转载请注明出处：https://www.cloudnative-tech.com/p/8466/
