BLOOM-176B と OPT-30B を Amazon SageMaker にデプロイし、大規模なモデルの推論を行う Deep Learning Containers と DeepSpeed

ここ数年、深層学習の分野で急速な発展が見られました。 NVIDIA や Amazon の最新世代のアクセラレーターなど、ハードウェアは改善されていますが、高度な機械学習 (ML) の実践者は、自然言語処理 (NLP) などのアプリケーションに大規模なディープ ラーニング モデルをデプロイする際に、依然として問題に直面しています。

以前の投稿で、 機能と構成可能な設定 in Amazon SageMaker モデルのデプロイ これにより、これらの大規模モデルの推論が容易になります。 本日、新作を発表いたします アマゾンセージメーカー ディープ ラーニング コンテナー (DLC) を使用すると、大規模なモデルの推論を数分で開始できます。 これ DLC DeepSpeed や Hugging Face Accelerate など、モデル並列推論用の最も一般的なオープンソース ライブラリのいくつかをパッケージ化しています。

この投稿では、新しい SageMaker 大規模モデル推論 DLC を使用して、最も人気のある XNUMX つの大規模 NLP モデルをデプロイします。 ブルーム-176B とメタの OPT-30B Hugging Face リポジトリから。 特に、DeepSpeed の Deep Java Library (DJL) サービングおよびテンソル並列処理技術を使用して、テキスト生成のユースケースでトークンあたり 0.1 秒のレイテンシーを達成します。

完全なサンプル ノートブックは、 GitHubリポジトリ.

大規模モデルの推論手法

言語モデルは最近、サイズと人気の両方で爆発的に増加しています。 Hugging Face などのモデル ズーから簡単にアクセスでき、分類やテキスト生成などの NLP タスクの精度とパフォーマンスが向上したため、実践者はこれらの大規模モデルにますます手を伸ばしています。 ただし、大規模なモデルは大きすぎて単一のアクセラレータのメモリに収まらないことがよくあります。 たとえば、BLOOM-176B モデルは 350 ギガバイトを超えるアクセラレータ メモリを必要とする場合があり、これは現在入手可能なハードウェア アクセラレータの容量をはるかに超えています。 これには、DeepSpeed や Hugging Face Accelerate などのライブラリのモデル並列手法を使用して、推論のためにモデルを複数のアクセラレータに分散させる必要があります。 この記事では、 SageMaker の大規模モデル推論コンテナ これら XNUMX つのオープンソース ライブラリを使用して、レイテンシとスループットのパフォーマンスを生成および比較します。

DeepSpeed と Accelerate は、異なる手法を使用して、推論用の大規模な言語モデルを最適化します。 主な違いは、DeepSpeed の 最適化されたカーネルの使用. これらのカーネルは、モデルの計算グラフのボトルネックを削減することで、推論のレイテンシを劇的に改善できます。 最適化されたカーネルは開発が難しく、通常は特定のモデル アーキテクチャに固有のものです。 DeepSpeed は、これらの最適化されたカーネルを使用して、OPT や BLOOM などの一般的な大規模モデルをサポートします。 対照的に、Hugging Face の Accelerate ライブラリには、執筆時点で最適化されたカーネルが含まれていません。 結果のセクションで説明するように、この違いは、DeepSpeed が Accelerate よりも優れているパフォーマンスの多くの原因となっています。

DeepSpeed と Accelerate の XNUMX つ目の違いは、モデルの並列処理のタイプです。 Accelerate はパイプライン並列処理を使用してモデルの隠れ層の間でモデルを分割しますが、DeepSpeed はテンソル並列処理を使用して層自体を分割します。 パイプラインの並列処理は、より多くのモデル タイプをサポートする柔軟なアプローチであり、より大きなバッチ サイズを使用する場合のスループットを向上させることができます。 モデル レイヤーは複数のデバイスに分散できるため、Tensor 並列処理では GPU 間でより多くの通信が必要になりますが、複数の GPU を同時に使用することで推論のレイテンシを改善できます。 並列処理の手法について詳しくは、 モデルの並列処理の概要 & モデルの並列性.

