NVIDIA H100でLlama 2 70Bを加速する

Perplexityの回答エンジンにおけるパフォーマンスの追求は、NVIDIAとAWSが提供する最新技術の採用へと私たちを駆り立てます。本ブログでは、私たちの最新の実験結果を共有します。それは、様々なハードウェアおよびソフトウェア設定におけるLlama 2 70Bの推論の比較です。

私たちのLLM推論プラットフォームであるpplx-apiは、オープンソースライブラリを活用した最先端のスタックの上に構築されています。10月にpplx-apiのパブリックベータが開始されて以来、私たちはスケーリングの課題に取り組み、大規模なスケールを実現するために設定を最適化する方法を学んできました。これに基づき、私たちは以下の指針となる質問を掲げて実験を行いました。

他の設定をすべて同一にした場合、GPUをNVIDIA A100からNVIDIA H100に切り替えることによる純粋なパフォーマンス向上はどの程度か。

H100がネイティブサポートを追加した8ビット浮動小数点（fp8）量子化による効率向上はどの程度か。また、この量子化による精度の低下はどの程度か。

テンソル並列処理とバッチサイズは、レイテンシとトークンスループットにどのような影響を与えるか。

以上を考慮すると、パフォーマンスとコスト効率のバランスが最もスケーラブルになる設定はどれか。

ネットワークレイテンシを排除するため、以下の実験を一連のローカルベンチマークとして実施しました。

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

スループット: 推論サーバーが全ユーザーおよび全リクエストを通じて生成できる、GPUあたり1秒あたりの出力トークン数。

以下の要因は主要指標に影響を及ぼすため、実験の各試行を通じて一定に保ちました。

パフォーマンスはLLMのサイズとともにスケールします。パラメータ数が多いほど計算量が増え、推論が遅くなります。例えば、他の設定が等しい場合、Llama 2 13BはLlama 2 70Bよりも高速です。本実験でLlama 2 70Bを採用したのは、最も高性能なオープンソースモデルの提供を最適化したいと考えているためです。

各サンプルリクエスト/レスポンスペアにおける入出力トークン量は、パフォーマンス測定に影響を与える可能性があります。一般的に、出力トークンの生成が全体の応答時間を左右します。データサンプリングによってLLMから「はい/いいえ」の回答のみが引き出される場合、LLMにエッセイの執筆を求めるサンプルと比較して応答は高速になります。私たちのデータセットは、1024個の入力トークンで512個の出力トークンを生成する合成リクエストで構成されています。この分布は、私たちのLlama 2 70Bパブリックデプロイメントで観測されたトラフィックの分布と一致するように選択されました。

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

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

第9世代Hopper (H100-HBM3-80GB / p5.48xlarge) GPUアーキテクチャは、前身であるAmpere (A100-SXM4-80GB / p4de.24xlarge) と比較して、2倍から6倍の計算レートや約2倍のGPUメモリ帯域幅を含む膨大な機能リストを搭載しています。GPUメモリ帯域幅は推論において重要な指標です。なぜなら、推論の行列乗算における主なレイテンシのボトルネックは、ギガバイト単位のモデルデータをGPUメモリから計算レジスタにロードすることに起因するためです。これらの統計に基づき、NVIDIA H100とA100を同等の条件で比較すれば、レイテンシとスループットの両面で2倍の向上が見られると仮説を立てました。

NVIDIA H100とA100のもう一つの大きな違いは、H100テンソルコアが8ビット浮動小数点（fp8）命令のサポートをネイティブで追加している点であり、これが以下に詳述するさらなる最適化への道を開きます。これが、H100に対して特にfp8とfp16を使用する理由です。

本実験においてGPUあたりのメモリを一定に保つため、NVIDIA A100とH100の両方で、8x80GB GPUメモリを備えたノードに限定しました。より大きなバッチサイズを可能にするだけでなく、サーバー起動時に高速アクセスを実現するためにモデルのパラメータがGPUメモリにロードされるという点でも、GPUメモリは重要です。例えば、私たちのモデルの700億個のパラメータがそれぞれ16ビット浮動小数点数の場合、モデルサイズは約140GBとなり、単一のGPUには収まりません。これが、後述するテンソル並列処理が必要となる理由です。

テンソル並列処理とは、推論サーバーを実行するために消費されるGPUデバイスの数を指します。一定数のGPUを割り当てると、TensorRT-LLMはそれらのリソースをプールし、Llama 2 70Bを実行するために必要な最小限のメモリバジェットの達成を支援します。私たちの仮説は、より高いテンソル並列処理と比較した場合、テンソル並列処理が低い方が（各バッチを処理するために消費されるリソースが少なくなるため）レイテンシは高くなるものの、（利用効率が高まるため）GPUあたりのスループットは高くなるというものです。

