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

所有博客文章

推理

发布于 2026年7月16日

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

作者：Ryan Lucchese, Sarung Tripathi

目录

40+ 个模型选择用于生产...40+ 个模型选择用于生产...40+ 个模型选择用于生产...

摘要

简而言之：每个可靠性层级对应一个特定的故障域，每个故障域需要其自身的架构来应对。大致来说：

• 99% 意味着你的架构能够应对节点级故障：GPU 硬件故障、驱动崩溃、热事件。达到这一级别通常需要自动健康检查、节点排空以及在同一数据中心内快速替换副本。

• 99.9% 意味着你的架构能够应对整个数据中心故障。这通常需要在两个设施中部署模型权重，每侧有足够的容量吸收全部负载，并持续进行实时流量路由，而不是冷备用。

• 99.99% 意味着你的架构能够应对区域故障。这通常需要多区域部署并具备可用区冗余，以及预留的故障转移容量。

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

Together 为 Cursor、Decagon、Cartesia 和 Yutori 等团队运行推理。我们曾对接下来讲述的大部分情况被传呼过；以下是我们学到的经验。

可靠性数字的问题

当推理服务中断时，某些人的产品也会随之中断。GPU 推理的故障方式与常规服务不同。硬件有故障模式，而CPU基础设施没有，并且系统为了性能而进行了极限调优。达到每分钟每GPU 100万 token 且 200 TPS，或在语音模型上使用自定义内核实现低于50毫秒的 TTFT，几乎没有余量。在这样的系统中增加可靠性，每增加一个九，难度指数级增加。

有用的思维模型是分层，每层的故障模式各不相同：

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

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

存储：中断阻止权重获取，延迟重新调度，并级联成容量问题。

软件：路由错误，调度器边界情况，部署失败，如果不小心可能会传播。

这些故障不会孤立发生。存储问题表现为容量问题，热事件在健康警报触发之前很久就以输出质量下降的形式出现。做好这一点需要学会从误导性症状中读取真实信号。

每个九的实际要求

每个层级都是不同的工程问题，而不仅仅是更难版本的相同问题。以下是每个层级实际需要的东西，以及我们为此构建的内容。

99%：应对节点故障

目标是在请求到达之前捕获正在降级的节点。快速检测、排空、替换。有趣的工程问题是可观测性。

被动健康检查（硬件遥测、指标）在没有容量开销的情况下提供可见性，但会遗漏一类仅在真实GPU负载下才会出现的故障。主动健康检查可以捕获这些故障，但需要容量来运行。你不能对已经服务于流量的GPU进行健康检查，因为这会引发明显的矛盾。每个人都希望接近100%利用率，而为健康检查维持多余容量只会以可靠性换取低效率。我们采取的方法是快速重新调度：将健康检查与调度器集成，以便在工作负载间隙运行，并使检查本身尽可能快速。这仍然是我们持续调整的内容。

这个层级的天花板是建筑物本身。热问题、变电站事件、边缘路由器故障。任何一个都会导致单数据中心部署宕机，无论数据中心内冗余如何。大多数提供商都有备用系统，但一个没有在真实条件下定期测试的冗余系统就像叫一个六周没有练习的球员上场。故障转移可能在纸面上存在，但能否正常工作是一个不同的问题。

99.9%：应对整个数据中心故障

整个设施是故障域：电源、冷却、网络入口、边缘网络。生存所需：权重部署在两个设施中，每侧有足够容量吸收全部负载，并且流量路由能够干净地切换。

决定提供商是否真正提供这一层级的架构决策是：他们是否持续向两个设施运行实时流量，还是维护冷备用。我们选择持续运行。大多数99.9% SLA声明隐含地承诺了这一层级。问题是声明背后的架构是否真正为此构建。

这也是基础设施所有权变得具体的地方。从超大规模云或新云提供商租用容量的提供商并不拥有其故障域。当电源或冷却层出现问题时，他们只能向拥有者提交工单。他们无法告诉你他们的SLA在该层实际承受什么，因为他们无法控制。当您使用Together AI时，一张工单涵盖硬件、网络、存储和软件，因为我们拥有整个全球足迹的芯片到令牌可见性。替代方案：向提供商提交工单，提供商向超大规模云/新云提交工单，排队。我们见过凌晨3点的样子。

99.99%：应对区域故障

这个层级的基本挑战是我们在本质上不可靠的硬件上构建可靠的基础设施。GPU故障率明显高于CPU故障率，每种故障模式都必须考虑。四个九的要求：多区域部署并具备可用区冗余，以及在故障转移区域预留容量，大小足以吸收整个区域故障。关键词是“预留”。不是“我们可以将流量路由到那里”，而是“我们现在有闲置的容量在那里”。

在承诺提供商之前应该问的问题

SLA是起点。这些问题深入底层架构：当故障发生时谁拥有什么，以及恢复速度有多快。我们也希望您向我们提出这些问题：

关于基础设施所有权：

• 模型托管在哪里？是单区域还是多区域？
• 您拥有自己的基础设施，还是从超大规模云或第三方租用容量？
• 谁负责数据中心：电源、冷却、传输？您有物理访问权限，还是需要通过工单队列？
• 如果一个数据中心发生故障，您多快能将部署转移到其他地方？您是为此维护预留容量，还是精打细算？

关于全栈专业知识：

• 您在整个堆栈中是否拥有芯片到令牌的可见性，还是推理和硬件之间的可观测性存在缺口？
• 当出现故障时，您的团队是否有直接硬件访问权限，还是依赖第三方进行诊断和响应？
• 您对GPU硬件的专业知识有多深，超出推理软件？

关于容量和故障转移：

• 故障转移是如何测试的：实时流量连续进行，还是定期演习？
• 当故障转移实际需要执行时，您的实际RTO是多少？

关于SLA测量：

• 每个SLA层级实际覆盖哪个故障域：节点、数据中心还是区域？
• 您的SLA是在负载均衡器层面测量，还是在成功推理完成层面测量？
• 客户端重试是否计入正常运行时间测量？

我们的数字定义

模糊的SLA定义是承诺与交付之间差距的根源。以下是我们测量的内容以及我们如何定义每个术语。

我们测量的内容 | 我们如何定义 | 我们的数字 ---|---|--- 交付的正常运行时间 | 推理端点成功服务请求的时间百分比（在推理完成时测量，而非负载均衡器） | 99.9%（持续交付） 保证SLA：单数据中心 | 单数据中心部署的合同SLA | 99% 保证SLA：多数据中心 | 多数据中心部署的合同SLA | 99.9% 故障转移时间 | 在设施故障后将流量切换到健康容量所需的时间 | 秒 请求量 | 测量窗口内服务的推理请求数 | 2B TPM+

我们在推理完成时测量，而不是在网关。到达负载均衡器但在GPU上失败的请求在我们的计算中算作停机。还有一件事：可用性和性能是不同的合同。在预配吞吐量中，您支付的是GPU分配以提供特定的TPS，而不仅仅是端点响应。一个服务虽然可用但只交付了合同吞吐量的30%，这并不符合约定。

来看看架构

每个提供商都会给您一个数字。重要的是架构是否真正支持它，以及他们是否拥有保证必须成立的基础设施。

这些是可回答的问题。要求任何提供商解释每个SLA层级背后的架构。询问他们是拥有基础设施还是位于其他人之上。询问故障转移路径是否在实时流量下运行。了解自己基础设施的提供商可以快速回答这些问题。

我们随时可以向您展示我们的架构。如果您想深入了解，我们在此恭候。