Together AI、GPUクラスターの自動修復を一般提供

Together AIは、GPUクラスターのハードウェアとソフトウェアの障害を検知し、修復を提案する自動修復機能を一般提供しています。顧客は、どの修復に承認を求めるか、実行中の処理をいつ中断するかを設定できます。同社によると、顧客と社内の推論基盤は、今年初めに機能を発表して以来、これを利用してきました。機能には、ヘルスチェック、修復の提案、障害別・ノード別の承認ポリシー、アイドル状態になるまでの待機設定、段階的な対応ルール、安全制限が含まれ、APIまたはコンソールから修復できます。顧客独自の検知システムがノードラベルで修復を依頼する機能は、引き続きプレビュー段階です。

システムは仮想マシン内と物理ホストの両方を検査します。仮想マシンでは、カーネルログのXidエラーやGPUのPCIeバス切断をエクスポーターで監視し、DCGMで訂正不能なECCエラー、行の再マッピング失敗、PCIe再送率、熱による速度制限を調べます。Node Problem Detectorは読み取り専用ファイルシステム、XFSの停止、カーネルのデッドロック、kubeletまたはcontainerdの繰り返し再起動を検出します。SlurmエクスポーターはDOWNまたはDRAINとされたノードを報告し、ホスト側ではInfiniBand接続とホストへの到達性を監視します。アラートには平易な説明と機械処理可能な証拠が含まれ、制御プレーンは情報を変更せずコンソール、API、通知へ渡します。対応する修復方法がないアラートは記録してサポートに送られ、ディスク容量の圧迫などは再起動を起こさず記録されます。

修復を実行するには、ヘルスチェックの失敗が必要です。顧客は提案を承認待ちにするか、特定の障害に自動対応させることができ、個別のXidコードごとにも設定できます。たとえばXid 119と95の再起動は自動承認し、移行には承認を求められます。GPUを要求するKubernetesポッドがなくなるか、Slurmの割り当てがなくなるまで修復を待たせることもできます。標準の最大待ち時間は2時間で、上限は24時間です。稼働中のジョブを中断しない設定を選ぶと、時間制限はなくなります。修復ごとに、依頼者と承認者、適用されたルール、実行時刻が記録されます。

修復依頼はAPI、コンソール、またはプレビュー中のノードラベルやアノテーションから送れます。依頼できる処置は再起動、迅速な再プロビジョニング、移行で、ノードの削除は人が実行します。検知器の名前と依頼IDを使い、同じ修復が繰り返し依頼されるのを防ぎます。依頼にも証拠確認、容量確認、クラスターごとの上限が適用されます。処理はノードのスケジュール停止、待機、ワークロードの退避、修復、再参加の順に進みます。再起動では仮想マシンを再起動し、ローカルのスクラッチ領域と一時データを保持します。迅速な再プロビジョニングではクリーンなイメージから再構築するため、ローカルデータは失われます。移行では別のハードウェア上に再構築し、旧ホストを検査に回します。削除ではノードを修理または交換に回します。

同じマシンで同じ処置を2回試した後に同じ障害が再発すると、対応を段階的に強めます。3回目の再起動の提案は再プロビジョニングに、3回目の再プロビジョニングの提案は移行に切り替わります。1週間より前の試行、キャンセルされた提案、自然に解消した障害は回数に含みません。移行には、現在発生中の重大アラート、または同じマシンで過去10日間に記録された重大アラートが必要です。証拠がない場合は迅速な再プロビジョニングを行います。GPUの電源を切る必要があるXid 79などに対応するホストの電源再投入はプレビュー中で、移行用に予備容量を確保することもできます。

同時に発生する障害による影響を抑えるため、アラートは設定した時間にわたって継続する必要があります。修復後にはおよそ30分のクールダウンがあり、同時実行の上限はクラスターの規模に応じて設定されます。ノードプールごとに実行できる修復は一度に1件です。自動修復が急増した場合はサーキットブレーカーが停止し、各修復の対象は1ノードに限られます。先にアラートが解消すれば提案は消えます。書き込みはべき等性を備えているため、制御プレーンの2つの複製が同じノードに処理を行っても修復は1件だけ作成されます。

移行または削除の後、空いた物理マシンはGPU、NCCL、InfiniBand、ストレージの検査を自動で受けてからクラスターに戻ります。検査に合格すればチケットを作成せずに復帰し、明確な失敗があれば検査結果とログを添えてハードウェア修理チケットを作成します。検査が中断された場合は、マシンを以前の状態に戻します。Together AIによると、この修復プロセスは、ベンダーごとの検知と診断チェックを用いながら、複数のアクセラレーター・ベンダーに対応する設計です。顧客は……