ソリューションの概要

大規模な言語モデルを効果的にホストするには、次の主要な領域での機能とサポートが必要です。

• ソリューションの構築とテスト – ML 開発の反復的な性質を考えると、これらのモデルがホストされているときに推論エンドポイントがどのように動作するかを構築し、迅速に反復し、テストする機能が必要です。これには、すばやく失敗する機能が含まれます。 これらのモデルは通常、p4dn や g5 などのより大きなインスタンスでのみホストできます。また、モデルのサイズを考えると、推論インスタンスをスピンアップしてテストの反復を実行するには時間がかかる場合があります。 テストには同様のサイズのインスタンスが必要であり、これらのモデルを取得するのは簡単ではないため、通常、ローカル テストには制約があります。
• 大規模なデプロイと実行 – モデル ファイルは、推論インスタンスにロードする必要があります。これは、サイズを考えると、それ自体が課題です。 Bloom-176B の例として、Tar / Un-Tar は、作成に約 1 時間、読み込みにさらに XNUMX 時間かかります。 モデル ファイルに簡単にアクセスできる別のメカニズムが必要です。
• モデルをシングルトンとしてロードする – マルチワーカー プロセスの場合、モデルが XNUMX 回だけ読み込まれるようにする必要があるため、競合状態に陥ったり、不要なリソースをさらに消費したりしません。 この投稿では、から直接ロードする方法を示します。 Amazon シンプル ストレージ サービス (アマゾン S3)。 ただし、これは DJL のデフォルト設定を使用する場合にのみ機能します。 さらに、エンドポイントのスケーリングは数分で開始できる必要があるため、モデルのロードと分散の方法を再検討する必要があります。
• シャーディング フレームワーク – これらのモデルは通常、テンソル並列メカニズムまたは典型的なシャーディング手法としてのパイプライン シャーディングによって必要とされ、テンソル シャーディングの上に構築された ZeRO シャーディングのような高度な概念があります。 シャーディング手法の詳細については、次を参照してください。 モデルの並列性. これを実現するために、NIVIDIA、DeepSpeed などのフレームワークをさまざまに組み合わせて使用​​できます。 これには、BYOC をテストするか、1P コンテナーを使用して、ソリューションを反復処理し、ベンチマーク テストを実行する機能が必要です。 非同期、サーバーレスなど、さまざまなホスティング オプションをテストすることもできます。
• ハードウェアの選択 – ハードウェアの選択は、前述のすべてのポイントと、さらなるトラフィック パターン、ユース ケースのニーズ、およびモデル サイズによって決まります。

この記事では、SageMaker で BLOOM-176B と OPT-30B をホストするために、DeepSpeed の最適化されたカーネルとテンソル並列処理手法を使用します。 また、Accelerate の結果を比較して、最適化されたカーネルとテンソル並列処理のパフォーマンス上の利点を示します。 DeepSpeed と Accelerate の詳細については、次を参照してください。 DeepSpeed 推論: 前例のない規模で Transformer モデルの効率的な推論を可能にする & DeepSpeed と Accelerate による驚異的な速さの BLOOM 推論.

この例では、モデル提供ソリューションとして DJLServing を使用します。 DJLServing は、プログラミング言語にとらわれない Deep Java Library (DJL) を利用した高性能のユニバーサル モデル サービング ソリューションです。 DJL と DJLServing の詳細については、次を参照してください。 DJLServing と DeepSpeed モデルの並列推論を使用して、Amazon SageMaker に大規模なモデルをデプロイする.

最適化されたカーネルによって精度が変化し、計算グラフが変更され、理論的にはモデルの動作が変化する可能性があることに注意してください。 これにより推論の結果が変わることもありますが、これらの違いがモデルの基本的な評価指標に重大な影響を与えるとは考えていません。 それにもかかわらず、実務家は、これらのカーネルを使用する場合、モデルの出力が期待どおりであることを確認することをお勧めします。

