Red Hat OpenShift AI での LLM の推論パフォーマンスを評価する

生成人工知能 (AI) を取り巻く環境は、過去 1 年間で急速な進化を遂げました。生成大規模言語モデル (LLM) の力が増すにつれて、組織はその能力を、ビジネスニーズを満たすために活用しようとするようになっています。LLM の実行には多くの計算を必要とするため、基盤となるハードウェア、特に GPU をコスト効率よく使用するために、パフォーマンスが高く信頼できるプラットフォームに LLM をデプロイすることが極めて重要です。

この記事では、Red Hat OpenShift AI に含まれるモデル提供スタックにデプロイされた Llama-2 モデルのパフォーマンステストの方法と結果を紹介します。OpenShift AI は、AI 対応アプリケーションを構築、デプロイ、管理するツールを備えた柔軟でスケーラブルな MLOps プラットフォームです。オープンソース・テクノロジーを使用して構築されており、実験、モデル提供、革新的なアプリケーションの提供のための、信頼性と一貫性に優れた運用機能を提供します。

モデル提供スタック

ソフトウェアスタックを提供するモデルは、KServe、OpenShift Serverless、OpenShift Service Mesh に基づいています。Llama-2 モデルを実行するために Caikit と text-generation-inference-service (TGIS) も使用しました。ただし、OpenShift AI は OpenVINO もサポートしており、他のカスタムランタイムをモジュールとして使用する機能があります。NVIDIA GPU Operator は、Text Generation Inference サーバー (TGIS) コンテナが使用できるように GPU を管理および公開します。

図 1：KServe/Caikit/TGIS スタックのコンポーネントとユーザーワークフロー間の相互作用

KServe は、OpenShift Serverless と OpenShift Service Mesh を活用して、AI モデル推論のための最先端の提供機能を多数提供します。これらのコンポーネントにより、ネットワーク、サービス構成、自動スケーリング、および実稼働モデル提供のためのヘルスチェックに関連する複雑さがカプセル化されます。

Caikit ツールキットにより、ユーザーは開発に便利な API セットを使用してモデルを管理できます。Caikit は標準の gRPC (リモート・プロシージャー・コール) および HTTP インタフェースを提供しており、さまざまな基盤モデルのクエリに使用できます。推論サービスである TGIS にリクエストを転送します。

TGIS は、テキスト生成推論提供ツールキット Hugging Face の初期フォークです。継続的バッチ処理、動的バッチ処理、Tensor Parallelism (モデルシャーディング)、PyTorch 2 コンパイルのサポートなど、LLM 提供のパフォーマンスを最適化するいくつかの重要な機能を提供します。

NVIDIA GPU Operator は、OpenShift で NVIDIA GPU をプロビジョニングして使用するために必要なさまざまなソフトウェア・コンポーネントの管理を自動化します。これには、ドライバーコンテナ、デバイスプラグイン、Data Center GPU Manager (DCGM) メトリクスエクスポーターなどが含まれます。DCGM メトリクスエクスポーターにより、OpenShift のモニタリング Prometheus インスタンスを使用して、メモリー使用率、ストリーミングマルチプロセッサー (SM) 使用率などの GPU メトリクスを分析することが可能になります。

大規模言語モデルのパフォーマンステスト方法

大規模な言語モデルのパフォーマンスを評価するために、レイテンシーとスループットという従来の測定値に注目します。ただし、LLM に対するリクエストのエンドツーエンドのレイテンシーは、いくつかの要因によって大きく変動する可能性があります。LLM はトークンを 1 つずつ生成するため、最も重要な点は出力の長さです。したがって、レイテンシーは主にトークンごとのレイテンシー、つまり「出力トークンごとの時間」(TPOT) という観点で測定します。

トークンは、単語または単語の構成要素となる文字列を表すテキストの単位です。大規模言語モデルが処理する際には、テキストはまずトークンに変換されます。テキストをトークンにマッピングするために使用される具体的なスキームは、モデルによって異なります。各トークンには、それを表す数値が割り当てられてベクターとして配列され、モデルへの提供とモデルからの出力はベクターで行われます。

