Red Hat OpenShift AI によるオープンソース基盤モデルのファインチューニングと提供

今年の Ray Summit では、IBM Research とともに構築しているインフラストラクチャ・スタックを紹介できることを楽しみにしています。これには、生成 AI 分散ワークロード向けの Ray と CodeFlare が含まれます。これらのテクノロジーは Open Data Hub などのオープンソース・コミュニティで採用され、そこで成熟して Red Hat OpenShift AI の一部になり、 Red Hat Ansible Automation Platform で使用されている IBM watsonx.ai および各種の IBM 基盤モデルも支えています。Red Hat OpenShift AI には、基盤モデルのファインチューニングと提供のプロセスをシームレスでスケーラブルかつ効率的なものにするために設計された、強力なツールとテクノロジーが結集しています。このプラットフォームは、オンサイトでもクラウドでも一貫した方法でモデルをチューニング、トレーニング、デプロイするためのツールを提供します。最新の取り組みにより、基盤モデルをファインチューニングし、提供するための複数の選択肢が利用可能になり、データサイエンスと MLOps の担当者には、クラスタリソースへのリアルタイムのアクセスやワークロードのバッチ処理のスケジューリングなどの機能が提供されます。 

本ブログでは、 WikiText データセット上の 1 億 3 千 7 百万個のパラメータで構成される HuggingFace GPT-2 モデルを、Red Hat OpenShift AI を使用してファインチューニングし、その後デプロイする方法について説明します。ファインチューニングについては、KubeRay で並列処理を行う分散ワークロードスタックを使用してこれを実現し、ファインチューニングされた GPT-2 の基盤モデルのデプロイと監視には KServe/Caikit/TGIS スタックを使用します。

分散ワークロードスタックは、次の 2 つの主要コンポーネントで構成されています。

• KubeRay: 分散コンピュートワークロードを実行するリモート Ray クラスタのデプロイと管理を行う Kubernetes Operator。
• CodeFlare：次の 3 つのコンポーネントのライフサイクルをデプロイし、管理する Kubernetes Operator。
  • CodeFlare-SDK：リモートの分散コンピューティングジョブとインフラストラクチャを定義し、制御するためのツール。CodeFlare Operator は CodeFlare-SDK を使用してノートブックをデプロイします。
  • Multi-Cluster Application Dispatcher (MCAD)：シングルまたはマルチクラスタ環境でバッチジョブを管理するための Kubernetes コントローラー
  • InstaScale：MachineSets セットアップを使用して、任意の OpenShift フレーバーの集約リソースをオンデマンドでスケーリング (セルフマネージド型またはマネージド型 Red Hat OpenShift on AWS / Open Data Hub)

図 1. 分散ワークロードでのコンポーネントとユーザーワークフロー間の相互作用

図 1 に示すように、Red Hat OpenShift AI では、基盤モデルのチューニングは CodeFlare で始まります。これは、モデルの構築、トレーニング、改良を最適化および単純化する動的フレームワークです。その下で、分散コンピューティング・フレームワークである Ray の力を活用し、KubeRay を使用してファインチューニング作業を効率的に分散します。その結果、最適なモデルパフォーマンスを実現するために必要な時間を大幅に短縮できます。ファインチューニング・ワークロードを定義すると、MCAD はリソース要件が満たされるまで Ray ワークロードをキューに入れ、すべての Pod をスケジュールできることが保証されてから Ray クラスターを作成します。

提供側の KServe/Caikit/TGIS スタックは次のもので構成されています。

• KServe：モデルのデプロイメントのライフサイクルを処理する実稼働環境向けの Kubernetes カスタムリソース定義
• Text Generation Inference Server (TGIS)：モデルをロードして推論エンジンを提供するバックエンド/サーバーを提供します
• Caikit：TGIS プロセスのライフサイクルを処理する AI ツールキット/ランタイムであり、さまざまなモデルタイプを処理する推論エンドポイントとモジュールを提供します
• OpenShift Serverless (前提条件の Operator)：オープンソースの Knative プロジェクトに基づいており、開発者がエンタープライズグレードのサーバーレスおよびイベント駆動型アプリケーションを構築し、デプロイできるようにします。
• OpenShift Service Mesh (前提条件の Operator):オープンソースの Istio プロジェクトをベースとして構築されており、サービスメッシュ内でネットワーク化されたマイクロサービスの動作に関する知見と運用制御のためのプラットフォームを提供します。

図 2. KServe/Caikit/TGIS スタックのコンポーネントとユーザーワークフロー間の相互作用

モデルのファインチューニングが完了したら、ランタイムとバックエンドを提供する Caikit/TGIS でモデルをデプロイし、信頼性の高い高度なサービング・インフラストラクチャを提供する KServe を使用してモデルのスケーリングとメンテナンスを単純化および最適化します。バックグラウンドで Red Hat OpenShift Serverless (Knative) がモデルのサーバーレス・デプロイメントをプロビジョニングし、Red Hat OpenShift Service Mesh (Istio) がすべてのネットワーキングとトラフィックフローを処理します (図 2 を参照)。

環境の設定

このデモでは、 Red Hat OpenShift Data Science Operator がインストールされた、またはアドオンとして追加された OpenShift クラスタを使用していることを前提とします。このデモは、基礎となるプラットフォームとして Open Data Hub を使用して実行することもできます。

