1. 非構造化データに制限はない

現在の機械学習のパラダイムでは、パフォーマンスと能力はコンピューティングに比例して増大しますが、コンピューティングは実際にはデータセットのサイズとモデルのサイズの代理です ( Scaling Laws for Neural Language Models 、Kaplan 他)。過去数年間で、これにより機械学習とデータ インフラストラクチャの構築方法に抜本的な変化がもたらされました。具体的には、ストレージとコンピューティングの分離、非構造化データで満たされた大規模なクラウドネイティブ データ レイクの構築、行列乗算を非常に高速に実行できる専用ハードウェアです。

トレーニング データセット、またはデータセットの個々のシャードが、システム メモリやローカル ストレージで使用可能な容量よりも多くのスペースを必要とする場合、ストレージをコンピューティングから分離することの重要性が明白になります。MinIO オブジェクト ストアにあるデータでトレーニングする場合、トレーニング データのサイズに制限はありません。MinIO はシンプルさと I/O スループットに重点を置いているため、トレーニング速度と GPU 使用率の唯一の制限要因はネットワークになります。

MinIOは、あらゆるオブジェクトストアの中で最高のパフォーマンスを提供するだけでなく、すべての最新の機械学習フレームワークと互換性があります。また、MinIOオブジェクトストアはS3 APIと100％互換性があるため、TorchDataなどの使い慣れたデータセットユーティリティを使用して、オンプレミスまたはデバイス上のオブジェクトストアに対してMLワークロードを実行できます。 S3 データパイプファイルシステムのような機能がアプリケーション側で必要な場合は、MinIOを次のようなオブジェクトストアファイルインターフェースとともに使用することもできます。マウントポイントS3またはS3FS今後のブログ投稿では、モデル トレーニングで「制限のない」トレーニング データと高い GPU 使用率を実現するために、一般的な PyTorch および FairSeq インターフェイス (それぞれ Dataset および Task など) のカスタム実装で MinIO Python SDK を使用します。

パフォーマンスと最新の ML スタックとの互換性を超えて、オブジェクト ストレージの設計上の選択、つまり (1) フラットな名前空間、(2) オブジェクト全体 (およびそのメタデータ) を最下位の論理エンティティとしてカプセル化すること、および (3) シンプルな HTTP 動詞 API により、オブジェクト ストレージは大規模な非構造化データ レイクの事実上の標準になりました。機械学習の最近の歴史を見ると、トレーニング データ (およびある意味ではモデル アーキテクチャ自体) は構造化されなくなり、より一般的なものになっていることがわかります。以前は、モデルは主に表形式のデータでトレーニングされていました。今日では、段落のプレーン テキストから何時間ものビデオまで、範囲がはるかに広くなっています。モデル アーキテクチャと ML アプリケーションが進化するにつれて、オブジェクト ストアのステートレスでスキーマレス、そしてその結果としてスケーラブルな性質はますます重要になります。

2. モデルとデータセットの豊富なメタデータ

MinIO オブジェクト ストアの設計上の選択により、パフォーマンスを犠牲にしたり、専用のメタデータ サーバーを使用する必要もなく、すべてのオブジェクトに豊富なスキーマレス メタデータを含めることができます。オブジェクトに追加するメタデータの種類に関しては、想像力だけが唯一の制限となります。ただし、ML 関連のオブジェクトに特に役立つ可能性のあるアイデアをいくつか紹介します。

モデル チェックポイントの場合: 損失関数の値、トレーニングにかかった時間、トレーニングに使用されたデータセット。

データセットの場合:ペアになったインデックス ファイルの名前 (該当する場合)、データセット カテゴリ (トレーニング、検証、テスト)、データセットの形式に関する情報。

このような非常に説明的なメタデータは、数十億のオブジェクトにわたってこのメタデータを効率的にインデックスしてクエリする機能と組み合わせると特に強力になります。 MinIO エンタープライズ カタログたとえば、「テスト済み」のタグが付けられたモデル チェックポイントや、特定のデータセットでトレーニングされたチェックポイントをクエリできます。

3. モデルとデータセットは利用可能、監査可能、バージョン管理可能

