大模型服务SLA谈判中最容易出现的冲突，是采购希望得到一句“稳定可用”，平台团队希望看到可量化指标，供应商则要求把模型、网络、调用方和基础设施例外全部写进边界。三方如果只讨论一个可用率数字，合同签完仍然无法回答：哪些请求算服务请求，什么状态算故障，谁负责采集证据，未达标之后如何补救。

采购口径：本文面向平台负责人、采购影响者、架构师和法务协同人，讨论模型服务采购中可计量、可举证、可复盘的SLA边界；不给予任何厂商默认承诺、价格或法律结论。

为什么同一个SLA会让各方得出不同结论

一家企业准备把内部知识助手和客服辅助接入外部模型服务。采购在招标文件中写了“服务可用率不低于约定目标，故障及时恢复”，平台团队却发现测试报告只记录了接口返回状态，没有记录输入长度、流式中断、限流、模型切换和调用方重试。供应商的解释是，网络不可达、调用方超限和上游模型调整不属于服务端故障。

这个冲突不是谁故意模糊，而是服务对象没有被定义。对普通Web接口来说，HTTP响应可能足以描述一次调用；对大模型服务来说，一次调用还可能包含排队、首Token、持续输出、完整响应、内容过滤、配额、模型版本和上下文限制。SLA的第一步不是写承诺值，而是先规定“被计量的服务是什么”。

采购合同还要区分三个层次：供应商承诺的服务能力、客户自身负责的接入条件，以及双方共同负责的端到端体验。模型服务返回成功，不代表业务应用一定展示成功；业务应用超时、网关丢弃或调用方凭证失效，也不能简单归入供应商可用性。若不把责任边界拆开，后续的故障复盘和补救都会变成争论。

先把“服务”定义成可计量对象

入口对象要能被双方识别

合同至少应写明服务入口、环境、模型或模型组、调用协议、身份凭证类型、计量时间源和允许的请求范围。私有化部署还要明确服务实例、集群或资源池属于哪一方管理；托管服务则要明确供应商能控制到哪一层。不能只写“模型API”，却不写模型版本、路由范围和环境边界。

建议为每个服务对象建立一份服务字典，内容包括：

• 服务名称、模型标识和版本识别方式
• 生产、测试或灾备环境的区分方法
• 请求类型、最大输入输出边界和流式规则
• 计量系统、日志字段、时间窗口和时区
• 客户侧网络、身份和网关依赖
• 服务方、客户方及共同责任的联系人

服务字典不等同于技术配置清单。它的作用是让采购合同、POC报告、监控面板和故障单使用同一组名称。模型发生切换时，如果服务名称不变但版本变化，合同还要规定如何通知、是否需要重新验证，以及何时可以把新版本视为同一服务。

“可用”不能只等于进程还活着

模型服务的可用性至少需要关联请求结果、服务状态和调用条件。健康检查正常但业务请求持续超时，不能直接作为可用；接口返回错误但原因是客户使用了超出约定边界的输入，也不应和服务端故障混算。这里不建议在没有实际数据时硬写某个比例，而应先写清纳入和排除规则。

以下维度通常需要在合同附件中单独定义：

表格中的“证据方向”不是要求采购方接受任意日志，而是要在谈判时先确定可复核来源。供应商给予截图、客户侧采集指标和双方工单，可能代表不同的事实层级；如果合同没有规定优先级，异常发生后会出现多套数字。

可用性之外，哪些指标必须写测试条件

延迟要区分服务阶段

大模型服务的响应时间不能只写平均值。平台负责人通常更关心请求进入后的排队时间、首Token等待、生成过程和完整响应耗时；采购则需要把这些指标翻译成业务可理解的服务边界。不同模型、输入长度、输出长度、并发和流式模式会影响结果，因此条款必须绑定测试条件。

写法可以采用“指标定义 + 测试样本 + 观察窗口 + 例外条件”的组合，而不是直接引用某次演示结果。比如，首Token时间和完整响应时间分别记录，输入输出长度分组统计，异常请求另行归类，客户端网络耗时不和服务端处理耗时混为一谈。没有这些前提，任何延迟承诺都难以复验。

容量要写保护动作，不只写吞吐数字

企业采购模型服务时常见的误区，是让供应商承诺一个看起来很高的并发数，却没有约定超过容量后的行为。高峰到来时，服务可能排队、限流、降级、切换模型或拒绝请求。每种动作都会影响业务，但风险性质不同。

