性能团队给出一组理想环境下的压测峰值，业务希望把它写进服务承诺，采购又要求出现违约时可以明确判断。大模型推理SLA不能从一张成绩表直接生成，它必须把服务对象、请求类型、容量前提、统计窗口和依赖责任转换为可计量条款。

评审口径：压测给予有条件的事实，SLO定义内部目标，SLA再选择可对外承诺且有补救流程的部分，三者不能混写。

先定义被承诺的服务和请求

服务对象要明确到模型或服务版本、接口、调用方、部署范围和可用时间。请求至少按交互、长上下文、批量、流式或工具调用等实际形态分组，因为它们对排队和生成时间的影响不同。把所有请求混为平均值，会让承诺失去解释力。

业务团队需要说明关键窗口和用户体验，平台团队说明容量和保护策略，性能团队说明测试方法，采购与法务确认条款语言。本文给予工程评审框架，不给出具体可用率、延迟或赔付数字。

压测结果必须携带完整条件

每组结果要关联模型、精度、镜像、硬件与拓扑、资源配额、请求集、并发、预热、测试时长和数据源。平均值可能掩盖尾部请求，单个峰值也可能来自短暂状态，因此应根据业务选择分位、错误、限流和吞吐等指标。

压测还要覆盖容量边界：随着负载增加，排队、首Token、完整响应和错误怎样变化。最终应形成区间和曲线，而不是只保留一个最好数字。

四层边界把事实转换为服务目标

下图从测试事实、容量条件、SLO到SLA逐层收敛，外部依赖和补救流程贯穿其中。

只有能持续采集、双方解释一致且责任可执行的指标，才适合进入服务承诺讨论。 如果数据仅来自临时脚本、无法在生产复现，先把它留在POC或SLO层。

测量窗口和数据源要能处理争议

SLA需要说明按什么时区和周期统计、维护窗口如何处理、失败请求怎样归类、限流是否计入、数据缺失怎么办，以及双方使用哪个数据源。网关、模型服务和客户端可能观察到不同时间，必须提前确定优先级与关联方式。

表格中的字段需要项目化确认，不能复制其他系统模板后直接使用。

依赖责任和持续校准决定承诺是否可执行

网络、调用方重试、上游模型、外部工具、数据源和企业自身配置都可能影响结果。责任边界要说明供应方可控制什么、调用方应满足什么，以及共同故障如何取证。排除项不能无限扩大，否则SLA失去意义。

压测条件和服务证据应先按 AI推理服务POC验收框架 固定；后续模型观测口径可参考 AI模型可观测性 进一步细化。

建议先以内部SLO运行一段观察期，检查指标稳定性和处置流程，再决定是否进入合同。压测峰值不应成为最低承诺，未经复核的平均值也不应成为争议依据。 模型、硬件或策略重大变化后应重新校准。

SLA评审要分别保留工程事实和商务条款

性能工程师提交的是模型、请求、资源和窗口限定下的测试事实；平台团队据此制定容量保护和内部SLO；采购与法务再决定哪些指标能够进入合同。三类材料应相互引用但保持分层，避免合同数字脱离测试条件，或工程报告被误读成外部承诺。

评审表至少包括指标定义、起止点、统计窗口、数据源、样本不足处理、限流与维护窗口、调用方前提、依赖排除和事件补救。任何字段无法达成共同理解，就先保留为内部观察项。没有稳定生产数据源的指标，即使压测表现很好，也难以在争议中复核。

责任讨论不应只有“供应方负责”与“客户负责”两列。网络、上游模型、外部工具和双方共同配置需要单独列出取证与升级流程。排除项要有限且可证明；过宽的排除范围会让承诺失去价值，过窄又会把不可控制因素转成不可执行责任。

模型版本、硬件、路由或调用画像重大变化后，应重新校准SLO，再决定是否影响SLA。持续校准不是频繁修改合同，而是用事实判断容量和风险是否发生变化，并为下一次商务评审准备可复核材料。

合同必须说明容量采购、变更和退出时怎样重算

