What does 99.9% uptime mean for inference?

99.9% 正常运行时间对推理服务意味着什么？

TL;DR

• 简而言之：每个可靠性层级对应特定的故障域，每个层级都需要独立的架构来应对。大致来说：

• 99% 表示你的架构能够应对节点级故障：GPU 硬件故障、驱动崩溃、热事件。要实现这一点通常需要自动化健康检查、节点卸载以及在同一数据中心内快速替换副本。

• 99.9% 表示你的架构能够应对整个数据中心故障。这通常意味着模型权重部署在两个设施中，每边都有足够的容量来吸收全部负载，并且实时流量路由到两个设施，而非冷备用。

• 99.99% 表示你的架构能够应对区域级故障。这通常需要跨区域部署，结合可用区冗余和预留的故障转移容量。

可靠性数字很容易发布。困难的是解释这些数字的含义：架构实际覆盖哪些故障域、提供商是否在这些层级控制基础设施、以及凌晨3点发生故障时会发生什么。

Together 为 Cursor、Decagon、Cartesia 和 Yutori 等团队提供推理服务。我们大部分时间都在处理以下问题的告警；以下是我们的经验总结。

可靠性数字的问题

当推理服务中断时，某人的产品也会随之中断。GPU 推理失败的方式与传统服务不同。硬件存在故障模式；CPU 基础设施没有这种模式，系统也经过严格调优以实现高性能。在每块 GPU 上达到每分钟 100 万个 token 或在语音模型上实现低于 50 毫秒的首次令牌延迟（TTFT）时，系统几乎没有容错空间。在这样的系统中添加可靠性，每增加一个 9 的难度呈指数级增长。

有用的思维模型是分层结构，每一层的故障模式都不同：

• 计算：VRAM 中的 ECC 错误（我们最常见的问题；它们会静默地破坏权重，导致请求返回但输出不可信）、热限流、驱动崩溃、NVLink 故障、NIC 或 CPU 故障（无论 GPU 状态如何都会导致机器宕机）。

• 网络：交换机故障、收发器问题（在完全不可用之前先导致性能下降）、边缘设备故障（导致整个站点宕机）。

• 存储：导致权重获取中断、重新调度停滞并引发容量问题的故障。

• 软件：路由错误、调度器边界情况、部署故障（如果不小心处理可能会传播）。

这些故障不会孤立发生。存储问题会表现为容量问题，热事件会在任何健康警报触发之前就表现为输出质量下降。擅长处理这些问题意味着学会从误导性症状中识别真实信号。

每个 9 实际上需要什么

每个层级都是不同的工程问题，而不仅仅是更难的同一问题。以下是每个层级实际需要的内容，以及我们为此构建的解决方案。

99%：应对节点故障

目标是在请求到达节点之前检测到其性能下降。快速检测、卸载、替换。有趣的工程问题是可观测性。

被动健康检查（硬件遥测、指标）可以在不增加容量开销的情况下提供可见性，但会遗漏一类仅在真实GPU负载下才会显现的故障。主动健康检查可以捕捉到这些故障，但需要消耗容量资源来运行。你无法在GPU正在处理流量时对其进行压力测试，因为这会引发明显的资源竞争。每个人都希望将利用率维持在接近100%的水平，而为健康检查保留额外容量只会用可靠性换取效率。我们正在探索的解决方案是提升调度系统的重调度速度：将健康检查与调度器集成，使其在工作负载间隙运行，并尽可能缩短检查耗时。这仍然是一个需要持续优化的领域。

这一层级的上限是建筑本身。散热问题、变电站事件、边缘路由器故障等。任何这类问题都会导致单数据中心部署失效，无论数据中心内部是否存在冗余。大多数供应商都为这种情况配备了备份系统，但一个未经实际条件定期测试的冗余系统，就像让一个六周未训练的替补球员上场。故障转移机制可能在纸面上存在，但实际能否运行则是另一个问题。

99.9%：承受整个数据中心故障

在此层级，整个设施构成故障域：电力、冷却、网络接入、边缘网络。要实现生存需要：在两个设施部署权重，每个设施具备足够的容量吸收全部负载，并实现流量的平滑切换。

决定供应商是否真正能实现这一层级的关键架构决策在于：是否持续向两个设施发送实时流量，还是维持冷备状态。我们选择了持续运行模式。大多数99.9% SLA承诺隐含地保证了这一层级。问题在于，承诺背后的架构是否真正为此设计。