容量条款可以围绕以下问题展开：

• 正常容量和保护容量是否分开
• 队列等待是否有上限，超时后返回什么状态
• 调用方超额时是单租户限流还是全局影响
• 扩容由谁触发，资源不足时谁批准降级
• 模型服务变更容量后是否需要重新压测
• 容量证据是否能按模型、应用和时间窗口拆分

容量不应脱离模型和资源条件。若服务运行在客户自有集群，硬件、驱动、网络、存储和平台调度可能属于客户责任；若由供应商托管，资源池和底层维护的责任又不同。合同应把端到端目标与单层服务目标分开，避免用基础设施指标替代业务服务结果。

故障分级、通知、恢复与补救如何闭环

先定义什么是故障

故障定义应结合影响范围、持续时间、可重复性和责任边界。单个调用方使用错误凭证，通常与全局服务不可用不同；一条模型路由失败，可能被备用服务接管，也可能造成部分业务受影响。若所有错误都用“服务异常”归类，既无法排优先级，也无法评估是否触发SLA补救。

可以在合同附件中建立故障等级，但等级名称不是重点，重点是每一档都要对应动作：

• 影响范围：单请求、单应用、单租户还是全局
• 发现方式：监控告警、客户报障还是定期核对
• 首次响应：谁接单、多久确认、如何更新状态
• 临时处置：限流、切换、回退、暂停发布或恢复资源
• 根因与复盘：是否需要报告，报告应包含哪些证据
• 关闭条件：恢复服务不等于问题单可以直接关闭

故障时序要能在双方系统中对齐。至少需要统一事件开始、发现、确认、恢复和关闭几个时间点，并明确使用哪个系统的时间作为计算依据。没有统一时点，即使双方都保存了日志，也可能因为“发现时间”不同而得出不同恢复时长。

补救机制必须和证据绑定

采购方可能要求服务未达标时触发服务抵扣、延长服务期、补充支持或重新评估。具体补救方式应由采购和法务根据合同模板确定，技术团队要做的是把触发条件、证据来源和例外情况写清，而不是自行承诺赔付比例。

建议把补救分为三种层次：技术处置、管理处置和合同处置。技术处置包括切换、限流和恢复；管理处置包括升级、复盘和整改；合同处置才涉及服务抵扣、续约影响或其他商务后果。三者不能混在一句“供应商负责解决”里。尤其要确认客户侧网络、凭证、输入边界或未授权配置造成的事件如何处理。

数据、模型变更和退出机制不能留在附件之外

数据边界要覆盖请求、日志和运维材料

模型服务采购往往只讨论“数据是否出域”，但实际数据链路至少还包括请求正文、响应、错误日志、调用指标、缓存、备份、工单附件和故障排查材料。不同数据可能由不同系统保存，权限和留存也不一样。

平台负责人需要把以下问题带进合同评审：

• 请求和响应是否被保存，保存目的和期限是什么
• 日志是否会记录敏感Prompt、业务标识或输出摘要
• 运维人员能看到什么，是否需要审批和审计
• 测试数据、生产数据和脱敏数据如何区分
• 服务结束后数据、缓存、备份和访问凭证如何清理

这些内容涉及组织安全制度、行业要求和合同条款，不能用“私有化”三个字替代验证。内网部署也不自动意味着所有数据都不会离开边界，备份、远程支持、镜像拉取和监控上报都要逐项确认。

变更和退出决定长期风险

模型服务的版本、接口、运行框架和底层资源都可能变化。合同至少要约定重大变更通知、兼容性验证、客户拒绝或延期条件、回滚方式和服务结束时的迁移协作。对采购方来说，退出机制不是默认要迁移，而是确保关键模型、配置、调用记录和业务接口不会被不可逆锁定。

退出条款可要求双方确认交付清单，例如模型或模型调用配置的归属、接口文档、版本记录、审计记录、数据清理证明和剩余支持周期。哪些内容能够交付，取决于服务模式和合同约定，不能预先把供应商内部实现当成客户天然拥有的资产。

从POC证据过渡到合同条款

POC报告不应只给出“性能顺利获得”或“接口可用”。在转采购阶段，至少把测试条件和结论拆成三类证据：

