可用性声明

我们不承诺任何可用率数字，也不提供服务等级协议（SLA）与服务积分。本页不会出现"99.9%"这类数字，服务条款里也不会。

原因很直接：我们没有足够的运行历史来支撑这样的承诺。一个没有数据支撑的可用率承诺，要么在出事时无法兑现， 要么迫使我们在事后重新解释口径 —— 两种结果都比不承诺更糟。

我们也没有任何第三方安全或合规认证（SOC 2、ISO 27001 或同类）。 没有就是没有，我们不写"正在准备中"这种既无法证伪也无法兑现的表述。

因此，服务按「现状」与「现有可用」提供， 见 服务条款 第 8 章。

多渠道容灾：一条渠道在首字节到达前失败（连接失败、超时、5xx）， 我们自动改换其它渠道重试，你通常无感。 为此额外付出的上游成本由我们承担，不进你的账单。

不做无谓的重试：客户端错误（400/413/422 一类）绝不跨渠道重试， 直接回传。重试一个本身就错的请求，只会让你多付钱、多等待。

排队而不是盲目故障转移：部分上游账号的并发能力很低， 槽位占满时我们让请求排队等待，而不是把它甩给一条更差的渠道。 排队时长会记录在请求元数据里。

自动暂停与分级降权：持续失败的渠道会被降权直至基本摘除， 并在冷却后以半开状态试探恢复。降权是有序等级而不是开关，避免反复抖动。

会话粘性：同一段对话在 5 分钟内尽量落到同一个上游账号， 以保住上游的 prompt cache —— 换账号意味着缓存全失，成本与首字延迟双输。 它是软约束：粘住的渠道不可用时正常改换其它渠道，也绝不会突破你的成本护栏（护栏在排序之前就已生效）。

部署不掐断进行中的流：发布时先停止接收新请求， 等待存量流式连接自然结束再退出。

长等待时保持连接：流式请求在等待上游首字节期间， 我们会持续发送 SSE 注释行保活，避免中间层与客户端 SDK 提前超时。 这些注释行符合规范，不会污染内容。

可复盘：带上 X-Akrouter-Metadata: enabled 就能拿到本次请求的 候选池大小、被硬过滤与被降权的渠道数、每次尝试的渠道与错误分类。 出问题时你不需要猜。

没有多地域部署。服务运行在单一地域， 该地域整体故障时服务会中断。

没有数据库层的自动故障切换。数据库故障需要人工介入恢复。 我们有定期备份，但恢复需要时间。

没有 7×24 值守承诺。我们会尽快响应，但不承诺响应时限。

没有对上游的控制权。绝大部分故障的根因在上游 —— 我们能做的是换一条， 换不掉时（例如所有渠道都被你的成本护栏排除）请求就会失败。

配置不是实时生效的。渠道、价格与策略的变更靠网关的定时全量轮询传播，密钥与余额在网关侧也有 数十秒量级的缓存。因此改完设置、充完值、吊销完一把 Key，都可能需要短暂等待才完全生效。我们选轮询而不是实时推送，是因为它的失效模式响亮 —— 轮询停了，配置的加载时间就不再推进，这是能被监控发现的； 推送丢一条消息则是静默的。

没有服务积分制度。发生重大且持续的中断时我们可以酌情补偿额度， 但这是个案处理，不是你可以主张的权利。见 退款政策。

那些是被动统计的历史结果，不是承诺。它们来自真实流量的聚合，不是我们自己跑的理想化测试。

计入失败的：认证失败、模型不存在、上游 5xx、流中途断开， 以及"HTTP 200 但结束原因异常"的伪成功响应。

不计入失败的：

• 客户端错误 —— 请求本身就是错的，不是渠道的问题
• 限流 —— 单独统计，因为它反映的是容量而不是可靠性
• 地域限制导致的拒绝

把这三类算进失败率会让数字变得没有意义： 一个用户批量发错请求就能把一条好渠道的成功率打到很低。

统计有滞后与样本量问题。分钟级汇总有聚合延迟； 低流量渠道的成功率可能只基于个位数样本。 样本不足时我们展示为无数据，而不是展示一个 100%。

汇总数据的保留期是 30 天，超过后无法回溯更早的曲线。

实时数据见 状态页 与 模型市场。

计划内维护：我们会尽量在低峰期进行，并通过状态页公告。 多数发布不需要停机。

紧急维护：为修复安全问题或止损，我们可能在不预先通知的情况下操作， 事后补充说明。

重大事故：影响面较大的事故，我们会在事后发布说明， 包括发生了什么、影响范围与我们打算怎么避免它再次发生。我们不承诺发布时限。

故障报告请联系 [email protected]，并附上请求 id 与发生时间 —— 没有请求 id 我们只能看到聚合曲线。

当我们积累了足够长的运行历史、具备多地域冗余与数据库故障切换能力， 并且能对承诺的口径做出可审计的度量时，我们会提供 SLA。在那之前，本页的内容不会变。

企业客户如需带承诺的服务等级、限定的渠道范围或数据处理协议， 请联系 [email protected] 单独商谈 ——那会是一份单独签署的合同，而不是这个页面。