Red Hat OpenShift は金融サービス向けの高性能 LLM 推論を提供

金融サービス業界は、他の多くの業界と同様、リソースを大量に消費する AI ワークロードの時代にハードウェアを最大限に活用することを目指しています。金融サービス企業はコンテナベースのアーキテクチャのメリットを活用してきましたが、コンテナ・オーケストレーション・プラットフォームによってパフォーマンスが低下し、リソースの制約がさらに大きくなる可能性を懸念するかもしれません。 

金融サービス分野における大規模言語モデル（LLM）の推論性能を評価するための業界標準ベンチマークである、新たな STAC-AI™ LANG6 (推論専用) 監査の結果は、Red Hat OpenShift に関するこうした懸念を和らげる一助となるかもしれません。NVIDIA および Supermicro とのコラボレーションにより、Red Hat のパフォーマンスおよびスケール・エンジニアリング・チームは、Supermicro SuperServer SYS-222C-TN で 2 つの NVIDIA RTX PRO 6000 Blackwell Server Edition GPU を使用して、OpenShift 上で STAC-AI LANG6 ベンチマークのスイート全体を実行しました。これらは、コンテナ化された Kubernetes プラットフォームで生成された、初めての監査済みの STAC-AI の結果です。

Red Hat は長年にわたり、OpenShift が極めて要求の厳しいワークロードに対してベアメタルのようなパフォーマンスを提供することを実証しており、Red Hat は独立して行われた監査の結果によってその主張を裏付けています。STAC-N1 ネットワーク・ベンチマーク において、Red Hat は OpenShift が市場データのベアメタルのレイテンシーに匹敵する (場合によってはそれを上回る) ことを示し、1 秒あたり 100,000 メッセージと 140 万メッセージの両方で平均および中央値レイテンシーの最小値を記録しながら、最大レイテンシーを 37% 削減しました。記録的な STAC-A2 市場リスク・ベンチマークにおいて、私たちは NVIDIA DGX A100 システムを使用して OpenShift 上で GPU 加速モンテカルロ・シミュレーションの複数の記録を達成しました。また、Intel CPU を使用した STAC-A2 において、私たちは OpenShift のコンテナ化によるオーバーヘッドが、CPU 負荷の高い金融ワークロードであっても無視できるほど小さいことを示しました。

この新しい STAC-AI の提出により、その実績は LLM 推論の領域にまで拡大することになります。金融機関が不正行為の検出、セキュリティ、感情分析、規制遵守のために AI を活用したワークフローを導入する中、この分野の重要性が急速に高まっています。

STAC-AI LANG6 の概要

Strategic Technology Analysis Center (STAC) は、世界最大級の金融機関がテクノロジースタックの評価に使用する標準化されたベンチマークを作成しています。STAC-AI LANG6 は、金融サービスのユースケースにおける LLM 推論パフォーマンスを測定します。STAC-AI LANG6 のデータセットは、実際の SEC EDGAR 財務報告書から派生したものであり、これらは金融機関における RAG (検索拡張生成) や長文コンテキスト処理のワークロードを支えるものです。

このベンチマークは 2 つの推論モードを対象としています。 バッチモード は、1 回の API 呼び出しでテスト対象システム (SUT) に完全なデータセットを渡すことで、最大スループットを測定します。 インタラクティブモードは、ポアソン分布に従ってさまざまな到着率でリクエストを送信することで実際の使用状況をシミュレートし、負荷下での反応時間 (最初のトークンまでの時間に相当)、応答時間、および出力率を測定します。

私たちは、プロンプトの長さと複雑さが異なる 4 つの EDGAR データセットにおいて、2 つのモデル (Llama-3.1-8B-Instruct および Llama-3.1-70B-Instruct) をテストしました。また、このベンチマークは fidelity: (忠実度) も測定します。これは、最適化されたモデルの出力が、STAC リファレンス SUT上でネイティブ精度で実行される同じモデルの出力と、どの程度一致しているかを示すものです。この仕様では、合計 7 つの必須ワークロードが必要です。 

表 1STAC-AI ベンチマークのモデル、データセット、実行モード

スタック