次の手順は、DJLServing と SageMaker の大規模モデル推論コンテナーを使用して、SageMaker に BLOOM-176B モデルをデプロイする方法を示しています。 完全な例は、 GitHubリポジトリ.

DJLServing SageMaker DLC イメージの使用

次のコードを使用して、リージョンをノートブックを実行している特定のリージョンに置き換えた後、DJLServing SageMaker DLC イメージを使用します。

763104351884.dkr.ecr..amazonaws.com/djl-inference:0.19.0-deepspeed0.7.3-cu113
# example uri might be like 763104351884.dkr.ecr.us-east-1.amazonaws.com/djl-inference:0.19.0-deepspeed0.7.3-cu113

モデルファイルを作成する

まず、というファイルを作成します。 serving.properties XNUMX 行のコードしか含まれていません。 これは、DeepSpeed エンジンを使用するように DJL モデル サーバーに指示します。 ファイルには次のコードが含まれています。

engine=DeepSpeed

serving.properties モデルごとの構成を構成するために使用される DJLServing によって定義されるファイルです。

次に、作成します model.py このファイルには、モデルをロードして提供するために必要なコードが定義されています。 私たちのコードでは、 TENSOR_PARALLEL_DEGREE 環境変数 (デフォルト値は 1)。 これは、テンソル並列モジュールが分散されるデバイスの数を設定します。 DeepSpeed は、BLOOM モデル用のものを含む、いくつかの組み込みパーティション定義を提供することに注意してください。 指定して使用します replace_method & relpace_with_kernel_inject. カスタマイズされたモデルがあり、効果的に分割するために DeepSpeed が必要な場合は、変更する必要があります relpace_with_kernel_inject 〜へ false と追加 injection_policy ランタイム パーティションを機能させるため。 詳細については、次を参照してください。 推論のための初期化. この例では、DeepSpeed で事前に分割された BLOOM モデルを使用しました。

第二に、 model.py ファイルに加えて、エンドポイントがスピンアップされた後、Amazon S3 からモデルもロードします。 モデルは /tmp SageMaker が /tmp Amazon Elastic Blockストア エンドポイント作成パラメータを指定したときにマウントされる (Amazon EBS) ボリューム VolumeSizeInGB. ボリューム インスタンスで事前に構築された p4dn のようなインスタンスについては、引き続き利用できます。 /tmp コンテナに。 次のコードを参照してください。

from djl_python import Input, Output
import os
import deepspeed
import torch
import torch.distributed as dist
import sys
import subprocess
import time
from glob import glob
from transformers import pipeline, AutoModelForCausalLM, AutoTokenizer
from transformers.models.opt.modeling_opt import OPTDecoderLayer

predictor = None

def check_config():
    local_rank = os.getenv('LOCAL_RANK')
    
    if not local_rank:
        return False
    return True
    
