Llama-2-70Bのベンチマーク

Built for Speed: ~10ms Latency, Even Under Load
Blazingly fast way to build, track and deploy your models!
- Handles 350+ RPS on just 1 vCPU — no tuning needed
- Production-ready with full enterprise support
本記事では、LLama2-70Bのパフォーマンスをレイテンシー、コスト、1秒あたりのリクエスト数(RPS)の観点からベンチマークします。これにより、ビジネス要件に基づいてそれが良い選択肢となり得るかを評価するのに役立ちます。なお、本記事では定性的なパフォーマンスについては触れていません。LLMを比較する様々な方法については、 こちらをご覧ください。
モデル:Llama2-70B
このブログでは、 Llama-2-70B モデルを NousResearch からベンチマークしました。これは、700億のパラメータを持つLlama-2の事前学習済みバージョンです。
Metaは、70億から700億のパラメータ規模にわたる事前学習済みおよびファインチューニングされた生成テキストモデルのコレクションである、大規模言語モデル(LLM)のLlama 2ファミリーを開発し、公開しました。
ベンチマークの指標
- 1秒あたりのリクエスト数(RPS): モデルが処理する1秒あたりのリクエスト数。RPSが高くなると、通常レイテンシーも上昇します。
- レイテンシー: 推論リクエストを完了するのにかかる時間はどのくらいですか?
- 経済性: LLMのデプロイに関連するコストはどのくらいですか?
ベンチマーク対象のユースケースとデプロイモード
ベンチマークを実施した際の主要な要素は以下の通りです。
GPUの種類:
- 4 x A100 40GB GPU
プロンプト長:
- 入力トークン1500、出力トークン100 (検索拡張生成のユースケースに類似)
- 入力トークン50、出力トークン500 (生成中心のユースケース)
ベンチマーク設定
ベンチマークには、オープンソースの負荷テストツールであるLocustを使用しました。Locustは、ユーザー/ワーカーを作成してリクエストを並行して送信することで機能します。各テストの開始時に、 ユーザー数 および スポーンレートを設定できます。ここで、 ユーザー数 は、同時に生成/実行できる最大ユーザー数を意味し、一方、 スポーンレート は、1秒あたりに生成されるユーザー数を意味します。
各デプロイ設定のベンチマークテストでは、まず 1 ユーザーから開始し、 ユーザー数 を徐々に増やして、RPSが着実に増加するまで続けました。テスト中には、 応答時間(ミリ秒) および 1秒あたりの総リクエスト数もプロットしました。
2つのデプロイ設定それぞれで、huggingfaceの text-generation-inference モデルサーバー( version=0.9.4)を使用しました。以下は、異なるモデル構成で text-generation-inference イメージに渡されたパラメータです。
ベンチマーク結果の概要
レイテンシー、RPS、およびコスト
一度に1つのリクエストのみを送信した場合に基づいて、最適なレイテンシーを計算します。スループットを向上させるため、LLMにはリクエストを並行して送信します。最大スループットとは、レイテンシーが大幅に悪化することなく、モデルが入力リクエストを処理できる場合を指します。

1秒あたりのトークン数
LLMは入力トークンと生成を異なる方法で処理するため、入力トークンと出力トークンの処理速度は別々に計算しています。

詳細な結果
A100 40GB GPU 4基(入力1500トークン + 出力100トークン)


上記のグラフから、 最適な応答時間 (ユーザー1人の場合) は 7.4秒。ユーザー数を増やしてモデルへのトラフィックを増やすと、スループットは 1.1 RPSまで、レイテンシーの大幅な低下なしに増加します。 1.1 RPSを超えると、レイテンシーが劇的に増加し、リクエストがキューに溜まっていることを意味します。
A100 40GB GPU 4基(入力50トークン + 出力500トークン)


上記のグラフから、 最適な応答時間 1ユーザー時 です。 33秒ユーザー数を増やしてモデルへのトラフィックを増やすと、スループットは 0.8 RPSまではレイテンシーの著しい低下は見られません。それを超えると、 0.8 RPSでは、レイテンシーが大幅に増加し、リクエストがキューに溜まっていることを意味します。
LLama2-70Bがあなたのユースケースに適しているか、またホスティングにかかるであろうコストを判断する上で、この情報がお役に立てば幸いです。
TrueFoundry AI Gateway delivers ~3–4 ms latency, handles 350+ RPS on 1 vCPU, scales horizontally with ease, and is production-ready, while LiteLLM suffers from high latency, struggles beyond moderate RPS, lacks built-in scaling, and is best for light or prototype workloads.


















.webp)
.webp)







.png)

.png)














