LLMを大規模にデプロイする

オープンソースの大規模言語モデル（LLM）を、信頼性、低レイテンシー、費用対効果を確保しながら大規模にデプロイすることは、困難な作業となる場合があります。当社がLLMインフラストラクチャを構築し、お客様のために成功裏にデプロイしてきた豊富な経験に基づき、このプロセスで一般的に遭遇する主な課題のリストをまとめました。

LLMのデプロイにおける主な課題

モデルの単一インスタンスをホストするための最適な方法を見つける

LLMをホストするためのモデルサーバーには複数の選択肢があり、ユースケースに最適なパフォーマンスを得るために調整すべき様々な設定パラメータがあります。 TGI、 VLLM、 OpenLLM は、これらのLLMをホストするための最も一般的なフレームワークの一部です。詳細な分析は、こちらの ブログ。ホスティングに適したフレームワークを選択するには、ユースケースに合わせてこれらのフレームワークのパフォーマンスをベンチマークし、最適なものを選ぶことが重要です。また、これらのフレームワークには、最適なベンチマーク結果を引き出すのに役立つ独自の調整可能なパラメータがあります。

GPU群の確保

GPUは高価で入手が困難です。AWS、GCP、Azureのような主要なクラウドから、Runpod、Fluidstack、Paperspace、Coreweaveのような小規模なクラウドプロバイダーまで、様々なGPUクラウドプロバイダーが存在します。これらのプロバイダーはそれぞれ、価格と提供内容に大きなばらつきがあります。また、一部の新しいGPUクラウドプロバイダーでは、信頼性も懸念事項となっています。

信頼性の維持

これは実際には言うほど簡単ではありません。LLMを本番環境で運用してきた当社の経験からすると、モデルサーバーでプロセスがハングアップし、すべてのリクエストがタイムアウトするような奇妙な単発バグに備える必要があります。モデルサーバーが障害から回復したり、トラフィックが異常なインスタンスから正常なインスタンスへシームレスに切り替わったりできるように、適切なプロセス管理とレディネス/ライブネスプローブを設定することが非常に重要です。

低レイテンシーで高スループットを確保する

ベンチマークを行う際には、レイテンシーとスループットのトレードオフを把握することが非常に重要です。モデルへの同時リクエスト数を増やすと、ある時点まではレイテンシーがわずかに上昇しますが、その後は急激に悪化します。レイテンシー、スループット、コストの間の適切なバランスを見つけることは、時間と手間がかかり、エラーが発生しやすい作業です。当社では、このようなベンチマークについて概説したブログをいくつか公開しています。 Llama7B と Llama13B。

Benchmarking Llama-2-70B

This blog captures Llama-2-70B benchmarks - where a model excels and the areas where it struggles. Make informed decisions about its practical deployment.

TrueFoundry Blog Truefoundry

‍

Benchmarking Falcon-40B

This blog captures Falcon-40B-Instruct benchmarks - where a model excels and the areas where it struggles. Make informed decisions about its practical deployment.

TrueFoundry Blog Truefoundry

‍

モデルの高速な起動時間を確保する

LLMモデルは10GBから100GBと非常にサイズが大きいです。モデルサーバーの準備ができてからモデルをダウンロードし、ディスクからメモリにロードするまでに多くの時間がかかることがあります。プロセスが再起動した場合にモデルを再度ダウンロードするのを避けるため、モデルをディスクにキャッシュすることが不可欠です。また、ネットワークコストを節約するため、各レプリカがインターネット経由でモデルを繰り返しダウンロードするのではなく、一度モデルをダウンロードして複数のレプリカ間でディスクを共有する方が良いでしょう。

オートスケーリングを設定する

LLMホスティングの場合、別のレプリカの起動時間が長いため、オートスケーリングは難しいです。負荷が非常に急増する場合、通常はピーク時のレプリカ数に合わせてインフラをプロビジョニングする必要がありますが、ピークが特定の時間帯に予想される場合は、時間ベースのオートスケーリングがうまく機能します。

LLMを本番環境に導入するには？

1. まず、異なるモデルサーバー、GPU、パラメータを使用してLLMのベンチマークを行い、どこで最高のパフォーマンスが得られるかを確認します。理想的には、この Llama7Bに関するブログにあるようなベンチマークデータが必要です。
2. モデルはKubernetes上の複数のGPU、またはベアメタルインスタンスにセットアップできます。ヘルスチェック、ルーティング、フェイルオーバーがすべて無料で利用できるため、理想的にはKubernetesをお勧めします。
3. モデルが繰り返しダウンロードされないように、EFSのような共有ボリュームにモデルを配置し、そのボリュームをすべてのポッドにマウントします。
4. インスタンスの監視とアラートを設定する。
5. 理想的には、トラフィックのパターンを理解しやすくなるため、すべてのリクエストでトークンカウントを実行できるレイヤーを用意することをお勧めします。
6. トラフィックパターンを監視し、それに応じてオートスケーリングポリシーを調整します。
7. コスト削減のため、スポットインスタンスとオンデマンドインスタンスを組み合わせて利用します。