Together AIは、GPUクラスターのハードウェアとソフトウェアの障害を検知し、修復を提案する自動修復機能を一般提供しています。顧客は、どの修復に承認を求めるか、実行中の処理をいつ中断するかを設定できます。同社によると、顧客と社内の推論基盤は、今年初めに機能を発表して以来、これを利用してきました。機能には、ヘルスチェック、修復の提案、障害別・ノード別の承認ポリシー、アイドル状態になるまでの待機設定、段階的な対応ルール、安全制限が含まれ、APIまたはコンソールから修復できます。顧客独自の検知システムがノードラベルで修復を依頼する機能は、引き続きプレビュー段階です。

システムは仮想マシン内と物理ホストの両方を検査します。仮想マシンでは、カーネルログのXidエラーやGPUのPCIeバス切断をエクスポーターで監視し、DCGMで訂正不能なECCエラー、行の再マッピング失敗、PCIe再送率、熱による速度制限を調べます。Node Problem Detectorは読み取り専用ファイルシステム、XFSの停止、カーネルのデッドロック、kubeletまたはcontainerdの繰り返し再起動を検出します。SlurmエクスポーターはDOWNまたはDRAINとされたノードを報告し、ホスト側ではInfiniBand接続とホストへの到達性を監視します。アラートには平易な説明と機械処理可能な証拠が含まれ、制御プレーンは情報を変更せずコンソール、API、通知へ渡します。対応する修復方法がないアラートは記録してサポートに送られ、ディスク容量の圧迫などは再起動を起こさず記録されます。

修復を実行するには、ヘルスチェックの失敗が必要です。顧客は提案を承認待ちにするか、特定の障害に自動対応させることができ、個別のXidコードごとにも設定できます。たとえばXid 119と95の再起動は自動承認し、移行には承認を求められます。GPUを要求するKubernetesポッドがなくなるか、Slurmの割り当てがなくなるまで修復を待たせることもできます。標準の最大待ち時間は2時間で、上限は24時間です。稼働中のジョブを中断しない設定を選ぶと、時間制限はなくなります。修復ごとに、依頼者と承認者、適用されたルール、実行時刻が記録されます。

修復依頼はAPI、コンソール、またはプレビュー中のノードラベルやアノテーションから送れます。依頼できる処置は再起動、迅速な再プロビジョニング、移行で、ノードの削除は人が実行します。検知器の名前と依頼IDを使い、同じ修復が繰り返し依頼されるのを防ぎます。依頼にも証拠確認、容量確認、クラスターごとの上限が適用されます。処理はノードのスケジュール停止、待機、ワークロードの退避、修復、再参加の順に進みます。再起動では仮想マシンを再起動し、ローカルのスクラッチ領域と一時データを保持します。迅速な再プロビジョニングではクリーンなイメージから再構築するため、ローカルデータは失われます。移行では別のハードウェア上に再構築し、旧ホストを検査に回します。削除ではノードを修理または交換に回します。

同じマシンで同じ処置を2回試した後に同じ障害が再発すると、対応を段階的に強めます。3回目の再起動の提案は再プロビジョニングに、3回目の再プロビジョニングの提案は移行に切り替わります。1週間より前の試行、キャンセルされた提案、自然に解消した障害は回数に含みません。移行には、現在発生中の重大アラート、または同じマシンで過去10日間に記録された重大アラートが必要です。証拠がない場合は迅速な再プロビジョニングを行います。GPUの電源を切る必要があるXid 79などに対応するホストの電源再投入はプレビュー中で、移行用に予備容量を確保することもできます。

同時に発生する障害による影響を抑えるため、アラートは設定した時間にわたって継続する必要があります。修復後にはおよそ30分のクールダウンがあり、同時実行の上限はクラスターの規模に応じて設定されます。ノードプールごとに実行できる修復は一度に1件です。自動修復が急増した場合はサーキットブレーカーが停止し、各修復の対象は1ノードに限られます。先にアラートが解消すれば提案は消えます。書き込みはべき等性を備えているため、制御プレーンの2つの複製が同じノードに処理を行っても修復は1件だけ作成されます。

移行または削除の後、空いた物理マシンはGPU、NCCL、InfiniBand、ストレージの検査を自動で受けてからクラスターに戻ります。検査に合格すればチケットを作成せずに復帰し、明確な失敗があれば検査結果とログを添えてハードウェア修理チケットを作成します。検査が中断された場合は、マシンを以前の状態に戻します。Together AIによると、この修復プロセスは、ベンダーごとの検知と診断チェックを用いながら、複数のアクセラレーター・ベンダーに対応する設計です。顧客は……