Zenn
🎨

vLLMとPagedAttention：LLM推論の革新的技術

2024/08/13に公開
推論
vLLM
pagedattention
メモリ最適化
tech

はじめに

大規模言語モデル（LLM）の世界で、効率的な推論は常に課題となっています。この記事では、その課題に革新的なソリューションを提供する「vLLM」と「PagedAttention」について詳しく解説します。これらの技術が、どのようにLLM推論を高速化し、メモリ使用を最適化しているのかを、初心者にも分かりやすく説明していきます。

解説スレ

https://hamaruki.com/vllm-pagedattention-discussion/

vLLMとは？

vLLMは、オープンソースのLLM推論・サービングエンジンです。その特徴は、「PagedAttention」と呼ばれる新しいメモリ割り当てアルゴリズムを使用していることです。

vLLMの主な特徴

  1. 高速処理: HuggingFace Transformers（HF）と比較して最大24倍、HuggingFace Text Generation Inference（TGI）と比較して最大3.5倍のスループットを実現します。
  2. 効率的なメモリ使用: 従来のシステムがKV-Cache（LLMメモリ）の60〜80%を無駄にしていたのに対し、vLLMは4%未満の無駄で、ほぼ最適なメモリ使用を達成します。
  3. コスト削減: 効率的なメモリ使用により、同じ出力を得るために必要なGPUの数を減らすことができ、結果としてコストを削減できます。

vLLMの実用例

多くの企業がvLLMを採用し、推論コストを削減しています。例えば、Chatbot ArenaとVicunaを運営するLMSYSは、vLLMを導入することで以下の成果を得ました：

  • 使用するGPUの数を50%削減
  • 1秒あたりのリクエスト処理数を2〜3倍に増加
  • 1日約45,000件の増加するトラフィックに対応

これらの改善は、PagedAttentionによるメモリ無駄の削減によって実現されました。

PagedAttentionとは？

PagedAttentionは、vLLMの心臓部とも言える革新的なアルゴリズムです。このアルゴリズムは、オペレーティングシステムで使用されているメモリページングの概念からインスピレーションを得ています。

メモリページングとの類似性

  1. オペレーティングシステムのメモリページング:

    • コンピューターのメモリを「ページフレーム」と呼ばれる区画に分割して管理します。
    • アクティブに使用されていないメモリ部分をスワップアウトすることで、より効率的なメモリ使用を可能にします。

  2. PagedAttentionのアプローチ:

    • LLMのサービングにおいて、メモリページングの考え方を応用します。
    • KV-Cache（Key-Value Cache）の最適化に焦点を当てています。

KV-Cacheの重要性

KV-Cacheは、トランスフォーマーモデルがテキストを処理する際に重要な役割を果たします。

  1. KV-Cacheの機能:

    • 新しく生成されたクエリベクトル（Q）を、以前に保存されたすべてのキーベクトル（K）と比較します。
    • 各キーベクトルは、モデルが考慮する以前のコンテキストに対応します。
    • 各値ベクトル（V）は、これらのコンテキストが現在の計算でどれだけ重要かを表します。

  2. KV-Cacheの利点:

    • 新しいトークンが生成されるたびにKVペアを再計算する必要がありません。
    • 代わりに、新しいKVペアをKV-Cacheに追加して、後続の計算で再利用できます。

  3. 従来のKV-Cache実装の問題点:

    • 連続したメモリ空間にKV-Cacheペアを保存します。
    • リクエストごとに固定の未分割ブロックを割り当てます。
    • LLMへのリクエストサイズは大きく変動するため、これらの固定ブロックの多くが無駄になります。

PagedAttentionによるKV-Cache最適化

PagedAttentionは、KV-Cacheの使用を最適化することで、従来のシステムの問題点を解決します。

従来のシステムのメモリ無駄

