推論における99.9%のアップタイムの意味とは？

すべてのブログ記事

推論

公開日: 2026年7月16日

推論における99.9%のアップタイムの意味とは？

著者: Ryan Lucchese, Sarung Tripathi

目次

40以上のモデルがプロダクションに…40以上のモデルがプロダクションに…40以上のモデルがプロダクションに…

概要

簡潔に言うと：各信頼性レベルは特定の障害ドメインに対応し、それぞれを生き残るための独自のアーキテクチャが必要です。おおまかに言うと：

• 99%は、ノードレベルの障害（GPUハードウェア障害、ドライバクラッシュ、サーマルイベント）に耐えられるアーキテクチャを意味します。これを達成するには、通常、自動ヘルスチェック、ノードのドレイン、単一データセンター内での高速レプリカ交換が必要です。

• 99.9%は、データセンター全体の障害に耐えられるアーキテクチャを意味します。これには通常、2つの施設にモデルウェイトをデプロイし、各サイドに全負荷を吸収できる十分な容量を用意し、コールドスタンバイではなく、両方にライブトラフィックをルーティングすることが必要です。

• 99.99%は、リージョン全体の障害に耐えられるアーキテクチャを意味します。これには通常、AZ冗長性を備えたマルチリージョンデプロイと、フェイルオーバー用の予備容量が必要です。

信頼性の数値を公表するのは簡単です。難しいのは、その意味を説明することです：アーキテクチャが実際にカバーする障害ドメイン、プロバイダーがそれらの層でインフラを制御しているかどうか、そして午前3時に何かが壊れたときに何が起こるか。

TogetherはCursor、Decagon、Cartesia、Yutoriなどのチーム向けに推論を実行しています。私たちは以下のほとんどでページングされた経験があります。ここで学んだことを共有します。

信頼性数値の問題

推論がダウンすると、誰かのプロダクトも一緒にダウンします。GPU推論は従来のサービスとは異なる方法で障害が発生します。ハードウェアには障害モードがあり、CPUインフラにはありません。そしてシステムはパフォーマンスのために限界までチューニングされています。GPUあたり毎分100万トークン、200 TPS、またはカスタムカーネルを使用した音声モデルでの50ミリ秒未満のTTFTを達成するには、余裕がほとんどありません。このようなシステムに信頼性を追加することは、9が増えるごとに指数関数的に難しくなります。

有用な考え方は階層モデルであり、各層の障害モードは異なります：

計算：VRAMのECCエラー（最も一般的な現象。サイレントにウェイトを破損し、リクエストは返るが出力は信頼できない）、サーマルスロットリング、ドライバクラッシュ、NVLink障害、GPUの状態に関係なくマシンを停止させるNICやCPUの障害。

ネットワーク：スイッチ障害、完全なダウン前にパフォーマンスを低下させるトランシーバの問題、サイト全体を停止させるエッジデバイスの障害。

ストレージ：ウェイトの取得を妨げ、再スケジューリングを停滞させ、容量問題に連鎖する障害。

ソフトウェア：ルーティングのバグ、スケジューラのエッジケース、注意しないと伝播するデプロイメント障害。

これらは単独では発生しません。ストレージの小さな問題は容量問題として現れ、サーマルイベントは健全性アラートが発動するずっと前に出力品質の低下として現れます。これをうまく行うには、誤解を招く症状から本当のシグナルを読み取ることを学ぶ必要があります。

各9が実際に必要とするもの

各レベルは異なるエンジニアリング問題であり、同じ問題のより難しいバージョンではありません。以下が各レベルに実際に必要なものと、私たちが構築したものです。

99%：ノード障害に耐える

目標は、劣化しているノードをリクエストが到達する前にキャッチすることです。高速に検出、ドレイン、交換。興味深いエンジニアリング問題は可観測性です。

パッシブヘルスチェック（ハードウェアテレメトリ、メトリクス）は容量オーバーヘッドなしで可視性を提供しますが、実際のGPU負荷下でのみ現れるタイプの障害を見逃します。アクティブヘルスチェックはそれらをキャッチしますが、実行するための容量が必要です。すでにトラフィックを処理しているGPUをチェックすることはできません。これは明らかなトレードオフを生み出します。誰もが100%に近い利用率を望み、ヘルスチェックのための余剰容量を維持することは信頼性と効率のトレードオフになります。私たちが取ったアプローチは、再スケジューリングを高速化することです。チェックをスケジューラと統合してワークロードの合間に実行し、チェック自体を可能な限り高速にします。これは今も調整中です。

このレベルの天井は建物そのものです。サーマル問題、変電所イベント、エッジルーター障害。これらのいずれかが、データセンター内の冗長性に関係なく、単一DCのデプロイをダウンさせます。ほとんどのプロバイダーはこれに対するバックアップシステムを持っていますが、実際の条件下で定期的にテストされていない冗長システムは、6週間練習していないベンチの選手を呼ぶようなものです。フェイルオーバーは紙の上では存在するかもしれませんが、実際に機能するかは別問題です。

99.9%：データセンター全体の障害に耐える

施設全体が障害ドメインです：電源、冷却、ネットワークイングレス、エッジネットワーキング。生き残るために必要なもの：2つの施設にウェイトをデプロイ、各サイドに全負荷を吸収する十分な容量、そしてトラフィックをクリーンにシフトするルーティング。

