详细解释
SLA（Service Level Agreement，服务等级协议） 是企业采购 AI API 时最容易被忽略、但”出了事才发现是命”的那个合同条款。它不是一句口头承诺”我们很稳定”，而是一套量化指标 + 不达标就真金白银赔钱的合同条款。对于 AI API 场景（Token 计费、流式输出、多区域），SLA 通常包括四个部分：可用性（Availability）、延迟分位数（Latency Percentiles，如 P50/P95/P99）、错误率（Error Rate，非 5xx / 429 正常限流不赔）、数据持久性（Durability，RAG 存储、微调训练数据不丢）。
四个数字：99.9% / 99.95% / 99.99% / 100% 意味着什么
可用性计算公式：Availability = (总时间 - 不可用时间) / 总时间 × 100%。这里的”总时间”按自然月或自然年算，扣除”计划维护窗口（提前 3 天通知客户的升级）“。换算成每月允许的真实停机时长（非维护窗口的）：
| SLA 承诺 | 月允许停机（分钟） | 月允许停机（小时） | 年允许停机（小时） | 典型售价溢价 | 适合业务场景 |
|---|---|---|---|---|---|
| 99.0%（两个九） | 432 分钟 = 7.2h / 月 | 7.2h | 87.6h | 无溢价（免费 / 免费试用版） | 内部测试、个人玩具项目、不对外（不能写在商用合同里） |
| 99.9%（三个九） | 43.2 分钟 / 月 | 0.72h | 8.76h | 基准价 | 中小企业 SaaS、非交易型内容（文档问答、摘要、翻译）、非工作时间的辅助工具 |
| 99.95%（三个九半） | 21.6 分钟 / 月 | 0.36h | 4.38h | 基准价 × 1.3 至 1.5 | 金融、客服核心、交易决策辅助、企业内部 OA 聊天机器人（工作日 9:00-18:00 不允许挂） |
| 99.99%（四个九） | 4.32 分钟 / 月 | 0.072h = 4.3 分钟 | 52.6 分钟 | 基准价 × 2 至 3 | 支付风控实时评分、医疗问诊、政务实时接口、电商大促期间核心文案生成 |
| 99.999%（五个九） | 25.9 秒 / 月 | — | 5.26 分钟 | 基准价 × 5+ | 航空/电力/运营商级；AI 场景几乎没人承诺（除非跨 5 个 AZ 多活 + 异地容灾 + 每秒百万 QPS 级别） |
关于 SLA 赔偿（Service Credit）：常见写法是”月度可用性每低于承诺 0.1%，赔该月对应服务消费额的 10%，最高赔偿不超过当月消费的 100%“。注意：API 公司的 SLA 赔偿通常不是”赔现金”，而是”赔下次买的额度（Service Credit）“，有效期 12 个月。
AI API 场景下 SLA 的四大特有条款（和传统 API 不一样）
别把传统云服务器 ECS 的 SLA 模板直接套 AI API。以下四条是 AI 专属，缺了一条等于 SLA 是废纸：
| 条款 | 说明 | 谈判时建议的措辞 |
|---|---|---|
| 5xx 才算不可用，429 Rate Limit 不纳入 SLA 计算 | 限流 429 是你自己客户侧调用太多，不算平台故障；但如果因为平台没按合同给足 RPM/TPM 配额导致 429，那应该算故障。 | “因乙方未按配额承诺满足客户限流阈值而返回的 HTTP 429，等同于 5xx 计入不可用。” |
| TTFT（首字延迟）P95 / P99 也要算 SLA | 模型推理”连接成功了但 30 秒才吐第一个字”，对用户来说等于不可用。流式输出是 AI API 核心场景，必须把 TTFT + TPOT（每个输出 Token 延迟）写入 SLA。 | “Streaming 请求首字延迟（Time To First Token）P95 ≤ 800ms；非流式请求总体响应 P95 ≤ 5 秒；超出部分每 30 分钟计 1 分钟不可用。” |
| “单模型故障 + 自动降级”不算不可用 | 大厂的 AI API 经常”具体某个模型（比如 xx-70B-int4）在 AZ-a 挂了 1 小时，但你请求到 AZ-b 自动切过去了，返回成功 200，只是延迟高了一点 → 这个 200 是成功返回，不算停机。” | 要”你最关心的主模型 ID”单独列出来：“Model=weimeta-deepseek-v3 的单区域可用性单独承诺 99.95%；多路由 fallback 不计入成功豁免。” |
| 数据持久性（Durability）独立条款 | 你在厂商那儿存了 RAG 知识库、SFT 训练集、LoRA 模型。厂商 S3 挂了 → 你的数据全没了，这比 API 宕一天损失还大。 | “客户托管至乙方平台的 Fine-Tuning 数据集、LoRA 权重、向量知识库，承诺 11 个 9（99.999999999%）年持久性；丢失每 GB 赔偿 XXX。” |
唯元智创 的企业版合同默认签 99.95% SLA（线上公开文档可查），白金版大客户可签 99.99% + 自定义 P95 延迟；数据持久性 11 个 9，跨区域双副本存储；赔偿走 Service Credit，每月 5 号前自动生成上月 SLA 报告邮件给客户对接人，有异议 15 个工作日申诉——这四条全部写死白纸黑字在合同里。
你如何验证 / 监控 SLA？（别只信厂商的报告）
合同签了 99.99%，你不能只靠厂商每月给你一份”我们达标啦”的报告。企业客户至少要做三件事自主验证：
- 外部多点探针（Synthetic Monitoring）：用 Blackbox Exporter / UptimeRobot / 唯元智创自带探针，从 3 个不同区域（上海、北京、深圳）每 1 分钟对 4 个 API（chat/completions、embeddings、models、tokenizer）各发 1 条固定请求，记录 HTTP 状态码 + TTFT + TotalTime；任一区域连续 3 次失败 = 计 1 分钟不可用。
- 客户端错误率埋点：在你自己业务的 SDK（OpenAI SDK 层）加拦截器，统计
status_code / error_type / model_id / region四维聚合，每日导出 CSV；发现你这边记录的 5xx 错误率 0.5% 和厂商给你的 0.02% 对不上时，拿你自己日志去申诉（厂商内部监控经常”只测 AZ 入口健康”，测不到某个具体模型卡了 1 小时的情况）。 - 延迟分位数 P95/P99 报表：不要信平均值（Average Latency），平均值永远好看（99 次 200ms + 1 次 10 秒，平均 = 300ms “看起来正常”，但真实 P99 = 10s，用户已经投诉了）。正确报表必须是 P50/P90/P95/P99 四条线，每小时一张。