研究者たちは、従来のシステムにおけるメモリ無駄を3つのタイプに分類しました：

  1. 内部断片化:

    • システムがモデルの生成トークン数を予測できないため、使用されない可能性のあるメモリスロットが割り当てられます。
    • 出力シーケンスの長さは、入力プロンプトの複雑さや自己回帰モデルの設計に影響されます。

  2. 予約:

    • システムは、リクエストの処理中、メモリブロック全体を予約します。
    • 予約されたメモリの一部しか使用されない場合でも、残りは他のリクエストで使用できません。

  3. 外部断片化:

    • 固定サイズのメモリブロックが、可変長のシーケンスと一致しない場合に発生します。
    • ブロック間に未使用の隙間が生じ、他のプロセスに割り当てられません。

これらの問題により、従来のシステムではKV-Cacheの20-40%しか実際のトークン状態の保存に使用されていませんでした。

PagedAttentionの解決策

PagedAttentionは、メモリページングの概念を応用して、KV-Cacheをより効率的に管理します：

  1. 動的ブロック割り当て:

    • 連続したブロックをメモリ空間の任意の部分に保存できます。
    • 必要に応じてブロックを割り当てます。

  2. ブロックテーブル:

    • 論理的なKV-Cacheと物理的なメモリ空間のマッピングを保存します。
    • これにより、効率的なメモリ管理が可能になります。

  3. フラグメンテーションの削減:

    • 外部断片化を排除し、内部断片化を最小限に抑えます。
    • 割り当てられたメモリのほぼ全てが効果的に使用されます。

  4. 高効率:

    • 従来のシステムが60%-80%のKV-Cacheメモリを無駄にしていたのに対し、vLLMは4%未満の無駄でほぼ最適なメモリ使用を達成します。

  5. バッチサイズの拡大:

    • メモリ効率の向上により、モデル推論時により大きなバッチサイズが可能になります。
    • より多くのリクエストを同時に処理でき、GPUリソースの使用効率が向上します。

PagedAttentionによるメモリ共有

PagedAttentionの動的ブロックマッピングは、別々のリクエストとそれに対応するシーケンス間でのメモリ共有を可能にします。これは以下のようなLLM推論デコーディングアルゴリズムで特に有効です：

  1. 並列サンプリング/デコーディング:

    • 同じプロンプトから複数の出力サンプルを生成します。
    • コンテンツ生成アプリケーションやモデルテストシナリオで有用です。
    • vLLMはプロンプトの計算とメモリを共有できます。

  2. ビームサーチ:

    • 機械翻訳などのタスクで最も可能性の高い単語シーケンスを見つけるために使用される戦略です。
    • 各ステップで最も有望なオプション（ビーム）を展開します。
    • vLLMは共有されたビーム分岐のメモリを効率的に管理します。

  3. 共有プレフィックス:

    • 複数のユーザーが共通の指示や例（システムプロンプト）から始められるようにします。
    • この共通の開始点をvLLMが事前に保存し、計算時間を節約します。

  4. 混合デコーディング方法:

    • 貪欲デコーディング、ビームサーチ、top-kサンプリングなど、様々なデコーディング戦略を利用するリクエストを効率的に管理します。
    • メモリ共有を最適化することで、これらの多様な設定を同時に処理できます。

vLLMのその他のパフォーマンス最適化

vLLMは、PagedAttention以外にも、いくつかの技術を実装してパフォーマンスを向上させています：

  1. 量子化:

    • 8ビット量子化により、モデルの数値データの精度を32ビットから8ビットに削減します。
    • 例えば、Llama 13Bモデルのサイズを52GBから13GBに削減できます。
    • これにより、より小さなGPUメモリでも大規模モデルを実行できるようになります。

  2. 自動プレフィックスキャッシング:

    • 異なる推論リクエスト間で繰り返される計算をキャッシュすることで効率を向上させます。
    • 特に、複数回のやり取りを含む会話シナリオで有効です。

  3. 推測的デコーディング:

    • 小さなモデルを使用して大きなモデルの出力を予測します。
    • これにより、応答の推論がより迅速になり、デコーディング速度が最大2倍になる可能性があります。

  4. マルチLoRAサポート:

    • Low-Rank Adaptation（LoRA）を使用して、複数のモデル適応を効率的に管理します。
    • 単一のベースモデルを様々なアダプターとともに使用できるようになり、異なるタスク間でのメモリ使用と計算効率を最適化します。