プロバイダーが実際にこのレベルを提供しているかどうかを判断するアーキテクチャ上の決断は、両方の施設に継続的にライブトラフィックを流すか、コールドスタンバイを維持するかです。私たちは継続的な方法を選びました。ほとんどの99.9% SLAの主張は暗黙的にこのレベルを約束しています。問題は、その主張の背後にあるアーキテクチャが実際にそのために構築されているかどうかです。

ここでインフラ所有権が具体的に重要になります。ハイパースケーラーやネオクラウドからキャパシティをレンタルしているプロバイダーは、自分の障害ドメインを所有していません。電源や冷却層で何かが壊れた場合、彼らはその所有者にチケットを提出します。彼らはSLAがその層で物理的に何に耐えられるかを教えられません。なぜなら彼らはそれを制御していないからです。Together AIを使用する場合、1枚のチケットでハードウェア、ネットワーク、ストレージ、ソフトウェアをカバーします。なぜなら、グローバルフットプリント全体でチップからトークンまでの可視性を持っているからです。代替案：プロバイダーにチケット、プロバイダーからハイパースケーラー/ネオクラウドにチケット、キュー。私たちは午前3時にそれがどのようになるかを見てきました。

99.99%：リージョン障害に耐える

このレベルの根本的な課題は、本質的に信頼性の低いハードウェア上に信頼性の高いインフラを構築することです。GPUの故障率はCPUよりも大幅に高く、すべての故障モードを考慮する必要があります。4つの9に必要なもの：AZ冗長性を備えたマルチリージョンデプロイ、そしてリージョン全体の障害を吸収できるサイズのフェイルオーバーリージョンに予備容量を確保すること。キーワードは「予備」です。「そこにトラフィックをルーティングできる」ではなく、「今そこにアイドルキャパシティがある」ということです。

プロバイダーにコミットする前に尋ねるべきこと

SLAは出発点です。これらの質問は基盤となるアーキテクチャ、問題発生時の責任者、復旧の速さに迫ります。私たちもこれらの質問をされることを期待しています：

インフラ所有権について：

• モデルはどこでホストされていますか？シングルリージョンですか、マルチリージョンですか？
• インフラを所有していますか、それともハイパースケーラーやサードパーティからレンタルしていますか？
• データセンターの責任者は誰ですか：電源、冷却、トランジット？物理アクセスはありますか、それともチケットキューを通じてですか？
• 1つのDCで障害が発生した場合、どれだけ早くデプロイを別の場所に移せますか？このために予備容量を維持していますか、それとも限界まで使っていますか？

フルスタックの専門知識について：

• スタック全体でチップからトークンまでの可視性がありますか？それとも推論とハードウェアの間に可観測性のギャップがありますか？
• 問題が発生した場合、チームは直接ハードウェアにアクセスできますか？それとも診断と対応をサードパーティに依存していますか？
• GPUハードウェアの専門知識は推論ソフトウェアを超えてどの程度深いですか？

キャパシティとフェイルオーバーについて：

• フェイルオーバーはどのようにテストされていますか：継続的なライブトラフィックですか、それとも定期的な訓練ですか？
• フェイルオーバーが実際に実行される必要がある場合、現実的なRTOはどのくらいですか？

SLA測定について：

• 各SLAレベルは実際にどの障害ドメインをカバーしていますか：ノード、DC、リージョン？
• SLAはロードバランサーで測定されますか、それとも推論完了時ですか？
• クライアント側のリトライはアップタイム測定にカウントされますか？

私たちの数値の定義

曖昧なSLA定義は、約束と実際の提供の間のギャップが存在する場所です。以下は私たちが測定するものと各用語の定義です。

私たちが測定するもの | 定義 | 数値 ---|---|--- 提供されたアップタイム | 推論エンドポイントがリクエストを正常に処理した時間の割合（ロードバランサーではなく推論完了時に測定） | 99.9%（一貫して提供） 保証SLA：単一DC | 単一データセンターデプロイメントの契約SLA | 99% 保証SLA：複数DC | 複数データセンターデプロイメントの契約SLA | 99.9% フェイルオーバー時間 | 施設障害後にトラフィックを健全なキャパシティにシフトする時間 | 秒 リクエストボリューム | 測定期間中に処理された推論リクエスト数 | 2B TPM+

私たちはゲートウェイではなく推論完了時に測定します。ロードバランサーに到達したがGPUで失敗したリクエストは、私たちの計算ではダウンタイムとしてカウントされます。もう一つ：可用性とパフォーマンスは異なる契約です。プロビジョンドスループットでは、特定のTPSを提供するためのGPU割り当てに対して料金を支払います。エンドポイントが応答するだけではありません。アップしているが契約スループットの30%しか提供しないサービスは、契約を満たしていません。

アーキテクチャを見に来てください

すべてのプロバイダーは数値を提供します。重要なのは、その背後にあるアーキテクチャがそれを裏付けるために構築されているかどうか、そして保証が成立しなければならないインフラを所有しているかどうかです。

これらは答えられる質問です。各SLAレベルの背後にあるアーキテクチャを説明するようプロバイダーに求めてください。インフラを所有しているのか、それとも他の上に位置しているのかを尋ねてください。フェイルオーバーパスがライブトラフィック下で動作しているかどうかを尋ねてください。自社のインフラを理解しているプロバイダーはこれらに素早く答えることができます。

私たちはいつでも私たちのアーキテクチャを案内できます。詳しく知りたい方は、ぜひお問い合わせください。