量子化とは、ニューラルネットワークで使用される重みと活性化関数の精度を低減させる技術です。私たちは、fp16からfp8に切り替える際にGPUメモリ消費量を半分にするためにこの技術を使用しています。これにより、同じモデルをより少ない総GPUメモリ使用量で実行することが可能となり、テンソル並列処理を低く抑えられるため、結果としてスループットが向上します。

量子化の実装には、精度を低下させる可能性があります。そのため、私たちはWikiTextコーパスを用いて、各LLMが文章中の次のトークンをどの程度うまく予測できるかを示す指標であるパープレキシティ統計を比較することで、異なる精度レベルの精度を評価しました。8ビット浮動小数点数および8ビット重み・8ビット活性化関数・SmoothQuant (w8a8 SQ) の場合、WikiText上ではfp16と比較してパープレキシティに有意な変化（< 1%）は見られなかったため、安心して進めることができると判断しました。しかし、w4a16はパープレキシティに7%という大幅な変化を示しました。これは、さらに低い精度であることと、int4とfp16の間で必要な動的変換に起因している可能性があります。

バッチ処理を通じた並列化は、リソースが制限されたシステムから最大限のパフォーマンスを引き出すための古典的な戦略です。ニューラルネットワークを通じた各フォワードパスにおいて複数のリクエストを処理することにより、バッチ処理はレイテンシを犠牲にしてスループットを向上させることが知られています。また、バッチ処理はより多くのGPUメモリ消費を招きます。これは、アテンションメカニズムを管理するKVキャッシュのサイズがバッチサイズとともに線形に増加するためです。

Llama 2 70B（80レイヤー）の場合、コンテキストサイズ4096でバッチサイズ32のfp16設定では、KVキャッシュのサイズは40GBという大きな値になります。その結果、重みだけで140GBを占めるLlama 2 70B fp16モデルが、テンソル並列処理2 (TP-2) で利用可能な160GBのGPUメモリに収まりにくくなるという事態が発生します。

私たちは実験の4つの変数の互換性のある組み合わせを総当たりで検証し、最も洞察に満ちた傾向を以下に示します。

図1 - 5つの異なる構成における、バッチサイズを変化させた際のリクエストレイテンシ。すべてテンソル並列処理8で行っており、利用可能なGPUが8基ある場合に最高のレイテンシが得られます。各構成内で、バッチサイズを1から32に増やすとレイテンシはおおよそ倍増し、32から128に増やすとさらに倍増します。十分に大きなバッチサイズでは、H100はA100と比較してレイテンシを約半分に短縮します。A100はfp8のネイティブサポートがないため、混合精度を使用しています。SmoothQuant (SQ) を用いたw8a8はfp8に似せて設計されています。

量子化によるレイテンシの改善は、H100のfp16からfp8、およびA100のfp16からSmoothQuantを用いたw8a8を比較すると、約10%の範囲内にあります。しかし、混合精度のw4a16は、fp16と比較して、低バッチサイズでは実際にはパフォーマンスが向上し、高バッチサイズでは悪化します。これは、計算カーネルの最適化不足、int4とfp16間の変換時間、およびw4a16が活性化関数に依然として16ビット浮動小数点数を使用しており、KVキャッシュの次元削減によるメリットがないことなど、いくつかの要因に起因している可能性があります。w4a16は精度低下も確認されたため、A100にはw8a8 SQを、H100にはfp8を維持すべきであると結論付けました。

図2 - 異なるアーキテクチャ、量子化、およびバッチサイズによるTP-8構成全体のスループット。各アーキテクチャと量子化において、バッチサイズは25600ms（512トークンに対して1秒あたり20トークン）というレイテンシ要件を満たす最大値として選択されました。これにより、同様のレイテンシを持つ構成を比較することが可能になります。この要件の下では、BS-128のH100は、同じ量子化（fp16）を使用したBS-64のA100と比較して228%のスループットに達し、バッチサイズが倍増しているにもかかわらず、応答レイテンシはむしろ低くなっています。fp8による量子化は、この係数を251%まで改善します。

最初の2つの図では、TP-8の構成のみを示しています。両者がfp16 / BS-128 / TP-8を使用する場合、H100はA100と比較して54%のレイテンシと184%のスループットを達成し、H100でfp8を使用すると、49%のレイテンシと202%のスループットに改善します。このパフォーマンスの向上は、H100とA100の間の計算能力とメモリ帯域幅の増加に起因します。注目すべきは、利用率が低くなる可能性のある低バッチサイズでは、この差はそれほど顕著ではないという点です。

プラットフォームの構築にあたり、私たちはユーザーに対する特定のレイテンシ要件を尊重しつつ、スループットを最大化したいと考えています。したがって、A100とH100を同じバッチサイズで比較するよりも、レイテンシ要件を満たす構成の下でのみスループットを比較する方が合理的です。512個の出力トークンの完了に対してレイテンシのカットオフを25600msに設定したところ、H100 / TP-8 / fp8 / BS-128は、A100 / TP-8 / fp16 / BS-64と比較して251%のスループットが得られることがわかりました。これは、より低いレイテンシでバッチサイズを2倍に処理できるためです。量子化がGPUメモリを節約できることがわかった今、テンソル並列処理がどのように次の最適化レイヤーを追加できるかを評価する必要があります。