vLLMと他の推論エンジンの比較

vLLM vs. TGI と Hugging Face Transformers

Berkeley の研究者たちが行った比較実験では、以下の結果が得られました：

  • NVIDIA A10G GPU上のLLaMA-7Bモデル、およびNVIDIA A100 GPU（40 GB）上のLLaMA-13Bモデルで比較
  • vLLMは、Hugging Face Transformers（HF）と比較して24倍高いスループットを達成
  • Hugging Face Text Generation Inference（TGI）と比較して3.5倍高いスループットを達成

vLLM vs. TensorRT-LLM

TensorRT-LLMとの直接的なパフォーマンス比較は難しいですが、セットアップの容易さと複雑さを比較できます：

  1. vLLM:

    • セットアップが簡単で、Pythonパッケージをpipでインストールし、使用するモデルを定義するだけです。
    • OpenAI互換のAPIを提供し、既存のインフラストラクチャに統合しやすいです。
    • 多くのモデルをサポートし、様々なアプリケーションのニーズに対応できます。

  2. TensorRT-LLM:

    • セットアップには複数のステップが必要で、NVIDIAのソフトウェアスタック、Docker、詳細な設定に関する知識が必要です。
    • モデルをTensorRTエンジンにコンパイルし、NVIDIA Triton Inference Serverを設定してデプロイする必要があります。
    • 経験の浅い開発者にとっては、学習曲線が急な可能性があります。

vLLMがサポートするモデル

vLLMは、HuggingFaceで人気の高いオープンソースLLMの多くをサポートしています：

  • 従来のTransformer LLM（例：Llama、GPT-2、GPT-J）
  • Mixture-of-Expert LLM（例：Mixtral、Qwen2MoE）
  • マルチモーダルLLM（例：LLaVA、GPT-NeoX、StableLM）

vLLMの発展と人気

vLLMの急速な成長は、その効果的な性能と使いやすさを反映しています：

  • 350人以上のオープンソースコントリビューターによる活発なコミュニティ
  • AMD、AWS、Databricks、Dropbox、NVIDIA、Robloxなどの著名な企業からのサポート
  • カリフォルニア大学バークレー校とカリフォルニア大学サンディエゴ校からの直接的なプロジェクトサポート

このような幅広いサポートと活発なコミュニティの存在は、vLLMの将来性と信頼性を示しています。

RunPod ServerlessでvLLM APIエンドポイントをデプロイする

vLLMを実際に試してみたい方のために、RunPod Serverlessを使用してvLLM APIエンドポイントをデプロイする手順を紹介します。

手順

  1. RunPodアカウントの作成:

    • RunPodの公式ウェブサイトでアカウントを作成します。

  2. Serverlessダッシュボードへのアクセス:

    • ダッシュボードの「Serverless vLLM」セクションで「Start」をクリックします。

  3. Hugging Faceモデルの入力:

    • 使用したいHugging Faceモデルを入力します。
    • 注意：プライベートモデルを使用する場合は、Hugging Faceのアクセストークンが必要です。

  4. vLLMモデル設定のカスタマイズ（オプション）:

    • 多くのモデルではデフォルト設定で問題ありませんが、GPTQなどの量子化バージョンを使用する場合は、量子化タイプを指定する必要があります。

  5. GPUタイプの選択:

    • テスト目的の場合、80GB（A100）を推奨します。

  6. デプロイとテスト:

    • 「Deploy」をクリックし、エンドポイントをテストします。
    • 「Requests」タブにあるUIを使用してモデルをテストするか、APIエンドポイントを直接使用できます。

  7. 初回実行時の注意:

    • 最初の実行時にはモデルのダウンロードに数分かかる場合があります。
    • ワーカーの準備が整うと、TTFT（最初のトークンまでの時間）レイテンシーが250ms未満になります。

RunPod上でのvLLMの使用は、モデルの効率を向上させ、大幅なコスト削減を実現します。特に、LLMアプリケーションを数百万のインファレンスリクエストにスケールアップするスタートアップにとって、優れた選択肢となります。

