入力が無効です。特殊文字には対応していません。
AIシステムが複雑化し、その能力が拡大するにつれ、ストレージインフラに求められる要件も、同じように急速に進化しています。巨大なモデルのトレーニングからリアルタイム推論の提供まで、ストレージはもはや受動的なバックエンドではなく、AIスタックのパフォーマンスを左右する極めて重要な要素です。MLPerf Storage v2.0ベンチマークスイートは、高スループットのトレーニングから耐障害性を確保するチェックポインティングまで、AIワークロード特有のI/Oパターンを現代のSSDがどのように処理するか、新たな視点で捉えます。
しかし、このトピックの話題はこれで終わりではありません。推論ワークロードが検索拡張生成（RAG）にシフトするにつれ、ストレージ最適化の次なる新天地として、ベクトルデータベースおよびキー値（KV）キャッシュが浮上しています。これらのワークロードは、新たな課題を生み出します。
この記事では、最新のMLPerf Storage結果について解説し、その裏側にあるワークロードを明らかにするとともに、ベクトル検索とKVキャッシュ再利用の台頭に今後のベンチマークがどのように適応すべきかについて検証します。
さらに詳しく知りたい方は、SNIA Developer Conference（SDC）にご来場ください。9月17日午前8:30から始まる以下のセッションで、私が詳しい解説を行います。「MLPerf StorageベンチマークスイートとAIストレージワークロードに関する考察と分析」
MLPerf Storage v2.0s：主な結果とワークロード
AIワークロードに関するストレージのベンチマークは、業界でも特に難しい課題とされています。現実のトレーニングジョブには高価なアクセラレーターが必要であり、一般公開されているデータセットは、小さすぎて本番スケールの動作を反映しない場合が少なくありません。
MLCommonsコンソーシアムが開発したMLPerf Storageは、この問題を解消しています。合成データセットと実際のデータローダー（PyTorch、TensorFlow、DALIなど）を使用して、現実のAIトレーニングをエミュレートしながら、コンピュートを校正済みのスリープ間隔で置き換えて、GPUの動作をシミュレートします。このアプローチにより、ストレージシステムの正確でスケーラブルなベンチマークが可能になり、何千ものGPUが不要になります。
また、キュー深度のヒストグラムから分かるように、ワークロードの強度に変動が見られます。低いQDのオペレーションが、非常に高いQDのオペレーションと混在しています。
MLPerf Storageの誕生以来、マイクロンはこのツールに深く関わっており、すべてのメジャーリリース（v0.5、v1.0、そして現在はv2.0）に貢献し、結果を提出するとともにベンチマークワークロードの形成を支援しています。
v2.0では、MLPerf Storageはトレーニングの取り込みからさらに範囲を広げ、チェックポインティングのワークロードを含むようになっています。
トレーニングのワークロード：ResNet50、CosmoFlow、Unet3D
MLPerf Storageにおけるトレーニングワークロードについて、私は何度か詳しく書いたり、話したりしてきました。直近ではFMS 2024で発表を行っています。v2.0におけるトレーニングベンチマークの定義は、v1.0と同じです。つまり、2回の提出時期の結果を比較することが可能です。
こちらの講演内容をぜひご覧になることをお勧めいたしますが、最大の気づきは、トレーニングデータの取り込み処理は、実に多様なワークロードを生み出すということです。MLPerf Storageで表される3つのモデルには、データコンテナ形式に応じてさまざまな転送サイズがあることが分かります（TFRecordは、多数の4KB IOという結果になっています）。
これらの特性から、AIトレーニング用のデータの取り込みは、予想よりも大幅に複雑になっています。
チェックポインティングのワークロード：モデルのLlama 3群
私たちはまず、2023年の終わり頃にチェックポインティングワークロードから始めました。私たちの仕事がMLPerf Storageに組み込まれたことを非常に誇らしく思います。チェックポインティングは、今ではファーストクラスのワークロードであり、トレーニング中にモデルとオプティマイザーの状態を定期的に保存する必要性を示しています。スケールアウトクラスターで大規模言語モデル（LLM）を実行する場合は、特にです。このベンチマークについての詳細は、mlcommons.orgにある私のブログで「新しいチェックポインティングワークロードを発表」をチェックしてください。
ベンチマークには4つのモデルサイズが含まれているため、チェックポイントは105GBから18,000GBまでの範囲となっています。各モデルで、チェックポインティングの2つのフェーズ（チェックポイントの保存、チェックポイントの読み込み）を測定します。
チェックポインティングの結果は、効率的なチェックポイントの保存と、以前のチェックポイントからの回復のためのさまざまなソリューションを示しています。1兆パラメーターのモデルで600GiB/秒以上の回復速度を達成したIBMに、大きな敬意を表します。
ありがたいことに、最新のSSDは、4KBチャンクのデータへのランダムアクセスを提供するのに非常に適しています。
新興のワークロード：ベクトルデータベース
ベクトルデータベースは、一般にAIモデルによって生成される埋め込み表現である、高次元ベクトルの保存と検索向けに最適化されています。これらのシステムは、レコメンデーションエンジン、画像とテキストの検索、不正行為の検出、そして最近ではLLMの検索拡張生成（RAG）などのアプリケーションにおける類似性検索を駆動します。
従来のデータベースとは異なり、ベクトルDBは完全一致よりも近似最近傍探索（ANN）を優先し、速度とスケーラビリティを得るために精度を犠牲にします。データセットが年々成長するにつれ、ベクトル索引をメモリからディスクにオフロードする必要性から、ストレージパフォーマンスがファーストクラスの懸案事項となっています。
ベクトル検索システムにストレージを統合する方法は複数ありますが、主要な方法は、高速のストレージからクエリーするよう設計された索引の使用です。私のチームメイトであるサヤリ・シロードが最近、FMS（Future of Memory and Storage）で行った「MLPerf Storageでの新しいベクトルデータベースのベンチマークに関する考察と分析」と題するセッションで、いくつかの所見を発表しました。
サヤリはこのセッションで、1億ベクトルのデータセットでMilvusのDiskANNを使用した結果について分析を示しました。ストレージに関する意思決定を方向づける、この研究の重要な所見は以下のとおりです。
- 小さいIO
- 低いキュー深度と非常に高いQDのバースト
サヤリは、レイテンシーに影響されやすいドメイン（低いバッチサイズ、単一プロセス）が、100%の4KBオペレーションを実行してディスクに索引付けすることを示しました。さらに、最大のスループット（高いバッチサイズと複数の同時プロセス）まで拡大しても、100%の4KBオペレーションによるディスクへの索引付けという同じ挙動が見られました。
第二の所見は、最初の所見に立脚しています。ワークロードのキュー深度のヒストグラムを見ると、大部分のIOが、キューの相対的に低い位置に挿入されていることが分かります。単一のプロセスは、QD7でピークとなり、QD35までテールが伸びています。64プロセスのテストでは、15という「低い」キュー深度で同じようにピークとなりましたが、QD 400+までの長いテールが見られました。
スレッド数またはバッチサイズをテストより高くすると、レイテンシーが非常に大きくなり、クエリースループットの増加は最小限という結果になりました。これらの結果から、DiskANNのストレージ要件は、多くの4KB IOを提供しながらレイテンシーを最小化し、QoSを最適化することであると分かります。
さらに詳しく知りたい方は
ベクトル検索とDiskANNの詳細について、SDCで行われたアレッサンドロ・コンカルベス（Solidigm）のプレゼンテーション「NVMeによるRAGのスケーリング：ベクトルデータベースの索引付けへのDiskANNのハイブリッドアプローチ」をご覧ください。アレッサンドロは、私たちが今年前半にこのイニシアティブを開始して以来、MLPerf Storageワーキンググループとともにベクトルデータベースのベンチマークに取り組んでいます。私たちは、合成データセットとクエリーを生成できるベンチマークツールも使用しています。このツールを使用すると大規模なデータセットをテストできますが、結果の精度は検証されないので、何らかの精度テストなしで、異なる索引を互いに比較する目的では使用しないでください。このツールは活発に開発が進められています。要望やバグについては、githubイシューをご利用ください。
KVキャッシュの管理と再利用
KVキャッシュは、その名前だけではなかなか理解しづらい、複雑なコンセプトです。知っておくべき重要なポイントは、トークンを生成するLLMにはクエリー用のKVキャッシュが必要であるということです。KVキャッシュは実質的に、トランスフォーマーベースのLLMが推論中に使用する短期メモリです。
KVキャッシュオフロードとは、トークン生成を行っている間に、他のメモリを利用してKVキャッシュを部分的に保存することを指します。これは、本記事で説明するものとは別のワークフロー部分です。
KVキャッシュの管理および再利用とは、トークン生成の完了後に、起こりうる今後の再利用に備えて、クエリーのKVキャッシュを保存することを指します。
これは、しばらく離席した後でLLMとの会話をピックアップする場合や、別のクエリーで同じ「コンテキスト」を参照する必要が生じた場合に起こります（同じコードベースに対するコーディングアシスタントからの連続するクエリーや、長いドキュメントに関する複数の質問など）。KVキャッシュを再計算し、出力トークンをさらに生成するためにコンピュートリソースを解放するよりも、ディスクからKVキャッシュを読み込むほうが高速です。
業界でこのワークフローはまだ開発中ですが、これらのプロセスの最適化を焦点とする研究開発がかなり行われています。MLPerf Storageワーキンググループ（およびその他）が、KVキャッシュ管理レイヤーを表すベンチマークプロセスの開発・定義と、それがストレージとどのように相互作用するかについての研究に取り組んでいます。
私たちの最初の分析によると、ワークロードは主として、キャッシングシステムで一般に見られる、高い書き込みスループット速度の大きな転送（2MB+）です。高スループットのGenAIシステムでは、KVキャッシュの生成速度は、GPUあたり1日あたり数十テラバイト超になる場合があります。
このことから、基にあるシステムの耐久性を最適化することにフォーカスしたストレージ要件が推進されます（オーバープロビジョニング、SLC対TLC対QLC、柔軟なデータ配置など）。
さらに詳しく知りたい方は
KVキャッシュのストレージ使用の詳細については、ウグール・ケイナー（Dell）によるSDCでのプレゼンテーション「KVキャッシュのストレージオフロードによるLLMでの効率的な推論」をご覧ください。ウグールも、v2.0の開発サイクルにおける複数の分野でMLPerf Storageワーキンググループに貢献しています。
KVキャッシュ管理の詳細については、KVキャッシュがなぜ重要なテーマであるかを具体的な数値を用いて解説した、私の以前のブログ記事「100万トークンのコンテキスト：良いところ、悪いところ、酷いところ」をお読みください。
AIシステム用ストレージの未来
現在のAIシステム用ストレージをベンチマークして特徴づけてみると、今後必要になるものが非常に多いことが分かります。AI用ストレージのの最先端技術にご興味がある方は、SDCで行われる以下のセッションもチェックしてみてください。
ジョン・マッツィー（マイクロン）：小粒度グラフのニューラルネットワークトレーニングとストレージの未来
ジョン・グローブス（マイクロン）：Famfs：分解された共有メモリの大きなプールに備えよう
CJ・ニューバーンとウェン・メイ・フー（Nvidia）：新世代のAIアプリケーションによるストレージへの影響
