建築家または建築家を目指す人が知っておくべき事柄を毎月まとめた概要です。
プロフェッショナルソフトウェア開発における知識とイノベーションの普及を促進
Git は、ソフトウェア開発におけるバージョン管理によく使われるツールです。複数の Git アカウントを使用することは珍しくありません。Git アカウントを正しく構成して切り替えることは困難です。この記事では、Git が提供するアカウント構成とその制限、およびプロジェクトの親ディレクトリの場所に基づいてアカウントを自動的に切り替えるソリューションについて説明します。
WebAssembly は、その範囲をブラウザからクラウドやエッジ コンピューティングなどの他のドメインにまで拡大しました。WebAssembly は、WebAssembly コンポーネント モデル (WCM) を使用して、Rust、Python、JavaScript などのさまざまなプログラミング言語のライブラリ間のシームレスな相互作用を可能にし、真の多言語プログラミング環境を推進します。
Jules Damji は、分散型の微調整とトレーニングにどのインフラストラクチャを使用すべきか、ML ワークロードを拡張する方法、大規模なモデルに対応する方法、CPU と GPU をどのように活用できるかについて説明します。
このポッドキャストでは、Culture & Methods の主任編集者である Shane Hastie が、開発者関係の役割とオープンソース コミュニティへの貢献について Craig Box に話を聞きました。
Ranjith Kumar は、グローバルな容量を持つサービス所有者に提示される抽象化と保証、数十の地域にわたるワークロードを管理するための設計と実装、さまざまな需要の分類とモデル化、さまざまな地域間で需要をシフトすることによるグローバルな容量管理の実現について説明します。
ソフトウェア開発の意思決定をレベルアップするための変革的な洞察を発見してください。限定オファーにはコード LIMITEDOFFERIDSBOSTON24 を使用してください。
上級開発者から実践的なアドバイスを得て、現在の開発課題を解決しましょう。限定オファーにはコード LIMITEDOFFERIDSMUNICH24 を使用してください。
注目すべき新たなトレンドを発見して、ソフトウェア スキルをレベルアップしましょう。今すぐ登録してください。
すべてのプロフェッショナルが知っておくべきすべてのトピック、テクノロジー、テクニックに関する月刊ガイド。無料で購読できます。
InfoQ ホームページ プレゼンテーション 大規模な AI/ML/LLM ワークロードをスケーリングするための最新のコンピューティング スタック
Jules Damji は、分散型の微調整とトレーニングにどのインフラストラクチャを使用すべきか、ML ワークロードを拡張する方法、大規模なモデルに対応する方法、CPU と GPU をどのように活用できるかについて説明します。
Jules S. Damji 氏は、Anyscale Inc の主任開発者アドボケートであり、MLflow の貢献者であり、『Learning Spark, 2nd Edition』の共著者です。同氏は 25 年以上の経験を持つ実践的な開発者であり、Sun Microsystems、Netscape、@Home、Opsware/LoudCloud、VeriSign、ProQuest、Hortonworks、Databricks などの大手企業で働き、大規模な分散システムを構築してきました。
ソフトウェアは世界を変えています。QCon は、開発者コミュニティにおける知識とイノベーションの普及を促進することで、ソフトウェア開発を強化します。実践者主導のカンファレンスである QCon は、チームのイノベーションに影響を与える技術チーム リーダー、アーキテクト、エンジニアリング ディレクター、プロジェクト マネージャー向けに設計されています。
Damji: では、近年の ML、AI、LLM スタックがどのように登場してきたかについてお話ししましょう。Scoutbee の Nischal はデータ スタックについて、また、従来の機械学習の方法から LLM が存在する今日に至るまでの、出現し進化する機械学習スタックについてもお話ししました。ML のコースに参加しても、LLM と ChatGPT について触れないわけにはいきません。この用語が進化し、長い時間をかけて広く使われるようになったことはよくわかります。約 1 か月半前、私は 21 歳の誕生日を祝い、ホールフーズ マーケットに行って大量の肉を買いました。ラムチョップ、フィレ ミニヨン、リブアイなど、50 ポンドほどの肉を買いました。袋は 12 袋ほどありました。レジに行き、それらをベルトコンベアに置きました。レジ係は私を見て微笑みながら、「バーベキューでもやるんですか?」と言いました。私は「はい、今週末はバーベキューを主催するんです」と答えました。彼女は振り返り、苦笑いしながら「バーベキューのおいしいレシピは ChatGPT に聞いてみて」と言いました。それがこんなにも広く使われる言葉になっているのだと、私は気づきました。
私は Anyscale のリード デベロッパーで、オープン ソース プロダクトの Ray チームの一員です。それ以前は、Databricks に 6 年近く在籍していました。Apache Spark、MLflow に貢献し、「Learning Spark」の主要著者でもあります。それ以前は Hortonworks に在籍し、Hortonworks の取り組みをリードしていました。3 頭の象、Hadoop を使ったことがある人はいますか? アドボカシーの道に進み、デベロッパーと協力し、スタンド アンド デリバーする道に進む前に、私は Sun Microsystems で 10 年ほど非常に内向的なソフトウェア エンジニアとして働き、その後 Netscape に移りました。その後、@Home にいました。@Home は、実際にケーブル モデムを導入した最初の会社です。皆さんの中にもケーブル モデムを使っていた方がいますが、実は @Home から来たものです。その後、Loudcloud と Opsware に移りました。この会社は、AWS が発明される前に、実際にクラウド コンピューティングを行っていました。その後 Verisign に移りました。私は幸運にも恵まれ、恵まれた立場にあり、いくつかの企業が実際にどのように変化を遂げたかを観察するのにちょうど良いタイミングでした。そして現在、私たちはLLMという新たな進化の真っただ中にいるのです。
私は Anyscale という会社で働いています。私たちは Ray のオリジナル開発者です。Ray は、分散コンピューティングを可能にする統合汎用フレームワークです。Ray は、カリフォルニア大学バークレー校の AMPLab という他の研究室の出現から発展しました。AMP は、アルゴリズム、マシン、人の頭文字です。Spark、Mesos、Caffe もここから生まれました。次に登場したのは RISELab で、Ray はここから生まれました。Anyscale は、Ray を実際に開発した最初の人たちです。私たちが実際にやりたいこと、Anyscale が実際に行っていることの背後にある全体的な考え方は、スケーラブルなコンピューティングを提供することです。私たちは、Ray を中核とするマネージド サービス用のスケーラブルなコンピューティングであり、これらすべての LLM ベースのアプリケーションを作成するための最適なプラットフォームを提供します。なぜ私たちがそれを行うのか? 機械学習がどのように進化し、データがどのように大きくなり、マシン モデルがどのように大きくなっているかというトレンドを追ってきたなら、スケーリングは必須であり、例外ではありません。最近では標準です。私たちは、スケーリングが難しくなく、簡単であることを保証し、Python プログラマーであれば誰でも、通常の Python プログラムを作成するのと同じように分散アプリケーションを作成できるようにしたいと考えています。
まず、既存の機械学習スタックの課題についてお話しします。Lighthouse ユーザーと協力した結果、実際に直面している課題や、ML ワークロードの最新状況が日々変化していることを考えると、インフラストラクチャの管理に問題があるかどうかについて、引き続き話を聞くことができました。Ray とは何か、なぜ Ray なのか、AI ライブラリがそれをスタックの一部としてどのように役立つかについて、簡単に説明します。特に、この ML スタックの非常に重要な部分である 2 つのライブラリ、Ray Data と Ray Train に焦点を当てます。次に、LLM を微調整するための新しい最新のスタックが大きな役割を果たしていること、そして Ray ライブラリが実際にこれにどのように適合するかについて説明します。次に、スタックについてお話ししたこと、スタックの重要なコンポーネントを使用して、6 ギガバイトの GPT モデルを実際に微調整する方法を紹介します。うまくいけば、私がやったことは、モデルを先に実行し、ライブで実行する部分をいくつか持つことでした。
既存のモデルの課題についてお話しします。私たちは ML ユーザーとかなり長い間一緒に仕事をしてきましたが、彼らからよく聞くのは、「トレーニングに時間がかかりすぎます。データが大きすぎて 1 台のマシンに収まりきりません。モデルは大きくなり、1 台のマシンに収まりきらないので、特定のモデルを分割する必要があります」というものです。既存のインフラストラクチャは、すべてが急速に変化しているため、すぐに時代遅れになり、常に更新するという泥沼にはまっています。実際にユーザーと話をすると、これらの課題や問題はどのように現れるのでしょうか。これらの課題や懸念、不満の一部は、Ray の旅を経験し、Ray サミットで Ray に移行することを決めた多くのユーザーからかなり多く聞かれました。今日の機械学習の課題の 1 つは、開発から実稼働規模に移行する方法です。これは、実際に機械学習を行っているほとんどの人が知っている、非常に小さな例です。左側には、実際に前処理に使用している Apache Spark があります。ETL からデータを取得して、いくつかの処理を行うか、大規模な前処理を行います。それが完了すると、その特定のクリーン データがトレーニング モデルに入力されます。このトレーニング関数は、Horovod を使用した TensorFlow であるため、すべてのトレーニング関数を複数のクラスターに分散できます。それが完了すると、事前トレーニング データから評価データを取得し、モデルをモデル ストアに配置して、評価を実行します。これも分散されます。これをどのようにオーケストレーションしますか? Airflow などを使用します。あちこちに、実際には 3 つのカスタム システムがあります。管理、監視、保守について心配する必要があります。これは、時間が経つにつれて少し難しくなります。なぜなら、これが開発環境である場合、これらすべてをラップトップに実際に配置できると想像してください。これは実際にユーザーから聞かれ続けた大きな問題でした。開発から本番スケールへの移行が困難であるということでした。このインフラストラクチャが一致しないため、マシンに SSH で接続する必要がありました。ステージング環境のようなものがありました。本番環境を複製し、実際にテストで実行して戻す、などといった作業を繰り返していました。これが最初の課題でした。開発者の速度が非常に遅いことでした。開発者がそれを行うには多くの時間がかかりました。インフラストラクチャの管理に気を配る必要がありました。
2 つ目の課題は、ご存知のとおり、ML 分野や AI 分野は急速に進化し、急速に変化しているため、インフラストラクチャが古くなることです。インフラストラクチャが古くなるのは、実際に構築する場合、JAX などの最先端の機械学習フレームワークを使用したい場合や、Alpa と呼ばれる別の機械学習を使用したい場合です。インフラストラクチャにはそれが含まれていません。なぜでしょうか。それは、そのためのプロビジョニングを行っていないためです。この時点でインフラストラクチャが古くなるのです。実際に使用したいフレームワークではなく、機械学習を既存のインフラストラクチャに組み込む必要があります。マンネリ化します。ハムスターが車輪の上を走るのと同じように、新しいフレームワークに対応するためだけにインフラストラクチャを絶えず更新することになります。これは、特に最高かつ最新のフレームワークの使用に集中したい小規模企業にとって大きな負担になります。これが起こるのは、実際にこれらの非常に優れた問題を何らかの方法で分析する必要がある場合、問題の推論の連鎖が発生することです。最初の問題は、データ サイエンティストにとって、機械学習のコードについて心配する必要がないため、スケーリングが難しいことです。インフラストラクチャについて心配する必要はありません。彼らが気にしたいのは、ML モデルを書いてビジネスを進めることだけです。その根拠は、スケーリングを提供してくれる特注のソリューションや Windows ソリューションを使用すれば、その心配をしなくて済むということです。ここで問題となるのは、ソリューションが 1 つの特定のフレームワーク、または 1 つまたは 2 つのフレームワークに限定されている場合、新しいフレームワークが登場すると、その更新を待たなければならないことです。長年確立されたプラットフォームのこのサイクルでは、必要な開発速度が得られません。柔軟性が制限されます。では、独自のインフラストラクチャを構築したらどうか、ベンダーに依存したくないのだから、自分で構築したらどうか、と主張するかもしれません。実際にこのカスタム インフラストラクチャを構築したいと考えているほとんどの企業にとって、幅広さと深さを兼ね備えた T 字型の組織がないため、少し難しい場合があります。それを実現するには、インフラストラクチャを構築する長いサイクルが必要になります。これにより、実際に必要な最新かつ最高の機械学習ライブラリをすべてサポートする 1 つのフレームワークを持つ理由と正当性の根本原因分析が得られます。インフラストラクチャをこの特定のフレームワークによって自動的に管理できるようにする必要があります。
実際にこれらの問題を解決するにはどうすればよいでしょうか。先ほど述べたように、規模の恩恵に対処する必要があります。今日、モデルはますます大きくなっています。規模の恩恵に対処できるようにする必要があります。特定のフレームワークを使用している場合は、開発者の速度が向上するようにする必要があります。インフラストラクチャの管理については考えないでください。インフラストラクチャの管理は、基盤となるフレームワークまたは基盤となるライブラリ、つまり基盤となるインフラストラクチャによって処理される必要があります。データの取り込み、トレーニングとチューニング、サービス提供、バッチ推論などを含むエンドツーエンドの機械学習パイプラインを実行できるようにする必要があります。私たちが実際に取り上げたのは、シンプルさと規模の恩恵と呼んでいるものです。これを類推で表現すると、2010 年頃の古き良き時代は、物事はシンプルで、規模も小さかったです。機械学習の線形回帰や、実際に使用するアルゴリズムをすべて scikit-learn で記述できました。実際に必要な機械学習ファイルをラップトップにダウンロードします。ノートパソコンでモデルを構築し、テストすれば完了です。すべてが 1 つのモデルに収まります。現在の状況では、これは機能しません。まったく機能しません。なぜでしょうか? データが大きすぎるからです。なぜでしょうか? モデルが大きすぎるからです。なぜでしょうか? マシンが小さいため、スケール アウトする必要があるからです。
私たちが本当に望んでいるのは、昨日のシンプルさと今日のスケールの恩恵を切望することです。私たちが望んでいるのは、機械学習アプリケーション全体を 1 つのファイルまたは 1 つの Python で記述できるシンプルさとスケールです。これには他のファイルも含まれますが、すべてが自己完結的です。特定のファイル内ですべての前処理を実行できるようにする必要があります。そのために別のフレームワークは必要ありません。前処理は、Delta Lake にデータを置くことで実行できます。Snowflake にデータを置くこともできます。ディスクや parquet ファイルにデータを置くこともできます。特定のフレームワーク内で実行できます。また、この特定のフレームワークがサポートする最新のトレーニング フレームワークを使用して、実際に使用することもできます。Hugging Face を使用する場合でも、トランスフォーマーを使用する場合でも、TensorFlow、PyTorch、PyTorch Lightning を使用する場合でもかまいません。実際にすべてを内部でトレーニングできるようにする必要があります。機械学習フレームワークが利用可能になるまで待つ必要はありません。それは、この特定の既存のフレームワークの一部であるべきであり、この特定のフレームワーク内でスコアと評価を行うことができます。私の主張は、もちろん独断的なものですが、Ray と Ray ライブラリは、フレームワーク内でこれらすべてのことを実行できる特定のシンプルなアプリケーションを提供します。これにより、将来的に「これはかなり優れたフレームワークです」と言えるようになります。この最先端のすべてをサポートしていますが、明日 JAX を使用したい場合や明日 Alpa を使用したい場合、それを実行するにはどれくらいの時間がかかりますか? 私たちは、実際に最先端のものを要求する新しいフレームワークがあれば、それを統合して実際に使用できるようにすることをコミュニティに確約しています。そのため、6 か月や 1 年待つ必要はありません。次のリリースで利用可能になります。私の主張は、明らかに独断的なものですが、Ray は実際にそれを実行でき、Ray ライブラリを組み合わせることで、単一のシンプルさとスケールの恩恵が得られる、と私は主張します。
課題についてお話ししましたが、1つは、機械学習の実用化が難しいという単純な理由です。インフラストラクチャが複雑になりすぎるからです。データ サイエンティストはインフラストラクチャの管理など気にしなくてよく、コードの作成と最先端の技術の使用にしか関心がありません。2つ目に、機械学習インフラストラクチャは時代遅れになります。最新の情報を入手するには、非常に簡単で将来性のあるものが必要です。Rayとは何かについて説明し、次にスタックの次のレイヤーに移ります。1つお伝えしたいのは、Rayは特定のワークロードをスケーリングできるシンプルな汎用ライブラリだということです。そのワークロードは、Pythonアプリケーション、機械学習ワークロード、LLMワークロード、バッチ推論などです。特定の規模で実際に配布したいものが何であれ、このライブラリ、Rayはそれを実現するための基本機能を提供します。すぐに使えるライブラリが用意されており、データの取り込み、スケーリング、サービング、ハイパーパラメータの調整、トレーニングも行えます。ラップトップで実行できます。 pip install Ray を実行するだけで、実際に搭載されている 10 個のコアを搭載したラップトップで Ray を実行し、実際に収まる適切な量のデータで実行できるはずです。
これは、私が何らかの形で皆さんに注目してもらいたい機能と能力の階層化されたケーキです。その特定のレイヤー、その特定のスタックを確認する必要がある場合、クラウド プロバイダーがあります。1 つ上のレイヤーに進むと、Ray Core 抽象化、つまりタスク、アクター、および将来のオブジェクトに到達します。タスクは、Python を取得してクラスター全体に配布できる実行単位です。アクターは、Python クラスを取得してステートフル サービスとして作成し、クラスター全体に展開できるステートフル タスクまたはステートフル クラスです。オブジェクトは、将来として実現できる分散オブジェクトです。将来のオブジェクト指向の概念に精通している方にとって、これらは参照として提供されるものであり、将来、実際に作成された場所で実現したときに、それらについて問い合わせることができます。1 つ上のレベルに進むと、私が説明したこれらのライブラリがあります。これらのライブラリはそれぞれ、ML 領域またはデータ領域のほとんどの人がよく知っている、またはおそらく使用している特定の機能またはワークロードにマップされます。 1 つは、実際にデータをトレーナーに渡す前に、データを取り込んだり、前処理したりすることです。統計モデル、従来のモデル、微調整モデル、または実際にゼロからモデルを構築しているかどうかに関係なく、トレーニングを行っている可能性があります。ハイパーパラメータの調整を行っている可能性があります。実際に最良の結果を得るために、最適なチューニングパラメータを設定するのは当然です。サーブしたい場合があります。サーブとは、オンラインサービングを行うことや、大規模なデータセットでバッチ推論を行うことです。最後の部分は強化学習です。実際に強化学習の分野にいる場合は、それが彼らが提供するライブラリです。これらのことを気にせず、大規模な Python アプリケーションのシミュレーションやモデリングを行うことに関心のある物理学者または大気科学者である場合は、これらの特定のプリミティブを使用して、タスク、アクター、リモートオブジェクトを使用した独自の分散アプリケーションを作成できます。
嘘をついている人もいます。実際に大規模に Ray を使用している人もいます。これらは数年前から Ray を使用している企業の一部です。実際に台頭してきた新しい企業もあり、そのうちの 1 つは DoorDash です。また、Pinterest、JP Morgan など、Ray サミットで講演したこれらの企業はすべて大規模に Ray を使用しています。ChatGPT、GPT-3、GPT-4 は Ray を使用して構築されました。これは私がここに送って宣伝しようとしているものではありません。これらの著名な企業の一部で実際に使用されています。私たちには大規模なコミュニティがあり、25,000 人のバニティ スターがいます。貢献者もたくさんいます。
焦点を移します。課題についてお話ししました。Ray とは何か、なぜそれが重要なのかについて話しました。次に、2 番目のレイヤー、つまり Ray ライブラリのいくつかと、それらが実際にトレーニング スタックを構成する方法についてお話しします。これは、私たちが主張する新しいトレーニング スタックであり、意見が分かれているものですが、実際に定期的に使用している人々から、実際に出現し始めています。一番上では、実際に LLM モデルを使用している場合、Hugging Face モデルのチェックポイントを使用している可能性があります。そのチェックポイントをモデルとしてロードするだけです。モデルが非常に大きい場合は、DeepSpeed を使用して特定のモデルをシャーディングすることになります。モデルの並列処理により、モデルを小さな部分に分割し、クラスター全体に渡って渡すことができます。Hugging Face ライブラリ トランスフォーマーの一部となった Accelerate ライブラリを使用している可能性があります。CPU から GPU へ、GPU から CPU へデータを変更または移動している可能性があります。 Zero-3 ステージを使用すると、Tensor を CPU から GPU に移動するときに自動的に実行されます。これは、Ray チューニング時に実際に行う非常に一般的なことです。これらはすべて、実際に行われるすべてのトレーニングのライブラリとして Ray Train が組み込まれているために有効になっています。Ray Data は、実際にデータを分割できるものです。いくつかを詳しく見ていきます。オーケストレーションには、スケールアウトやダウンスケールが可能な Ray を使用できます。最新のハードウェア アクセラレータを使用する場合は、GPU、TPU、Inferentia 1 および 2、Trainium を使用できます。これにより、LLM、ディープラーニング フレームワーク、従来のモデルなど、あらゆるワークロードに対応する最新のスタックが作成されます。この特定のレイヤー スタックを使用できます。この奇妙なものが、微調整モデルをスケーリングしたり、ディープラーニング モデルを大規模にスケーリングしたりするための現在のスタックです。
これらの Ray AI ライブラリは、なぜ、いつ使用するのでしょうか。これらが何であるか、そしてその利点について、これらすべてのデータ ポイントを私に提供していただきました。実際に使用したいシナリオがいくつかあります。たとえば、ある種のワークロードをスケーリングしたい場合、データ推論を実行したい場合などです。特定のスケールでバッチ推論を実行したい場合、Ray Data を使用して実際にそれを行うことができます。または、特定のモデルを提供したい場合、Ray Serve を使用して実際にそれを行うことができます。すべてではなく、実際にその個々の部分を使用できます。または、データの取り込みからトレーニング、チューニング、提供までのパイプライン全体を構築したい場合、これらは非常に構成可能なライブラリであるため、実際に使用できます。これらは実際に連携して機能します。これらは非常に宣言的であるため、API ですぐに確認できます。または、たとえば Hugging Face など、組み込まれている既存のライブラリを使用して、それを使用して何かを実行したい場合、これが私たちが集中する点です。あるいは、実際に企業用の機械学習プラットフォーム全体を構築し、Ray ライブラリをすべて抽象化して、データ サイエンティストに機械学習を実行するよう指示できる高度な機能を用意したいとします。Shopify、Spotify、Pinterest などの企業は、すでにこれを行っています。これらの企業は、実際に Ray を呼び出す独自の ML ライブラリの上に Ray を抽象化しています。これらはすべて異なるシナリオです。これらはすべて、この特定のスタックを実際に使用するさまざまな方法です。
Ray Data についてお話ししましょう。Ray Data は、共通フォーマットを提供する高レベル ライブラリです。ディスクから任意のフォーマットでデータを読み取ることも、クラウドから任意の方法でデータを読み取ることもできます。画像を使用している場合でも、CVS を使用している場合でも、Parquet ファイルがある場合でも、Hugging Face データがある場合でも、非常にシンプルな API を使用して実際にデータを読み取ることができます。データがある場合、先ほどお話しした課題の 1 つは、データが大きすぎて 1 台のマシンに収まらない場合です。Ray Data を使用すると、データをシャード化して、分散方式で実行されているトレーナーにデータを渡すことができます。Ray Data は自動的にそれを行います。Ray Train と非常にうまく連携します。1 台のマシンに収まらないデータがある場合、そのデータをワーカー間でシャード化して、その特定のデータでトレーニングを行うことができます。Ray Data は、先ほどお話しした特定のスタックの重要な部分です。以下は、実際にどのように使用しているかの例です。 parquet ファイルまたは CVS ファイルがある場合は、ストレージから読み取ることができるかもしれません。これを使用してデータを変換できます。変換は前処理の重要な部分であり、バッチ推論を行うときにも重要な部分です。Ray Data には、非常に簡単な map_batches 関数が用意されており、独自の関数または独自の UDF を提供して、このデータを処理したり、このデータを特定の方法で変換したりできます。これはバッチで実行することも、関数で実行することもできます。最後に、データを消費できます。データがワーカーに到着すると、実際に各バッチを使用してバッチを提供できます。これで、トレーニング関数がその特定のバッチで機能してそれを実行できます。これらは現在、Amazon でペタバイト規模で使用されています。これは、社会的証拠なしに私が言っていることではありません。実際に人々が使用しています。これについて書かれたブログがあります。最後にいくつかのリソースを紹介します。これが、データの概要が実際に機能する方法です。
もう 1 つの例を挙げます。先ほども述べたように、データ プリプロセッサはすぐに使用できます。これを行うには 2 つの方法があります。デフォルトのプリプロセッサを使用することもできます。これは非常に一般的です。スケーリングや変換を使用している場合は、そのまま使用できます。または、独自の UDF を提供して実際に実行することもできます。データを変換したいのですが、特定の方法で変換する必要があります。テンソルの場合、回転を変更したり、何かを削ったり、サイズを拡大または縮小したりする場合、これらはすべて、トレーナーのラスト マイルの取り込みとして非常に一般的な変換です。Ray Data は、データ処理や ETL ライブラリの代替ではないと私は主張します。その主な目標と目的は、トレーナーのラスト マイルのデータ取り込みを提供することです。これは重要な部分です。これは、スケーラーを使用したり、連結器を使用したりする場合の例です。その API は、よく知られているものと非常に似ています。 scikit-learn を使っているなら、fit と transform の使い方はご存知でしょう。これが 1 つの方法です。すぐに、一般的な ML 変換であるスケーラーを使用できます。
2 つ目は、ユーザー定義関数を提供することです。これは非常にシンプルなワークフローです。これは、実行したい非常にシンプルなことです。たとえば、膨大な量のデータを読み取りたいとします。分散方式で前処理したいとします。前処理したら、推論を行い、その推論または予測を取得して保存します。これを行うコードは非常にシンプルです。非常に宣言的です。非常に Python 的であり、構成可能です。Spark のバックグラウンドを持つ方もいらっしゃると思いますが、これは操作のチェーンを作成する方法であり、これらは実際にストリーミング形式で実行できます。特定の分類可能なモデルを定義できます。プロセス関数は、定義した任意の Python 関数にすることができます。モデルは、NumPy Ray にある特定のバッチを取得できます。次に、モデルを呼び出して実際にバッチを実行し、その結果を返すことができます。これらの操作を連結する場合、データを読み取っているときにチェーン演算子を使用して実際に実行できます。その特定のデータの出力は map_batches に送られ、pre_function を使用して実行されます。それが完了するとすぐに、map_batches に送られて予測が行われます。その後、それを parquet ファイルに書き込んで保存できます。これがバッチ推論を実行する簡単な方法の 1 つです。
では、非常に一般的な多段式異種パイプラインの場合はどうでしょうか。ディープラーニング推論パイプラインを実行する場合、CPU で使用されるデータと GPU で使用されるデータがある可能性があります。異種を実際に組み合わせるにはどうすればよいでしょうか。実際に両方を組み合わせるにはどうすればよいでしょうか。データのこの部分を CPU クラスターで使用し、この部分を GPU で使用するようにします。これは、Ray Data で UDF を使用するために使用できる一般的なパイプラインです。ここでは、パーティクル クラスを作成しています。このクラスには、実際に送信されたバッチを受け取る呼び出し可能な関数、呼び出し可能なクラスがあります。この特定のバッチでモデルを呼び出して、結果を取得します。これらのバッチは、GPU または CPU 上にある可能性があります。実際にどのように決定し、宣言し、Ray Data にこれを GPU にする必要があることをどのように伝えるのでしょうか。ここでも、前の例に基づいて構築された非常に単純な例ですが、ここでは異種環境を使用しています。もう一度、データを読み込んでいます。データの前処理を行いたいです。データの特定の部分を変更したいかもしれません。それが CPU に必要な方法です。特定のデータ バッチを、実際に CPU があるクラスターに送信します。結果が返ってきたら、それに対してバッチ推論を行います。ここで、クラスを指定します。バッチ推論の操作のこの特定の部分には 1 つの GPU が必要であるとします。X 個のアクターの実際のプールを使用します。5 つまたは 6 つのアクターを作成し、それらの間でデータを分割してバッチ推論を行います。データが返ってきたら、実際に parquet に書き込むか、実際に必要な場所に保存します。これが Ray Data です。これは、大規模な機械学習アプリケーションを構築するとき、スタックのその部分を作成するときに重要な部分です。
もう 1 つ、皆さんにお伝えしたいのは、Ray Train についてです。Ray Train は、柔軟性があり、フレームワークを絶対確実なものにすることを目指しているため、その重要なコンポーネントです。将来的に絶対確実であるというのは、実際に登場した新しいライブラリを、この特定の最後の上部に組み込むことができるということです。実際に使用したい JAX トレーナーがあるとします。または、Alpa を使用する場合は、Ray Train と非常に簡単に統合できます。Ray Train は Ray 上に構築されているため、すべてのスケーリングとフォールト トレランスが自動的に実現されます。どのクラウド プロバイダーでも実行できます。この特定の Ray Train について、もう少し詳しく説明しましょう。トレーナーの核となる概念は 2 つあります。1 つは、クラスター全体でどのようにスケーリングするかです。この高レベル API に提供するトレーニング関数はどのようなもので、各ワーカーで実行されます。こちらには、Ray Train、Lightning PyTorch、Hugging Face、Horovod、JAX、Alpa と統合されたこれらのライブラリのいずれか用に記述できるトレーニング関数があります。特定のトレーニング関数を記述し、それをどのようにスケーリングするかを指定します。これは非常にシンプルな API で表現され、汎用の TorchTrainer があり、実際に特定のクラスを Coach トレーナーに作成します。記述するトレーニング関数を提供します。これは、すでに記述した変更のないコードである可能性があります。ここに配置するだけで、それがトレーニング関数になります。スケーリング構成を TorchTrainer に提供して、「これが私のトレーニング関数です。これをすべての特定のクラスターで実行してください。これがスケーリング方法です。これがそのために使用したいリソースです」と伝えます。次に、トレーニング フィットを使用するだけで、結果が返されます。シンプルで宣言的であり、必要な新しいライブラリを組み込むことができます。非常にシンプルな Python コードを書いているだけなので、非常に構成しやすいです。
ディープラーニング フレームワーク用に実際に作成している既存の PyTorch を実際にどのように使用するかの例を示します。Ray を使用せず、PyTorch のみを使用するとします。このボイラー コードをすべて作成します。分散環境を設定します。分散データ並列プロトコルである DDP を作成します。CPU と GPU 間でデータを移動するための分散サンプラーを設定します。次に、そのデータを実際にトレーニングを行う GPU に移動します。この特定のコードを結晶化して、実際に持っている 3 行の緑色のコードで簡素化できます。Ray Train Torch からいくつかの関数を継承するか、または含め、データ ローダーを準備し、CPU から GPU、デバイス、またはデバイスからデバイスにデータを移動するためのデータを準備するモデルを準備します (実際にロードするデータ ローダーがあります)。次に、トレーニングを開始します。これがトレーニング関数です。 TorchTrainer に同じトレーニング関数を提供し、それを実行します。これを可能にするのは、シンプルで宣言的で構成可能な API です。これはすべて、TorchTrainer と呼ばれる高レベルの抽象化に含まれています。実際に同じことを行いたい Hugging Face トランスフォーマーがあるとします。実際にモデルを微調整したい場合や、特定のモデルを調整したい場合、まったく同じことを行います。トランスフォーマーを 1 台のマシンでトレーニングするために作成した既存のコードを取得します。これは単一のモデル、単一の GPU であるためです。これを Ray Train に転送して、複数の GPU、複数のマシンに分散して使用できるようにします。トランスフォーマー用に作成した同じトレーニング コードをトレーニング関数にカット アンド ペーストし、トレーニング関数を TorchTrainer に提供してトレーニングを開始します。Python 的で表現力豊かで宣言的でシンプルです。
もう 1 つの重要な部分は、チェックポイントの統合です。大規模な言語モデルやディープラーニング モデルを構築またはトレーニングしているときはいつでも、エポックごと、または X 個のエポックごとに、チェックポイントを作成する必要があります。何か問題が発生した場合は、チェックポイントから開始できます。Ray Train が実際にチェックポイントを配置する方法を改善する前は、チェックポイントをすべてヘッド ノードに戻していましたが、多くの OOM メモリが発生していました。これは、一部のモデルが重みに大きなテンソルを持っているためです。バックワード パスを通過すると、実際にはすべての異なるワーカーからの勾配 [inaudible 00:34:26] がヘッド ノードにあり、特定のディスクに書き込まれます。これにより、大量の OOM メモリが生成されていました。現在は、各ワーカーが実際にローカル ディスクに書き込み、その後、非同期でクラウドに配置するように指定できます。これにより、すべてのデータをヘッド ノードに移動したり、すべてのデータをコピーしたりするトラフィックが削減されます。直接ディスクに書き込みます。そして、各ワーカーはそれをクラウド内の特定の中央の場所にアップロードします。そして、実際にチェックポイントから読み取りたいときには、ライブラリによって、Loudcloud にあるチェックポイント ライブラリにアクセスして、その特定のチェックポイントからモデルを作成することができます。ディレクトリ構造がどのようになっているかを正確に把握し、各データ ディクショナリの重みを読み取り、特定のモデルを作成します。これは、Ray Train の非常に重要な部分になっています。Ray Train はどのように動作するのでしょうか。新しいプロトコルは開発していません。基盤では同じ DDP ライブラリを使用しています。Trainer は単なるオーケストレーションです。つまり、4 つのワーカーがあり、DDP init Python プロセスを作成し、内部の Python プロセスがすべての勾配通信を行うということです。再作成しているわけではなく、オーケストレーションしているだけなので、基盤では DDP プロトコルについて心配する必要はありません。Python プロセス グループが実際にすべての同期を行います。大規模な分散コンピューティングを実行するための新しいスタックの一部となることは、Ray Train にとって大きなメリットです。
では、もう 1 つレベルを上げて、実際に Ray Train を使用して LLM モデルのスケーリングと微調整を行う方法について説明します。大規模なモデルと大規模なデータセットのトレーニングについて話し合うカンファレンスに参加したことがあるなら、実際に目にしたトレンドのいくつかは、常に一緒に行われています。現在、NLP のムーアの法則は、モデルのサイズが毎年 10 倍に増加するというものです。これは、古いムーアの法則が消滅したためです。ムーアの法則に代わるものが必要です。現在、NLP のムーアの法則に関する新しいアイデアが生まれています。これは、モデルのサイズが 10 倍に増加し、それに伴い、実際にデータも増加するというものです。これで、大規模なモデルと大規模なデータセットの課題があります。これをどうすればよいのでしょうか。モデルの並列処理に何らかの方法で対処する必要があります。ほとんどのフレームワークがサポートするモデルの並列処理には 2 種類あります。 1 つは、特定のモデルを分割するか、特定のモデルのレイヤーを取得して、それをワーカー全体に分割することです。特定のワーカーをトレーニングすると、すべての勾配が最終的に同期されます。または、実際に持っているマトリックスの一部を取得し、すべての GPU 間で Tensor 並列化します。これは、Tensor 並列化、つまりモデル並列化を実行する別の方法です。今日のほとんどのライブラリは実際にこれをサポートしています。Ray Train が組み込まれているため、心配する必要はありません。モデル並列化が必要だと言うだけで、データが提供されます。データ並列化は、モデルを重要なシャードに分割し、それらを横断する別の方法です。これらを組み合わせると、データ並列化とモデル並列化の両方を提供するフレームワークがあれば、大規模な分散トレーニングを行うことができます。
Ray Data についてお話ししました。それがトランスフォーマーとどのように統合されるか、最新の最先端のフレームワークとどのように統合されるかについて話しました。Ray がどのようにオーケストレーションを提供するか、そして Ray Train がどのようにそれを可能にするか。私たちが目にしてきた、出現し、現在ほとんどの人が実際に使用している特定のモデル スタックを提供します。トップ レベルにある他のものを置き換えることができます。Hugging Face からモデルをダウンロードすることも、実際にそれを持っている他のサービス エージェンシーからモデルをダウンロードすることもできます。重要なのは、主に Hugging Face Transformers ライブラリを使用している場合、DeepSpeed、Accelerate、Zero-3 を使用するメリットをすべて得られることです。これらは実際にはそのライブラリの一部です。Ray Train を使用して高レベルの抽象化または TorchTrainer を作成し、それを分散方式で実際に使用できるようになりました。これは重要な部分です。これは、私たちが実際に進化を見てきた重要な要素です。私はそれが独断的なスタックだと主張していますが、実際にそれを使用している人が増え始めています。ゼロから使用しているか、LLM モデル全体をゼロから構築しているか、完全なパラメータの微調整を行っているか、実際に部分的な微調整を使用しているかにかかわらず、LoRA を使用しているか、モデルを微調整するこの機能に対応する PEFT を使用しているかに関係なく、同じことが言えます。
これらすべてを無料で利用できます。分散データの並列化などはすべて PyTorch ライブラリでサポートされており、そのラッパーを用意しているだけです。DeepSpeed トレーニングは、Hugging Face トランスフォーマーの一部になりました。これはライブラリに自動的に付属しているため、特定のライブラリを使用してこれを実行します。Ray クラスターでは、勾配同期を行う PyTorch プロセス初期化グループをすべて作成するだけで、トレーニングが自動的に実行されます。心配する必要はありません。Hugging Face トランスフォーマーを使用している場合は、私が示したように、それほど多くのコードを変更する必要はありません。トランスフォーマーのトレーニングに実際に使用するコードとほぼ同じコードを使用して、分散方式で実行します。Ray データセットを使用すると、Hugging Face データを実際に取得し、それを Ray データに変換して配布できます。この互換性と、1 つのフレームワークから別のフレームワークに実際に移動する機能により、2 つのメリットが得られます。課題の 1 つを覚えていますか?課題の 1 つは、開発から本番環境に移行するにはどうすればよいかということでした。これはすべて 1 台のマシンで実行できます。1 台のマシンで実際に実行し、分散する方法をお見せします。これにより、将来にわたって万全な準備が整います。ML フレームワークが変更され、明日新しい ML フレームワークが登場しても、その ML フレームワークの人気度に応じて、高レベルの TorchTrainer や Transformer Trainer などを提供できます。これにより、非常にタイムリーに実行できるため、開発者の速度を維持できます。
これから行う作業の例をご紹介します。865 GB を超える Pile データセットで 60 億のパラメータを使用してトレーニングした Eleuther GPT モデルを実際に使用する例を示します。このモデルを Shakespearean festival で微調整します。このモデルに簡単な英語でクエリとプロンプトを送信し、中世の言語で話しかけてもらいたいからです。次に、先ほど説明したスタックを使用します。オーケストレーションには Ray を使用します。Ray Train を使用します。DeepSpeed を使用し、Hugging Face モデルを使用します。結果は事前トレーニング済みモデルになります。Hugging Face 単一モデルで実際に使用する可能性のある非常に一般的なトレーニング フローを以下に示します。データを読み込みます。チェックポイントから特定のモデルを作成します。チェックポイントでトレーニング引数を提供します。トレーナーを作成してトレーニングします。これが、実際にこれを分散ライブラリのトレーニング済みフローに変更する方法です。これを取得してトレーニング関数を作成し、ほぼ同じコードを使用します。次に、実際に TorchTrainer を作成し、スケーリング構成を指定して、trainer.fit を実行すれば完了です。
丸で囲んだ緑色のモデルを使用しますが、2 シリーズの Llama モデルを実際に微調整できます。また、私が持っている 3 つのフレームワークのいずれかを使用することもできます。私が行ったことは、このノートブックを 1 時間ほど実行したことです。この特定のモデルをご覧になったと思います。ここでは、この特定のフェーズを実行しています。簡単なバッチ推論を行います。トレーニングを行います。データ処理を行います。最初にモデルをセットアップします。モデルをセットアップすることで、実際に持っているものをインポートするだけです。ここにモデル名を指定します。必要な環境で初期化します。ray.init を実行すると、クラスターを作成するように指示されます。Python 3.1 を使用していることが示されています。これは、私が使用しているナイトリー ビルドです。ここで実際にそれを使用できます。この特定のコードについては心配しないでください。ここで重要なのは、インポートからロードデータセットを読み込んでいることです。これは私の Hugging Face データです。400,000 のデータのうち 1 行しかないことに注意してください。これは本当に悪いことです。データを行に分割して前処理する必要があります。データセットの前処理では、Hugging Face の Ray を使用していることがわかります。次に Ray データセットを使用します。トランスフォーマーを使用して実際に分割しているため、実際には 40,000 行のコードがあり、トークン化を使用してトークン化します。これがバッチ プロセッサです。分割テキストを使用し、パンダに変換し、トークナイザーを使用します。これを微調整します。微調整を行うと、持っているすべての Ray データ、つまり 40,000 行のコードがブロックに分割され、すべてのワーカーに渡されます。これがコードの要点です。
トレーニング コードを書くだけでよいと話したことを思い出してください。これが私が書いているトレーニング コードです。これは各ワーカーで実行されます。バッチ サイズです。これがハイパーパラメータ調整パラメータです。これが実際に必要な DeepSpeed です。これがゼロ セット最適化です。CPU と GPU 間でデータを移動するために必要なこの特定の構成を使用します。実際に実行され、初期化されているのはすべてここで行われます。トレーニング引数を使用しています。これは Hugging Face トレーニング引数です。必要な引数をすべて提供しています。次に、コンピューティング メトリックを取得し、トレーナーを返します。トレーナーを返すときに、先に進んでトランスフォーマー トレーナーを使用します。トランスフォーマー トレーナーの使用方法を確認しました。トレーニング関数を提供し、スケーリング構成を提供します。GPU を使用してください。これが私のリソースです。これが私のトレーニング データです。これが私の検証データです。先に進んでトレーニングしてください。トレーニングを開始します。実行には約 7 分半かかりました。560 個の CPU のうち約 385 個と、32 個の GPU すべてを使用して、非常に分散された方法で実際にトレーニングしました。5 回の反復を実行しました。1 エポックには 5 つのステップがあります。通常はそれ以上のステップを読みますが、説明のために、手短に済ませたいと考えました。実行しました。最終的に、約 7 分半後にモデルをトレーニングしました。すべての Ray Trainer はチェックポイントを作成します。チェックポイントは、モデルの後に実際に実行した最後のチェックポイントの状態を実際に取得し、そのモデルを予測に使用する方法です。さまざまなハイパーパラメータ調整を行ったので、最高のチェックポイントを取得します。チェックポイントが実際にディスク上にあることがわかります。その特定のチェックポイントを読み取ってマテリアライズします。これが、バッチ推論として使用する DataFrame です。ロミオとジュリエット、「ロミオ、愛しい人よ、私はあなたにどう愛情を示せばいいでしょうか」など。これをシェイクスピア風に変換します。私は英語を取り上げ、それをシェイクスピア風に変換します。微調整し、プロンプトを取り、シェイクスピア風に書き直すからです。予測します。うまくいくかどうか見てみましょう。見事にうまくいきました。
ここで私が基本的に行ったのは、エマージェンシー スタックを使用することです。Ray Train と Ray Hugging Face トランスフォーマーを使用して、実際にこれを実現しました。DeepSpeed と、実際に配布できるすべてのライブラリを使用しました。トレーニング関数を作成し、これを 32 のワーカーで実行します。実際に使用してもらいたいすべてのパラメーターは次のとおりです。次に、チェックポイントを作成します。32 の GPU とすべての CPU で約 7 分間実行されました。EC2 に 32 のワーカーがあるためです。約 7 分かかりました。これは小さなデータセットですが、他のモデルを微調整する場合にも同じ戦略を使用できます。私が実際に提供したものは、実際に実行できます。次に予測を行い、シェークスピアで予測を取得しました。
概要を説明し、いくつかの課題について検討しました。実際にそれを実現する方法について独自の方法を提案しました。Ray スタックを実際に使用する方法についての洞察と直感を提供しました。モデルの調整に実際に使用できるモデル スタックを実演しました。
Damji: モデルの並列処理を使用して特定のモデルを分割できることについてお話ししました。
実際に推論を行うと、モデルをロードしたときにモデルが大きすぎる場合は、推論全体でモデルが分割されます。各データは実際に分割を行うために使用されます。各データの回答が収集され、それを返します。これが、DeepSpeed が特定のモデルを分割するために実際に使用する方法です。
Damji: Ray Data が ETL の代替にならないのはなぜですか?
Spark を見てみると、Spark は実際には DataFrame という概念全体に基づいています。Spark の中心的な概念は、実際に DataFrame があり、分散されており、DSL があり、実際に使用するドメイン固有言語があることです。これは、かなり優れたグラフを作成し、それを Spark タスクに変換します。それに関連付けられた DSL があります。これは、ETL の大規模データ処理に非常に適しています。大規模データ処理の ETL を行う場合、Ray は考慮しません。これはそのためのものではないからです。これは、Ray タスクとアクターを使用して、その上に独自の DCL を使用、構築、または構築できないという意味ではありません。私が言ったことを思い出してください。これは汎用分散フレームワークです。スキーマに縛られていません。DataFrame に縛られていません。実際にそれを書くためのプリミティブを提供します。これを Unix ファイルシステム、またはさまざまなものすべてへのインターフェイスを持つ Unix-C インターフェイスと考えてください。実際にこれらのプリミティブを使用して、その上に高レベルのアプリケーションを構築できます。同様のアナロジーです。Spark は ETL に適しています。ストリーミングに適しています。SQL に適しています。Ray は異なります。Ray では、実際にトレーニングに送信するためのマップ結合、グループ化、ラスト マイル インジェクションがいくつか提供されます。Ray は大規模な ETL に使用されていません。大規模な ETL に使用していない場合は、Ray を使用せず、Dask または Spark を使用してください。私は Spark のファンなので、Spark を選びます。はい、大規模な場合は Spark を使用します。データが実際に準備され、最後の調整を行うと、それを Ray に渡してトレーナーに渡すことができます。大きな違いがあります。どちらも非常に補完的であり、どちらかを置き換えるのではなく、非常にうまく連携します。
トランスクリプト付きのプレゼンテーションをもっと見る
InfoQ の先週のコンテンツのまとめが毎週火曜日に配信されます。250,000 人以上のシニア開発者のコミュニティに参加してください。例を見る
2024 年 6 月 24 日 – 25 日 | ボストン、マサチューセッツ州今日の重要な開発優先事項を明確にする実用的な洞察。InfoQ Dev Summit Boston は、InfoQ が主催する 2 日間のカンファレンスで、シニア ソフトウェア開発者が現在直面している最も重要な技術的決定に焦点を当てています。20 以上の技術講演を詳しく聞き、ジェネレーティブ AI、セキュリティ、最新の Web アプリケーションなどを扱うシニア ソフトウェア開発者から革新的な学びを得ましょう。今すぐ登録
InfoQ.com およびすべてのコンテンツの著作権は © 2006-2024 C4Media Inc. に帰属します。プライバシー通知、利用規約、Cookie ポリシー
元記事: https://www.infoq.com/presentations/scale-large-ml-models/