AIモデルとプラットフォーム

LLMデプロイの最適化: vLLM PagedAttentionと効率的なAIサービングの未来

mm
公開日
更新日
Unite.AI を Google の優先ソースに追加

大規模言語モデル（LLM）は、実世界のアプリケーションにデプロイする際に、計算リソース、待ち時間、コスト効率などのユニークな課題を提起します。この包括的なガイドでは、LLMサービングのランドスケープを探索し、特にvLLM（ベクトル言語モデル）という解決策に焦点を当てます。vLLMは、LLMのデプロイとインタラクションの方法を変革しています。

大規模言語モデルのサービス提供の課題

具体的な解決策に取り組む前に、LLMサービス提供の複雑なタスクとなる主要な課題を検討しましょう。

計算リソース

LLMは、数十億から数百億のパラメータを持つことで有名です。たとえば、GPT-3は175億のパラメータを持ち、より最近のモデルであるGPT-4はさらに多くのパラメータを持つと推定されています。このような大規模さは、推論に重大な計算リソースを必要とします。

例：
比較的慎重なLLM、たとえば13億パラメータを持つLLaMA-13Bを考えてみましょう。このモデルでは、

– 16ビット精度を仮定して、約26 GBのメモリがモデルパラメータを格納するために必要です。
– 活性化、注意メカニズム、 intermediate 計算のための追加メモリ。
– 実時間推論のための大量のGPUコンピューティング能力。

待ち時間

チャットボットやリアルタイムコンテンツ生成などの多くのアプリケーションでは、低待ち時間はユーザーエクスペリエンスのために不可欠です。ただし、LLMの複雑さは、特に長いシーケンスの場合に、重大な処理時間につながる可能性があります。
例：
LLMを搭載したカスタマーサービスチャットボットを想像してみましょう。各レスポンスを生成するのに数秒かかる場合、会話はユーザーにとって不自然で苛立たしいものになります。

コスト

LLMを大規模に実行するために必要なハードウェアは非常に高価です。高性能GPUまたはTPUはしばしば必要であり、これらのシステムのエネルギー消費は重大です。
例：
NVIDIA A100 GPU（LLM推論にしばしば使用される）のクラスタを実行することは、クラウドコンピューティング料金で1日あたり数千ドルかかる可能性があります。

LLMサービス提供の伝統的なアプローチ

より高度な解決策を探求する前に、LLMサービス提供の伝統的なアプローチを簡単にレビューしましょう。

Hugging Transformersを使用したシンプルなデプロイ

Hugging Face Transformersライブラリは、LLMをデプロイするための直截的な方法を提供しますが、高スループットのサービスには最適化されていません。
例コード：

from transformers import AutoModelForCausalLM, AutoTokenizer
import torch

<p>model_name = "meta-llama/Llama-2-13b-hf"
model = AutoModelForCausalLM.from_pretrained(model_name, device_map="auto")
tokenizer = AutoTokenizer.from_pretrained(model_name)</p>

<p>def generate_text(prompt, max_length=100):
inputs = tokenizer(prompt, return_tensors="pt").to(model.device)
outputs = model.generate(**inputs, max_length=max_length)
return tokenizer.decode(outputs[0], skip_special_tokens=True)</p>

<p>print(generate_text("The future of AI is"))

このアプローチは機能しますが、高トラフィックアプリケーションには、リソースの非効率的な使用と最適化の欠如のため不適切です。

TorchServeまたは同様のフレームワークを使用する

TorchServeなどのフレームワークは、ロードバランシングやモデルバージョニングなどのより堅牢なサービス機能を提供します。ただし、これらは依然としてLLMサービス提供の特定の課題、たとえば大規模モデルに対する効率的なメモリ管理に対処していません。

LLMサービス提供におけるメモリ管理の理解

LLMサービス提供における効率的なメモリ管理は、必要な大量の計算リソースのため不可欠です。以下の画像は、LLMパフォーマンスを最適化する上で重要なメモリ管理のさまざまな側面を示しています。

セグメント化されたメモリとページ化されたメモリ

これらの図は、オペレーティングシステム（OS）で一般的に使用されるセグメント化されたメモリ管理とページ化されたメモリ管理技術を比較しています。

  • セグメント化されたメモリ：この技術は、メモリを異なるセグメントに分割し、それぞれが異なるプログラムまたはプロセスに対応します。LLMサービス提供のコンテキストでは、さまざまなセグメントは、トークン化、埋め込み、注意メカニズムなどのモデルのさまざまなコンポーネントに割り当てられます。各セグメントは独立して拡大または縮小でき、柔軟性を提供しますが、適切に管理されない場合、断片化につながる可能性があります。
  • ページ化されたメモリ：ここでは、メモリは固定サイズのページに分割され、物理メモリにマップされます。ページは必要に応じて入れ替えられ、メモリリソースの効率的な使用が可能になります。LLMサービス提供では、これはモデル重みと中間計算を格納するために必要な大量のメモリを管理する上で重要です。

OSとvLLMのメモリ管理

この画像は、従来のOSのメモリ管理とvLLMのメモリ管理アプローチを対比しています。

  • OSのメモリ管理：従来のオペレーティングシステムでは、プロセス（例：プロセスAとプロセスB）は、物理メモリ（ページ0、ページ1など）にページを割り当てます。この割り当ては、プロセスがメモリを要求および解放するにつれて断片化につながる可能性があります。
  • vLLMのメモリ管理：vLLMフレームワークは、Key-Value（KV）キャッシュを使用してメモリをより効率的に管理します。リクエスト（例：リクエストAとリクエストB）は、KVキャッシュのブロック（KVブロック0、KVブロック1など）に割り当てられます。このアプローチは、断片化を最小限に抑え、メモリ使用を最適化し、より迅速で効率的なモデルサービスを可能にします。

LLMの注意メカニズム

LLMの注意メカニズム

LLMの注意メカニズム


mm

私は過去5年間、機械学習とディープラーニングの魅力的世界に没頭してきました。私の情熱と専門知識は、AI/MLに特に焦点を当てた50以上の多様なソフトウェアエンジニアリングプロジェクトに貢献することになりました。私の継続的な好奇心は、自然言語処理という分野にも私を引き付け、さらに探求したいと思っています。