生産環境における大規模な言語モデル
_あなたがメンバーではないが、この記事を読みたい場合は、この友達リンクをチェックしてください。 _
さまざまなサイズのオープンソースモデルを試している場合、不思議に思うかもしれません。それらを展開する最も効率的な方法は何ですか？
従量制のプロバイダーとサーバーレスプロバイダーの価格差は何ですか？また、LLMサービスプラットフォームが存在する場合、AWSのような参加者を処理する価値がありますか？
このトピックを掘り下げて、AWSのようなクラウドベンダーを、モーダル、ベントムル、複製、フェイスエンドポイントを抱き締めるなどの更新された代替品を比較することにしました。
処理時間、コールドスタートレイテンシ、CPU、メモリ、GPUコストなどのメトリックを調べて、どのものが最も効果的で経済的であるかを確認します。また、展開の容易さ、開発者エクスペリエンス、コミュニティなど、より柔らかいメトリックも取り上げます。
CPUに小さなモデルの展開やGPUで7〜80億個のパラメーターモデルを実行するなど、いくつかのユースケースを調査します。
ここでは、さまざまなフレームワークや量子化を使用して推論を高速化するなど、最適化戦略の深さには入りません。これは完全に個別のトピックです。
代わりに、この記事では、適切な展開オプションを選択する方法に焦点を当て、さまざまなシナリオでパフォーマンスを比較する機会を与え、大小のLLMを展開する経済コストを理解するのに役立ちます。
はじめに
これらのモデルもローカルでホストすることもできますが、コンピューターには十分なリソースが必要であり、これらのモデルを別のサーバーで実行されているアプリケーションに統合することをお勧めします。
これにより、オープンソースモデルをオンデマンドまたはサーバーレスプラットフォームを介してホストすることになります。アイデアは、ServerLessのように、使用するリソースのみを使用しているか、実行中であろうと、使用するリソースのみを支払うということです。
サーバーレスおよびオンデマンド作業は少し似ていますが、サーバーレスではスケーリングが速いため、アイドルリソースに支払う必要はありません。
以下のDoodleをチェックして、さらに比較することができます。
このように、何が最適かをよりよく理解することができます。
サイドノートとして、私はこれらのベンダーから補償を受けていないので、ここで共有する情報は私の個人的な意見です。
あなたが利害関係者である場合、これはさまざまなオプションの経済性と、モデルサイズとベンダーの選択に基づいて推論を実行するコストを理解する素晴らしい方法です。
記事の最初の部分は、誰でも参加できる研究をカバーしていますが、2番目の部分では、読みたくない場合と読みたくない展開テクノロジーの側面をカバーしています。
さあ、始める前に、サービスモデルのAPIエンドポイントのセットアップを簡素化するLLM推論フレームワークについてコメントしたいと思います。 VLLM、Tensort、TGIなど、いくつかのオープンソースLLMサービスフレームワークが利用可能です。ここで使用できます。
以前に共有したリストのLLMサービスフレームワークセクションで、より一般的なフレームワークのいくつかをチェックできます（以下を参照）。
これらのフレームワーク間のパフォーマンスの違いを測定している人もいれば、間違いなく独自の研究を行う必要があります。
CPUで実行されている小型コンバーターモデルを展開するには、ハグの顔
pipelineまたはTransformersライブラリを直接使用しました。 研究
処理時間
処理時間を、応答を完了するのにかかる合計時間として定義します。
特にストリーミング出力の場合、一部の人は最初の応答時間を測定できることに注意してください。一貫性のために、各テストに同じプロンプトを使用しました。 400mモデルの場合、テキストを30個にバッチしました。
以下のインジケーターを見ることができます。
同じ日に各プラットフォームでこれらのテストを数回しか実行しませんでした。理想的には、数日でテストする必要があります。私はこれらのテストのいくつかについて不運かもしれません。 
ただし、****サーバーレスプロバイダーのパフォーマンスを議論するために、MODALとBeamはCPUで非常にうまく機能します（薄緑色のバーとして表示）。 8Bモデルを開始するよりも、400mモデルを開始する方が簡単です。
特にEFSキャッシュモデルを使用する場合、小さいモデル（130m未満）であっても、AWSラムダで動作することがわかります。
私は顔のエンドポイントを抱き締めるのが本当に好きですが、彼らのCPUインスタンスは少し予測不可能であることがわかりました。ただし、彼らのAWS GPUインスタンスは非常に信頼性が高く、高速です。
7BモデルをL4インスタンスでホストしている場合でも、GPUで非常に高速な応答を得ることができます。これは10秒で返すことができます。これはサーバーレスプロバイダーで実装できないものです。強力なGPU。
A100 GPUを選択すると、すべてのプロバイダーが7B-8Bパラメーターモデルに対して非常にうまく機能し、秒単位で完全な応答を返すことができます。
もちろん、速度は非常に高速ですが、他の指標を考慮する必要があります。
次に、コールドスタートに飛び込みましょう。つまり、モデルがしばらく使用されない場合に応答するのにどれくらいかかるか。モデルをキャッシュしても、数秒を追加する可能性のあるシャードをダウンロードする必要がある場合があります。
オンデマンドサービスでは、モデルをキャッシュしてスタートアップ時間をスピードアップできる場合があります。ここではこれを行っていませんが、ほとんどのサーバーレスプロバイダーはビルド時にモデルをキャッシュする方法を示します。
次のプラットフォームの指標を見てみましょう。
コールドスタート中に処理時間全体を計算したことに注意してください。コールドスタートのみの計算を直接確認してください。
hugging hugging hugging face endpointは実行後もうまく機能しますが、最後の30秒から5分間のコールドスタートを経験する場合があります。これは、頻繁にスケーリングしてスケーリングする必要がある場合に問題になる可能性があります。また、コンテナが完全に再び実行される前に、500のエラーを投げます。
サーバーレスプロバイダーは、最初の展開時にモデルの重みをキャッシュする必要があることにより迅速にスケーリングするように設計されているため、より速くなります。
BeamはCPUで最適に機能し、続いてEFSを使用したBaseten、Modal、Lambdaが続きます。通常、小さいモデルはより速く始まります。 Lambdaは、125mパラメーターしかない小さなモデルでは、処理時間が速く、最小限のコールドスタートレイテンシで優れた結果を示します。
より小さなモデルにモーダルまたはビームを使用するのは良いことだと思いますが。
gpuおよびcpu価格
プラットフォームにはいくつかの明らかな違いがあります。
GPUの使用に加えてCPUおよびメモリ料金を請求するため、サーバーレスプロバイダーはしばしばより高価です。ただし、アイドル時間のために請求することはありません。これは、より高いコストを相殺するのに役立ちます。下の写真でNvidia GPUの価格を見つけることができます。
ただし、Sagemakerを見る必要があります。Sagemakerは、すべてのGPUコストが高いことです。 AWSを使用する必要がある場合は、EC2を直接使用することをお勧めします。
CPU価格も見てみましょう。
フェイスエンドポイントを抱きしめて、2つのVCPUと4GBのメモリがあり、残念ながらCPUインスタンスはパフォーマンスが低いです。
ビームとモーダルを使用すると、必要なリソースを調整できます。これにより、コストを最小限に抑えることができます。 400mモデルでは、両方のプラットフォームで3GBのメモリと1コア（2 VCPU）のみが必要であると計算しました。
一方、複製では、モデルサイズに関係なく4つのVCPUを使用するように強制され、ここで最も高価なCPUオプションになります。
これらすべてのプラットフォームの価格と効率を比較するために、いくつかのユースケースをカバーします。
最初のケースは、1日を通して400mモデルの散発的な操作です。これは、コンテナへの各呼び出しにスケールアップとダウンサイズが必要であることを意味します。
スケーリングとスケーリングに必ずしも必要ではありませんが、カウントする必要があります。
このケーススタディを実行して、1日を通して250個のコールを使用して、コールごとに30個のテキストをバッチ（小さい微調整モデルを使用して）にバッチします。 簡単にするために、コンテナが走るたびにコールドスタートされていると仮定します（ハグする顔のエンドポイントを除く）。
サーバーレスプロバイダーは、オンデマンドのようにアイドル時間を支払うことはないため、ここではより良い選択です。 Bentomlの場合、サイズを自動的に縮小する前に少なくとも5分間アイドル状態を維持する必要があり、HFエンドポイントの場合、15分間待つ必要があります。
HFエンドポイントは縮小に少なくとも15分かかるため、5〜6分ごとに関数を呼び出すとスケーリングする時間がないため、コールドスタートはほとんどありませんが、ほとんどの場合はアイドル状態です。 。サイドノート、自動スケール削減に精通していない場合、この概念は、許可された場合、プラットフォームにインスタンスを自動的にスケーリングするように指示することを意味します。
それらにはすべて異なる要件があり、BasetenとHFのエンドポイントには15分間の無料ウィンドウがあり、Bentomlには5分があります。
HFケースのような17時間の自由時間があり、ベントムルの場合は18時間が本質的に非効率的であることがわかります。私たちは、ほとんどの資金を一日中アイドルリソースに支払います。
ここでは1セントまたは1ドルあり、最初の数日間はそれほど多くないようですが、しばらくすると蓄積されます。
毎日普通預金口座に少量のお金を節約している人を考えてみてください。ここで過払いは逆です。
しかし、コンテナが予熱された状態にある間に250個すべての通話を実行した場合はどうなりますか？どのくらいの違いがありますか？
ビームはここでは外れ値のように見えますが、他のプラットフォームでは使用できない最大のCPU以上に実行していると思います。
この場合、コールドスタートと自由時間は消えます。これは、すべてに一度に作業する場合、永続的な容器を使用することがより良いオプションであることを示しています。それははるかに安いことです。
フェイスエンドポイントとベントムルを抱き締めるために、400mモデルがT4 GPUに最適であることは注目に値します。この設定により、コストが削減され、処理時間が大幅に短縮されます。
注意すべきことの1つは、EFSでAWS Lambdaを使用する場合、NATゲートウェイに追加料金が発生することです。
さあ、2番目のケースに進みましょう。GPUで実行されている7Bから8Bのパラメーターを備えたより大きなモデルです。
この場合、ミストラル、ジェマ、ラマなど、ミストラル、ジェマ、ラマなどのサイズのモデルをテストしています。
このシーンには、モデルへの散発的な呼び出しが1日を通して250回の散発的な呼び出しが含まれます。コンテナは、それが呼び出されるたびにスケーリングしてスケールダウンすると仮定しますが、これは必ずしもそうではありません。
CPUテストと同様に、オンデマンドサービスはスケールダウンする時間がないため24時間実行されると想定しています。
各ベンダーに使用するGPUインスタンスを必ず書き留めました。以下のバーチャートを確認してください。
サーバーレスプロバイダーの場合、乗算により処理時間をわずかに誇張していますが、総価格計算からコールドスタートを除外しました。
実際のコストが低い場合がありますが、この調整は注意してください。いくつかのスタートアップにお金を払うので、あなたはもっと請求されるかもしれません。
CPUケースで見たように、一度に250個の通話を実行する方が費用対効果が高くなります。
人類とOpenaiの最も安いモデルの計算を設定し、それらを自己ホスティングのコストと比較すると、同じプロンプトでそれらを呼び出すモデルは、ホストよりもはるかに安価であることがわかります。
人々はこれらのサプライヤーをLLMのマクドナルドを呼び出します。
オープンソースは安くなると考えていますが、ホスティングの実際のユニットエコノミーは計算しません。これらのプラットフォームは、ベンチャーキャピタルファンドによっても助成されています。しかし、前述したように、ここで見つけることができるベンダーを使用してオープンソースモデルにアクセスする方が安価です。
詳細な計算を掘り下げたい場合は、このファイルを表示できます。公正な警告 - 少し乱雑に見えます。
これまでのところ、あなた自身の結論に達したかもしれませんが、私が最後に紹介したいのはユーザーエクスペリエンスです。
HFエンドポイントは、Coderでない場合は非常に使いやすいです。簡単なクリックでHuggingfaceセンターからモデルを展開できます。いくつかのテクノロジーを知っている場合は、さらに制御できる他のオプションを好むかもしれません。
複製するために、彼らは大ファンとさまざまな人々が共有する多くのパブリックモデルを持っています。周りにはコミュニティがあります。操作を容易にするために、ワンクリックトレーニングと展開プロセスがいくつかあります。
しかし、Modal、Beam、およびBentomlは、全体的に優れた開発者エクスペリエンスを持つことがわかりました。端末から直接展開し、そのサーバーでコードを実行することができます。
複製の場合、独自のモデルを展開する場合は、GPUマシンが必要になり、BasetenにはTrussというライブラリをダウンロードする必要があります。
この表にメモの一部を収集しました（以下を参照）。
これらのいずれかを使用したい場合、テーブルにはリンクも含まれてスクリプトを開始します。
非技術的な側面のほとんどをカバーしたので、CPU、AWSラムダ、モーダルでうまく機能するモデルの2つの展開オプションを説明します。
両方のツールはサーバーレスです。つまり、構築時にモデルを正しくキャッシュする必要があるため、連続的な実行で迅速にアクセスできます。 AWSは、簡単に調整できる既製のスクリプトを提供し、ここでモーダル用のスクリプトも準備しました。
2つのことに焦点を当てます。各プラットフォームにモデルを展開する方法と、展開プロセスの重要な違いを反映する方法です。
EFSを使用してLambdaに展開します
それに従うには、Git、AWS CDK、Docker、Nodejs 18、Python 3.9をコンピューターにインストールする必要があります。これらすべてをインストールした後、新しい端末を開くことができます。
新しいディレクトリを作成する場合は、以下のリポジトリをクローンします。
作成されたディレクトリを入力します。
<code>git clone https://github.com/aws-samples/zero-administration-inference-with-aws-lambda-for-hugging-face.git</code>
コードエディターでこれらのファイルを開くことができます。
<code>cd zero-administration-inference-with-aws-lambda-for-hugging-face</code>
vscodeを使用しているので、やります。
ここで、作成されたファイルに移動して、それを調整することができます。推論フォルダーを見ると、2つのファイル、sentiment.pyとsummary.pyが表示されます。
<code>.code</code>
これらのファイルのモデルを希望するファイルに簡単に変更できます。
Huggingface Centerに行って、興味のあるモデルを見つけたら。
自分のモデルの1つを使用します。
このようなモデルの構築方法を学ぶことに興味がある場合は、ここでキーワード抽出チュートリアルとテキスト分類チュートリアルをご覧ください。
興味のあるモデルを見つけたら、[このモデルを使用]ボタンをクリックできます。
通常使用する新しいモデルを使用して、次のファイルのコードを変更しましたが、「テキスト」だけでなく、バッチ処理に「テキスト」が使用されることも期待しています。
上記の画像を表示して、ファイル構造を表示できます。
<code>git clone https://github.com/aws-samples/zero-administration-inference-with-aws-lambda-for-hugging-face.git</code>
通常使用するさまざまなモデルを使用して、両方のスクリプトを変更しました。終了したら、スクリプトを保存してください。
ターミナルに仮想環境を設定できます。
要件をダウンロードする前に、Nodejs 18があることを確認してください。
<code>cd zero-administration-inference-with-aws-lambda-for-hugging-face</code>
AWS CDKで構成したユーザーが、他のことをする前に正しい権限を持っていることを確認する必要があります。
<code>.code</code>
の後、ブートストラップを実行できます。
<code># inference/summarization.py
import json
from transformers import pipeline
extractor = pipeline("text2text-generation", model="ilsilfverskiold/tech-keywords-extractor")
def handler(event, context):
# texts should be an array
texts = event['texts']
response = {
"statusCode": 200,
"body": extractor(texts)[0]
}
return response</code>ここでECRに問題がある場合は、手動でリポジトリを作成します。
<code>python3 -m venv venv source venv/bin/activate</code>
コンピューターでDockerを実行すると、端末を介して展開できます。
ここから、CDKは、推論フォルダーのDockerFileを使用してLambda関数のDocker画像の構築を開始します。各ラムダ関数には、
8 gBのメモリ<code>pip install -r requirements.txt</code>
600秒のタイムアウトが装備されています。 インターネットゲートウェイ、キャッシュモデル用のEFS、いくつかのDockerベースのLambda関数（スクリプトのホスティングで2つのモデルの場合）、およびLambda実行のいくつかのiamの役割
VPCを作成します。これには時間がかかります。
私はこれをイタリアの小さな村で行っていたので、インターネット接続が失敗し、展開のためにGPUマシンをレンタルしなければなりませんでした。
これはあなたには起こらないかもしれませんが、十分なリソースと展開する安定したインターネット接続があることを確認してください。 
ラムダ関数はプライベートサブネット（VPC）にあるため、インターネットにアクセスできないため、AWSがNATゲートウェイを作成するという指示がいくつかあります。ただし、Nat Gatewayを使用するのは高価であり、いくら使用しても、1日あたり約1〜3ドルが発生します。
ラムダ関数をパブリックサブネットに配置しようとすることはできますが、残念ながら私はそれを試しませんでした。この問題をバイパスしてVPCエンドポイントを作成する方法があるかもしれません。
EFS用のVPCが必要なため、機能を呼び出すたびにモデルをダウンロードする必要がないように、モデルをキャッシュできるようにします。はい、AWS Lambdaには非常に寛大な無料のティアがありますが、他のリソースを追加する際には他のコストに注意する必要があります。
完了したら、24時間年中無休でNATゲートウェイを支払う必要がないように、これらのリソースを破壊することをお勧めします。
<code>git clone https://github.com/aws-samples/zero-administration-inference-with-aws-lambda-for-hugging-face.git</code>
ただし、125mパラメーター以下の小さなモデルを使用する場合、AWS Lambdaを完全に無視することはありません。メモリが少ないラムダ関数を構成できます。
モーダル
に展開します展開すると、関数でメモリ、CPU、およびGPUを直接指定できます。また、スクリプトでエンドポイントを作成することを依頼することもできます。これにより、エンドポイントを使用してモデルのテストが容易になります。
しかし、私たちが別のプラットフォームを使用しているからといって、それが私たちにもお金がかからないという意味ではありません。
前に行った計算を覚えておいてください。
開始するには、モーダルアカウントが必要で、Python3をインストールする必要があります。アカウントを作成した後、端末を開き、新しいフォルダーを作成できます。
その後、仮想環境をセットアップできます。
<code>cd zero-administration-inference-with-aws-lambda-for-hugging-face</code>
PIPを使用してモーダルパッケージをインストールします。
<code>.code</code>
<code># inference/summarization.py
import json
from transformers import pipeline
extractor = pipeline("text2text-generation", model="ilsilfverskiold/tech-keywords-extractor")
def handler(event, context):
# texts should be an array
texts = event['texts']
response = {
"statusCode": 200,
"body": extractor(texts)[0]
}
return response</code>を使用して、すべてのリソース、環境設定、および実行は、オンプレミスではなくプラットフォーム上で行われるため、AWSに展開するときと同じ問題はありません。 認証するには、このコマンドを実行します。
さて、フォルダーにファイルがない場合は、作成します。
<code>python3 -m venv venv source venv/bin/activate</code>
次のコードを単純に貼り付けることができますが、紹介します。
<code>pip install -r requirements.txt</code>
同じモデルを使用していることを忘れないでください。別のモデルを使用できます。
<code>{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ecr:*",
"ssm:*",
"iam:*",
"lambda:*",
"s3:*",
"ec2:*",
"logs:*",
"cloudformation:*",
"elasticfilesystem:*"
],
"Resource": "*"
}
]
}</code>展開するには、次のコマンドを実行するだけです。
このスクリプトは、
モーダル<code>cdk bootstrap</code>
これらの依存関係をモーダル環境に直接インストールするため、ローカルで対処する必要はありません。アプリは、1 CPU Coreおよび3 GBのメモリを要求します。これは、テスト中に使用した設定です。
モデルキャッシュは、@modal.build（）で処理されます。これは、snapshot_download（）を使用して、顔を抱きしめて /キャッシュで保存してモデルを抽出します。コールドブーツでより速く呼び出すことができるように、これを行う必要があります。
@modal.enter（）デコレーターは、テキストエクストラクションクラスへの最初の呼び出しで実行され、キャッシュされたファイルからメモリにトークネイザーとモデルをロードします。
モデルを読み込んだ後、推論を実行するにはextract_text（）メソッドを呼び出すことができます。 @Modal.Web_Endpointは、POSTリクエストでextract_Text（）を押してテキスト抽出結果を取得できるサーバーレスAPIエンドポイントを設定します。
プロセス全体がモーダル環境で実行されるため、コンピューターに十分なリソースがあるかどうかを心配する必要はありません。もちろん、これはより大きなモデルにとってより重要です。
展開が完了した後、端末にこれに似たものが表示されます。これにはエンドポイントが含まれています。
このアプリケーションはモーダルダッシュボードで表示できます。
<code>git clone https://github.com/aws-samples/zero-administration-inference-with-aws-lambda-for-hugging-face.git</code>
いくつかの指示
新しいプラットフォームを使用することは必ずしも悪いことではなく、はるかに高速になります。ただし、組織が使用できるプラットフォームに厳格な制限がある場合があります。
使用が簡単で、わずかに高くなる可能性がありますが、EC2を直接使用するコストとそれほど違いはありません。
これを見たことがあるなら、私がここで行った研究を理解し、サプライヤーを選ぶのに役立つことを願っています。
❤
以上がオープンソースLLMSをホストする経済学の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