リクエストの合計レイテンシーに影響を与えるもう 1 つの要素は、「プリフィル」の時間です。これは、入力プロンプトトークンが処理され、モデルが最初の新しいトークンを生成するまでにかかる時間を指します。リクエストの合計レイテンシーに大きく影響する 3 番目の要因は、キュー時間です。GPU メモリーなどのハードウェアの制約により、推論サービスの処理速度が入力の速度に追いつかなくなった場合、一部のリクエストはキューで処理を待たなければなりません。これらの要因により、「最初のトークンまでの時間」(TTFT) が LLM のパフォーマンスを測定するための一般的な指標となっています。TTFT は特に、トークンがストリーミングされ、生成と同時に表示されるチャットボットのようなユースケースに適しています。

レイテンシーと同様、スループットも、1 秒あたりのリクエストを使用して測定した場合はリクエストで生成されるトークンの数に応じて大きく変動します。したがって、全体的なスループットは、モデルにクエリを送信したすべてのユーザーに対して 1 秒あたりに生成されるトークンの合計数という観点から測定します。

llm-load-test による負荷テスト

OpenShift AI モデル提供スタックで実行されるモデルに対する負荷テストを行うために、llm-load-test というオープンソースツールを作成しました。これは Python で記述され、ghz という gRPC 負荷テストツールを内部で利用します。テスト出力に各リクエストの応答とワーカースレッド ID を保存する機能を追加するために、ghz をフォークしました。

llm-load-test では、ghz で提供される機能に加えて、各インスタンスで複数の ghz プロセスを入力データセットと並行してランダムな順序で実行できます。これにより、多くのユーザーがモデルに対して異なるプロンプトで同時にクエリする状況をシミュレートできます。llm-load-test は実験後に結果を S3 バケットに直接アップロードし、実行に対応するメタデータで出力オブジェクトをタグ付けすることもできます。

入力データセット

llm-load-test では、JSON ファイルを使用して、負荷テストの入力プロンプトを設定できます。このブログ記事でご紹介する結果を生成するために、OpenOrca データセットから 32 の入力のデータセットを選択し、さまざまな入出力の長さを設定して実験を行いました。テストデータの最長入力は 1,688 トークン、最長出力は 377 トークンでした。図 2 は、テストデータセットにおける入出力の長さの分布を示したものです。

図 2：テストデータセットのトークン長

現実的なシナリオで TGIS の継続的バッチおよび動的バッチ機能をテストするには、さまざまなサイズの入力と出力の組み合わせを使用することが重要です。最近のモデルは、4,000 を超える極めて長いコンテキスト長をサポートするようになりました。これは、検索拡張生成 (RAG) などのユースケースで特に重要です。このため、将来的には負荷テストのデータセットのサイズを増やして、より長い入力を含める予定です。

AWS 上の OpenShift AI での llama-2 のパフォーマンス結果

次のパフォーマンス測定値は、AWS にインストールされた、インストーラーによってプロビジョニングされたインフラストラクチャ (IPI) のセルフマネージド OpenShift クラスタを使用して収集したものです。OpenShift AI Operator をインストールし、ServingRuntime および InferenceService オブジェクトを作成して、Kserve、Caikit、TGIS でモデルを提供できるようにしました。

以下の表 1 は、モデルと AWS インスタンスタイプの 4 つの組み合わせをテストした結果をまとめたものです。

表 1：テスト構成の概要

各構成で、llm-load-test を使用してさまざまな数のスレッドを並列処理 (以下の図の「並列度」パラメーターを参照してください) を実行して 4 分間の負荷テストを複数回実行しました。テストにおいて、並列処理の各スレッドは、前のリクエストから応答を受け取るとすぐに、一度に 1 つのリクエストを継続的に送信します。

1 つの実験を視覚的に示す例として、以下の図 3 に、テスト実施中における各リクエストの合計レイテンシーのプロットを示します。ドットはトークンの長さによって色分けされているため、トークン長と全体的なリクエスト出力の関連性が視覚的にわかりやすくなっています。

図 3：負荷テストの実施中におけるすべてのリクエストの合計レイテンシー

スループットは、TGIS ログを解析して各リクエストの合計レイテンシーを取得し、負荷テスト中に生成されたトークンの合計をテスト時間 (240 秒) で割って計算しました。

図 4 は、g5.2xlarge インスタンスでさまざまな並列度設定を使用して llama-2-7b の負荷テストを行ったときに測定されたレイテンシーとスループットを示しています。このケースでは、負荷テストの並列度がおよそ 20 スレッドになるまで、スループットが向上していくことがわかります。g5.2xlarge インスタンスでは GPU メモリーの制約があるため、TGIS では、一度におよそ 20 件以上のリクエスト (リクエストの入出力の長さによって異なります) をバッチに収めることができません。

