99.9%可用率对AI推理意味着什么：故障域与架构要求解析
每个可靠性等级对应一个特定故障域，每个等级都需要专属架构才能应对故障。简单来说：
99%可用率意味着架构能承受节点级故障，比如GPU硬件故障、驱动崩溃、热事件。实现这一点通常需要自动健康检查、节点排空，以及在单个数据中心内快速替换副本。
99.9%可用率意味着架构能承受整个数据中心故障。这通常需要将模型权重部署在两个不同设施，每个设施都有足够容量承接全部流量，并且始终向两个设施分配在线流量，而非使用冷备。
99.99%可用率意味着架构能承受区域性服务中断，这一般需要多区域部署，搭配可用区冗余和预留故障切换容量。
公布可靠性数字很容易，难的是解释清楚它的实际含义：架构实际覆盖哪些故障域，服务提供商是否控制对应层级的基础设施，凌晨3点发生故障时会如何处理。
Together AI为Cursor、Decagon、Cartesia和Yutori等团队提供推理服务，团队多数时间都在处理各类故障，以下是他们总结的经验。
可靠性数字的问题
当推理服务中断，依赖它的产品也会随之中断。GPU推理的故障模式和传统服务不同。GPU有CPU基础设施不存在的故障模式，而且系统为了性能通常会进行深度调优。要实现单GPU每分钟100万token输出、每秒200次事务处理，或是搭配自定义内核的语音模型将首包响应时间控制在50毫秒以内，系统几乎没有冗余余量。在这类系统中增加可靠性，每多一个9，难度都会呈指数级增长。
可以用分层模型梳理问题，每一层的故障模式都各不相同：
- 计算层：显存ECC错误（最常见，会静默损坏权重，导致请求返回但输出不可信）、热节流、驱动崩溃、NVLink故障、NIC或CPU故障，这些都会无视GPU状态导致机器宕机。
- 网络层：交换机故障、收发器问题（在完全不可用之前先导致性能下降）、边缘设备故障（导致整个站点不可用）。
- 存储层：服务中断会阻断权重获取、延迟重调度，最终演变为容量问题。
- 软件层：路由bug、调度器边界问题、部署故障，如果不小心可能传播扩散。
这些故障很少独立发生。存储小问题会表现为容量问题，热事件在健康警报触发前很长时间，就会表现为输出质量下降。要处理好这类问题，就得学会从误导性症状中找到真正的问题根源。
每个9的实际要求
每个可靠性等级都是完全不同的工程问题，不只是同一问题难度升级而已。以下是每个等级的实际要求，以及Together AI对应的搭建方案。
99%：应对节点故障
目标是在请求分发到故障节点前就识别出异常节点：快速检测、排空节点、替换副本。核心工程问题是可观测性。
被动健康检查（硬件遥测、指标）不需要额外容量开销就能获得可见性，但会漏掉只在GPU实际负载下才会显现的故障。主动健康检查能捕捉到这类故障，但需要额外容量运行。没法在已经承载流量的GPU上做检查，这会产生明显矛盾——用户都希望GPU利用率接近100%，为健康检查保留额外容量相当于用效率换可靠性。Together AI的方案是优化重调度速度：将检查和调度器整合，让检查在工作负载的间隙运行，同时尽可能压缩检查本身的耗时。这仍是他们持续调优的方向。
这个等级的故障边界就是整个数据中心建筑。热事件、变电站事故、边缘路由器故障，任何一个都会让单数据中心部署整体中断，不管数据中心内部冗余做得多好。多数服务商都有备份系统，但没有在真实环境下定期测试的冗余系统，就像让六周没训练的替补选手上场——纸上存在的故障切换机制，是否真能工作完全是另一回事。
99.9%：应对整个数据中心故障
故障域是整个设施：电力、冷却、网络入口、边缘网络。要实现这一点，需要将权重部署在两个设施，每个设施都有足够容量承接全部负载，并且流量路由可以顺畅切换。
决定服务商能否真正达到这个等级的架构决策，是持续向两个设施分发在线流量，还是维护冷备。Together AI选择持续在线分发流量。多数99.9%服务水平协议（SLA）承诺都默认对应这个等级，问题在于承诺背后的架构是否真的符合要求。
这一层级里，基础设施所有权的影响非常具体。从超大规模厂商或新型云厂商租用容量的服务商，并不控制自己的故障域。电力或冷却层出问题时，他们只能给产权方提交工单。他们没法告诉你SLA在这一层实际能应对哪些故障，因为他们不控制基础设施。使用Together AI时，一个工单就能覆盖硬件、网络、存储和软件问题，因为Together AI在全球全栈拥有从芯片到输出token的全链路可见性。替代方案则是服务商提交工单给超大规模厂商或云厂商，然后排队等待处理——这就是凌晨3点出问题时的实际情况。
99.99%：应对区域性服务中断
这个等级的核心挑战是，本身要在 inherently unreliable hardware（天生不可靠的硬件）上搭建可靠基础设施。GPU的故障率远高于CPU，所有故障模式都需要提前覆盖。达到四个9需要做带可用区冗余的多区域部署，并且在故障切换区域预留足够容量，足以承接整个区域中断后的全部负载。关键词是预留——不是“可以把流量导过去”，而是“那里现在就有预留的闲置容量”。
选择服务商前要问的问题
服务水平协议只是起点。以下问题能帮你弄清楚背后的架构、故障发生时的责任划分，以及恢复速度。这些问题同样适用于询问Together AI：
### 关于基础设施所有权
- 模型托管在哪里？是单区域还是多区域？
- 你是自有基础设施，还是从超大规模厂商或第三方租用容量？
- 谁负责数据中心的电力、冷却、传输？你有物理访问权限，还是需要走工单排队？
- 一个数据中心中断后，多久能把部署转移到其他地方？你是否为这种场景预留容量，还是低冗余运行？
### 关于全栈专业能力
- 你有没有从芯片到输出token的全链路可见性？还是推理和硬件之间的可观测性存在缺口？
- 故障发生时，你的团队能直接访问硬件，还是依赖第三方诊断和响应？
- 除了推理软件，你们的GPU硬件专业能力积累到什么程度？
### 关于容量和故障切换
- 故障切换怎么测试？是持续走在线流量，还是定期演练？
- 真需要执行故障切换时，实际恢复时间目标是多少？
### 关于服务水平协议测量
- 每个SLA等级实际覆盖哪个故障域？节点、数据中心还是区域？
- 可用性统计是从负载均衡器算，还是从成功完成推理算？
- 客户端重试会不会计入你的可用率统计？
Together AI的指标定义
模糊的SLA定义，就是承诺和实际交付之间出现缺口的根源。以下是Together AI明确的测量方式和定义：
我们在推理完成环节统计可用性，不从网关统计。到达负载均衡器但在GPU端失败的请求，在我们的统计里计入停机时间。另外，可用性和性能是两份不同的承诺。在预置吞吐量模式下，用户付费购买的是能提供特定事务处理速度的GPU配额，不只是端点能响应而已。服务在线但只达到承诺吞吐量30%，不算符合要求。
来看架构
所有服务商都能给你一个可用率数字。真正重要的是，数字背后的架构是否能支撑承诺，服务商是否真的拥有承诺需要的基础设施。
这些都是可以回答的问题。要求任何服务商讲解每个SLA等级背后的架构，询问他们是自有基础设施还是架设在第三方之上，询问故障切换路径是否承载在线流量。熟悉自己基础设施的服务商能快速给出答案。
Together AI随时可以讲解自己的架构。如果想深入了解，可以联系我们。