def get_model():

    if not check_config():
        raise Exception("DJL:DeepSpeed configurations are not default. This code does not support non default configurations") 
    
    tensor_parallel = int(os.getenv('TENSOR_PARALLEL_DEGREE', '1'))
    local_rank = int(os.getenv('LOCAL_RANK', '0'))
    model_dir = "/tmp/model"
    bucket = os.environ.get("MODEL_S3_BUCKET")
    key_prefix = os.environ.get("MODEL_S3_PREFIX")
    print(f"rank: {local_rank}")
    if local_rank == 0:
        if f"{model_dir}/DONE" not in glob(f"{model_dir}/*"):
            print("Starting Model downloading files")
            try:
                proc_run = subprocess.run(
                    ["aws", "s3", "cp", "--recursive", f"s3://{bucket}/{key_prefix}", model_dir]
                )
                print("Model downloading finished")
                # write file when download complete. Could use dist.barrier() but this makes it easier to check if model is downloaded in case of retry
                with open(f"{model_dir}/DONE", "w") as f:
                    f.write("download_complete")
                    
                proc_run.check_returncode() # to throw the error in case there was one
                
            except subprocess.CalledProcessError as e:
                print ( "Model download failed: Error:nreturn code: ", e.returncode, "nOutput: ", e.stderr )
                raise # FAIL FAST  
                               
    dist.barrier()
                
    
    tokenizer = AutoTokenizer.from_pretrained(model_dir)
    
    # has to be FP16 as Int8 model loading not yet supported
    with deepspeed.OnDevice(dtype=torch.float16, device="meta"):
        model = AutoModelForCausalLM.from_config(
            AutoConfig.from_pretrained(model_dir), torch_dtype=torch.bfloat16
        )
    model = model.eval()
    
    model = deepspeed.init_inference(
        model,
        mp_size=tensor_parallel,
        dtype=torch.int8,
        base_dir = model_dir,
        checkpoint=os.path.join(model_dir, "ds_inference_config.json"),
        replace_method='auto',
        replace_with_kernel_inject=True
    )

    model = model.module
    dist.barrier()
    return model, tokenizer

DJLServing は、で定義された任意の pip パッケージのランタイム インストールを管理します。 requirement.txt. このファイルには次のものが含まれます。

awscli
boto3

というディレクトリを作成しました。 code と model.py, serving.properties, requirements.txt ファイルはこのディレクトリに既に作成されています。 ファイルを表示するには、ターミナルから次のコードを実行します。

mkdir -p code
cat code/model.py 
cat code/serving.properties 
cat code/requirements.txt 

次の図は、 model.tar.gz.

最後に、モデル ファイルを作成し、Amazon S3 にアップロードします。

tar cvfz model.tar.gz code
s3_code_artifact = sess.upload_data("model.tar.gz", bucket, s3_code_prefix)

Hugging Face からモデルをダウンロードして保存する (オプション)

モデルを Amazon S3 にダウンロードしてそこから使用する場合に備えて、このセクションの手順を提供しています。 手順は、GitHub の Jupyter ファイルに記載されています。 次のスクリーンショットは、手順のスナップショットを示しています。

SageMaker モデルを作成する

ここで、 SageMakerモデル。 私たちは Amazon エラスティック コンテナ レジストリ (Amazon ECR) によって提供されたイメージと、前のステップのモデルアーティファクトを使用して、SageMaker モデルを作成します。 モデルのセットアップでは、構成します TENSOR_PARALLEL_DEGREE=8これは、モデルが 8 つの GPU に沿って分割されていることを意味します。 次のコードを参照してください。