大規模なLLMホスティングのためのアーキテクチャ

当初は上記のアプローチで開始しましたが、すぐに以下のアーキテクチャに移行しました。これにより、非常に低いコストと高い信頼性でLLMをホスティングできるようになりました。

基本的に、異なるクラウドプロバイダーの異なるリージョンに複数のGPUプールを作成します。AWS、GCP、Azureのいずれかであれば通常スポットインスタンスを使用し、小規模なクラウドプロバイダーからはオンデマンドノードを使用します。また、中央にキューを配置し、すべてのリクエストを受け入れます。異なるGPUプールはキューからリクエストを消費し、処理結果をキューに戻し、そこからHTTPレスポンスがユーザーに返されます。このアーキテクチャの利点は以下の通りです。

1. スポットインスタンスによる高い信頼性： 複数のクラウドプロバイダーおよびリージョンのスポットインスタンスに負荷を分散しているため、すべてのスポットインスタンスが同時に停止する可能性は極めて低くなります。また、いずれかのプールが停止した場合でも、他の各プールが負荷を引き受けるように拡張できます。
2. 高負荷時でもキューがもたらす高い信頼性： HTTPサービスは、急なスパイクが発生すると503エラーを返し始めます。しかし、中間にキューがあるため、スパイク状のワークロードにも耐えることができます。スパイク時にはリクエストのレイテンシがわずかに増加しますが、失敗することはありません。中間にキューを追加することで、全体のレイテンシが約10〜20ミリ秒増加しますが、LLMの推論ユースケースでは全体の推論レイテンシが秒単位であるため、これは問題ありません。
3. コスト削減： これにより、オンデマンドインスタンスでLLMをホスティングする場合と比較して、コストを大幅に削減できます。コストの詳細な比較を以下で行います。
4. 詳細な分析： LLMゲートウェイ層は、受信リクエストに関する詳細な分析を計算し、リクエスト間のトークン分布も計算できます。また、後でファインチューニングを可能にするために、リクエストのログ記録を開始することもできます。
5. 特定のクラウドプロバイダーへの依存なし： このアーキテクチャにより、より良い価格が見つかった場合でも、ダウンタイムなしでGPUプロバイダーを別のプロバイダーに簡単に切り替えることができます。また、いずれかのプロバイダーが停止した場合でも、他のプールがシステムをスムーズに稼働させ続けます！

LLMホスティングにおけるコスト削減

ピーク時で毎秒10リクエスト、平均で毎秒7リクエストのLLMをホスティングするシナリオを考えてみましょう。ベンチマークにより、1台のA100 80GB GPUマシンが0.5 RPSを処理できるとします。また、トラフィックは1日のうち12時間は多く（約9〜10 RPS）、残りの12時間は少ない（7〜8 RPS）とします。

上記のデータに基づき、ピーク時の12時間と非ピーク時の12時間で必要なGPUマシンの台数を算出できます。

ピーク時の12時間： GPU 20台
非ピーク時の12時間： 15 GPU

Sagemakerを使用した場合、AWS、GCP、Azureのオンデマンドマシンに単純にホスティングした場合、そしてオートスケーリングを備えた独自のアーキテクチャを使用した場合のLLM実行コストを比較します。

Sagemakerでのホスティング費用（us-east-1リージョン）：

8基のA100 80GBマシン（ml.p4de.24xlarge）の費用 -> 1時間あたり47.11ドル

非ピーク時には2台、ピーク時には3台のマシンが必要になります。

月額総費用：8万5千ドル

AWSノードに直接ホスティングする場合の費用：

8基のA100 80GBマシン（p4de.24xlarge）の費用 -> 1時間あたり40.966ドル

非ピーク時には2台、ピーク時には3台のマシンが必要になります。

月額総費用：7万3千ドル

Truefoundryでのホスティング費用

スポットインスタンスや他のGPUプロバイダーを利用することで、平均GPU価格を1時間あたり2.5ドルまで抑えることができます。非ピーク時に15GPU、ピーク時に20GPUと仮定すると、総費用は以下のようになります。

2.5ドル * (15*12 + 20*12) * 30（1ヶ月あたりの日数） = 3万1千ドル

ご覧の通り、Sagemakerのほぼ30%の価格で、同じLLMを高い信頼性でホストできます。ただし、このアーキテクチャを構築し維持するには労力が必要です。 TrueFoundry はお客様のためにホスティングを支援したり、お客様自身のクラウドアカウントに手間なくホスティングしたりすることで、同時にコストを削減できます。