推論における 99.9% の稼働率の意味

TL;DR

• 要約すると、各信頼性レベルは特定の障害ドメインに対応し、それぞれを生き延びるには独自のアーキテクチャが必要です。大まかに言えば：
• 99% はノードレベルの障害（GPU ハードウェア故障、ドライバークラッシュ、熱暴走など）に耐えられることを意味します。これを実現するには、自動化されたヘルスチェック、ノードの排水処理、および単一データセンター内での高速なレプリカ交換が必要です。
• 99.9% は、データセンター全体がダウンしても機能し続けることを意味します。通常、これはモデル重みを 2 つの施設に分散配置し、各側にフルロードを吸収できる十分なキャパシティを持たせ、コールドスタンバイではなくライブトラフィックを両方にルーティングする構成を指します。
• 99.99% は、リージョン全体のアウトエージ（広域障害）にも耐えられることを意味します。これには通常、可用性ゾーン（AZ）の冗長性を備えたマルチリージョン展開と、予備のフェイルオーバーキャパシティの確保が必要です。

信頼性数値を公表するのは簡単ですが、その実態を説明するのは難しいものです。アーキテクチャが実際にカバーする障害ドメインは何か、プロバイダーが各レイヤーでインフラを制御しているのか、そして深夜 3 時に何かが壊れた際にどうなるのか——これらを明確に示す必要があります。

Together は Cursor、Decagon、Cartesia、Yutori などのチームに対して推論（inference）サービスを提供しています。以下の内容は、私たちが実際にページングされた事例に基づいた教訓です。

信頼性数値が抱える問題

推論（inference）システムが停止すれば、それを利用する製品も同時に停止します。GPU を用いた推論の障害は、従来のサービスとは異なる様相を呈します。

ハードウェアには固有の故障モードが存在し、CPU インフラストラクチャにはそれがありません。また、システムは性能最大化のために徹底的にチューニングされています。1 GPU あたり 1 分間に 100 万トークンを処理し、200 TPS を達成する、あるいはカスタムカーネルを用いて音声モデルで 50 ミリ秒未満の TTFT（Time To First Token）を実現するような状況では、余裕は極めて限られています。そのようなシステムに信頼性を付与することは、9 の数値が増えるごとに指数関数的に困難になります。

理解を深めるための有効な思考モデルは「層」です。各層には固有の故障モードが存在します：

• 計算（Compute）： VRAM 内の ECC エラー（最も頻繁に発生する事象で、重みデータを静かに破損させるため、リクエストは正常に返されますが出力の信頼性は失われます）、サーマルスロットリング、ドライバークラッシュ、NVLink の障害、GPU の状態に関わらずマシン全体を停止させる NIC や CPU の故障。
• ネットワーク： スイッチの障害、性能低下を引き起こしてから完全な利用不可に至るトランシーバの問題、サイト全体をダウンさせるエッジデバイスの故障。
• ストレージ： 重みの取得をブロックし、リスケジューリングを停止させ、最終的に容量問題へと連鎖するアウトエイジ（停電）。
• ソフトウェア： ルーティングのバグ、スケジューラの極端なケース、注意を怠ると伝播する可能性のあるデプロイメントの失敗。

これらはいずれも単独で発生することはありません。ストレージの一時的な不具合は容量問題として表面化し、サーマルイベントは健康アラートが鳴るずっと前に出力品質の低下として現れます。この問題を克服するには、誤解を招く症状から真のシグナルを見極めるスキルを身につける必要があります。

各「9」が実際に要求するもの

それぞれの稼働率レベルは、単に難易度が上がるだけでなく、異なるエンジニアリング課題を意味します。ここでは各レベルで何が必要か、そして私たちがそのために何を構築してきたかを解説します。

99%：ノード障害への耐性

目標は、リクエストが到達する前に劣化したノードを検知し、迅速に検出・排水・交換することです。ここで重要なエンジニアリング課題は「可視化（オバザビリティ）」にあります。

パッシブなヘルスチェック（ハードウェアのテレメトリーやメトリクス）は、リソースを消費せずに状況を把握できますが、実際の GPU 負荷下でしか発生しない故障タイプを見逃す可能性があります。アクティブなヘルスチェックはその欠点を補いますが、実行にはリソース容量が必要です。すでにトラフィックを処理している GPU をテストすることはできません。なぜなら、それでは明らかなジレンマが生じるからです。誰もが稼働率を 100% に近づけたいと考えていますし、ヘルスチェック用の余剰容量を維持することは、信頼性を犠牲にして非効率さを招くことになります。

私たちが選んだ道は、「スケジューリングの高速化」です。チェック機能をスケジューラと統合してワークロード間の隙間に実行させるとともに、チェック自体を可能な限り短時間で完了させるようにしています。これはまだ調整が必要な領域です。

このレベルの稼働率を阻む最大の要因は、建物そのものの問題です。熱暴走、変電所の事故、エッジルーターの故障など、いずれも DC 内の冗長性があっても単一 DC 構成全体をダウンさせます。

多くのプロバイダーがバックアップシステムを用意していますが、実環境で定期的にテストされていない冗長システムは、6 週間練習していない選手をベンチから呼び出すようなものです。ペーパー上ではフェイルオーバーの仕組みがあるとしても、実際に機能するかは別問題です。

99.9%: DC 全体の障害に耐えること

この場合、障害ドメインは施設全体を指します。電源、冷却システム、ネットワークの入口（ingress）、エッジネットワークが対象です。これを生き延びるために必要なことは、重み付けされたモデルを2つの施設に分散配置し、各側にフルロードを吸収できる十分なキャパシティを持たせ、トラフィックをシームレスに切り替えることです。

