模型推理服务方案相关项目最容易在需求、平台和采购之间出现口径冲突。技术团队证明组件能运行，业务团队关心结果和时效，平台团队需要知道资源、版本与故障如何治理，采购还要判断支持范围和长期责任。只有把对象、条件、证据和退出方式写清，方案才具备企业决策价值。

方案分流原则：先依据交互时限、任务可重试性和结果交付方式，把需求分到在线、离线或批量链路；同一模型不代表可以共用队列与故障处置。

先把任务分到正确的交付链路

方案设计从业务等待方式开始。用户是否停留在页面等待首Token，任务是否允许数小时后取结果，输入能否分片，失败后能否重跑，以及结果由接口、对象存储还是数据表交付，这些答案决定任务属于在线、离线还是批量。模型名称相同，也不能据此合并运行方式。

三类任务至少要形成以下服务契约：

服务目录、入口、队列和结果存储都应标明任务类型。一个接口同时接收三类任务却没有不同等待预算和恢复语义，通常会把在线超时、离线重跑和批量重复混成同一故障。

共享资源前先定义抢占与降级

在线服务需要受保护容量和最大排队时间；离线任务可以降低优先级或暂停；批量任务可安排在窗口内运行，但必须保留中间状态。资源不足时，应提前写清谁可以抢占谁、何时停止接收新任务，以及被暂停任务如何恢复。

验证要包含组合负载：在线高峰期间启动离线任务、批量窗口结束后释放资源、离线重试与在线突发同时发生。记录入口等待、各类队列、任务进度、GPU水位和结果状态，确认调度策略没有用在线长尾换取批量完成量。

证据按任务结果而不是统一性能表保存

在线链路保留首Token、完整响应、拒绝、取消和降级记录；离线链路保存检查点、恢复位置、结果一致性与重跑资源；批量链路保存批次清单、成功失败状态、重试次数和交付位置。报告必须能回答某次故障后是否漏结果、重复结果或继续消耗资源。

真实业务数据需要脱敏，测试凭证与生产凭证分离。对外采购结论也应注明平台覆盖到哪一类任务：如果候选方案只负责在线模型发布，离线编排和批量结果管理所需的系统与人员不能被写成“平台已支持”。

在线、离线与批量任务要分开设计恢复语义

在线服务的恢复目标是尽快阻止失败扩散，并让新请求进入可用实例或降级路径。入口需要知道何时停止向未就绪实例发送流量，调用方要能识别限流、超时和不可重试错误。已经开始流式返回的请求通常不能简单从中断位置续接，因此业务应提前定义重新发起、缩短回答或人工接管的体验。

离线任务更关注进度能否保存和结果能否校验。长任务若没有检查点、输入分片标识与幂等写入，节点故障后可能从头重跑，既占资源又造成重复结果。批量任务则要能识别成功、失败、跳过和待重试批次，并把重试上限、死信处理和结果清单交给业务复核。三类任务共用同一模型资产，并不意味着可以共用同一种恢复策略。

资源隔离也应按失败影响面设计。在线服务可保留受保护容量和最大排队时间；离线任务可以在资源紧张时暂停或降低优先级；批量任务可以按窗口调度，但必须避免抢占后留下无法识别的中间结果。方案边界应写清谁可以抢占谁、谁负责恢复，以及恢复后如何证明结果没有遗漏或重复。

压测要模拟三类任务的竞争关系

分别测试三类任务只能证明各自能运行，不能证明它们共享资源后仍可控。测试计划应包含在线请求与离线任务并行、批量任务在峰值前后启动、资源回收后在线服务重新升压等组合场景。每一轮都要固定模型版本、输入输出分组、并发或任务数量、资源配额和调度策略，并记录入口等待、队列、任务进度、资源水位与失败结果。

在线验收关注首Token、完整响应、长尾和拒绝行为；离线验收关注任务完成时长、检查点恢复与结果一致性；批量验收关注单位窗口完成量、失败批次隔离和重试放大。若优化批量吞吐导致在线长尾越界，不能用总体处理量上升判定顺利获得。报告应同时保留正常、压力、故障和恢复阶段，避免只呈现最稳定的一段。

方案成本要按运行方式和责任拆账

在线服务通常需要持续驻留、峰值余量和更及时的值守；离线任务可能允许排队，但会产生长时间占用、检查点存储和失败重跑成本；批量任务还涉及任务编排、结果存储、重试和数据清理。预算不能只按GPU时长汇总，否则无法解释为何同一资源池中有些空闲属于必要保护，有些等待来自调度或数据依赖。

采购或自建评估应列出入口与队列改造、模型和镜像维护、监控字段接入、任务编排、存储留存、值班和故障演练。候选平台若只覆盖在线发布，而离线调度与批量结果交付需要另建系统，应把集成接口、人员投入和升级责任作为实施成本，而不是默认由现有团队无成本承担。

