核验清单

  • ✓自己签的这份API服务协议里，SLA条款覆盖的具体范围是"服务可用性/响应时间"，还是也包含了生成内容的质量或准确性——两者不要混为一谈
  • ✓服务出现明显中断或大面积超时报错时，是否第一时间记录下了中断的起止时间、具体错误码，而不是等事后再凭印象回忆
  • ✓自己这边的调用日志（请求时间戳、HTTP状态码、错误信息）是否有留存机制，能不能在申请赔偿时作为独立证据提交，而不是只依赖厂商自己的状态页
  • ✓是否已经确认赔偿需要用户主动提交申请、并且有申请时限（比如自然月内或月份结束后一定期限内），而不是厂商发现中断后会自动补偿
  • ✓具体的可用性承诺百分比、计算周期、赔偿比例，是否已经去对应厂商的官方SLA文档核实过，而不是套用别的产品或别的厂商的数字

1. 现象：接口大面积报错之后，企业才想起来问"能不能赔"

企业接入DeepSeek、通义千问这类国内大模型API做对外产品或内部工具，平时很少会去翻服务协议里那份SLA（Service Level Agreement，服务级别协议）条款，直到真的遇到接口大面积超时、频繁5xx报错，甚至连续一段时间完全连不上的情况，才想起来问一句"这种情况是不是该有赔偿"。这时候常见的两个卡点是：第一，不清楚这份SLA条款到底承诺了什么、能不能覆盖眼前这次中断；第二，就算想申请，手上也拿不出能证明"服务确实中断了多久"的具体证据，只能凭一句"当时确实用不了"去找客服，往往得不到实质性回应。

2. SLA到底覆盖什么：服务可用性与响应时间，不是生成内容质量

要理解SLA能不能赔，先得弄清楚SLA条款到底承诺了什么维度。国内主流大模型厂商公开的SLA文档，承诺和计算的通常是"服务可用性"（接口在约定周期内能不能正常响应、错误率是否超过阈值）和"响应时间"（请求返回是否在约定的延迟范围内），这是两个纯技术层面的、可以按调用记录客观统计的指标。开发者容易产生的一个误解是：以为模型某次回答"答非所问"、生成内容质量不理想，也算SLA意义上的"服务不达标"。但SLA条款覆盖的从来不是生成内容本身的质量或准确性——接口正常返回了200状态码、在承诺时延内给出了响应，无论这次回答内容让人满不满意，从SLA的角度看这次调用都是"正常"的。这是两个完全不同的维度，一个管的是"接口通不通、快不快"，一个是模型生成能力本身，服务协议里的免责条款通常也会单独说明不对生成内容的准确性作保证。

3. 赔偿是怎么算的：按服务费用比例折算的代金券，不是现金

确认这次中断确实属于SLA覆盖的"可用性不达标"之后，下一个要弄清楚的是赔偿到底以什么形式发放。国内云厂商公开的SLA体系里，常见的做法是把一个统计周期（比如自然月）内的服务可用性算出一个百分比，再按这个百分比落在哪个区间，对应到不同比例的赔偿额度，赔偿通常以服务积分或代金券的形式发放、用于折抵后续账单，而不是直接退还现金。需要特别说明的是：具体的可用性承诺百分比、统计周期长短、赔偿对应的比例区间，不同厂商、甚至同一厂商不同产品线或订阅层级（比如个人版和企业版）的规定都可能不一样，这里不存在一个所有厂商通用的统一标准，实际数字必须以你采购的这个具体产品的官方SLA文档为准，不能拿别的产品或别的厂商的公开数字直接套用。

4. 厂商不会主动补偿：赔偿需要用户自己主动申请

另一个容易被忽略的现实是：SLA赔偿几乎都需要用户自己主动发起申请，厂商的系统不会因为后台监控到某次可用性没达标，就自动给账户加发代金券。这意味着，如果企业自己没有留意到中断发生、或者没有在规定的申请时限内提交材料，即使这次中断在客观上确实达到了SLA承诺的赔偿条件，这笔赔偿大概率也不会主动落到账户上。申请通常需要在一个限定的时间窗口内完成（比如中断发生的自然月内，或者该月结束后的一到两个月内），逾期未申请，很多厂商的规则里会直接视为放弃这次赔偿资格。这也是为什么"知道SLA条款存在"和"能真正拿到赔偿"之间，还差着一步主动申请的动作。

5. 想真的用上SLA赔偿，平时该留哪些证据

与其等中断发生之后再手忙脚乱去找证据，更务实的做法是把日常的调用监控当成一项基础工作提前做好。具体建议：第一，把每次API调用的请求时间戳、返回的HTTP状态码、具体错误信息（比如超时、5xx、限流拒绝）记录进自己的日志系统，不要只依赖厂商自己的服务状态页——厂商状态页更新是否及时、是否完整覆盖了你实际遇到的那次异常，本身就存在不确定性。第二，一旦观察到明显的异常波动（比如错误率短时间内明显升高、大量请求超时），主动截图或导出当时的监控面板、日志片段留存，方便后续核对具体的中断起止时间。第三，提前找到自己所用产品官方SLA文档里关于"如何申请赔偿"的具体入口和时限要求，出问题时才不会临时抱佛脚。这些调用失败日志和时间戳，就是申请SLA赔偿时最直接、最有说服力的证据。

6. 小结：SLA是可用性的账，不是内容质量的账

企业采购DeepSeek、通义千问这类国内大模型API时，服务协议里的SLA条款保的是服务可用性和响应时间，不是生成内容的质量或准确性，这是判断"这次中断算不算SLA违约"的第一道分界线。赔偿通常按服务费用的一定比例折算成代金券而非现金，具体的可用性承诺百分比、统计周期与赔偿比例因厂商、产品线、订阅层级而异，不存在统一的行业标准，一切以官方SLA文档为准。更关键的是，赔偿几乎都需要用户主动申请、并在规定时限内提供中断证据，厂商不会主动补偿——平时留好自己的调用失败日志和时间戳，才是真正能把SLA赔偿落到实处的前提。