采购 AI 推理服务时，合同里最容易写错的是“平均时延达标”。平均值会掩盖少数请求的严重拥堵，而用户体验和业务超时往往由尾部请求决定。因此，合同应把尾部时延定义为指定条件下的 P95、P99，而不是笼统承诺“响应迅速”或“平均响应时间满足要求”。
先把测量对象写清楚
尾部时延不能脱离业务负载单独约定。合同附件至少应固定模型名称与版本、精度或量化方式、上下文长度、输入输出 Token 分布、并发请求数、流量到达方式，以及是否启用动态批处理、KV Cache、前缀缓存或投机解码。若这些条件可以由供应方自由调整，测试结果就缺乏可比性。
在线生成服务还应拆分指标。首 Token 时延反映排队、输入处理和调度效率；持续输出时延反映后续生成是否稳定；端到端时延则覆盖网关、网络、推理和后处理。合同可分别约定各指标的平均值、P95 和 P99，并明确统计窗口、预热方式、持续运行要求及失败请求的处理口径。不能用高吞吐掩盖用户长时间等待，也不能只报告某次压测中的最高 Token/s。
把“达标条件”与“违约处理”连起来
合同应定义有效请求：成功返回、满足质量要求且在约定时延内完成的请求，才可计入有效产出；超时、错误、被丢弃或因服务降级未完成的请求，应单独统计。测试至少应覆盖典型负载、峰值负载和压力负载，并观察吞吐、P95/P99 时延、错误率、显存、功耗、温度、通信带宽和服务抖动是否随并发变化。
验收条款还要写明单卡、多卡、单机和多机配置，以及模型—硬件—软件版本矩阵。版本升级、模型更换、流量分布显著变化或部署拓扑变化后，应触发复测；若尾部时延未达标，合同应明确整改期限、重新验收方式、性能回退方案及相应责任，而不是只保留一句“双方协商解决”。
真正可执行的尾时延条款，核心不是承诺一个漂亮数字，而是锁定测量边界、业务条件、统计方法和不达标后果。只有这样，合同验收的才是可持续交付能力，而不是实验室里的瞬时峰值。