ハードウェア：

• Supermicro SuperServer SYS-222C-TN (2U DC-MHS サーバー)
• 2x Intel Xeon 6730P CPU (合計 64 物理コア)
• 2 TiB DDR5-5200 (32x 64 GiB DIMM)
• 2x NVIDIA RTX PRO 6000 Blackwell Server Edition GPU (各 96 GiB GDDR7)

ソフトウェア：

• Red Hat OpenShift 4.20 (シングルノード OpenShift)
• Red Hat Enterprise Linux CoreOS 9.6
• Node Feature Discovery Operator
• NVIDIA GPU Operator
• STAC-AI Operator (Red Hat が開発したカスタム Operator)
• NVIDIA TensorRT-LLM 1.2.0rc2 (PyTorch バックエンド) と NVIDIA Model Optimizer 0.37.0 による NVFP4 量子化

Operator スタックは、Red Hat が STAC-A2 の取り組みで確立したものと同じパターンに従います。前提条件となるのは Node Feature Discovery Operator です。この Operator は各ノードでハードウェア機能を検出し、Kubernetes ラベルとして表面化させます。NVIDIA GPU Operator はこれらのラベルを使用して GPU ドライバーコンテナをデプロイする場所を特定し、スケジューラーで GPU を nvidia.com/gpu リソースとして使用できるようにします。その時点から、Pod は CPU またはメモリーをリクエストするのと同じ方法で GPU をリクエストします。

これら 2 つの Operator をインストールすることで、GPU はファーストクラスの Kubernetes リソースになります。手動でのドライバーのインストール、特別なホスト設定、カスタムカーネルモジュールは不要です。同じアプローチが、エッジに単一の GPU ノードがあっても、データセンター内にそれらのクラスタがある場合でも機能します。

この基盤の上に、私たちはベンチマーク自体をオーケストレーションする STAC-AI Operator を追加しました。

STAC-AI Operator

STAC-AI ベンチマークをエンドツーエンドで実行するには、多くの可動要素が関与します。モデルをターゲット精度に量子化する、GPU クロックと電力制限をロックする、複数のワークロードと到着率に対してベンチマーク・ハーネスを実行する、各実行と同期して電力と温度のトレースを収集する、最後に参照モデルに対して忠実度分析を実行する、といった作業が関係します。これらすべてを手動で行うのは時間がかかり、ミスが発生しやすく、再現が困難です。STAC-AI Operator はワークフロー全体を宣言型にします。

カスタムリソース

Operator は、次の 3 つのカスタムリソース定義 (CRD) を導入します。

• Implementation は、利用可能な LLM バックエンド (TensorRT-LLM など) を、そのコンテナイメージ、サポート対象のモデルおよびデータセットとともに登録します。
• BenchmarkRun は主要なリソースです。BenchmarkRun は、単一のベンチマーク実行を宣言します。使用する実装、テストするモデルとデータセット、量子化手法、GPU 割り当て、および後処理の忠実度分析を実行するかどうかを指定します。Operator がそこからすべてを処理します。
• BenchmarkImageBuild は、TensorRT-LLM スタックの 1 回限りのコンテナイメージビルドを管理します。

ライフサイクル管理

BenchmarkRun が作成されると、Operator はそれをステートマシンで駆動します。

Pending → Queued → Initializing → Quantizing → Building → Running → RunCompleted → PostProcessing → Completed

各フェーズで、Operator は作業を実行する Kubernetes Job を作成します。Operator は nvidia-smi を使用して GPU の最大クロック速度と電力制限を自動的に検出して適用し、一度に 1 つのベンチマークのみが実行されるように順次実行キューを管理し (実行間の GPU 競合を防止)、vLLM をリファレンスとして使用して忠実度分析フェーズを処理します。いずれかのステップが失敗すると、実行は Failed 状態に移行し、型指定された理由コードが付与されるため、診断が容易になります。

ベンチマークの実行

監査済みワークロードを実行するために必要なものは次のとおりです。

apiVersion: stac.ai/v1alpha1
kind: BenchmarkRun
metadata:
  name: stac-rtxpro6000-8b-e4a-batch
  namespace: stac-ai