図 4：g5.2xlarge での Llama-2-7b のレイテンシーとスループットの概要

図 5 のグラフは、g5.12xlarge インスタンスで llama-2-13B の負荷テストを行ったときに測定されたレイテンシーとスループットを示しています。このケースでは、トークンあたりの最小レイテンシーは g5.2xlarge の 7B モデルよりも低い値で始まり、モデルがより大規模でインスタンスの GPU のタイプが同じであるにもかかわらず、少なくとも 30 の同時リクエスト数まではスループットがスケールアップしていることがわかります。これは、Tensor Parallelism を使用してモデルを 4 つの GPU に分散することでパフォーマンスが大きく向上したためです。

図 5：g5.12xlarge での Llama-2-13b のレイテンシーとスループットの概要

図 6 は、g5.48xlarge インスタンスで llama-2-70b の負荷テストを行ったときに測定されたレイテンシーとスループットを示しています。このケースでは、トークンあたりのレイテンシーは、これまでの構成よりも全体的に大きくなっています。llama-2-70B のようなモデルには厳しいハードウェア要件があります。8xA10G GPU には合計 192 GB の VRAM がありますが、そのほとんどは、70B のパラメーターを 16 ビット精度でメモリーにロードするためだけに使用されます (70 B × 16 ビット = 約 140 GB)。パフォーマンスの要件によっては、p4d.24xlarge インスタンスなど、さらに大きな計算能力が必要になる場合があります。

図 6：g5.48xlarge での Llama-2-70b のレイテンシーとスループットの概要

図 7 は、p4d.24xlarge インスタンスで llama-2-70b のロードテストを行ったときに測定されたレイテンシーとスループットを示しています。このインスタンスでは、g5.48xlarge インスタンスと比較して、同じ数のユーザーに対するレイテンシーが大幅に小さくなります。並列度 = 30 になっても、負荷テストの並列度が増加するにつれてスループットがスケーリングし続けます。

図 7：p4d.24xlarge での Llama-2-70b のレイテンシーとスループットの概要

コスト計算

測定されたスループットとインスタンスタイプのコストを使用して、100 万トークンを生成するためのコストを見積もることができます。以下の表は、負荷並列度 10 で収集された結果の実測スループットを使用して、これらの推定値をまとめたものです。

表 2：各構成と 100 万トークンあたりのコストの計算結果の概要

今後の取り組み

以上の結果は、Red Hat の Performance and Scale for AI Platforms (PSAP) チームで行っているテストのごく一部です。このチームでは、OpenShift AI の他の側面のパフォーマンステストに加えて、モデル提供スタックのパフォーマンスとスケーラビリティの分析を継続的に実施しています。他のモデルを使用したテストや、トラフィックに基づくモデルのレプリカの自動スケーリングなど、今後もさらに多くの結果を共有していきたいと考えています。

llm-load-test の開発は今後も続けます。また、近々追加したいと考えている機能がいくつかあります。たとえば次のようなものです。

• リクエストのストリーミングの TTFT と TPOT の測定機能
• HTTP や gRPC など、さまざまな API を使用するモデルにクエリするためのプラガブル/モジュール式のインタフェース
• ウォームアップフェーズと、モデルがエラーなくロードされ、応答していることを検証する機能
• ランダムなポアソン到着率など、より複雑な負荷パターン

まとめ

OpenShift AI で Llama-2 モデルのパフォーマンスをテストした結果、いくつかの構成で LLM を実行した場合のレイテンシー、スループット、コストのトレードオフに関する概要を得ることができました。たとえば、7B モデルの場合、最も手頃な価格なのは g5.2xlarge インスタンスですが、Tensor Parallelism によってレイテンシーとスループットが大幅に向上するため、一部のユースケースにおいては g5.12xlarge へのステップアップが有益な場合があります。大規模なモデルを実行すると出力の品質が向上しますが、より多くの GPU メモリーが必要となり、コストが高くなります。

OpenShift AI は、生成大規模言語モデルのデプロイに伴う複雑さへの対処を求める組織に、パフォーマンスと適応性に優れたモデル提供ソリューションを提供します。モデルの品質、レイテンシー、スループット、コストのいずれを優先する場合も、プラットフォームが柔軟であるため、さまざまな要件に対応できます。自社の独自のユースケースにおけるこれらのメリットを確認していただくためにも、ぜひ OpenShift AI にモデルをデプロイしてみてください。