図3 - H100 fp8における、バッチサイズとテンソル並列処理を変化させた際のレイテンシ。レイテンシは通常、バッチサイズを1から32に増やすと倍増し、32から128に増やすとさらに倍増します。TP-2は、バッチサイズが等しい場合、常にTP-8の約2倍の低速さとなります。テンソル並列処理を2倍にしつつバッチサイズも2倍にすることで、GPUごとの処理バッチ数は均等に保たれるため、レイテンシは比較的安定します。

量子化とアーキテクチャに関しては、明確な勝者が存在します。H100はA100を圧倒し、低精度量子化はメモリ利用効率、レイテンシ、スループットを改善します。しかし、バッチサイズとテンソル並列処理は、主要指標においてトレードオフの関係にあります。大きなバッチサイズはスループットを最適化しますが、その代償としてレイテンシとメモリ消費量が増加します。一方で、より高いテンソル並列処理は利用可能なメモリの総プールを増やし、レイテンシを最適化しますが、分散行列乗算の同期コストや、より多くのGPUリソースを占有するという性質上、スループットとのトレードオフが発生します。

図4 - H100 fp8における、バッチサイズとテンソル並列処理を変化させた際のスループット。最高のスループットはTP-2 BS-128で得られ、A100/TP-8/fp16/BS-64を基準とした場合と比較して460%となります。しかし、TP-2 BS-128は図3において最も遅い結果でもあります。

本実験におけるスループットを最大化する構成はH100 / fp8 / TP-2 / BS-128であり、GPUあたり1秒間に767個の出力トークンを生成します。これはA100 / fp16 / TP-8 / BS-64と比較して460%の向上です。しかし、512個の出力トークンに対して約42000msという、2倍のレイテンシを代償とするため、本番環境の構成としては不適切である可能性があります。TP-4 BS-128（応答時間26188msで626 tok/sec/gpu）やTP-2 BS-32（応答時間18821msで435 tok/sec/gpu）の結果の方が、主要指標においてより優れたトレードオフを示している可能性があります。

私たちの結果は以下を証明しています：

H100を使用すると、同条件のA100と比較して54%のレイテンシと184%のスループットを達成でき、H100がfp8のネイティブサポートを活用すると、それぞれ49%と202%に改善します。

レイテンシ制約下でスループットを最大化する場合、H100 / fp8 / TP-8 / BS-128は、A100 / fp16 / TP-8 / BS-64と比較して251%のスループットが得られます。これは、より高速に、かつ2倍のバッチを処理できるためです。

TP-2とfp8を備えたH100を活用することで、A100 / fp16 / TP-8 / BS-128と比較して、レイテンシの増加を10%未満に抑えつつ、373%のスループットを達成できます。

バッチサイズとテンソル並列処理は、LLM推論システムの運用者にとって、スループットとレイテンシの間のトレードオフをもたらします。

これらの結果により、以前はA100で稼働していたハードウェアスタックからH100 GPUへの完全な移行に自信を持つことができました。NVIDIAが公表しているパフォーマンス向上を確証できることを嬉しく思うとともに、加速ハードウェアにおける同社の次なるブレイクスルーを期待しています。

私たちの次なる最適化のフロンティアは、構造化スパース性とint4精度の精度およびパフォーマンスへの影響を調査することです。これにより、Llama 2 70BのGPUメモリ使用量を大幅に削減し、レイテンシを最大2倍改善できる可能性があります。私たちは今後も超高速推論の追求を続け、ユーザーが私たちのプラットフォーム上で強力なアプリケーションを構築できるよう支援していきたいと考えています。

近い将来、pplx-apiはレート制限を解除し、事実に基づいた情報を根拠とするインターネット対応LLMを含む、より多くのカスタムPerplexity LLMを提供する予定です。

perplexity.ai/proからPerplexity Proに登録してください。最先端のpplx-apiへのアクセス権を取得し、これらの高度な機能をあなたのプロジェクトで活用しましょう。pplx-apiの詳細については、私たちのブログをご覧ください。

AIの未来を切り拓くことに興味はありますか？私たちは採用を強化しています！大規模な生成AI LLMインフラを推進するチームの一員になりませんか。Perplexity採用情報で機会を探索してください。

Aarash Heydari, Grigorii Alekseev, Kevin Hu, Denis Yarats

実験設定

主要指標:

定数:

AIモデル

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

ソフトウェアバージョン

変数

GPUアーキテクチャ

テンソル並列処理

量子化

バッチサイズ

結果

結論

今後の展望

著者: