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層級背後的架構。詢問他們是擁有基礎設施還是位於其他人之上。詢問故障轉移路徑是否在實時流量下運行。瞭解自己基礎設施的提供商可以快速回答這些問題。

我們隨時可以向您展示我們的架構。如果您想深入瞭解，我們在此恭候。