モデルをファインチューニングするには、OperatorHub で利用可能な CodeFlare コミュニティ Operator をインストールする必要があります。CodeFlare Operator は、MCAD、InstaScale、KubeRay Operator、および CodeFlare ノートブックイメージを、codeflare-sdk、pytorch、torchx などのパッケージとともにインストールします。GPU を使用する場合は、NVIDIA GPU および Node Feature Discovery Operator もインストールする必要があります。

モデルの提供部分については、このスクリプトを実行するだけで、すべての前提条件の Operator と KServe/Caikit/TGIS スタック全体がインストールされます。TARGET_OPERATOR を rhods に設定してください。 

ここでは分散ワークロードと KServe/Caikit/TGIS スタックの両方について、おおよそ手動のインストール手順を説明していますが、どちらのスタックも Red Hat OpenShift AI でまもなく利用可能になり、サポートされる予定です。

LLM モデルのファインチューニング

まず、Red Hat OpenShift AI のダッシュボードから CodeFlare ノートブックを起動し (図 3 を参照)、このデモに必要なノートブックとその他のファイルが含まれるデモリポジトリのクローンを作成します。

図 3. OpenShift Data Science ダッシュボードに表示された CodeFlare ノートブックのイメージ。

最初に、クラスタの名前、デプロイ先の名前空間、CPU と GPU とメモリの必要なリソース、マシンタイプ、InstaScale の自動スケーリング機能を利用するかどうかなど、希望するクラスタのタイプ (ClusterConfiguration) のパラメータを定義する必要があります。オンプレミス環境で作業している場合は、machine_types を無視し、instascale=False を設定します。その後、クラスタオブジェクトが作成され、MCAD に送信されて、Ray クラスターがスピンアップされます。 

Ray クラスタの準備が完了し、ノートブックで cluster.details() コマンドを実行して Ray クラスタの詳細が確認できると、名前、実行するスクリプト、引数 (該当する場合)、必要なライブラリのリストを指定することで、ファインチューニングジョブを定義し、それを先ほど起動した Ray クラスタに送信できるようになります。引数リストは、使用する GPT-2 リストと、モデルのファインチューニングに使用する WikiText を指定します。CodeFlare SDK の優れた点は、ステータスやログなどの情報を cli を介して簡単に追跡し、Ray ダッシュボードで表示できることです。 

モデルのファインチューニング・プロセスが完了すると、job.status() の出力が SUCCEEDED に変わり、Ray ダッシュボードのログに完了が示されます (図 4 を参照)。2 つの CPU と 8GB のメモリーを搭載した NVIDIA T4 GPU で 1 つの Ray ワーカーを実行したところ、GPT2 モデルのファインチューニングには約 45 分かかりました。

図 4. Ray Dashboard のログが、モデルのファインチューニング・プロセスの完了を示しています。

この後は、ノートブックに新しいディレクトリを作成し、モデルをそこに保存してからローカル環境にダウンロードして、後からモデルを変換して MinIO バケットにアップロードできるようにする必要があります。このデモでは MinIO バケットを使用していますが、別のタイプの S3 バケットや PVC、または任意のストレージを使用できます。

LLM モデルの提供

これで基盤モデルのファインチューニングが完了しました。次はこれを実際に動作させます。モデルをファインチューニングした同じノートブックから新しい名前空間を作成して、次のことを実行します。

• Caikit+TGIS Serving Runtime をデプロイする
• S3 データ接続をデプロイする
• MinIO バケットにあるモデルを指す推論サービスをデプロイする

提供ランタイムは、モデルのデプロイと管理のための環境を実稼働環境に作成するために設計されたカスタムリソース定義です。さまざまな形式のモデルをオンデマンドで動的にロードしたりアンロードしたりできる Pod のテンプレートを作成し、推論リクエスト用のサービスエンドポイントを公開します。推論サービスが検出されると、ランタイム Pod をスケールアップする提供ランタイムをデプロイします。ポート 8085 が推論に使用されます。

推論サービスは、入力データを受け取ってモデルに渡し、モデルを実行して推論出力を返すサーバーです。デプロイする InferenceService で、先ほどデプロイしたランタイムを指定し、gRPC 推論のパススルールートを有効にして、サーバーが指す先をファインチューニングされたモデルが存在する MinIO バケットに指定します。

InferenceService の準備が完了していることを確認したら、推論呼び出しを実行して、選択した文を完成させるようモデルに要求します。 

これで、Distributed Workloads スタックを使用して GPT-2 大規模言語モデルのファインチューニングが完了し、OpenShift AI の KServe/Caikit/TGIS スタックで正常に提供することができました。 

次のステップ 

Open Data Hub と Ray コミュニティのサポートに感謝いたします。これは、OpenShift AI を使用した AI/ML の潜在的なユースケースのほんの一部に過ぎません。CodeFlare のスタック機能についてさらに詳しく知りたい方は、こちらの デモビデオ をご覧ください。このビデオでは、CodeFlare SDK、KubeRay、および MCAD についてさらに詳しく説明しています。

Red Hat では、まもなく CodeFlare および KubeRay Operator を OpenShift Data Science に統合する予定です。OpenShift Data Science で限定的な機能として最近リリース された KServe/Caikit/TGIS スタック用 UI の開発も進めておりますので、今後の動きにご注目ください。