退出机制要保护接口、任务和结果

替换服务方案时，在线调用方需要稳定接口与切流窗口；离线任务需要暂停接单、完成或安全终止在途任务；批量任务需要导出任务清单、状态、结果位置和失败原因。模型版本、运行配置、权限规则、审计记录与监控口径也要有可交付范围，不能只备份权重文件。

退出演练可以先在测试环境执行：停止新任务，确认在途任务处置，导出必要配置和记录，再让代表性调用切换到备用入口。无法迁移的专用字段、调度语义或结果格式，应在采购前列为锁定成本。这样即使短期不更换方案，企业也知道服务停止、合同到期或架构调整时如何收口。

放行结论要分别回答三类任务

在线链路的结论写清等待预算、拒绝与降级行为；离线链路说明检查点粒度、恢复范围和结果校验；批量链路说明分片、重试上限、重复处理与失败清单。某一类任务顺利获得，不能自动放行另两类；共用资源时还要附上竞争测试结果。

责任也按链路划分。应用团队定义时限、重试与结果正确性，平台团队维护入口、队列、调度和资源，数据或业务团队负责批次清单与结果消费，SRE负责告警和恢复。候选平台缺失离线编排或结果治理时，采购附件必须列出补建系统、存储、值班和升级工作。

下一步建议

先从三个真实需求各选一个样本，填写时限、入口、资源、失败语义和交付物，再决定是否共享资源池。在线与离线竞争、在线与批量窗口重叠是首轮必测场景；若需要补充访问、伸缩与监控验收，可参考 AI推理服务POC怎么做？模型、伸缩、访问与监控4类验收项。不要先选框架再强迫所有任务适应同一运行方式。

常见问题

在线推理和批量推理可以共用同一组GPU吗？

可以共享资源池，但不能默认使用同一优先级和排队规则。在线请求有明确等待预算，批量任务更适合按窗口运行；如果批量占满显存或队列，在线请求可能在GPU高利用率下持续超时。

共享前要定义在线保留容量、批量启动窗口、抢占或暂停条件，以及批量任务被中断后的恢复方式。组合压测若无法证明在线长尾受控、批量状态可恢复，就应先隔离资源，而不是用总体利用率为共享方案辩护。

成本评估还要分开记录在线保护容量和批量实际占用。若共享依赖人工反复腾挪资源，值班工时与误操作风险也应进入方案成本；出现持续抢占或任务状态丢失时，应能快速恢复到隔离配置。

离线任务与批量任务有什么关键区别？

离线任务强调单个长任务的进度、检查点和最终结果，例如一次长文档处理；批量任务强调大量独立或可分片输入的状态管理、失败隔离与结果清单。两者都不要求用户同步等待，但恢复单位和交付方式不同。

若把离线任务简单拆成批次，却没有幂等写入和汇总规则，故障后可能产生重复结果；把批量任务当作一个长任务，又会让少量失败触发全量重跑。方案应依据可分片性和结果校验方式选择实现。

验收时可以中断一个测试分片，检查离线任务从哪个检查点恢复、批量任务是否只重跑失败分片，以及汇总结果能否识别重复和遗漏。无法说明恢复单位时，任务分类仍停留在名称层面。

三类任务需要使用不同的服务入口吗？

不一定需要三个域名或网关，但调用契约必须能清楚区分。在线入口应快速返回成功、拒绝或降级；离线和批量入口需要任务标识、状态查询、取消、结果位置与失败明细。只给予同步接口通常无法表达长任务生命周期。

即使共享统一网关，也应在路由、配额、凭证、队列和监控中保留任务类型。否则故障时无法判断请求应该重试、暂停、降级还是等待人工处理。

接口契约还要写清版本、幂等标识、取消后的资源处理和结果留存。未来更换编排或推理组件时，业务可继续使用稳定契约，而不必跟随底层任务状态字段整体改造。

采购平台时怎样判断它真正覆盖了批量任务？

现场验证应从提交一组分片开始，观察任务状态、资源调度、单片失败、有限重试、重复提交、暂停恢复和结果清单。只有“支持异步接口”或“有任务页面”不足以证明批量治理完整。

还要核对结果存储、留存清理、权限审计和失败批次导出由谁负责。若这些能力依赖外部工作流或自建脚本，应把集成边界、维护人和升级回归写入实施成本，而不是把它们算作平台原生能力。

最后执行一次停止接单与退出演练，确认在途批次如何完成或终止、结果和失败清单怎样导出、临时资源与凭证怎样清理。只有交付和收口都可复核，批量能力才具备采购价值。