イントロダクション

Perplexityの回答エンジンにおけるパフォーマンスの追求が、NVIDIAとAWSが提供する最新テクノロジーを採用することを推進しています。このブログでは、最新の実験結果である、様々なハードウェアとソフトウェア設定におけるLlama 2 70Bの推論の比較を共有することに興奮しています。

当社のLLM推論プラットフォームpplx-apiは、オープンソースライブラリによってパワードされた最先端のスタックに基づいて構築されています。pplx-apiのパブリックベータが2023年10月に始まって以来、スケーリングの課題に取り組んでおり、構成を最適化して大規模なスケールを実現するための最良の方法を学んできました。これにより、次のようなガイドとなる質問に基づいて実験を行いました。

1. 他の設定を変更せずに、GPUをNVIDIA A100からNVIDIA H100に切り替えた場合の生のパフォーマンスの向上はどれくらいですか？
   
   

2. H100がネイティブサポートを追加した8ビット浮動小数点（fp8）の量子化の効率向上はどれくらいですか？この量子化の精度のコストはどれくらいですか？
   
   

3. テンソル並列処理とバッチサイズがレイテンシとトークンスループットにどのように影響するのですか？
   
   

4. 上記を考慮すると、どの構成が最もスケーラブルでパフォーマンスとコスト効率のバランスが取れていますか？

実験の設定

我々は、ネットワーク遅延を避けるために、以下の実験をローカルベンチマークとして実行しました。

主要なメトリクス

1. レイテンシ：推論サーバーが完全な応答を生成するまでにかかる合計時間。
   
   

2. スループット：推論サーバーが全ユーザーおよびリクエスト全体で生成できる出力トークンの数（秒ごと、GPUごと）
   
   

定数

次の要因が主要なメトリクスに影響を与えるため、異なる実験のトライアルを一貫して保ちました。

AIモデル

パフォーマンスは、LLMのサイズとともにスケールします。より多くのパラメータはより多くの計算を必要とし、それによって推論が遅くなります。例えば、他の設定が等しいとき、Llama 2 13BはLlama 2 70Bよりも速いです。これらの実験では最も高性能なオープンソースモデルを提供するため、この実験ではLlama 2 70Bを使用しています。

入力/出力トークンデータセット

各サンプルのリクエスト/レスポンスのペアの入力トークンおよび出力トークンの数は、パフォーマンスの測定に影響を与えることができます。一般的に、出力トークンの生成が全体の応答時間を支配します。LLMに「はい/いいえ」の応答のみを促すサンプルデータでは、他のサンプルに比べて応答が速くなります。当社のデータセットは、1024の入力トークンで512の出力トークンを誘発する合成リクエストで構成されており、これはLlama2 70Bの公開デプロイメントの観測されたトラフィック分布に合わせるために選択しました。

ソフトウェアバージョン

NVIDIA TensorRT-LLM（リリースv0.5.0）は、LLM推論を最適化するためのオープンソースライブラリです。2023年後半にリリースされ、NVIDIAの多くの推論最適化を統合し、この実験の主要パラメータの柔軟なカスタマイズ層を提供しています：バッチサイズ、量子化、およびテンソル並列処理。

変数

我々は構成の4つの軸にわたって実験を行いました：テンソル並列処理、GPUアーキテクチャ、量子化、および最大バッチサイズ。これらの軸は、それぞれがGPUメモリの重要なボトルネックリソースに対するトレードオフを表しています。

GPUアーキテクチャ

第9世代のHopper（H100-HBM3-80GB / p5.48xlarge）GPUアーキテクチャは、前世代のAmpere（A100-SXM4-80GB / p4de.24xlarge）と比較して、2倍から6倍の演算速度とほぼ2倍のGPUメモリ帯域幅を備えた多機能なリストを提供しています。推論の主要な遅延のボトルネックである推論の行列乗算からのモデルデータのギガバイト単位のGPUメモリへの読み込みに起因するものです。これらの統計に基づいて、NVIDIA H100とA100のアップル対アップルの比較は、レイテンシとスループットの両方で2倍の改善を示すと仮説を立てました。

