AI/ML データレイクのリファレンスアーキテクチャを構築するためのアーキテクトガイド

この投稿の短縮版は、2024 年 3 月 19 日に The New Stack に掲載されました。 エンタープライズ AI には、識別型と生成型の 2 つの主なモデルがあります。識別型モデルはデータの分類や予測に使用され、生成型モデルは新しいデータの作成に使用されます。最近は生成型 AI がニュースで取り上げられることが多くなりましたが、組織は依然として両方のタイプの AI を追求しています。識別型 AI は、より効率的に業務を行い、追加の収益源を追求したい組織にとって、依然として重要な取り組みです。これらの異なるタイプの AI には多くの共通点がありますが、同時に、AI データ インフラストラクチャを構築するときに考慮しなければならない大きな違いもあります。 組織は、ビジネス インテリジェンス、データ分析、データ サイエンスなどのワークロードを放置したまま、AI 専用のインフラストラクチャと AI のみを構築すべきではありません。ビジネス インテリジェンス、データ分析、データ サイエンス、識別 AI、生成 AI など、組織のすべてのニーズをサポートする完全なデータ インフラストラクチャを構築することは可能です。 別の投稿では、ビジネス インテリジェンス、データ分析、データ サイエンス、AI/ML のニーズに対応できる最新のデータレイクのリファレンス アーキテクチャを紹介しました。最新のデータレイク リファレンス アーキテクチャを確認し、AI/ML ワークロードをサポートするための機能について説明します。 現代のデータレイク まず、リファレンス アーキテクチャの基礎となるモダン データレイクを定義することから始めましょう。このアーキテクチャは「リサイクル」されたものではなく、広く適用可能なエンジニアリングの基本原則を反映しています。モダン データレイクは、半分がデータ ウェアハウスで半分がデータ レイクであり、すべての用途にオブジェクト ストレージを使用します。オブジェクト ストレージは非構造化データ用であり、データ レイクは非構造化データを格納することを意図しているため、データ レイクにオブジェクト ストレージを使用することは理にかなっています。ただし、データ ウェアハウスにオブジェクト ストレージを使用するのは奇妙に聞こえるかもしれませんが、このように構築されたデータ ウェアハウスは、次世代のデータ ウェアハウスを表しています。これは、Netflix、Uber、および Databricks によって作成された Open Table Format Specifications (OTF) によって可能になり、データ ウェアハウス内でオブジェクト ストレージをシームレスに使用できるようになります。 OTF は、Apache Iceberg、Apache Hudi、Delta Lake です。これらはそれぞれ Netflix、Uber、Databricks によって作成されました。これは、市場にはそれらのデータ ニーズに対応できる製品がなかったためです。基本的に、これらはすべて (さまざまな方法で)、オブジェクト ストレージ (MinIO) 上に構築できるデータ ウェアハウスを定義します。オブジェクト ストレージは、他のストレージ ソリューションでは実現できない、スケーラブルな容量と高パフォーマンスの組み合わせを提供します。これらは最新の仕様であるため、パーティション進化、スキーマ進化、ゼロ コピー ブランチなど、従来のデータ ウェアハウスにはない高度な機能を備えています。最後に、データ ウェアハウスはオブジェクト ストレージを使用して構築されるため、この同じオブジェクト ストアを画像、ビデオ ファイル、オーディオ ファイル、ドキュメントなどの非構造化データに使用できます。 非構造化データは通常、業界でデータ レイクと呼ばれる場所に保存されます。データ レイクとデータ ウェアハウスの両方の基盤としてオブジェクト ストアを使用すると、すべてのデータを保持できるソリューションが実現します。構造化ストレージは OTF ベースのデータ ウェアハウスに存在し、非構造化ストレージはデータ レイクに存在します。MinIO の同じインスタンスを両方に使用できます。 MinIO では、OTF ベースのデータ ウェアハウスとデータ レイクのこの組み合わせをモダン データレイクと呼んでおり、これをすべての AI/ML ワークロードの基盤と見なしています。ここでデータが収集、保存、処理、変換されます。識別 AI (教師あり学習、教師なし学習、強化学習) を使用したモデルのトレーニングには、多くの場合、データ ウェアハウスに格納できる構造化データを処理できるストレージ ソリューションが必要です。一方、大規模言語モデル (LLM) をトレーニングする場合は、データ レイクで未加工の形式と処理済みの形式の非構造化データまたはドキュメントを管理する必要があります。 ： ソース 最新のデータレイクリファレンスアーキテクチャ この投稿では、さまざまな AI/ML ワークロードをサポートする AI/ML 向けモダン データレイク リファレンス アーキテクチャの領域に焦点を当てています。これらの機能領域を以下に示します。モダン データレイクの視覚的な描写は上記に示されています。これらの機能領域が見つかるレイヤーは強調表示されています。 識別AI 非構造化データのストレージ 半構造化データの保存 データ ウェアハウスにおけるゼロ コピー ブランチ 生成AI ベクターデータベースを使用したカスタムコーパスの構築 ドキュメントパイプラインの構築 検索拡張生成 (RAG) 大規模言語モデルの微調整 LLM の精度の測定 機械学習オペレーション この投稿では、GPU の現状とそれが AI データ インフラストラクチャに与える影響についても説明します。また、インフラストラクチャの構築方法と構築しない方法を示すシナリオをいくつか紹介します。最後に、独自の AI データ インフラストラクチャを構築するための推奨事項をいくつか紹介します。 GPUの現状 GPU の過剰使用問題 オブジェクトストレージの強化 二つの組織の物語 AIデータインフラストラクチャを構築するための計画 識別AI 識別的 AI モデルのトレーニングには、あらゆる種類のデータが必要です。画像分類や音声認識のモデルでは、画像や音声ファイルなどの非構造化データを使用します。一方、不正検出や医療診断のモデルでは、構造化データに基づいて予測を行います。識別的 AI に必要なデータを保存および操作するために、Modern Datalake 内で利用できるオプションを見てみましょう。 非構造化データのストレージ 非構造化データはデータ レイクに保存され、モデルのトレーニングとテストに使用できます。メモリに収まるトレーニング セットは、トレーニング前 (エポック ループの開始前) に読み込むことができます。ただし、トレーニング セットが大きくてメモリに収まらない場合は、トレーニング前にオブジェクトのリストを読み込み、エポック ループで各バッチを処理するときに実際のオブジェクトを取得する必要があります。高速ネットワークと高速ディスク ドライブを使用してデータ レイクを構築しないと、データ レイクに負担がかかる可能性があります。メモリに収まらないデータを使用してモデルをトレーニングする場合は、100 GB ネットワークと NVMe ドライブを使用してデータ レイクを構築することを検討してください。 半構造化データの保存 Modern Datalake には、Parquet ファイル、AVRO ファイル、JSON ファイル、さらには CSV ファイルなどの半構造化ファイルを保存するためのオプションがいくつかあります。最も簡単な方法は、それらを Data Lake に保存し、非構造化オブジェクトをロードするのと同じ方法でロードすることです。これらの半構造化ファイルのデータが、Modern Datalake がサポートする他のワークロード (ビジネス インテリジェンス、データ分析、データ サイエンス) で必要ない場合は、これが最適なオプションです。 もう1つのオプションは、これらのファイルをデータウェアハウスにロードして、他のワークロードで使用できるようにすることです。データがデータウェアハウスにロードされると、 あなたのデータを使って。 実験を行うためのゼロコピー分岐 データ ウェアハウスにおけるゼロ コピー ブランチ 特徴エンジニアリングは、モデルのトレーニングに使用されるデータセットを改善する手法です。OTF ベースのデータ ウェアハウスが備えている非常に優れた機能は、ゼロ コピー ブランチです。これにより、Git リポジトリ内でコードをブランチするのと同じ方法でデータをブランチできます。名前が示すように、この機能はデータのコピーを作成しません。むしろ、データ ウェアハウスの実装に使用されるオープン テーブル形式のメタデータ レイヤーを使用して、データの一意のコピーの外観を作成します。データ サイエンティストはブランチで実験を行うことができます。実験が成功した場合は、そのブランチをメイン ブランチにマージして、他のデータ サイエンティストが使用できるようにします。実験が成功しなかった場合は、ブランチを削除できます。 生成AI Scikit-Learn で構築された小さなモデル、PyTorch または TensorFlow で構築されたカスタム ニューラル ネットワーク、Transformer アーキテクチャに基づく大規模言語モデルなど、すべてのモデルは入力として数値を必要とし、出力として数値を生成します。この単純な事実により、単語を数値 (または後で説明するようにベクトル) に変換する必要がある生成 AI に関心がある場合、AI/ML インフラストラクチャにいくつかの追加要件が課せられます。LLM によって生成された回答を強化するために、会社の独自の知識を含むプライベート ドキュメントを使用する場合、生成 AI ソリューションはさらに複雑になります。この強化は、検索拡張生成または LLM 微調整の形式になる場合があります。 このセクションでは、これらすべてのテクニック (単語を数字に変換する、RAG、微調整) と、それらが AI インフラストラクチャに与える影響について説明します。まず、カスタム コーパスの構築方法と、その配置場所について説明します。 ベクターデータベースを使用したカスタムコーパスの作成 Generative AI に真剣に取り組むなら、カスタム コーパスで組織を定義する必要があります。カスタム コーパスには、他の誰も知らない知識を含むドキュメントと、真実で正確な情報のみが含まれている必要があります。さらに、カスタム コーパスはベクター データベースを使用して構築する必要があります。ベクター データベースは、ドキュメントを数値表現したベクター埋め込みとともにインデックスを作成し、保存し、ドキュメントへのアクセスを提供します (これにより、上記の数値の問題が解決されます)。 ベクター データベースはセマンティック検索を容易にします。これを行うには、多くの数学的背景が必要で複雑です。ただし、セマンティック検索は概念的には理解しやすいものです。たとえば、「人工知能」に関連するあらゆることを論じているすべてのドキュメントを検索したいとします。従来のデータベースでこれを行うには、「人工知能」のあらゆる略語、同義語、関連用語を検索する必要があります。クエリは次のようになります。 SELECT snippet FROM MyCorpusTable WHERE (text like '%artificial intelligence%' OR text like '%ai%' OR text like '%machine learning%' OR text like '%ml%' OR ... and on and on ... 手動による類似性検索は面倒でエラーが発生しやすいだけでなく、検索自体も非常に低速です。ベクター データベースは、以下のようなリクエストを受け取り、より高速かつ正確にクエリを実行できます。検索拡張生成を使用する場合は、セマンティック クエリを迅速かつ正確に実行できることが重要です。 { Get { MyCorpusTable(nearText: {concepts: ["artificial intelligence"]}) {snippet} } } カスタム コーパスに関するもう 1 つの重要な考慮事項は、セキュリティです。ドキュメントへのアクセスは、元のドキュメントのアクセス制限に従う必要があります (インターン生が、まだウォール街に公開されていない CFO の財務結果にアクセスできれば、それは残念なことです)。ベクター データベース内では、元のコンテンツのアクセス レベルに一致するように認証を設定する必要があります。これは、ベクター データベースを組織の ID およびアクセス管理ソリューションと統合することで実行できます。 ベクター データベースは本質的に非構造化データを保存します。そのため、ストレージ ソリューションとしてデータ レイクを使用する必要があります。 ドキュメントパイプラインの構築 残念ながら、ほとんどの組織には、クリーンで正確なドキュメントを保管する単一のリポジトリがありません。むしろ、ドキュメントはさまざまなチーム ポータルにさまざまな形式で組織全体に分散しています。したがって、カスタム コーパスを構築する最初のステップは、Generative AI での使用が承認されたドキュメントのみを取得してベクター データベースに配置するパイプラインを構築することです。大規模なグローバル組織の場合、これは Generative AI ソリューションの最も難しいタスクになる可能性があります。チームがポータルにドラフト形式のドキュメントを持っていることはよくあります。また、何が可能かについてのランダムな思索であるドキュメントもあるかもしれません。これらのドキュメントはビジネスを正確に表していないため、カスタム コーパスの一部にすべきではありません。残念ながら、これらのドキュメントのフィルタリングは手作業になります。 ドキュメント パイプラインは、ドキュメントをテキストに変換する必要もあります。幸い、一般的なドキュメント形式の多くに対して、この処理を実行できるオープン ソース ライブラリがいくつかあります。さらに、ドキュメント パイプラインは、ドキュメントをベクター データベースに保存する前に、ドキュメントを小さなセグメントに分割する必要があります。これは、これらのドキュメントが検索拡張生成に使用される場合のプロンプト サイズの制限によるもので、これについては後のセクションで説明します。 大規模言語モデルの微調整 大規模な言語モデルを微調整する場合、カスタム コーパスの情報を使用してもう少しトレーニングします。これは、ドメイン固有の LLM を取得するのに適した方法です。このオプションでは、カスタム コーパスに対して微調整を実行するためにコンピューティングが必要ですが、モデルを最初からトレーニングするほど集中的ではなく、適度な時間枠で完了できます。 ドメインに日常使用では見られない用語が含まれている場合、微調整によって LLM の応答の品質が向上する可能性があります。たとえば、医学研究、環境研究、自然科学に関連するあらゆる文書を使用するプロジェクトでは、微調整のメリットが期待できます。微調整では、文書内の非常に特殊な専門用語をモデルのパラメトリック パラメータに組み込みます。このアプローチを決定する前に、微調整のメリットとデメリットを理解しておく必要があります。 デメリット 微調整にはコンピューティング リソースが必要になります。 説明可能性は不可能です。 コーパスが進化するにつれて、定期的に新しいデータで微調整する必要があります。 幻覚が心配です。 ドキュメントレベルのセキュリティは不可能です。 利点 LLM は、微調整によってカスタム コーパスから得た知識を持ちます。 推論フローは RAG よりも複雑ではありません。 微調整は、LLM にビジネスの言語を教える良い方法ですが、ほとんどの LLM には何十億ものパラメータが含まれており、データがこれらすべてのパラメータに分散されるため、データが薄まります。微調整の最大の欠点は、ドキュメント レベルの承認が不可能なことです。ドキュメントが微調整に使用されると、その情報はモデルの一部になります。ユーザーの承認レベルに基づいてこの情報を制限することはできません。 推論時にカスタム データとパラメトリック データを組み合わせる手法を見てみましょう。 検索拡張生成 (RAG) 検索拡張生成 (RAG) は、質問から始まる技術です。ベクター データベースを使用して質問と追加データを結合し、質問とデータを LLM に渡してコンテンツを作成します。RAG では、質の高いドキュメントのコーパスから関連するテキスト スニペットを送信して LLM を教育するため、トレーニングは必要ありません。 質問応答タスクを使用すると、次のように機能します。ユーザーは、アプリケーションのユーザー インターフェイスで質問をします。アプリケーションは質問 (具体的には質問に含まれる単語) を受け取り、ベクター データベースを使用して、コンテキストに関連するテキスト スニペットを品質の高いドキュメントのコーパスで検索します。これらのスニペットと元の質問は、LLM に送信されます。この質問とスニペット (コンテキスト) のパッケージ全体をプロンプトと呼びます。LLM はこの情報を使用して回答を生成します。これは愚かなことのように思えるかもしれません。回答 (スニペット) がすでにわかっているのに、なぜ LLM を使う必要があるのでしょうか。これはリアルタイムで行われ、目的はテキストを生成すること (リサーチにコピーして貼り付けることができるもの) であることを忘れないでください。カスタム コーパスからの情報を組み込んだテキストを作成するには、LLM が必要です。 これは微調整よりも複雑です。ただし、ドキュメント (またはドキュメント スニペット) は推論時にベクター データベースから選択されるため、ユーザー認証を実装できます。ドキュメント内の情報は、モデルのパラメトリック パラメータの一部になることはありません。RAG の利点と欠点を以下に示します。 デメリット 推論フローはより複雑です。 利点 LLM はカスタム コーパスから直接得た知識を持ちます。 説明可能性は可能です。 微調整は必要ありません。 幻覚は大幅に軽減され、ベクター データベース クエリの結果を調べることで制御できます。 認可を実装できます。 機械学習オペレーション (MLOps) MLOps の重要性をより深く理解するには、モデル作成と従来のアプリケーション開発を比較すると役立ちます。アプリケーションに新しい機能を追加する新しいマイクロサービスの実装などの従来のアプリケーション開発は、仕様の確認から始まります。新しいデータ構造や既存のデータ構造への変更は、最初に設計されます。コーディングが始まったら、データの設計は変更しないでください。次にサービスが実装され、コーディングがこのプロセスの主なアクティビティになります。ユニット テストとエンドツーエンド テストもコーディングされます。これらのテストは、コードに欠陥がなく、仕様を正しく実装していることを証明します。アプリケーション全体をデプロイする前に、CI/CD パイプラインによって自動的に実行できます。 モデルの作成とトレーニングは異なります。生データと必要な予測を理解することが最初のステップです。ML エンジニアは、ニューラル ネットワークを実装したりアルゴリズムを設定したりするためにコードを記述する必要がありますが、コーディングが主なアクティビティではありません。繰り返しの実験が主なアクティビティです。実験中は、データの設計、モデルの設計、および使用されるパラメーターがすべて変更されます。実験のたびに、モデルがトレーニングされたときにどのように実行されたかを示すメトリックが作成されます。また、検証セットとテスト セットに対するモデルのパフォーマンスのメトリックも生成されます。これらのメトリックは、モデルの品質を証明するために使用されます。モデルをアプリケーションに組み込む準備ができたら、パッケージ化してデプロイする必要があります。 MLOps (Machine Learning Operations の略) は、これらの違いに対処することを目的とした一連のプラクティスとツールです。実験の追跡とコラボレーションは MLOP に最も関連のある機能ですが、今日の業界の最新の MLOP ツールはさらに多くの機能を備えています。たとえば、実験用のランタイム環境を提供したり、アプリケーションに統合する準備ができたらモデルをパッケージ化して展開したりできます。以下は、今日の MLOps ツールに含まれる機能のスーパーセットです。このリストには、サポートやデータ統合など、考慮すべきその他の事項も含まれています。 - MLOps の技術と機能は常に進化しています。ツールが継続的に開発および改善されていることを保証する、主要プレーヤーによってサポートされているツールが必要です。 主要プレーヤーからのサポート - 実験では、大量の構造化データと非構造化データが生成されます。理想的には、これをデータ ウェアハウスとデータレイクに保存できます。ただし、多くの MLOps ツールは、最新のデータレイクを生み出したオープン テーブル形式より前から存在していたため、ほとんどのツールでは構造化データ用に別のソリューションを用意しています。 最新のデータレイク統合 - 各実験のデータセット、モデル、ハイパーパラメータ、およびメトリックを追跡します。実験の追跡により、再現性も向上します。 実験の追跡 - チーム メンバーがすべての ML エンジニアが実行したすべての実験の結果を表示できるようにします。 コラボレーションを促進 - 他のプログラミング環境からアクセスできるようにモデルをパッケージ化します。 モデルのパッケージ化 - 組織の正式な環境にモデルをデプロイします。モデルを既存の CI/CD パイプラインに組み込む方法を見つけた場合、これは必要ありません。 モデル サービング - すべてのモデルのすべてのバージョンを維持します。 モデル レジストリ - 一部のツールでは、関数またはモデルをクラスター内で実験を実行するためのコンテナ化されたサービスとしてデプロイできるように、コードに注釈を付けることができる機能が提供されています。 サーバーレス関数 - 一部の MLOps ツールは、完全なエンドツーエンド機能を提供することを目的としており、生データを取得して保存するためのパイプラインを構築できる機能を備えています。すでにデータ パイプラインがある場合、この機能は必要ありません。 データ パイプライン機能 - サーバーレス関数を有向非巡回グラフにオーケストレーションする機能。トレーニング パイプラインのスケジュール設定と実行も可能。 トレーニング パイプライン機能 AI データ インフラストラクチャに対する GPU の影響 チェーンの強さは最も弱いリンクの強さに比例します。AI/ML インフラストラクチャの速度は、最も遅いコンポーネントの速度に比例します。機械学習モデルを GPU でトレーニングする場合、ストレージ ソリューションが弱いリンクになる可能性があります。その結果、「GPU 不足問題」と呼ばれる問題が発生します。GPU 不足問題は、ネットワークまたはストレージ ソリューションがトレーニング ロジックにトレーニング データを十分な速度で提供できず、GPU をフルに活用できない場合に発生します。症状はかなり明白です。GPU を監視すると、GPU がフルに活用されることは決してないことがわかります。トレーニング コードをインストルメント化している場合は、トレーニング時間全体が IO によって占められていることがわかります。 残念ながら、この問題に取り組んでいる人たちにとっては悪い知らせがあります。GPU はますます高速化しています。GPU の現在の状態と、GPU で達成されているいくつかの進歩を見て、今後この問題がさらに悪化する可能性があることを理解しましょう。 GPUの現状 GPUはますます高速化しています。パフォーマンスが向上しているだけでなく、メモリと帯域幅も増加しています。Nvidiaの最新GPUの3つの特徴を見てみましょう。 、 そしてその 。 A100 H100 H200 グラフィックプロセッサ パフォーマンス メモリ メモリ帯域幅 A100 624 テラフロップス 40GB 1,555GB/秒 H100 1,979 TFLOPS 80GB 3.35TB/秒 H200 1,979 TFLOPS 141GB 4.8TB/秒 注: 上記の表では、A100 の PCIe (Peripheral Component Interconnect Express) ソケット ソリューションと、H100 および H200 の SXM (Server PCI Express Module) ソケット ソリューションに一致する統計を使用しています。A100 には SXM 統計は存在しません。パフォーマンスに関しては、浮動小数点 16 Tensor Core 統計が比較に使用されています。 上記の統計に関する比較観察をいくつか挙げると、注目に値します。まず、H100 と H200 のパフォーマンスは同じ (1,979 TFLOPS) で、これは A100 の 3.17 倍です。H100 のメモリは A100 の 2 倍で、メモリ帯域幅も同様に増加しています。これは理にかなっています。そうでなければ、GPU が飢えてしまうからです。H200 は 141 GB という驚異的なメモリを処理でき、そのメモリ帯域幅も他の GPU に比べて比例して増加しています。 これらの統計をそれぞれ詳しく見て、それが機械学習にとって何を意味するのかを説明しましょう。 - テラフロップス (TFLOP) は、1 秒あたり 1 兆 (10^12) の浮動小数点演算です。これは、1 の後に 12 個のゼロが続く数です (1,000,000,000,000)。モデル トレーニング中に発生する浮動小数点演算には、単純なテンソル計算と損失関数 (勾配) に対する 1 次導関数が含まれるため、TFLOP をギガバイト単位の IO 需要と等しくすることは困難です。ただし、相対的な比較は可能です。上記の統計を見ると、1,979 TFLOPS で動作する H100 と H200 は 3 倍高速であることがわかります。他のすべてが追いつくことができれば、データの消費も 3 倍高速になる可能性があります。 パフォーマンス - ビデオ RAM またはグラフィックス RAM とも呼ばれます。GPU メモリはシステムのメイン メモリ (RAM) とは別で、グラフィックス カードによって実行される集中的なグラフィック処理タスクを処理するために特別に設計されています。GPU メモリは、モデルをトレーニングする際のバッチ サイズを決定します。以前は、トレーニング ロジックが CPU から GPU に移動するとバッチ サイズが減少しました。ただし、GPU メモリが容量の点で CPU メモリに追いつくと、GPU トレーニングに使用されるバッチ サイズが増加します。パフォーマンスとメモリ容量が同時に増加すると、結果として、トレーニング データの各ギガバイトが高速に処理されるようになり、リクエストが大きくなります。 GPU メモリ - GPU メモリ帯域幅は、メモリと計算コアを接続する「高速道路」と考えてください。単位時間あたりに転送できるデータ量を決定します。高速道路が広いほど、一定時間内に通過できる車が増えるのと同様に、メモリ帯域幅が広いほど、メモリと GPU の間で移動できるデータ量が増えます。ご覧のとおり、これらの GPU の設計者は、新しいバージョンごとにメモリに比例してメモリ帯域幅を増やしました。そのため、チップの内部データ バスがボトルネックになることはありません。 メモリ帯域幅 モデルトレーニングのためのオブジェクトストレージの強化 GPU不足の問題が発生している場合は、100 GBのネットワークとNVMeドライブの使用を検討してください。 このような構成で MinIO を使用すると、市販の NVMe SSD のノード 32 個だけで、GET で 325 GiB/秒、PUT で 165 GiB/秒を達成しました。 最近のベンチマーク コンピューティングの世界が進化し、 サーバー構成には、500 GB 以上の DRAM が搭載されていることがよくあります。超高密度 NVMe ドライブを搭載した大規模な展開を扱う場合であっても、サーバーの数とそれらのサーバーの DRAM を掛け合わせると、すぐに合計が大きくなり、インスタンスあたり数 TB になることがよくあります。この DRAM プールは、分散共有メモリ プールとして構成でき、大量の IOPS とスループット パフォーマンスを必要とするワークロードに最適です。その結果、Enterprise および Enterprise Lite のお客様がインフラストラクチャを構成してこの共有メモリ プールを活用し、GPU トレーニングなどのコア AI ワークロードのパフォーマンスをさらに向上させながら、完全な永続性を維持できるように、MinIO Cache を構築しました。 DRAMの価格が急落した 二つの組織の物語 最後の思考実験として、AI/ML の取り組みでまったく異なるアプローチをとっている 2 つの組織についてお話ししましょう。組織 1 には「反復的な改善」という文化があります。彼らは、すべての大きな取り組みは、より小さく、より管理しやすいプロジェクトに分割できると考えています。これらの小さなプロジェクトは、それぞれが前のプロジェクトの結果に基づいて、ますます複雑化する問題を解決するようにスケジュールされます。また、彼らは、それぞれがビジネスに価値をもたらすように編成されたこれらの小さなプロジェクトを好みます。彼らは、ビジネスに新しい機能を提供しない、純粋にインフラストラクチャの改善やソフトウェアの最新化を目的としたプロジェクトは、予算を管理する幹部にあまり人気がないことに気付きました。その結果、彼らは、生成 AI の概念実証のために高価なストレージ アプライアンスとコンピューティング クラスターを要求することは、インフラストラクチャの改善と新しいソフトウェア機能を調整する最善の方法ではないことを学びました。むしろ、成長に合わせて拡張できるインフラストラクチャ製品から小規模に開始し、シンプルな AI モデルから始めて MLOP ツールを導入し、既存の DevOps チームや CI/CD パイプラインと連携する方法を模索します。 組織 #2 には「光り輝くオブジェクト」文化があります。最新のアイデアが業界に持ち込まれると、まず最も注目度の高い課題に取り組み、その技術力を実証します。これらのプロジェクトは社内外から非常に注目されていることがわかりました。何かが壊れても、賢い人がいつでもそれを修正できます。 組織 #1 は、メインの e コマース サイトの推奨モデルに取り組みながら、AI データ インフラストラクチャの一部を構築することで、最初のプロジェクトを構成しました。推奨モデルのトレーニングは比較的簡単でした。これは、ファイル共有にすでに存在するデータセットを使用する識別モデルです。ただし、このプロジェクトの最後には、チームは小規模 (ただしスケーラブル) な最新のデータレイクを構築し、MLOP ツールを実装し、モデルのトレーニングと展開に関するベスト プラクティスをいくつか導入しました。モデルは複雑ではありませんが、それでもサイトに多くの効率性をもたらしました。彼らはこれらの肯定的な結果を利用して、生成 AI ソリューションとなる次のプロジェクトの資金を獲得しました。 組織 #2 は、製品に関する顧客の質問に答える e コマース サイトのチャットボットを構築しました。大規模言語モデルはかなり複雑で、チームは微調整や検索拡張生成に精通していなかったため、このプロジェクトのすべてのエンジニア サイクルは、急な学習曲線を迅速に通過することに重点を置いていました。モデルが完成すると、特に目立つものはなく、まずまずの結果が出ました。残念ながら、デプロイするための MLOps ツールがなかったため、プレプロダクション環境とプロダクション環境に手動でサイドロードする必要がありました。これにより、DevOps チームとの間に若干の摩擦が生じました。モデル自体も、プロダクション環境での安定性の問題がいくつかありました。モデルが実行されていたクラスターには、生成 AI ワークロードを処理するのに十分なコンピューティング能力がありませんでした。重大度 1 の呼び出しがいくつかあったため、クラスターが緊急に強化され、LLM がトラフィックの多い状況で失敗しないようにしました。プロジェクト終了後、振り返りにより、AI で成功するにはインフラストラクチャを強化する必要があると判断されました。 AI/ML データ インフラストラクチャを構築するための計画 上記の短いストーリーは、2 つの極端な状況を簡潔に説明したものです。AI モデル (識別的および生成的) の構築は、従来のソフトウェア開発とは大きく異なります。AI/ML の取り組みを計画する際には、この点を考慮する必要があります。下の図は、前のセクションで説明したストーリーを視覚的に表現したものです。これは、AI データ インフラストラクチャ ファーストとモデル ファーストのアプローチを並べて比較したものです。上のストーリーが示すように、インフラストラクチャ ファーストのアプローチの以下の各要素は、独立したプロジェクトである必要はありません。組織は、インフラストラクチャが構築されている間に AI を提供するための創造的な方法を探す必要があります。これは、AI のすべての可能性を理解し、シンプルなものから始めて、徐々に複雑さを増す AI プロジェクトを選択することで実現できます。 結論 この投稿では、企業と協力して AI/ML 向けの最新のデータレイク リファレンス アーキテクチャを構築した当社の経験について概説します。コア コンポーネント、主要な構成要素、さまざまな AI アプローチのトレードオフを特定します。基礎となる要素は、オブジェクト ストア上に構築された最新のデータレイクです。オブジェクト ストアは、数百ペタバイト、多くの場合エクサバイトの規模でパフォーマンスを提供できる必要があります。 このリファレンスアーキテクチャに従うことで、ユーザーはAIとMLを対象としながらも、すべてのOLAPワークロードで同等のパフォーマンスを発揮する、柔軟で拡張可能なデータインフラストラクチャを構築できるようになると期待しています。コンポーネントパーツに関する具体的な推奨事項については、お気軽にお問い合わせください。 。 keith@min.io