プロバイダーがこのレベルの稼働率を実際に提供できるかどうかを決めるのは、両方の施設で継続的に本番トラフィックを流しているか、それともコールドスタンバイ（待機状態）で維持しているかのアーキテクチャ上の判断です。私たちは継続運用を選びました。多くの 99.9% SLA の主張はこのレベルを暗黙に約束していますが、肝心なのは、その主張の背後にあるアーキテクチャが実際にそれを支えるように設計されているかどうかです。

インフラの所有権が具体的にどう影響するかは、ここでも明確になります。ハイパースケラーやネオクラウドから容量を借りているプロバイダーは、自社の障害ドメインを所有していません。電源や冷却層で何かが故障した場合、彼らはその責任を持つ誰かにチケットを起こすしかありません。その層での SLA が物理的にどの程度まで耐えられるかについて、彼らには答えることができません。なぜなら、そこを制御していないからです。

Together AI なら、ハードウェア、ネットワーク、ストレージ、ソフトウェアのすべてを一つのチケットでカバーできます。これは、グローバルな展開全体にわたってチップからトークンまでの可視性を持っているからこそ可能です。対照的なケースでは、プロバイダーへの問い合わせ、プロバイダーからのハイパースケラーやネオクラウドへの問い合わせ、そして待ち行列が発生します。深夜 3 時にこれがどうなるか、私たちは実際に目撃しています。

99.99%：地域全体の障害を生き延びる

このレベルでの根本的な課題は、本質的に信頼性の低いハードウェアの上に、信頼できるインフラを構築している点にあります。GPU の故障率は CPU よりも明らかに高く、すべての故障モードに対応する必要があります。4 つの 9（99.99%）を実現するために必要なことは、可用性ゾーン（AZ）の冗長性を備えたマルチリージョン展開と、地域全体の障害を吸収できる規模で予備容量をフェイルオーバー先に確保することです。ここで重要なのは「予約済み」という言葉です。「そこにトラフィックをルーティングできる」ではなく、「今すぐそこに空きリソースが待機している」という状態です。

プロバイダーにコミットする前に確認すべき質問

SLA は出発点に過ぎません。これらの質問は、その背後にあるアーキテクチャ、障害発生時に誰が何を責任を持つのか、そして復旧がどの程度迅速に行われるのかを問うものです。私たちに対しても同様の質問をしていただくことを期待しています：**

インフラの所有権について：モデルはどこにホストされ、単一リージョンかマルチリージョンか。

自社のインフラを所有しているのか、それともハイパースケラーやサードパーティから容量を借りているのか。

データセンターの責任範囲は誰が担うのか。電力、冷却、トランジットなどだ。物理的なアクセス権はあるのか、それともチケット待ちの窓口を経由する必要があるのか。

ある DC で障害が発生した場合、そのデプロイ先をどこかに移すのにどれくらい時間がかかるのか。まさにこのための予備容量を維持しているのか、それとも無理のない運用をしているのか。

フルスタックの専門性について：チップからトークンまで、スタック全体にわたって可視化できているか、推論とハードウェアの間に観測性のギャップはないか。

何か障害が起きた際、チームは直接ハードウェアにアクセスできるのか、それとも診断や対応をサードパーティに依存しているのか。

GPU ハードウェアに関する専門知識は、推論ソフトウェアの範囲を超えてどこまで及んでいるのか。

容量とフェイルオーバーについて：フェイルオーバーのテストはどのように行われるか。継続的な本番トラフィックで行うのか、それとも定期的な訓練なのか。

実際にフェイルオーバーを実行する必要がある場合、現実的な RTO はどれくらいか。

SLA の測定について：各 SLA ティアが実際にカバーする障害ドメインは何か。ノード、DC、リージョンのいずれか。

SLA はロードバランサーレベルで測定されるのか、それとも推論完了の成功基準で測定されるのか。

クライアント側のリトライは、アップタイム測定の対象に含まれるのか。

数値の定義

曖昧な SLA の定義こそが、約束と実際の提供の間に生じるギャップの原因となる。ここでは私たちが実際に測定する項目と、各用語の定義を明確に示す。

インフラの稼働率は、推論完了時点でのみ計測します。ロードバランサーには到達したが GPU で失敗したリクエストも、私たちの計算ではダウンタイムとしてカウントされます。

もう一点重要なのは、「可用性」と「パフォーマンス」は別々の契約条件だということです。Provisioned Throughput では、単にエンドポイントが応答するだけでなく、特定の TPS を達成するために GPU 割当に対して課金します。サービスは稼働していても、契約したスループットの 30% しか提供できていなければ、それは契約違反となります。

アーキテクチャを確認しよう

すべてのプロバイダーが何らかの数値を提示しますが、重要なのは、その数値を支えるアーキテクチャが信頼に足るものか、そして保証が守られるインフラを自前で所有しているかどうかです。

これらは明確に答えられるべき質問です。各 SLA ティアを支えるアーキテクチャについて、プロバイダーに説明を求めましょう。また、そのインフラを自社で所有しているのか、それとも他社の上位層に乗っているのかも確認してください。さらに、フェイルオーバー経路が実際のトラフィック下で機能するかも問うべきです。自社のインフラを熟知しているプロバイダーなら、これらの質問に即座に答えられるはずです。

私たちのアーキテクチャについても、いつでもご説明できます。詳しく知りたい場合は、お気軽にお声がけください。