vLLMを使用すべき理由

vLLMには多くの利点があり、LLM推論の効率化を目指す開発者や企業にとって魅力的なツールとなっています。以下に、vLLMを使用すべき主な理由をまとめます：

  1. 卓越したパフォーマンス:

    • HuggingFace Transformers（HF）と比較して最大24倍のスループット
    • HuggingFace Text Generation Inference（TGI）と比較して最大3.5倍のスループット
    • これらの性能向上により、同じハードウェアでより多くのリクエストを処理できます。

  2. 幅広い互換性:

    • 数百のLLMと数十のトランスフォーマーアーキテクチャをサポート
    • NVIDIAとAMDのGPUに対応し、あらゆるGPUワークロードで使用可能
    • この互換性により、様々なプロジェクトや環境でvLLMを利用できます。

  3. 活発な開発者エコシステム:

    • 350人以上のコントリビューターによる継続的な改善
    • 新しいオープンソースモデルがリリースされてから数日以内にvLLM互換になることが多い
    • コミュニティの活発さにより、最新の技術や改善が迅速に取り入れられます。

  4. 使いやすさ:

    • 簡単なインストールと設定
    • RunPod Serverlessを使用することで、数分でカスタムの本番用APIエンドポイントをデプロイ可能
    • 初心者でも容易に始められ、経験豊富な開発者も効率的に作業できます。

  5. 高いカスタマイズ性:

    • OpenAI互換性、量子化、自動プレフィックスキャッシング、推測的デコーディング、LoRAなどをサポート
    • 様々なユースケースや要件に合わせて調整できます。

  6. コスト効率:

    • 効率的なメモリ使用により、必要なGPUの数を削減
    • スループットの向上によりインフラストラクチャコストを削減
    • スタートアップや大規模プロジェクトの両方でコスト削減に貢献します。

  7. 継続的な改善:

    • 活発なコミュニティと企業のサポートにより、常に最新の技術が取り入れられています
    • 将来的な性能向上や新機能の追加が期待できます。

vLLMの将来展望

vLLMの急速な成長と広範なサポートを考慮すると、その将来は非常に明るいと言えます。以下に、vLLMの将来展望についていくつかの予測を示します：

  1. さらなる性能最適化:

    • PagedAttentionアルゴリズムのさらなる改良
    • 新しいハードウェアアーキテクチャへの最適化

  2. より広範なモデルサポート:

    • 新しいLLMアーキテクチャへの迅速な対応
    • マルチモーダルモデルのサポート強化

  3. クラウドサービスとの統合:

    • 主要クラウドプロバイダーとの直接的な統合
    • サーバーレスデプロイメントオプションの拡大

  4. エンタープライズ向け機能の強化:

    • 大規模デプロイメントのためのより高度な管理ツール
    • セキュリティと監査機能の強化

  5. コミュニティ主導の革新:

    • オープンソースコミュニティによる新機能の開発
    • ユースケース固有の最適化とプラグイン

  6. 教育とトレーニングリソースの拡充:

    • vLLMの効果的な使用方法に関する包括的なドキュメンテーション
    • オンラインコースやワークショップの提供

まとめ

vLLMとPagedAttentionは、LLM推論の世界に革命をもたらしています。その優れたパフォーマンス、幅広い互換性、使いやすさ、そしてコスト効率の高さは、多くの開発者と企業にとって魅力的な選択肢となっています。

活発なコミュニティと継続的な改善により、vLLMは今後も進化し続けると予想されます。LLMを活用したプロジェクトや製品の開発を検討している場合、vLLMは強力な味方となるでしょう。

RunPod Serverlessを使用すれば、数分でvLLMベースのAPIエンドポイントをデプロイできます。これにより、LLMの力を簡単に自分のプロジェクトに統合できます。

vLLMは、LLM推論の未来を形作る重要な技術の一つです。その発展に注目し、積極的に活用することで、AIプロジェクトの可能性を大きく広げることができるでしょう。

参考サイト

https://blog.runpod.io/introduction-to-vllm-and-how-to-run-vllm-on-runpod-serverless/

Discussion