1. 服务证据：模型版本、接口行为、响应时间、并发形态、容量保护和错误类型。
2. 治理证据：身份权限、日志字段、变更流程、监控告警、故障分级和回滚动作。
3. 责任证据：客户、供应商及第三方依赖各自负责的条件、联系人、升级路径和未验证项。

如果POC只在理想流量、单一模型和管理员凭证下完成，采购合同就不能直接把结果扩展成全部生产承诺。平台团队应把未验证边界写入风险登记，采购再决定哪些风险要转成合同条款、验收前置条件或分阶段采购范围。

可以参考AI模型可观测性怎么看？指标、链路和日志怎么定位问题补齐指标和日志证据；涉及统一入口、鉴权、路由和调用审计时，可结合AI网关是什么？大模型应用与Agent智能体入口治理核对责任分层。若模型服务与训练任务共享资源，还应在AI基础设施分类中继续梳理算力、推理和运营边界。

下一步建议

先把现有POC报告转换成一页SLA条款矩阵：每个指标写明对象、条件、数据源、责任方和未达标动作。然后让平台、采购、安全和法务分别标记无法接受、需要补测和可以直接进入合同的条款。最后选择一条真实但可控的业务链路演练故障、切换、通知和证据汇总，再决定是整体采购还是分阶段扩大服务范围。

不要在没有计量系统和故障演练的情况下承诺复杂SLA。先把双方都能观察、复现和解释的边界写清，比提前填入一个漂亮但无法举证的数字更有价值。

常见问题

大模型服务SLA是否一定要写一个可用率百分比？

不一定。可用率数字只有在服务对象、统计窗口、请求范围、排除项和证据来源都明确时才有意义。若服务包含流式输出、模型路由、配额保护和多种调用方，还需要说明“接口可达”“请求被接受”“首Token返回”“完整响应结束”分别如何计算。否则供应商可以把健康检查正常作为可用，采购方却根据业务超时认定不可用，双方都会拿出看似合理的结果。

更稳妥的做法是先定义基础服务指标，再根据POC和历史数据确定目标。没有足够数据时，可以把目标写成阶段性验证条件，并约定观察窗口、补测和复盘，不要把未经验证的数字直接当成长期承诺。最终是否采用某个百分比，还需要采购、法务和业务负责人结合合同模板确认。

首Token延迟和完整响应时间应该怎么写进合同？

两者应分开记录。首Token延迟反映请求进入服务后多久开始返回生成内容，完整响应时间还受到输出长度、流式策略、客户端读取和网络条件影响。如果把二者合成一个平均响应时间，长输出和短输出会互相掩盖，平台团队也无法判断慢在排队、模型计算还是传输。

条款应写明模型版本、输入输出样本、并发形态、统计分位、流式或非流式方式、是否包含客户端网络，以及异常请求如何归类。采购方还要要求保留原始时间线和测试配置，避免供应商只提交一个汇总数字。涉及业务体验的目标应与服务端指标分开，端到端目标不能自动转嫁给单一模型服务给予方。

私有化部署的大模型服务，SLA由谁负责？

需要按控制边界拆分，而不是笼统归给平台供应商。客户可能负责机房、网络、GPU节点、操作系统和集群资源，供应商负责平台、模型服务或运维支持，业务团队又可能负责调用方和输入数据。任何一层变化都可能影响最终体验。

合同可将SLA分为平台软件可用性、服务组件运行状态、支持响应和端到端业务体验四类，并为每类指定监控来源、责任方和例外条件。例如GPU节点故障、客户网络中断、调用方超限、模型配置变更和供应商软件缺陷应分别登记。只有控制边界和举证方式都写清，私有化服务的SLA才有可执行性。

供应商未达到SLA时，采购方最先应该保留什么证据？

先保留能证明影响范围和时间线的原始记录，包括服务对象和版本、调用方、请求时间、返回状态、延迟阶段、错误类型、容量与资源状态、告警、变更记录以及双方沟通单。不要只保存截图或最终结论，因为截图通常无法说明统计窗口和样本范围。

同时保留客户侧依赖的状态，例如网络、身份凭证、网关、输入边界和自身发布变更。双方应尽快对齐事件开始、发现、确认和恢复时间，再决定是否进入SLA计算。若证据不足，应把事件标记为待核验，而不是为了触发补救强行下结论；后续应把缺失字段补进监控和合同附件。