TL;DR
- 简短版本：每个可靠性层级对应一个特定的故障域，每个故障域都需要自己的架构来应对。大致来说：
- 99%
- 99.9%
- 99.99% 意味着你的架构能够应对区域性中断。这通常需要多区域部署，具备可用区冗余和预留的故障转移容量。
可靠性数字容易发布。困难的是解释它们的含义：架构实际覆盖了哪些故障域，提供商是否控制这些层的基础设施，以及凌晨3点出问题时会发生什么。
Together 为 Cursor、Decagon、Cartesia 和 Yutori 等团队运行推理服务。我们经历过下文中的大部分情况；以下是我们学到的经验。
可靠性数字的问题
当推理服务宕机时，某个产品也会随之宕机。GPU 推理的故障方式与传统服务不同。硬件有故障模式；CPU 基础设施没有，而且系统为了性能而进行了硬调优。在每 GPU 每分钟 100 万 token、200 TPS 或使用自定义内核的语音模型上实现低于 50ms 的 TTFT，几乎没有余量。在这样的系统中增加可靠性，每增加一个九，难度呈指数级增长。
有用的思维模型是分层，每一层的故障模式都不同：
计算：VRAM 中的 ECC 错误（我们最常见的问题；它们静默地损坏权重，因此请求返回但输出不可信）、热节流、驱动崩溃、NVLink 故障、NIC 或 CPU 故障（无论 GPU 状态如何都会导致机器宕机）。网络：交换机故障、收发器问题（在完全不可用之前降低性能）、边缘设备故障（导致整个站点瘫痪）。存储：中断导致权重获取受阻、重新调度停滞，并级联成容量问题。软件：路由错误、调度器边界情况、部署失败（如果不小心可能会传播）。
这些故障不会孤立发生。存储问题表现为容量问题，热事件在健康警报触发之前很久就表现为输出质量下降。要擅长处理这些问题，需要学会从误导性症状中读取真实信号。
每个九实际需要什么
每个层级都是一个不同的工程问题，而不仅仅是同一个问题的更难版本。以下是每个层级实际需要的内容，以及我们围绕它构建的内容。
99%：应对节点故障
目标是在请求到达之前捕获降级的节点。快速检测、排空、替换。有趣的工程问题在于可观测性。
被动健康检查（硬件遥测、指标）让你无需容量开销即可获得可见性，但会遗漏一类仅在真实 GPU 负载下才出现的故障。主动健康检查能捕获这些故障，但需要容量来运行。你无法在已经处理流量的 GPU 上执行检查，因为这会产生明显的矛盾。每个人都希望接近 100% 的利用率，而为健康检查维持多余容量只是用低效换取可靠性。我们采取的方法是加快重新调度：将检查与调度器集成，使其在工作负载之间的间隙运行，并尽可能快地执行检查本身。这仍然是我们需要调整的地方。
这一层的天花板是建筑本身。一个散热问题、一个变电站事件、一个边缘路由器故障。其中任何一个都会导致单数据中心部署宕机，无论数据中心内部冗余如何。大多数提供商为此准备了备份系统，但一个未在真实条件下定期测试的冗余系统，就像把一个六周没训练过的替补球员叫上场。故障转移可能在纸面上存在，但能否正常工作则是另一个问题。
99.9%：承受整个数据中心故障
整个设施是这里的故障域：电力、冷却、网络入口、边缘网络。要承受它需要：跨两个设施部署权重，每侧有足够容量吸收全部负载，以及能干净切换流量的路由。
决定提供商是否真正实现这一层的架构决策是：他们是否持续在两个设施上运行实时流量，还是维持冷备。我们选择了持续。大多数99.9% SLA声明隐含地承诺了这一层。问题是声明背后的架构是否真的为此构建。
这也是基础设施所有权具体重要的地方。从超大规模云或新云提供商租用容量的提供商并不拥有自己的故障域。当电力或冷却层出现问题时，他们只能向拥有者提交工单。他们无法告诉你他们的SLA在该层物理上能承受什么，因为他们不控制它。当你使用Together AI时，一张工单覆盖硬件、网络、存储和软件，因为我们在全球范围内拥有从芯片到令牌的可观测性。另一种选择：向提供商提交工单，提供商再向超大规模云/新云提交工单，排队。我们见过凌晨3点时的样子。
99.99%：承受区域中断
这一层的根本挑战是我们在本质上不可靠的硬件上构建可靠的基础设施。GPU故障率明显高于CPU故障率，每种故障模式都必须考虑。四个九的要求：多区域部署并具备可用区冗余，以及在故障转移区域预留足够容量以吸收整个区域中断。这里的关键词是“预留”。不是“我们可以将流量路由到那里”，而是“我们现在那里有空闲空间”。
在承诺使用提供商之前要问什么
SLA是起点。这些问题涉及底层的架构、出问题时谁拥有什么、以及恢复速度有多快。我们也希望你向我们提出这些问题：
关于基础设施所有权：
- 模型托管在哪里？是单区域还是多区域？
- 你拥有自己的基础设施，还是从超大规模云或第三方租用容量？
- 谁负责数据中心：电力、冷却、传输？你有物理访问权限，还是需要通过工单队列？
- 如果一个数据中心发生故障，你能多快将该部署迁移到其他地方？你是否为此维护了预留容量，还是保持精简？
关于全栈专业知识：
- 你是否拥有跨堆栈的芯片到令牌可观测性，还是在推理和硬件之间存在可观测性缺口？
- 当出现问题时，你的团队是否可以直接访问硬件，还是依赖第三方进行诊断和响应？
- 你的GPU硬件专业知识在推理软件之外有多深入？
关于容量和故障转移：
- 故障转移是如何测试的：持续通过实时流量，还是定期演练？
- 当实际需要执行故障转移时，您的实际恢复时间目标（RTO）是多少？
关于SLA测量：
- 每个SLA层级实际覆盖哪个故障域：节点、数据中心还是区域？
- 您的SLA是在负载均衡器处测量，还是在推理成功完成时测量？
- 客户端重试是否计入您的正常运行时间测量？
我们的定义
模糊的SLA定义是承诺与交付之间差距的根源。以下是我们测量的具体内容以及每个术语的定义。
我们在推理完成时测量，而不是在网关处。到达负载均衡器但在GPU处失败的请求，在我们的统计中算作停机。还有一点：可用性和性能是不同的合同。在预置吞吐量中，您支付的是GPU分配以提供特定的每秒事务数（TPS），而不仅仅是端点响应。一个正常运行但仅提供合同吞吐量30%的服务并不符合约定。
来看看架构
每个提供商都会给您一个数字。重要的是背后的架构是否能够支撑它，以及他们是否拥有保证必须兑现的基础设施。
这些都是可以回答的问题。要求任何提供商解释每个SLA层级背后的架构。询问他们是拥有基础设施还是位于其他人的基础设施之上。询问故障转移路径是否在实时流量下运行。了解自己基础设施的提供商可以快速回答这些问题。
我们随时可以向您介绍我们的架构。如果您想深入了解，我们随时待命。