機械学習モデルとそのデータセットがますます重要な資産になるにつれて、これらの資産をフォールト トレラント、監査可能、バージョン管理可能な方法で保存および管理することが同様に重要になっています。

データセットと、それを基にトレーニングするモデルは、時間、エンジニアリングの努力、そして資金を費やして苦労して得た貴重な資産です。したがって、アプリケーションによるアクセスを妨げない方法で保護する必要があります。MinIO のビットロット チェックや消失訂正符号などのインライン操作と、マルチサイト、アクティブ/アクティブ レプリケーションなどの機能により、これらのオブジェクトの大規模な復元力が確保されます。

特に生成 AI では、提供されている特定のモデルをトレーニングするためにどのデータセットのどのバージョンが使用されたかを把握しておくと、幻覚やその他のモデルの誤動作をデバッグするときに役立ちます。モデルのチェックポイントが適切にバージョン管理されていれば、以前に提供されたチェックポイントのバージョンへの迅速なロールバックを信頼しやすくなります。MinIO オブジェクト ストアを使用すると、すぐにオブジェクトにこれらのメリットを享受できます。

4. 自社所有のサービスインフラストラクチャ

MinIOオブジェクトストアは、基本的に、あなたやあなたの組織が管理するオブジェクトストアです。使用例がプロトタイピング、セキュリティ、規制、または経済目的、制御は共通のスレッドです。したがって、トレーニングされたモデルのチェックポイントがオブジェクト ストアに存在する場合、推論または消費用のモデルを提供するタスクをより細かく制御できます。

前回の投稿では、モデル ファイルをオブジェクト ストアに保存する利点と、PyTorch の TorchServe 推論フレームワークを使用してそれらを直接提供する方法について説明しました。ただし、これは完全にモデルとフレームワークに依存しない戦略です。

しかし、なぜこれが重要なのでしょうか。サードパーティのモデル リポジトリでネットワーク ラグや障害が発生すると、推論用のモデルの提供が遅くなったり、まったく利用できなくなったりする可能性があります。さらに、推論サーバーが拡張され、モデル チェックポイントを定期的に取得する必要がある実稼働環境では、この問題が悪化する可能性があります。最も安全で重要な状況では、可能な限りインターネット経由のサードパーティへの依存を避けるのが最善です。MinIO をプライベートまたはハイブリッド クラウド オブジェクト ストアとして使用すれば、これらの問題を完全に回避できます。

終わりに

これら 4 つの理由は、決してすべてを網羅したリストではありません。開発者や組織は、開発の容易さからフットプリントの超軽量化まで、さまざまな理由から AI ワークロードに MinIO オブジェクト ストレージを使用しています。

この記事の冒頭で、AI 向け高性能オブジェクト ストアの採用の原動力について説明しました。スケーリングの法則が成り立つかどうかに関わらず、組織とその AI ワークロードは常に、利用可能な最高の I/O スループット機能の恩恵を受けることは間違いありません。それに加えて、開発者が使いにくいAPI や「ただ機能する」だけではないソフトウェアを求めることは決してないと確信できます。これらの前提が成り立つ将来においては、高性能オブジェクト ストアが道となります。

これを読んでいるアーキテクトやエンジニアリングの意思決定者にとって、ここで紹介したベスト プラクティスの多くは自動化でき、オブジェクト ストレージを活用して AI/ML ワークフローをよりシンプルかつスケーラブルにすることができます。これは、最新の MLOps ツール セットのいずれかを使用することで実現できます。AI/ML SME の Keith Pijanowski は、これらのツールの多くを調査しました。MLOps ツールの詳細については、ブログ サイトで Kubeflow、MLflow、MLRun を検索してください。ただし、これらの MLOps ツールが組織にとって選択肢になく、すぐに開始する必要がある場合は、この投稿で紹介した手法が、MinIO で AI/ML ワークフローの管理を開始するのに最適な方法です。

開発者（または興味のある人）向けに、今後のブログ投稿では、制限のないトレーニング データと適切な GPU 使用率を目標に、オブジェクト ストアを活用するために ML フレームワークを適応させるエンドツーエンドのウォークスルーを実施します。

読んでいただきありがとうございます。参考になれば幸いです。いつものように、ご質問があれば、 Slackチャンネルまたは、こんにちは。