デザインツール
AI

チェックポイント処理が負担になっていませんか?

ウェス・ヴェスク、セイジー・ヴォルコフ | 2025年2月

はじめに:

何十年もの間、ソフトウェアはチェックポイントを使用してシステムの状態を保存してきました。チェックポイント処理は、メモリからストレージにデータチャンクをダンプしたり、コード内のセクションを完成させたり、コードやソフトウェアが適切に実行およびテストされたことを確認する方法として使用するような簡単なものです。

しかし、AIの世界ではどうでしょうか。お客様やパートナーから、AIシステムのチェックポイント処理が課題になっているという話を聞くことがあります。そこで、AIのチェックポイント処理に関する3部構成のブログシリーズの第1回では、基本的な項目をいくつか取り上げ、それらが重要である理由を解説します。第2回のブログでは、チェックポイントのパフォーマンス要件について説明します。最後の第3回のブログでは、マイクロンとLightbitsのストレージがあらゆる種類のチェックポイントの問題をどのように解決するかを紹介します。

AIにおけるチェックポイントとは?

チェックポイントは、AIトレーニングジョブの状態を保存することをいいます。保存することで、問題が発生した場合に、データが安全に保存された最後の状態からトレーニングを再開できるため、ジョブを最初からやり直す必要がなくなります。ビデオゲームで「ゲームの保存」オプションを使用するのと同じです。

AIトレーニングは、5年以上前から企業の重要なワークロードとなっています。では、なぜ今チェックポイントが話題になっているのでしょうか。答えは2つあります。1つはトレーニングされるモデルの種類、もう1つは基本的なトレーニングの実行方法のうちのひとつに関連しています。

トランスフォーマーモデルの台頭

トランスフォーマーモデルはデータセンターで広く使用されています。トランスフォーマーモデルの説明はこのブログの対象ではありませんが、私たちが関心を持っている主な効果は並列処理の実現です。

トランスフォーマーモデル(ChatGPT、Llama、Geminiなど)は、シーケンスデータ(文章や段落など)を取得し、それを大量のハードウェアで並列処理が可能なベクトルに変換します。

以前のモデルでは、クラスターにGPUを追加すると、トレーニングのパフォーマンス効果がすぐに損なわれていましたが、並列処理が可能になったことで、大規模なAIトレーニングクラスターが爆発的に増加しました (この場合の大規模とは、数万個のGPUを搭載した数千台のサーバーをいいます)。

基本的なトレーニングプロセス

トレーニングをいくつかのステップに分けてみましょう。

  1. 新しいデータでトレーニングする(更新されたモデルの重みをデータから学習する)
  2. 更新されたモデルの重みをすべてのGPU間で共有する

最新のトレーニングでは、この2つのステップを同時に実行します。つまり、すべてのGPUがトレーニングを停止して更新されたモデルの重みを共有してから、新しいデータでトレーニングを続行します。標準的なすべてのトレーニングプロセスは、トレーニング期間中にいずれかのコンポーネントに故障が発生した場合、クラスター全体を停止して前のチェックポイントから再読み込みするように関連付けられています。

故障率の方程式

コンポーネントの故障率

次に、故障する可能性のあるコンポーネントの数が増加した場合、全体の故障率がどのように変化するかを理解することが重要となります。

確率を計算するには、データバッチでトレーニング中にGPUが故障しない可能性を考慮する必要があります。

つまり、クラスターの故障率を推定するとき、故障率はクラスターサイズに比例して急激に増加します。これは、平均故障時間(MTTF)としてグラフで表せます。

平均故障時間(MTTF)のグラフ

グラフを見ると、クラスターサイズが増加するにつれて、MTTFが驚くほど低い値になることがわかります。アクセラレーターが24,000個の場合、2時間ごとに故障が発生すると推定しています。グラフの右端は、今日デプロイされている大規模クラスターを示していますが、MTTFは30分未満であることがわかります。

ストレージを考慮することがチェックポイント処理で重要な理由

トレーニングとその流れについて理解を深めたところで、実際のシナリオをいくつか見てみましょう。

4050億のパラメーターを持つLlama 3のような大規模なオープン大規模言語モデルを見てみると、そのチェックポイントのサイズは約5TBです。

95%の良好なクラスタースループットを達成するために、故障と故障の間で20回チェックポイント処理をするとします。

つまり、MTTFが124分の24,000個のアクセラレーターの場合、6分ごとにチェックポイント処理をします。これにより、1日あたり233個のチェックポイント(各5TB)が発生し、クラスターによって毎日1.1ペタバイトのチェックポイントデータが書き込まれます。24時間の運用で平均すると、クラスター全体で13GB/秒の書き込みスループットが持続的に必要です。

この例から、チェックポイント処理はストレージのパフォーマンスに依存していることがわかります。そのため、マイクロンとLightbitsはMLPerf Storage Benchmark Suite(MLCommonsの一部)をサポートし、チェックポイント処理プロセスをテストしたり、AIソリューションを設計する際のクラスターとストレージの要件を把握したりするためのベンチマークを作成しています。

まとめと次回のブログ

第1回の今回のブログでは、チェックポイント処理がトレーニングの重要な要素である理由と、チェックポイント処理では高性能のストレージソリューションが重要である理由について説明しました。

次回のブログでは、大規模なストレージ環境(エンタープライズ、クラウドプロバイダー、ハイパースケール)におけるチェックポイントの要件について説明します。ぜひお読みください。

Lightbitsとマイクロンの高度なストレージおよびメモリソリューションの詳細については、www.lightbitslabs.com/micron/をご覧ください。

SMTSシステムパフォーマンスエンジニア

Wes Vaske

ウェス・ヴェスクは、マイクロンテクノロジーのテクニカルスタッフシニアメンバー(SMTS)であり、システムパフォーマンスエンジニアです。ストレージソリューションとAIインフラストラクチャに関する豊富な経験を持ち、マイクロンがデータインテリジェンスと機械学習の分野で能力を向上させるうえで極めて重要な役割を果たしています。AIトレーニングシステムのベンチマークと、次世代GPUの要求を満たすストレージパフォーマンスの最適化に関する専門知識が評価されています。マイクロンに入社する前は、Dellでシステムエンジニアを務めていました。アイオワ州立大学で学士号を取得しています。

上級パフォーマンスアーキテクト

Lightbits Labs guest author Sagy Volkov

セイジー・ヴォルコフは、Red HatのOpenshift Container Storage(OCS、現在のODF)の元パフォーマンスアーキテクトです。それ以前は、ScaleIO(現在のDell PowerFlex)のパフォーマンスエンジニアリンググループとエンタープライズアドボケイトグループを統括するとともに、ScaleIOストレージアプライアンスの設計を行っていました。現在は、Lightbits Labsで上級パフォーマンスアーキテクトを務め、NVMe/TCPのパフォーマンスとNVMe/TCPを使用したアプリケーションのパフォーマンスの向上に取り組んでいます。これまでに、KubeCon、DoK、CNS、DevConf、EMC World、Red Hat Summitで講演を行った経験を持ちます。