spec:
  implementation: tensorrt-llm
  model: llama-3.1-8b
  dataset: edgar4a
  sut: RTXPRO6000-8B-E4a-Batch
  sutConfig:
    configMapName: sut-tensorrt-llm-rtxpro6000-batch
    key: RTXPRO6000-8B-E4a-Batch.yaml
  config:
    quantization: NVFP4
    gpuCount: 2
    useExecutor: false
  postProcessing:
    fidelity: true
  storage:
    workspacePVC: stac-workspace-pvc
    modelCachePVC: stac-model-cache-pvc
    logsPVC: stac-logs-pvc

この YAML がユーザーとのやり取りのすべてと言えます。この YAML を適用すると、Operator はモデルの量子化、GPU チューニング、ベンチマーク実行、電力と温度のキャプチャ、および忠実度分析を処理します。ワークロード固有のパラメーター (バッチサイズ、シーケンス長、到着率) が ConfigMap を介して注入されるため、コンテナイメージを再構築することなく、さまざまな構成をテストできます。

完全な STAC-AI LANG6 スイートを実行するために、7 つのワークロードすべてを定義する SUT 構成を参照する単一の BenchmarkRun を適用しました。これにより、Operator は (カスタムリソースで定義された) ベンチマーク・ハーネスを起動し、ハーネスは (SUT 構成で定義された) 各ワークロードを順次実行します。電力と吸気温度は、各測定期間を通じて Yokogawa WT1804R 高精度電力アナライザ (ベンチマーク Pod から VXI-11/SCPI 経由でクエリ) と、USB シリアル経由の Dallas DS18B20 プローブを使用してキャプチャされます。

成果

表 2 および 3 の監査結果は、公式 STAC レポートから引用したものです。すべてのワークロードは FP8 KV キャッシュを備えた NVFP4 に量子化され、各 GPU で独立したモデルインスタンスが実行されました。

表 2バッチモードの結果

表 3 インタラクティブモードの結果 (最高の持続到達率)

監査結果からのいくつかの所見は次のとおりです。

• 2U フォームファクターによる優れたスペース効率STAC レポートによると、2U の SYS-222C-TN は、比較可能なすべてのワークロードにおいて、より大規模な NVIDIA GH200 システムよりも高いバッチスペース効率を実現しました (EDGAR4a では 1 ft³・時あたり 950.1 万ワード対 614.8 万ワード、EDGAR4b では 142.8 万ワード対 799,500 ワード、EDGAR5a では 237,400ワード対 226,900ワード)。また、報告されたすべてのワークロードセットをわずか 2 つの GPU で完了しました。
• NVFP4 により、70B モデルを単一 GPU で余裕を持って実行できます。Llama-3.1-70B-Instruct を NVFP4 に量子化すると、ディスク上のモデルサイズは約 35 GB に縮小されます。これは、単一の RTX PRO 6000 の 96 GB メモリに十分に収まり、KV キャッシュ用の余裕も十分に確保できます。各 GPU は独立したモデルインスタンスを実行し、バッチおよびインタラクティブ・ワークロードの両方で 2 つの GPU が同時に使用されます。

STAC-AI Operator がこれらの実行すべてを行いました。Red Hat はスイート全体の SUT 構成を参照する BenchmarkRun カスタムリソースを適用し、Operator はそれ以上の介入なしに量子化、チューニング、実行、および後処理を処理しました。

LLM 推論に Red Hat OpenShift を使用する理由

Red Hat がよく受ける質問は、コンテナ化されたプラットフォームがパフォーマンスを重視するワークロードに影響を与えるオーバーヘッドをもたらすのではないか、という点です。この監査結果は、LLM 推論に関する強力な指標となります。ボトルネックはプラットフォームではなく GPU にあると考えられ、OpenShift のコンテナランタイムやスケジューリングが推論パイプラインに有意なオーバーヘッドを加えていることを示すデータはありません。報告書における STAC 独自の解説もこれと一致しています。「コンテナおよびオーケストレーション・レイヤーは、実際の重大なパフォーマンス制限をもたらすものではないと思われる」以前に監査した STAC-N1 (ネットワーク) および STAC-A2 (GPU コンピューティング) の結果と合わせると、これは、OpenShift が要求の厳しい金融ワークロードに対して、組織がベアメタルに期待するようなパフォーマンスを提供できるという Red Hat の見解を裏付ける 3 番目のデータポイントとなります。

