勾配、再計算、重みの比較を組み合わせる実装例です。異常の候補をノードへ対応させ、隔離と確認を経て復旧します。 GPUが警告しない計算誤りで学習が汚染される問題を扱います。分散方式や再計算の費用、戻すチェックポイントの選択が焦点です。 エラーを出さない誤計算は学習側で探す AWSは11月11日、Amazon SageMaker HyperPodで静かなデータ破損を検出する方法を公開しました。SDCと呼ばれる問題で、ハードウェアが異常を報告せず、もっともらしい誤った数値を返す場合があります。分散学習では勾配や重みへ伝わり、損失の値だけでは気付けないことがあります。通常のハードウェア監視や保存データのチェックサムは、計算結果が正しいかを直接保証しません。そこでPyTorchのDistributedDataParallelの学習ループに確認処理を加える構成を示しました。原文はソフトウェアで故障を注入して検証した例であり、実際の全故障を捕捉した結果ではありません。検出できる故障の範囲を明示します。 勾配と再計算と重みで別の異常を捉える 最初の確認は、勾配のNaNや無限大などを検出します。次の確認は、別ノードが扱った小さなバッチを再計算し、損失や勾配の指紋を比較します。さらに更新後の重みを複数の複製間で比べます。それぞれが異なる場所の誤りを対象とします。検証は32基のH100を使う4インスタンスの環境で行い、必要最小の3インスタンスでも繰り返したと説明しました。対象は大規模学習を運用するチームで、異常候補をGPUからノードへ対応させる作業にも関係します。重みの比較は分割された重みにそのまま使えるわけではなく、再計算も監査したステップの条件に依存します。通常の監視が正常でも疑いが解消したとは限りません。既存監視の置き換えではなく、学習中の数値の関係を追加で調べる構成です。 検出後の隔離と復旧まで手順に含める 実務では、検出の感度だけでなく、誤検知時にどこまで止めるかが論点です。計算の非決定性や通信の扱いが比較結果へ影響しないかを検証する必要があると見られます。再計算と指紋の確認には追加の計算や通信の費用が伴います。監査の頻度は、見逃す期間と負荷の両方を見て決めます。異常時にはジョブを止め、疑うノードを隔離し、指標を確認してから交換する流れです。復帰先には疑わしい期間より前のチェックポイントを選びます。保存済みの重みが一貫して壊れていれば、保存の検査だけでは分からない可能性があります。自動復旧の機能があっても、どの学習状態まで戻すかの判断は残ります。運用記録を保ち、再発するノードを追える体制が重要になります。長い学習でどの時点まで影響が広がったかを追うには、監査の実施時刻と保存した状態を結び付ける必要があります。検出の記録を復旧判断へ使えることが前提です。