LLAMA 2モデルの性能評価ベンチマークを理解する

本記事では、LLama2-7Bのパフォーマンスをレイテンシー、コスト、1秒あたりのリクエスト数（RPS）の観点からベンチマークします。これにより、ビジネス要件に基づいてそれが良い選択肢となり得るかを評価できます。なお、本記事では定性的なパフォーマンスについては触れていません。LLMを比較する様々な方法は こちらで確認できます。

モデル：Llama2-7B

このブログでは、 Llama-2-7B モデルを NousResearchからベンチマークしました。 これは、70億のパラメータを持つLlama-2の事前学習済みバージョンです。

‍

NousResearch/Llama-2-7b-hf · Hugging Face

We’re on a journey to advance and democratize artificial intelligence through open source and open science.

‍

Metaは、大規模言語モデル（LLM）であるLlama 2ファミリーを開発し、一般公開しました。これは、70億から700億のパラメータ規模に及ぶ、事前学習済みおよびファインチューニングされた生成テキストモデルのコレクションです。

LLAMA 2モデルでベンチマークされたメトリクス：主要なパフォーマンス指標の評価

1. 1秒あたりのリクエスト数（RPS）： モデルが処理する1秒あたりのリクエスト数。RPSが高くなると、通常レイテンシーも増加します。
2. レイテンシー： 推論リクエストを完了するのにどれくらいの時間がかかりますか？
3. 経済性： LLMの導入にはどのような費用がかかりますか？

LLAMA 2を用いたユースケースとデプロイモード：シナリオの評価

ベンチマーク評価を行った主要な要素は以下の通りです。

GPUの種類：

1. A100 40GB GPU
2. A10  24GB GPU

プロンプト長：

1. 入力トークン1500、出力トークン100 （検索拡張生成（RAG）のユースケースと同様）
2. 入力トークン50、出力トークン500 （生成中心のユースケース）

LLAMA 2を用いたベンチマーク設定：テスト環境の構築

ベンチマークには、オープンソースの負荷テストツールであるLocustを使用しました。Locustは、ユーザー/ワーカーを作成してリクエストを並行して送信することで機能します。各テストの開始時に、設定できるのは ユーザー数 と スポーンレートです。ここで ユーザー数 同時に生成/実行できるユーザーの最大数を示し、一方、 生成レート は1秒あたりに生成されるユーザー数を示します。

各デプロイ設定のベンチマークテストでは、 1 ユーザーから開始し、 ユーザー数 をRPSが着実に増加するまで徐々に増やしていきました。テスト中、私たちは 応答時間（ミリ秒単位） および 1秒あたりの総リクエスト数をプロットしました。

2つのデプロイ設定のそれぞれで、huggingfaceの text-generation-inference モデルサーバーを使用しました。その version=0.9.4です。以下は、 text-generation-inference イメージに渡された、異なるモデル構成のパラメータです。

‍

‍

Here's The Evaluation Framework for Proposal Template

Criteria	What should you evaluate ?	Priority	TrueFoundry
Unified API & Routing
Unified OpenAI-compatible endpoint	Is the gateway API compatible with OpenAI's /v1/chat/completions and /v1/responses formats, allowing consistent access across different models through a standardized interface?	Must have	✅ Supported: OpenAI-compatible endpoint across all providers.
Provider and model coverage	Does it support leading providers like OpenAI, Azure OpenAI, Amazon Bedrock, Anthropic, Gemini, Groq, plus self-hosted models?	Must have	✅ Supported: 1000+ LLMs across hosted and self-hosted providers.
Model onboarding speed	How quickly can new models (OpenAI-compatible and non-standard APIs) be added without code changes?	Must have	✅ Supported: config-driven onboarding within minutes.
Multimodal support	Does the gateway support text, vision, audio, image generation, and embeddings through a single interface?	Depends on use case	✅ Supported: chat, embeddings, images, audio, rerank, and realtime APIs.
Routing, load balancing, fallback	Can requests be routed by model, provider, latency, priority, weight, region, and failure state with automatic retries?	Must have	✅ Supported: load balancing, fallbacks, weighted and latency-based routing.
Model switching without code change	Is model switching supported via headers or config without changing client code?	Must have	✅ Supported: header-based and config-based model switching.

AI Gateway Evaluation Checklist

A practical guide used by platform & infra teams

ベンチマーク結果の概要：LLAMA 2の調査結果を要約

レイテンシー、RPS、コスト

最高のレイテンシーは、一度に1つのリクエストのみを送信した場合に基づいて計算されます。スループットを向上させるため、LLMにリクエストを並行して送信します。最大スループットとは、レイテンシーを大幅に悪化させることなく、モデルが入力リクエストを処理できる状態を指します。

トークン/秒

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

詳細な結果：LLAMA 2の詳細分析

A10 24GB GPU (入力1500トークン + 出力100トークン)

上記のグラフから、 最適な応答時間 (1ユーザーの場合) は 4.1秒。ユーザー数を増やしてモデルへのトラフィックを増やすことで、スループットは 0.9 RPSまで、レイテンシーの大幅な低下なしに増加します。 0.9 RPSを超えると、レイテンシーが大幅に増加し、リクエストがキューに溜まっていることを意味します。

A10 24GB GPU (50入力 + 500出力トークン)

上記のグラフから、 最適な応答時間 （1ユーザー時） は 15秒。ユーザー数を増やすことでモデルへのトラフィックを増やせます。スループットは〜まで増加することがわかります。 0.9 RPSまで、レイテンシが大幅に低下することなく。〜を超えると 0.9 RPSでは、レイテンシが劇的に増加し、リクエストがキューに滞留していることを示しています。

A100 40GB GPU (1500入力 + 100出力トークン)

上記のグラフから、 最適な応答時間 （1ユーザー時） は 2秒。ユーザー数を増やすことでモデルへのトラフィックを増やせます。スループットは〜まで増加することがわかります。 3.6 RPSまではレイテンシーの大幅な低下は見られません。それを超えると、 3.6 RPSでは、レイテンシーが劇的に増加し、リクエストがキューに溜まっていることを意味します。

A100 40GB GPU（入力50トークン + 出力500トークン）

上記のグラフから、 最良応答時間 （ユーザー1人の場合） は 8.5秒であることがわかります。ユーザー数を増やしてモデルへのトラフィックを増やすことができます。スループットは 3.5 RPSまではレイテンシーの大幅な低下なしに増加することがわかります。それを超えると、 3.5 RPSでは、レイテンシーが劇的に増加し、リクエストがキューに溜まっていることを意味します。

この情報が、LLama7Bがあなたのユースケースに適しているかどうか、またLLama7Bをホスティングする際に発生するであろうコストを判断するのに役立つことを願っています。