这也是基础设施所有权具体影响的领域。从超大规模云或新云租用容量的供应商并不拥有自己的故障域。当电力或冷却层出现问题时，他们只能向实际负责方提交工单。他们无法告诉你其SLA在这一层级实际能承受的故障范围，因为他们没有控制权。在Together AI，一张工单即可覆盖硬件、网络、存储和软件，因为我们对全球所有基础设施实现了从芯片到令牌的全链路可见性。另一种情况：向供应商提交工单，供应商再向超大规模云/新云提交工单，排队处理。我们曾在凌晨3点亲眼见过这种流程的后果。

99.99%：承受区域级故障

这一层级的根本挑战在于，我们正在用本质上不可靠的硬件构建可靠基础设施。GPU的故障率明显高于CPU，每种故障模式都必须被考虑。要实现四个9的要求：跨区域部署并具备可用区冗余，在故障区域预留足够容量以吸收整个区域级故障。这里的关键词是"预留"。不是"我们可以在那里路由流量"，而是"我们此刻正在那里保留着空闲容量"。

在承诺供应商之前需要提出的问题

SLA只是一个起点。这些问题触及架构底层、明确故障时的权责归属，并衡量恢复速度。我们同样期待你向我们提出这些问题：

• 关于基础设施所有权：模型部署在何处？是单区域还是多区域？您是否拥有自己的基础设施，还是从超大规模云服务商或第三方租用资源？数据中心的电力、冷却和网络传输由谁负责？您是否拥有物理访问权限，还是需要通过工单系统申请？如果某个数据中心发生故障，您能多快将部署迁移至其他位置？您是否为此保留了备用容量，还是采取精简运营模式？

• 关于全栈能力：您是否能从芯片到令牌实现全栈可见性？推理层与硬件之间是否存在可观测性断层？当系统出现故障时，团队是否可以直接访问硬件，还是必须依赖第三方进行诊断和响应？您的GPU硬件专业知识在推理软件之外有多深？

• 关于容量与故障转移：故障转移如何测试？是持续使用真实流量，还是定期进行演练？当实际需要执行故障转移时，您的恢复时间目标（RTO）是多少？

• 关于SLA（服务等级协议）测量：每个SLA层级实际覆盖的故障域是什么？是单个节点、数据中心还是整个区域？您的SLA是在负载均衡器层面测量，还是在推理成功完成时测量？客户端重试是否会计入您的正常运行时间统计？

我们的指标定义

模糊的SLA定义正是承诺与实际交付之间存在差距的根源。以下是我们精确测量的指标及每个术语的具体定义。

| 我们测量的指标 | 定义方式 | 我们的指标 | |----------------|----------|------------| | 实际交付的正常运行时间 | 推理端点成功处理请求的时间占比（在推理完成时测量，而非负载均衡器层面） | 99.9%（持续稳定交付） | | 保证SLA：单数据中心 | 单数据中心部署的合同SLA | 99% | | 保证SLA：多数据中心 | 多数据中心部署的合同SLA | 99.9% | | 故障转移时间 | 设施故障后将流量切换至健康容量所需时间 | 秒级 | | 请求量 | 测量窗口内处理的推理请求数量 | 20亿TPM+ |

我们测量的是推理完成时的指标，而非网关层面。如果请求到达负载均衡器但在GPU处失败，这在我们的统计中会被视为停机时间。再补充一点：可用性与性能是两个不同的合同。在预置吞吐量模式下，您支付的是为实现特定TPS而分配的GPU资源，而不仅仅是端点响应能力。一个虽然在线但仅实现合同吞吐量30%的服务，并未履行协议。

来了解我们的架构

每个供应商都会给您一个数字。真正重要的是，支撑这个数字的架构是否能够兑现承诺，以及他们是否拥有必须承担保证责任的基础设施。

这些都是可以回答的问题。要求任何供应商逐层解释每个SLA层级背后的架构。询问他们是否拥有基础设施，还是建立在他人基础设施之上。询问故障转移路径是否在真实流量下运行。真正了解自己基础设施的供应商可以迅速回答这些问题。

我们随时可以带您了解我们的架构。如果您想深入了解，我们随时在此。