しかし、OpenShift で実行することの真の価値は、単なるパフォーマンスの面にとどまりません。金融サービスの本番環境では、セキュリティポリシー、ロールベースのアクセス制御、監査ログ、ライフサイクル管理、およびマルチテナンシーも必要です。OpenShift は、これらすべてを標準機能として提供します。ベアメタルのようなパフォーマンスとエンタープライズグレードの運用のどちらかを選択する必要はありません。

また、GPU ワークロードを実行するために並列スタックを用意する必要もありません。このベンチマークを実行したのと同じクラスタで、アプリケーションのワークロード、仮想化、バッチジョブ、CI/CD パイプラインを並行して実行できます。これらはすべて、同じ運用チーム、同じ可観測性環境、同じセキュリティポリシーの下で実行されます。すでに OpenShift を運用しているチームは、第 2 の運用環境を構築することなく、GPU 推論プラットフォームを導入できます。

このベンチマークで使用した Operator パターンは、より広範な事実を示しています。ベンチマークスイートであれ、本番環境の LLM 提供であれ、複雑な GPU ワークロードは宣言型の Kubernetes ネイティブ API を通じて管理できるということです。ユーザーが必要なこと (モデル、量子化、データセット) を記述すると、Operator がその提供方法を判断します。このパターンは、単一ノードのテスト環境からマルチノードの本番クラスタまで、同様の方法で拡張できます。

Red Hat OpenShift AI も同様の方法で構築されています。Red Hat OpenShift AI は、同じ Node Feature Discovery および NVIDIA GPU Operator、同じ nvidia.com/gpu リソースモデル、およびクラウド、オンプレミス、エッジにおけるモデル開発、トレーニング、提供、モニタリングを管理するための同じ Operator パターンを使用して、コアの OpenShift 上で動作します。このベンチマークを実行したインフラストラクチャは、その基盤を変更することなく、本番環境の AI プラットフォームへと直接拡張できます。

GPU 管理も同様に単純化されています。Node Feature Discovery および NVIDIA GPU Operator は、クラスタ全体でハードウェア検出、ドライバーのライフサイクル、およびリソーススケジューリングを処理します。新しい GPU ノードの追加は Operator をインストールするだけで済み、残りは自動的に行われます。同じデプロイメントモデルが、ここで使用したようなシングルノード of OpenShift クラスタ、支社に適した 3 ノードのコンパクトクラスタ、エッジのリモートワーカーノード、または地域のデータセンターにあるマルチノードクラスタでも、変更なしで適用されます。YAML は、いずれもそれらを再ターゲットするように変更されることはありません。

最後に、このプロジェクトにおけるすべてのベンチマークの実行は、バージョン管理された YAML で定義されます。すべての構成は再現可能です。STAC が独立した監査を実施した際、私たちは同じリソースを適用して、まったく同じ環境と結果を再現しました。このレベルの再現性は Kubernetes デプロイメントモデルの必然的な結果であり、ベンチマークの提出に対するのと同様に、本番環境のワークロードにとっても価値があります。

まとめ

この監査済みの結果によると、Red Hat OpenShift では、金融サービス企業が AI インフラの評価に用いるような LLM 推論ワークロードが実行されており、プラットフォームのオーバーヘッドによって GPU の性能が制限されている兆候は見られません。これまでの STAC-N1 および STAC-A2 の結果と合わせると、一貫した傾向がさらに裏付けられます。つまり、組織は、同じ OpenShift プラットフォーム上で、最も負荷の高いワークロードをベアメタル並みのパフォーマンスで実行できるということです。

完全な監査結果は、STAC の Web サイトで確認できます。TensorRT-LLM の実装および SYS-222C-TN ハードウェアプラットフォームに関する追加の解説については、NVIDIA のこちらのブログ記事を参照してください。