PrimaryContainer={
        "Image": inference_image_uri,
        "ModelDataUrl": s3_code_artifact,
        "Environment": {
            "MODEL_S3_BUCKET": bucket,
            "MODEL_S3_PREFIX": s3_model_prefix,
            "TENSOR_PARALLEL_DEGREE": "8",
},

Jupyter ファイルで前のセルを実行すると、次のような出力が表示されます。

{
    "ModelArn": "arn:aws:sagemaker:us-east-1::model/bloom-djl-ds-"
}

SageMakerエンドポイントを作成する

テストには、複数の GPU を備えた任意のインスタンスを使用できます。 このデモでは、p4d.24xlarge インスタンスを使用します。 次のコードで、 ModelDataDownloadTimeoutInSeconds, ContainerStartupHealthCheckTimeoutInSeconds, VolumeSizeInGB 大きなモデル サイズに対応するパラメータ。 の VolumeSizeInGB パラメータは、EBS ボリューム アタッチメントをサポートする GPU インスタンスに適用されます。

endpoint_config_response = sm_client.create_endpoint_config(
    EndpointConfigName=endpoint_config_name,
    ProductionVariants=[
        {
            "VariantName": "variant1",
            "ModelName": model_name,
            "InstanceType": "ml.p4d.24xlarge",
            "InitialInstanceCount": 1,
            #"VolumeSizeInGB" : 200,
            "ModelDataDownloadTimeoutInSeconds": 2400,
            "ContainerStartupHealthCheckTimeoutInSeconds": 2400,
        },
    ],
)'

最後に、SageMaker エンドポイントを作成します。

create_endpoint_response = sm_client.create_endpoint(
    EndpointName=f"{endpoint_name}", EndpointConfigName=endpoint_config_name
)

次のコードで出力されます。

{
    "EndpointArn": "arn:aws:sagemaker:us-east-1::endpoint/bloom-djl-ds-"
}

エンドポイントの開始には時間がかかる場合があります。 に遭遇した場合は、さらに数回試すことができます InsufficientInstanceCapacity または、AWS にリクエストを発行して、アカウントの制限を引き上げることができます。

パフォーマンスチューニング

この投稿と付属のノートブックを別のモデルで使用する場合は、SageMaker、DeepSpeed、および DJL が提供する調整可能なパラメーターのいくつかを調べてみてください。 これらのパラメーターを繰り返し実験すると、ホストされている大規模モデルのレイテンシー、スループット、およびコストに重大な影響を与える可能性があります。 ワーカーの数、テンソルの並列度、ジョブ キューのサイズなどのパラメーターの調整の詳細については、次を参照してください。 DJL サービング構成 & DJLServing と DeepSpeed モデルの並列推論を使用して、Amazon SageMaker に大規模なモデルをデプロイする.

結果

この投稿では、DeepSpeed を使用して、SageMaker ML インスタンスで BLOOM-176B と OPT-30B をホストしました。 次の表は、Hugging Face の Accelerate との比較を含む、パフォーマンス結果をまとめたものです。 レイテンシは、256 トークンの文字列を XNUMX 回生成するのにかかるミリ秒数を反映します (batch_size=4) モデルから。 スループットは、各テストで XNUMX 秒あたりに生成されるトークンの数を反映しています。 Hugging Face Accelerate では、GPU メモリ マッピングを使用したライブラリのデフォルトの読み込みを使用しました。 DeepSpeed では、より高速なチェックポイント読み込みメカニズムを使用しました。

レイテンシの観点から、DeepSpeed は Accelerate よりも BLOOM-3.4B で約 176 倍、OPT-5.6B で 30 倍高速です。 DeepSpeed の最適化されたカーネルが、このレイテンシの違いの多くを担っています。 これらの結果を考慮して、選択したモデルがサポートされている場合は、Accelerate よりも DeepSpeed を使用することをお勧めします。

また、DeepSpeed を使用したモデルの読み込み時間が大幅に短縮されたことも注目に値します。これは、エンドポイントの数をすばやくスケールアップする必要があると予想される場合に適したオプションです。 DeepSpeed でサポートされていないモデルまたはモデルの精度がある場合は、Accelerate のより柔軟なパイプライン並列処理手法の方が適している場合があります。

これらの結果は、異なるモデル サイズのレイテンシとスループットの違いも示しています。 私たちのテストでは、OPT-30B は、BLOOM-2.4B よりも 176 倍以上安価なインスタンス タイプで、単位時間あたり 30 倍の数のトークンを生成します。 単位スループット ベースの価格では、g5.24xl インスタンスの OPT-8.9B は、p176d.4xl インスタンスの BLOOM-24B よりも XNUMX 倍優れています。 待ち時間、スループット、またはコストの制限が厳しい場合は、機能要件を達成できる最小のモデルを使用することを検討してください。

クリーンアップ

ベスト プラクティスの一環として、アイドル状態のインスタンスを削除することを常にお勧めします。 以下のコードは、インスタンスを削除する方法を示しています。

# - Delete the end point
sm_client.delete_endpoint(EndpointName=endpoint_name)

# - In case the end point failed we still want to delete the model
sm_client.delete_endpoint_config(EndpointConfigName=endpoint_config_name)
sm_client.delete_model(ModelName=model_name)

必要に応じて、S3 からモデル チェック ポイントを削除します

!aws s3 rm --recursive s3:///{s3_model_prefix}

まとめ

この投稿では、SageMaker の大規模なモデル推論コンテナーを使用して、BLOOM-176B と OPT-30B の XNUMX つの大規模な言語モデルをホストする方法を示しました。 単一の SageMaker ML インスタンスで複数の GPU を使用して、DeepSpeed のモデル並列技術を使用しました。

Amazon SageMaker とその大規模モデル推論機能の詳細については、以下を参照してください。 Amazon SageMaker が、構成可能なボリューム サイズとタイムアウト クォータを介して大規模モデルのデプロイをサポートするようになりました & リアルタイム推論.

著者について

サイモンザマリン はAI / MLソリューションアーキテクトであり、その主な焦点は、顧客がデータ資産から価値を引き出すのを支援することです。 余暇には、家族と過ごしたり、SFを読んだり、さまざまなDIYハウスプロジェクトに取り組んだりしています。

ルピンダー・グレワル AWS のシニア Ai/ML スペシャリスト ソリューション アーキテクトです。 彼は現在、SageMaker でのモデルと MLOps の提供に注力しています。 この役職に就く前は、モデルの構築とホスティングを行う機械学習エンジニアとして働いていました。 仕事以外では、テニスや山道でのサイクリングを楽​​しんでいます。

フランク・リュー AWSディープラーニングのソフトウェアエンジニアです。 彼は、ソフトウェアエンジニアと科学者のための革新的な深層学習ツールの構築に焦点を当てています。 余暇には、友達や家族と一緒にハイキングを楽しんでいます。

アランタン 大規模モデルの推論に関する SageMaker の主要な取り組みのシニア プロダクト マネージャーです。 彼は機械学習を分析の分野に適用することに情熱を注いでいます。 仕事以外では、アウトドアを楽しんでいます。

ダワル・パテル AWSのプリンシパル機械学習アーキテクトです。 彼は、分散コンピューティングや人工知能に関連する問題について、大企業から中規模の新興企業に至るまでの組織と協力してきました。 彼は、NLPおよびコンピュータービジョンドメインを含むディープラーニングに焦点を当てています。 彼は、顧客がSageMakerで高性能モデルの推論を実現するのを支援します。

青蘭 AWS のソフトウェア開発エンジニアです。 彼は、高性能 ML 推論ソリューションや高性能ロギング システムなど、Amazon でいくつかの挑戦的な製品に取り組んできました。 Qing のチームは、Amazon Advertising で最初の XNUMX 億パラメータ モデルを成功裏に立ち上げ、非常に低いレイテンシーを必要としました。 Qing は、インフラストラクチャの最適化とディープ ラーニングの高速化に関する深い知識を持っています。

チンウェイ・リー アマゾンウェブサービスの機械学習スペシャリストです。 彼は博士号を取得しました。 アドバイザーの研究助成金口座を破り、約束したノーベル賞を授与できなかった後、オペレーションズリサーチで。 現在、彼は金融サービスおよび保険業界の顧客がAWSで機械学習ソリューションを構築するのを支援しています。 暇なときは、読書と教育が好きです。

ロバート・ヴァン・デューセン は、Amazon SageMaker のシニア プロダクト マネージャーです。 彼は、大規模モデルの推論などのアプリケーション向けのディープ ラーニング モデルの最適化をリードしています。

シッダールス・ベンカテサン は、AW​​S 深層学習のソフトウェア エンジニアです。 彼は現在、大規模なモデルの推論のためのソリューションの構築に注力しています。 AWS に入社する前は、Amazon Grocery 組織で働き、世界中の顧客向けに新しい支払い機能を構築していました。 仕事以外では、スキー、アウトドア、スポーツ観戦を楽しんでいます。