NVIDIA H100とA100のもう一つの違いは、H100テンソルコアがネイティブで8ビット浮動小数点（fp8）命令のサポートを追加することです。これにより、以下で詳細に説明するさらなる最適化の可能性が生まれます。これは、H100およびH100のために特にfp8およびfp16を使用する理由です。

この実験では、NVIDIA A100およびH100の両方に80GB GPUメモリのノードを使用してメモリ- GPUメモリの一貫性を保つために使用しました。また、より高いバッチサイズを有効にするだけでなく、GPUメモリは、サーバー起動中にモデルのパラメータがGPUメモリにロードされるため重要です。例えば、当社のモデルの700億のパラメータの各々が16ビット浮動小数点数である場合、モデルは約140GBのサイズで、単一のGPUに収まりません。これが次に説明するテンソル並列処理の必要性です。

テンソル並列処理

テンソル並列処理とは、推論サーバーを実行するために消費されるGPUデバイスの数を指します。GPUの数を割り当てると、TensorRT-LLMは、Llama2 70Bを実行するための最小限の必要メモリ予算に到達するために、リソースをプールします。我々の仮説は、より低いテンソル並列処理は、各バッチを満たすために消費されるリソースが少ないため、レイテンシが高くなる（各バッチを満たすために消費されるリソースが少ないため）が、スループットが高くなる（より良い利用率が得られるため）というものです。

量子化

量子化は、ニューラルネットワークで使用される重みと活性化の精度を減らすことです。この技術を使用して、fp16からfp8に切り替えるとGPUメモリの消費を半分にできます。これにより同じモデルをより低い総GPUメモリ使用量で実行することが可能となり、スループットを上げることができます。

量子化の実装は精度を低下させる可能性があります。そのため、我々は、相対的な精度であるperplexity統計を使用して異なる精度の精度を評価しました。w8a8 SQ）では、WikiText上のfp16と比較してperplexityに有意な変化が見られず（＜1％）、この実行には自信を持つ必要があると判断しました。しかし、w4a16では、fp16と比較してperplexityに7％の変化が見られ、この大幅な変化は、更新された低い精度とint4およびfp16の間の必要な動的変換に起因する可能性があります。

バッチサイズ

バッチ処理を用いた並列処理は、リソースに制約があるシステムからパフォーマンスを引き出すための典型的な戦略です。ニューラルネットワークを逆伝播させるために複数のリクエストを1回の前向き伝播で処理することで、バッチ処理はいくつかのレイテンシを犠牲にしてスループットを増やすことが知られています。バッチ処理は、バッチサイズに応じて注意機構を管理するKVキャッシュのサイズが線形に増加するため、GPUメモリの消費も増加します。

Llama 2 70Bの場合（80層）、fp16でバッチサイズ32の場合、4096のコンテキストサイズのKVキャッシュのサイズは大きな40GBになります。このため、Llama 2 70B fp16は、キャッシュのサイズが大きいため、160GBのGPUメモリで快適に収まらなくなります。これは、TP-2（テンソルパラレリズム 2）で利用可能な場合。

結果

我々は、実験の4つの変数の互換性のある組み合わせを掃引し、以下に最も洞察に富んだトレンドをご紹介します。

図1 - テンソル並列処理8でバッチサイズが異なるリクエストのレイテンシ、この場合、8つの利用可能なGPU環境

各構成の中で、バッチサイズを増やすと（1→32）、さらに倍へと（32→128）、通常レイテンシは2倍になります。十分大きなバッチサイズでは、H100はA100に比べてレイテンシを約半分に短縮します。A100はfp8のネイティブサポートを欠いているため、ミックスプレシジョンを使用します。w8a8 SQでは、fp8を模倣することが意図されています。

量子化のレイテンシ改善は、H100 fp16→fp8およびA100 fp16→w8a8 with SmoothQuantで約10％です。ただし、ミックスプレシジョンのw4a16は、fp16と比較して低いバッチサイズでのパフォーマンスが向上し、高いバッチサイズでのパフォーマンスが低下します。これは、最適化されていない演算カーネルがいくつかの要因に影響している可能性があり、int4とfp16の間のキャスト時間、w4a16がアクティベーションに対して依然として16ビット浮動小数点数を使用しているため、KVキャッシュの寸法に節約がありません。また、w4a16は低い精度を示したため、A100とw8aS8およびH100とfp8に固執すべきであると結論付けました。