推理SLA创建依赖约定容量。合同应说明基础资源由谁给予、业务增长如何申报、突发流量超过配额时系统采取什么保护，以及扩容完成前哪些请求不进入承诺范围。供应方不能在容量不足时无限免责，调用方也不能在未通知的负载变化下要求沿用原条件，双方需要可执行的变更流程。

指标变更同样需要门禁。模型、精度、硬件、请求长度、路由或客户端重试变化后，技术团队先判断是否影响基线，必要时重跑代表性负载；采购和法务再决定是否修改合同附件。历史数据与新口径要分开保存，避免统计定义变化后仍把两个周期直接比较。

服务事件材料至少应包括承诺对象、时间窗口、受影响请求、双方数据源、容量与维护状态、处置动作和恢复验证。合同可约定争议时如何交换脱敏证据、多久提出异议以及谁组织联合复核。补救不应只有赔付，也可以包含根因报告、限期整改、容量调整或退出协助，具体形式由相关方确认。

退出条款要覆盖数据与配置导出、凭证撤销、未结工单、历史指标保留和切换支持。若服务从外部模型转为自建，或从一种推理平台迁移到另一种，原SLA不自动继承。企业应先建立新基线并保留旧路径的受控回退窗口，再结束原承诺。

实施团队还要维护一份指标字典，记录每项指标的采集位置、计算方法、缺失数据和负责人。监控组件或网关升级后先做并行核对，确认新旧数据差异可解释，避免合同争议来自测量工具变化而非服务本身。

下一步建议

先选择一个业务服务和两类真实请求，统一压测与生产的指标定义。把结果整理成容量曲线，标出稳定区、保护区和未验证区，再召开技术、业务、采购与法务联合评审。先落内部SLO和事件流程，证据稳定后再讨论外部SLA。

常见问题

压测结果可以直接写进SLA吗？

通常不可以直接照搬。压测结果绑定模型、请求、硬件、软件、资源、预热和观察窗口，而SLA需要面对持续运行、负载变化、维护和故障。若不补充条件，理想环境中的数字会被误解为任何时间都必须达到的承诺。

更稳妥的做法是先把结果转成容量曲线和内部SLO，验证生产数据源与处置流程。只有可持续测量、责任清晰、业务认可的指标，再由采购和法务转成合同条款。具体数字与补救方式必须由项目相关方确认。

合同评审应把压测报告、容量曲线和指标字典作为附件，注明哪些数据只用于内部SLO、哪些进入SLA讨论。模型或资源改变时，先重建基线，再由业务与采购确认是否调整承诺。

推理SLA应该按平均值还是分位数？

没有适用于所有服务的单一选择。平均值容易理解，但可能掩盖少量严重慢请求；分位数能描述尾部体验，却依赖样本量、窗口和请求分组。批量任务可能更关注吞吐和完成窗口，交互服务则更关注首Token、完整响应和错误。

项目应先按请求类型定义用户体验，再选择指标，并写清起止点、统计窗口、样本不足和限流处理。平均值和分位数也可以组合使用，但不能把不同请求混在一起。最终口径要能由双方使用同一数据复核。

指标选择应跟随请求类型。交互请求可重点观察尾部体验和错误，批量任务更关心吞吐与完成窗口；样本量不足时标记数据不稳定。双方需约定统计脚本和缺失数据处理，避免只选择对己有利的口径。

上游模型或网络故障如何划分责任？

先列出平台可控制、调用方可控制和共同依赖三类对象，再为每类指定数据源与通知流程。上游模型故障需要有健康和错误证据，网络故障要区分企业侧、供应侧和公共链路，不能仅凭单方日志下结论。

SLA可以定义排除项，但也应说明故障期间的路由、降级、通知和恢复责任。共同依赖出现争议时，按预先约定的时间戳、链路和工单证据复核。具体法律与赔付责任应由采购和法务确认，技术团队只给予事实。

责任矩阵应分别列出平台可控制、调用方可控制、上游或网络依赖和共同配置，并为每类约定证据与通知人。故障期间是否路由、降级或暂停服务也要有预案，法律与赔付仍由采购和法务确认。