[Weibo Live Room] へようこそ。コーヒーの大きな景色を 2 分で概観
この共有には主に次の 5 つの側面が含まれます。
- Alluxio について;
- 企業が AI を実験する際に直面する課題を棚卸しします。
- テクノロジースタックにおける Alluxio の位置。
- モデルのトレーニングとモデルのオンライン シナリオにおける Alluxio のアプリケーション。
- 効果の比較: Alluxio 使用前 VS Alluxio 使用後。
1. Alluxio について
Alluxio - データ オーケストレーション プラットフォーム、高性能データ アクセス レイヤー。
2. 企業が AI を試す際に直面する課題を棚卸しする
1.GPU不足。
2.オンライン モデルは遅いです。
3. GPU 使用率が低い。
3. テクノロジースタックにおける Alluxio の位置
√ Alluxio は永続ストレージ層ではなく、永続ストレージはクラウド上の S3 ストレージ、Ceph、HDFS などの分散ストレージに依存します。
√ Alluxio は、AI 分野の高性能アクセス レイヤーです。
√ Alluxio は、Pytorch と TensorFlow の IO パフォーマンスに多くの最適化を行いました。
√ さらに上には、Ray や MLFlow などの AI/ML オーケストレーション レイヤーがあります。
4. モデル トレーニングおよびモデル オンライン シナリオにおける Alluxio の適用
√ 必要な場所で GPU クラスターを起動します。
√ 既存のデータレイク上に AI/ML を構築します。
√ データのコピーを排除し、コストと複雑さを軽減します。
√ より迅速なモデルの展開と起動を実現します。
5. 効果比較: Alluxio 使用前 VS Alluxio 使用後
√ 使用前: データのロードに費やされた時間が 80% を超え、GPU 使用率が 20% 未満である。
√ 使用後: データ読み込みプロセスにかかる時間が 82% から 1% に短縮され、GPU 使用率が 17% から 93% に増加しました。
上記はコーヒーに関する大規模なスピーチの概要にすぎません。全内容を視聴するにはビデオをクリックしてください。
添付ファイル: ビッグコーヒーによって共有されたテキスト版の全内容は以下でご覧いただけます
1. Alluxio について
モデル トレーニングの人気はますます高まっており、この人気を利用して、AI/ML シナリオでの Alluxio のアプリケーションも共有します。Alluxio や Spark などのエコシステムについてはすでに皆さんよく理解されていると思いますが、さらに詳しく紹介したいと思います Alluxio は、仮想レイヤーとデータ オーケストレーション レイヤーを提供します。また、ストレージから上位コンピューティング エンジンへのアクセス、データ アクセスのパフォーマンス、使いやすさなど、ビッグ データ フレームワークの上流と下流で多くの最適化が行われています。
Alluxio - データ オーケストレーション プラットフォーム、高性能データ アクセス レイヤー。
誕生したプロジェクト:
Alluxio (以前は Tachyon として知られていました) は、もともとカリフォルニア大学バークレー校 AMP 研究室の Apache Spark の姉妹プロジェクトであり、分散テクノロジを使用して外部メモリを統一的に管理し、Apache Spark アプリケーションにメモリ レベルのデータ アクセス アクセラレーションを提供する方法を研究していました。このプロジェクトはLi Haoyuan氏（当時AMP研究室の博士候補生）が主導し、同じ研究室の他の教師や学生も参加した。
Alluxio は当初ビッグデータに焦点を当てていましたが、Spark や Presto などのコンピューティング エンジンと非常に密接に統合されていましたが、2020 年から現在に至るまで、AI シナリオには現在の現状では解決できない多くの問題があることがわかりました。システム フレームワークまたはその組み合わせソリューションはまだ比較的高価であるため、私たちはビッグ データ テクノロジー スタックに取り組んでいる一方で、同時に AI シナリオの最先端テクノロジーの探索も開始しています。誰もが使用できるように提供できる指向のソリューション。今日は、AI シナリオにおいて国内外の企業が直面する課題に基づいて体系的に共有します。
2. 企業が AI を試す際に直面する課題を棚卸しする
1.GPU不足
実際、数年前、クラウド上で GPU を使用する場合でも、IDC (データ ウェアハウス) を構築するために GPU を購入する場合でも、AI インフラストラクチャはより困難であることがわかりました。その理由は、大きく 3 つの状況に分類できます。
1. 多くの企業は GPU を購入できません。
2. 一部の企業が GPU を購入したとしても、その量はそれほど多くなく、ビジネス ニーズを満たすのは困難です。
3. 一部の企業は Alibaba Cloud または Tencent Cloud で GPU を購入できるかもしれませんが、これらの GPU を上位レベルのビジネス用途向けに体系的なコンピューティング プールに形成する方法は比較的困難です。
2. オンラインモデルは遅い
同社の既存のデータ ウェアハウス/ストレージ ソリューションは比較的古く、反復するのが困難です。GPU トレーニング後、モデルを推論クラスターに起動する方法は不可欠なリンクであると同時に、難しいリンクでもあります。
1) 多くのデータ ウェアハウスと基盤となるストレージは、社内では依然として比較的伝統的なストレージ ソリューション (HDFS など) であり、10 年以上前に使用されている可能性があり、現在ストレージ設定を調整するのは困難です。
2) データはクラウド上にあり、現在の制限は深刻で、使用制限が多数あります。
この問題を解決する方法については後で詳しく説明します。
3. GPU 使用率が低い
現在、多くの企業のモデル トレーニング プロセスにおける GPU の使用率は一般に比較的低いです。もちろん、これは Alluxio で解決できる問題ではありません。私たちが目にしたのは、企業データのほとんどがデータ ウェアハウスにあるということです。これらのデータを GPU クラスターにインポートする方法は非常に難しく、多くの課題があります。後ほど、Alluxio が国内外のさまざまなクラウド ベンダーや大企業の間でこの問題をどのように解決するかについても共有します。
上記は主にビジネス上のプレッシャー、またはビジネス上の意思決定のプレッシャーです。これらのプレッシャーは基本的にエンジニアにとって技術的なプレッシャーになります。モデルをより速く開発できるようにするために、実際には次のような期待があります。
1) モデル開発時間の短縮。
2) より頻繁なモデル データの更新。
3) より高い精度とトレーサビリティ。
4) 急速に増大するデータセットに適応する。
技術面に反映されるこれらのプレッシャーは、次の 3 つの点に要約できます。
- 広範なデータコピータスク管理
たとえば、現在のアプリケーションでこのシステムを実行するには、多くの場合、ローカル NAS、NFS システム、またはローカルへのコピーのいずれにデータをコピーするかに関係なく、データ ウェアハウスから GPU トレーニング クラスターにデータをコピーする、いくつかの複雑なデータ コピー タスクが必要になります。データ管理用のディスクはさらに複雑になります。
2. 専用ストレージ
AI シナリオのニーズを満たすためには、比較的高いパフォーマンス要件が求められますが、20 ～ 30 年前、GPU は HPC (ハイ パフォーマンス コンピューティング) とともに開発されたため、当時は一般的に誰もが一連の IB ネットワークがあり、ビジネス開発をサポートする一連の高性能ストレージ (オールフラッシュ) があります。実際、クラウドまたは IDC では、ほとんどの企業がこの問題を解決するのが非常に難しいことがわかります。 /cloud 機能には、モデルのトレーニングやモデルの配布タスクをサポートするために、このような高レベルの専用ストレージを提供する方法がありません。
3. クラウドとインフラストラクチャのコストが制御不能になっている
モデルの開始後、ビジネス規模の成長に伴い、クラウドとインフラストラクチャのコストは非常に制御不能になりやすく、クラウドのコストが 3 年間で 5 倍に増加するなど、多くのシナリオが見られます。普通。
3. テクノロジースタックにおける Alluxio の位置
詳細な技術的な議論に入る前に、AI/ML テクノロジー スタックにおける Alluxio の位置を体系的に紹介しましょう。
まず第一に、Alluxio は永続ストレージ レイヤーではありません。当社の永続ストレージはクラウド上の S3 ストレージ、Ceph、HDFS などの分散ストレージに依存しています。これらはすべて Alluxio の下にあるインターフェイスであり、永続ストレージ レイヤーではありません。 Alluxioと同じコンセプトです。
さらに、Alluxio は AI 分野における高性能アクセス レイヤーです。永続ストレージ レイヤーについては、ほとんどの企業が価格とパフォーマンスの効率性を追求しているため、この効率性は非常に安価なストレージ プールを大量に保存できることを意味します。多くのインターネット メーカーや伝統的な企業では、PB レベル、さらには EB レベルのデータ ボリュームが数百個も存在するのを私たちは見てきたため、永続ストレージとして非常に高価な高性能ストレージのセットを用意することは期待されていません。同時に、トレーニング データはそれほど多くはなく、数十 TB、または 1PB を少し上回る可能性があります。これらのデータを上向きドッキング用の高性能ストレージに保存できれば、はい、ユーザーにとっては、価格は高くなります/パフォーマンス比は非常に低いため、この永続ストレージ層を利用して非常に単純なドッキングを行うか、永続ストレージ層があるので、アーキテクチャを変更せずにデータ ドッキングを直接実行できます。
Pytorch と TensorFlow の IO パフォーマンスには、キャッシュ戦略、スケジュールの最適化と接続方法、Kubernetes のデプロイメントなど、多くの最適化が行われています。
さらに上位には、Ray や MLFlow などの AI/ML オーケストレーション レイヤーがあります。
Alluxio はビッグデータのシナリオから開発された会社なので、これは比較的明確な図です。私たちは AI を約 4 ～ 5 年間取り組んでいます。この 4 ～ 5 年間、私たちは Alluxio を使用してきました。多くの値があります。顧客/ユーザー環境に見られるものは、次の 4 つのポイントに要約できます。
1. より高性能でスケーラブルな AI/ML パイプライン
既存のオブジェクト ストレージや HDFS などの既存のクラスター デプロイメントを変更せず、同時にビジネスを拡大したいと考えています。ここでは実際に 2 つの重要なポイントがあります。
√ 一般に、ビッグ データと AI の 2 つのチームは同じ大規模なアーキテクチャの下にありますが、テクノロジー スタックは実際には大きく異なります。たとえば、ビッグ データ テクノロジー スタックには Spark、Trino、Hive、HBase などが含まれます。ダウンストリームのドッキングは HDFS、クラウド上の一部のオブジェクト ストレージなどです。これらのデータは常にそこにあり、データ量は数百 PB、場合によっては EB レベルになる可能性があります。同時に、AI インフラ プラットフォームを構築する必要があります。テクノロジー スタックは実際には Pytorch と TensorFlow です。次のドッキング そのほとんどは Ceph、MinIO などのオブジェクト ストレージです。その他には、上向きドッキング用の NFS や NAS システムを提供するなど、いくつかの専用ストレージがあります。
√ 実際、これら 2 つのシステムの存在によりドッキングの問題が発生しています。つまり、データはデータ ウェアハウスにありますが、処理は AI インフラ内で行われ、非常に複雑なシステムになります。Alluxio はこの問題を解決するのに役立ちます。このシステムでは、毎回非常に複雑なデータ移行を必要としません。
2. いつでもタイムリーで正確なモデルデータを取得
モデルのデータがトレーニング クラスターから出てくるときは、最初にストレージにドロップしてから、推論クラスターにプルアップする必要があります。このプロセスは、データ パイプラインなど、非常に複雑であることがよくあります。私たちが通信した多くのインターネット企業以前は一時的なチェックポイント ストアがあり、その後は永続的なチェックポイント ストアがあり、低パフォーマンスと高パフォーマンスで相互にプルするのは非常に複雑なプロセスです。
3. 複雑なデータ移行を回避する
4. このモデルのオンライン時間は、オブジェクト ストレージや従来のデータ ウェアハウスのオンライン時間より 2 ～ 4 倍高速です
基盤となるストレージは通常、オブジェクト ストレージまたは従来の HDFS です。たとえば、従来の HDFS は大規模なデータ ストレージ用に設計されています。これはパフォーマンスを目的として設計されていません。ほとんどの場合、フォールト トレランスを確保することを目的としています。同時に、次のことを目的としています。多くのクラウド ベンダーとやり取りした結果、多くの場合、AI サービスをサポートするためにクラウド上のオブジェクト ストレージを直接使用できないことがわかりました。
Alluxio がこのシステムをどのように構築するかについて詳しく話しましょう。その中には多くのシーンがあります。ここでは、Alluxio のアーキテクチャ設計の当初の意図を共有したいと思います。
まず、多くのインターネット ベンダーで、ほとんどの顧客/ユーザーのデータがデータ レイクにある可能性が高く (90 ～ 95%)、そのデータはそのために別のデータ クラスターを使用していないことがわかりました。従来の Hive メタ ストア、一般的なデータ レイクのデータ、直接受信する大量のストリーミング データ データなど、大量のデータが存在し、大量の非構造化データがデータ レイクに保存されます。
では、Alluxio はこれにおいてどのような役割を果たしているのでしょうか?
現在では、Spark または Ray アーキテクチャを使用してデータを前処理し、データ レイクに戻すことがより一般的です。後で、TensorFlow と Pytorch がトレーニングのためにデータをここにプルします。たとえば、左側の図を見てください。 Alluxio を使用してデータを取得しない場合、データに何が問題を引き起こす可能性がありますか?
たとえば、元のデータ ウェアハウスは HDFS クラスターを使用し、AI トレーニングは Ceph クラスターを使用します。
√ まず、処理済み/未処理のデータを Ceph クラスターにプルする必要があり、その後、プルされたデータが上向きに提供されます。ここにはいくつかの問題があります: まず、プルのプロセスは非常に複雑になり、多くの企業は、データ管理システムを独自に開発すると、その中にはさまざまなプロセスがいくつか存在します。
√ 第二に、データを段階的にプルする必要があります。
√ 最後に、データに問題がないかどうかを確認する必要があります。
このプロセスではプルから利用可能になるまでに長い遅延が発生するため、この問題の解決に役立つ Alluxio キャッシュ機能を使用したいと考えています。
まず、データの一部を Alluxio にプリロードし、計算に近いストレージに置くことで、帯域幅の消費を削減できます。同時に、プリロードされたデータがない場合でも、Alluxio のキャッシュ メカニズムは、データをトレーニング クラスターに迅速にプルするのに役立ちます。この方法は株式取引における T+1 (T+0) トランザクションに似ており、最初にデータにアクセスした瞬間から迅速にデータを提供でき、データの転送に数時間待つ必要はありません。データを保存できるため、時間を大幅に節約できます。
第二に、Alluxio は、ユーザーの自己啓発によって引き起こされるデータ ガバナンスの問題も軽減できます。ユーザーがすでにデータガバナンスシステムを導入している場合、ユーザー向けにカスタマイズされた開発を容易にするために、生データを更新するための API を含むさまざまな API も提供します。
さらに、トレーニング クラスターのコストを削減し、効率を向上させる方法にも焦点を当てています。以前は、多くの企業がトレーニングに高性能ストレージ クラスターを使用していましたが、このコストは非常に高価であり、ビジネスの拡大が制限される可能性がありました。GPU 計算ノードのみにディスクが装備されている場合、このコストは通常、GPU クラスターの全体コストと比較して 3 ～ 5% を超えないことがわかりました。さらに、多くの企業は大量のストレージ リソースを持っていますが、これらのリソースをどのように最大限に活用するかは依然として課題です。
Alluxio は、この点に関して多くの統合ポイントを提供します。Alluxio クラスターをトレーニング ノードに直接デプロイでき、消費量はほとんどありません (メモリ約 30 ～ 40GB) が、高パフォーマンスのトレーニング サポートを提供できます。ユーザーは、コンピューティング クラスター全体のコストの 3 ～ 5% を支払うだけで、GPU クラスターを最大限に活用し、IO ボトルネックを克服して 100% の GPU 使用率を達成できます。
トレーニング クラスターに加えて、推論クラスターのコストと効率にも特別な注意を払っています。推論クラスターがスケールするにつれて、コストがトレーニング クラスターよりもはるかに高くなる可能性があります。したがって、私たちはトレーニングによって生成されたモデルをオンライン クラスターに迅速にデプロイする方法の問題を解決することに取り組んでいます。
従来の方法では、トレーニング結果は Ceph ストレージに書き戻され、オンライン クラスターは同じまたは異なる IDC に配置されるため、複雑な管理が必要になります。多くの企業は、クロスドメインまたはクロス IDC の問題を解決するために独自のストレージ ゲートウェイ (ストレージ ゲートウェイ) のセットを開発しますが、そのゲートウェイには、クロスドメインまたはクロス IDC の問題を解決するテーブルの問題がありますが、そうではありません。これは高パフォーマンスかつクロスドメインの問題です。簡単に理解すると、トレーニング クラスターとオンライン ML は接続できますが、AWS のゲートウェイが推論拡張などの推論クラスターを完全にサポートできない場合、 100 ノード、さらには 1000 ノードまでクラスタがオンラインになると、非常にひどいジッターが発生します。別の例: Alluxio は 2 ～ 3 分以内にモデル全体を推論クラスタにデプロイできます。一般に、この種のシステムは、システムの 10 倍の時間がかかりますP95 と P99 は非常に長くなります。
4. モデル トレーニングおよびモデル オンライン シナリオにおける Alluxio の適用
次に、さまざまなシナリオで Alluxio がどのように機能するかを詳しく説明します。
1 つ目は、前に述べた問題です。GPU が非常に不足している場合、私たちが見た企業はこれまでマルチクラウド戦略を持っていませんでした。多くの場合、このような展開を余儀なくされることがわかりました。データが AWS 上にある多くの顧客/ユーザーは、Azure や Google Cloud などの他のクラウドを使いたくないのですが、今年問題が見つかりました。Azure がすべての GPU を購入しました。この場合、実際には困難です。すべてのクラスターは AWS 上にあると言えます。その場合、表示されるクラスターは Azure にある必要があり、AWS に直接アクセスする方法が必要です。データを直接取得すると、この問題によりデータのパフォーマンスが非常に低下します。ネットワーク帯域幅が非常に低い場合、GPU の使用率は通常 10% を超えませんが、より優れたネットワーク (専用線など) の場合は 20 ～ 30% に達することがあります。
2 番目の問題は、マルチクラスターを構築する場合、データの一貫性の確保、これらのデータの更新とプルの方法など、データ管理が非常に複雑であることです。しかし、Alluxio では多くの統合が行われており、Alluxio を直接使用できることです。これらの問題を解決するために。第二に、私たちは誰もがハードウェア ソリューションのセットを購入することを望んでいません。Alluxio に参加する前、私の研究室は HPC を行っていました。HPC の大きな問題は、コストが非常に高いことです。HPC のセットを購入するのは通常、次のとおりです。 10 セットの Hadoop ハードウェア、またはクラウド上のストレージ ハードウェアなので、AI インフラストラクチャ アーキテクチャを構築するために独自のハードウェア セットを購入する必要がある場合、労力は半分で、コストは非常に高価です。私たちは、データ レイク上に AI および ML データ パスを直接構築することでストレージ システムを変更できず、同時に IDMA などの追加のハードウェアを購入することなく既存のものを使用してトレーニング ニーズをサポートできることを期待しています。が私たちのビジョンです。同時に、元のデータ ウェアハウス内のタスクからのデータの分離の問題を考慮する必要はありません (いわゆる分離では、データを移行する必要があり、その後 2 つの非常に独立したシステムが実行されますが、これは非常に問題です)。データのプルと取得）。
上の図は上で述べたものですが、Alluxio が提供する自動データ レイクのロード/アンロード機能やデータ更新機能などの一部の機能は、データ エンジニアリング チームの生産性を向上させることができます。一般的なシナリオは次のとおりです。 add Ceph の場合、基本的なタイムラインは 3 ～ 6 か月に延長されます。外国企業ではタイムラインが 6 か月以上に延長されるのは非常に一般的です。データ パイプライン全体がその中に組み込まれています。ご興味があれば、こちらをご覧ください。Zhihu の適用事例についての詳細. このシステムを構築する方法を説明する非常に詳細な解釈が含まれています。
上の図は、前に述べた別の問題を示しています: モデルの展開は、帯域幅の問題を含む基盤となるストレージによって制限され、IDC のさまざまな場所によっても制限されます。私たちの Alluxio は、どこから来ても、マルチクラウド マルチ アーキテクチャを構築できます。パブリック クラウド プライベート クラウドであっても、異なるパブリック クラウド間のモデル展開であっても、この問題はすぐに解決され、ビジネスの高同時実行をサポートする高同時実行キャッシュ システムを提供します。
要約すると、AI アーキテクチャにおける Alluxio の位置は何でしょうか? Alluxio はどのような問題の解決に役立ちますか?
√ 1 つ目は、変革と適応のコストを削減し、全員がモデル立ち上げのロジックにより集中できるようにすることです。
√ 2つ目は、専用のストレージアーキテクチャを廃止することです。例えば、これまではNASやNFSなどのシステムを利用する必要がありましたが、Alluxioを利用することでその必要がなくなり、既存のHDFSや以下のオブジェクトストレージを利用してAlluxioを構築することができます。 AIプラットフォーム。
√ 3 番目は、GPU 使用率をより高いレベルに高めるためにキャッシュを追加する必要があるということです。
√ 4 つ目は、GPU を自由に導入したいという企業のニーズを満たすことです。クラウド上で購入した GPU であっても、クラウド外で購入した GPU であっても、データがどこにあるかに関係なく、非常に効率的なデータ適応を実現できます。具体的なケースは後で説明します。 。
5. 効果比較: Alluxio 使用前 VS Alluxio 使用後
これは tensor ボードから取り出したデータで、AI インフラを担当する多くのエンジニアがこのシステムを使用すると思います。実際にはクラウド上に比較的大きな問題があることがわかりました。たとえば、S3 Fuse を使用すると、S3 Fuse から直接プルできます。これは、ここ数年で一般的な使用法です。たとえば、ローカル ディスクでは、データをプル アップできます。モデル トレーニングの場合、コピー タスクを実行してローカルに配置するか、Fuse インターフェイスと同様のエクスポージャを使用してデータをローカルにプルし、上向きにサービスを提供します。この方法が使用される場合は、 , DataLoader の割合が非常に高いですはい、AI アーキテクチャをよく理解している場合は、彼の DataLoader は次のように実行します。データをストレージ システムから CPU メモリにプルし、CPU がプリプサシングまたはリサシング処理を実行します。次に、データを CPU メモリに配置し、GPU がそれを処理します。後者の 2 つは、一般に CPU と GPU の比率が比較的妥当であり、メモリの比率も比較的妥当であるため、クラウド上では問題ありません。問題は比較的小さいでしょうが、もともとクラウドストレージ上にあるという事実に基づいて、CPU にプルされる問題があり、DataLoader の最初の段階でパフォーマンスが非常に低下します。非同期プロセスではあるが、パフォーマンスが要求されます。前のステップの完了を待ちます。DataLoader 比率が 80% 以上を占めることがわかり、GPU 使用率はわずか約 17% です。これは、非常に標準的なベンチマークである Resnt-50 で測定されます。
Alluxio 導入後、DataLoader の時間は 1% 未満に低下し、GPU の使用率は 93% に向上しました。もちろん、これ以上上がらないわけではありませんが、実際には GPU の使用率は 93% に向上しました。一方では IO によって制限され、他方では CPU のパフォーマンスによっても制限されるため、これは非常に高い使用率になります。
さらに、最近では「Alluxio Assisted Model Training Plan」など、AI シーンでいくつかのプロジェクトを立ち上げており、実際、すでに多くの大規模モデルが Alluxio 上で実行されており、Alluxio を高性能データ アクセス レイヤーとして使用しています。 2023 年 7 月 1 日から 9 月 30 日までの期間中、大規模なモデル トレーニングやより一般的なダイナミック モード トレーニングの構築に役立つ、3 か月間のプロフェッショナル チーム 1V1 テクニカル サポートを受けることができる登録プランも公開されます。シーン。
著者について
Alluxio の辛口記事、人気のイベント、専門家の共有について詳しく知りたい場合は、クリックして[Alluxio Think Tank]に入ってください。
