大規模言語モデル (LLM) 推論最適化入門: 1. 背景と問題の定式化

大規模言語モデル (LLM) 推論の概要、その重要性、課題、および主要な問題の定式化。 大規模言語モデル (LLM) は、チャットボットや AI エージェントからコードやコンテンツの生成まで、幅広いアプリケーションを可能にすることで、自然言語処理 (NLP) の分野に革命をもたらしました。しかし、実際のシナリオで LLM を展開すると、レイテンシ、リソース消費、スケーラビリティに関連する課題に直面することがよくあります。 このブログ投稿シリーズでは、LLM 推論のさまざまな最適化手法について説明します。キャッシュ メカニズムからハードウェア アクセラレーションやモデル量子化まで、レイテンシ、メモリ フットプリント、計算コストを削減するための戦略について詳しく説明します。 この記事では、LLM 推論、その重要性、およびそれに関連する課題について簡単に説明します。また、最適化手法の探求の指針となる重要な問題の定式化についても概説します。 モデル推論: 概要 モデル推論とは、トレーニング済みの機械学習モデルを使用して、新しい入力データに基づいて予測を行ったり、出力を生成したりするプロセスを指します。LLM のコンテキストでは、推論にはテキスト入力の処理と、一貫性がありコンテキストに関連するテキスト出力の生成が含まれます。 モデルは一度だけ、または定期的にトレーニングされますが、推論ははるかに頻繁に行われ、実稼働環境ではおそらく毎秒数千回行われます。 推論の最適化は、LLM を実際のアプリケーションに効果的に導入するために不可欠です。目標は、レイテンシ (応答の生成にかかる時間) を最小限に抑え、リソースの消費 (CPU、GPU、メモリ) を減らし、スケーラビリティ (増加する負荷を処理する能力) を向上させることです。 たとえば、GPT-3 (1,750 億のパラメータを持つ) では、推論にかなりの計算リソースが必要です。最適化により、応答時間を 1 ～ 2 秒から数ミリ秒に短縮できるため、LLM はインタラクティブ アプリケーションにとってより実用的になります。 Transformerアーキテクチャの概要 注意メカニズムを使用するトランスフォーマー アーキテクチャは、最先端の LLM の基盤となっています。このアーキテクチャには、位置エンコーディング、マルチヘッド セルフアテンション、フィードフォワード ニューラル ネットワーク、レイヤー正規化が含まれます。トランスフォーマーは、一般的に 3 つの主なタイプに分類されます。 (BERT など) は、テキスト分類や名前付きエンティティの認識などのタスク向けに設計されています。入力シーケンスを固定長の表現 (埋め込み) に変換します。これらのモデルは双方向であり、トークンの左側と右側の両方からコンテキストを考慮するため、入力テキストをよりよく理解できます。 エンコーダのみのモデル (例: GPT-3) は、テキスト生成タスクに使用されます。入力シーケンスから、以前に生成されたトークンに基づいて、一度に 1 つのトークンずつテキストを生成します。これらのモデルは単方向であり、トークンの左側からのコンテキストのみを考慮します。これは、言語モデリングなどのタスクに適しています。これは最も一般的な LLM アーキテクチャです。 デコーダのみのモデル (例: T5) は、論文「Attention is All You Need」で紹介されたオリジナルのアーキテクチャです。これらのモデルは、翻訳や要約など、理解と生成の両方を必要とするタスク向けに設計されています。エンコーダーで入力シーケンスを処理し、デコーダーで出力シーケンスを生成します。 エンコーダー デコーダー モデル デコーダーのみのモデルは自己回帰タスクの最も一般的な LLM アーキテクチャであるため、このシリーズでは、このタイプのモデルに特化した最適化手法に焦点を当てます。 注意メカニズムの概要 アテンション メカニズムは、出力を生成する際にモデルが入力シーケンスのさまざまな部分に焦点を当てることを可能にする、トランスフォーマー アーキテクチャの重要なコンポーネントです。入力表現の加重合計を計算します。ここで、加重は、各入力トークンと現在生成されている出力トークンの関連性によって決まります。このメカニズムにより、モデルは、入力シーケンス内の距離に関係なく、トークン間の依存関係をキャプチャできます。 注意メカニズムは、すべてのトークン間のペアワイズ相互作用を計算する必要があるため、特に長い入力シーケンスの場合は計算コストが高くなる可能性があります ( 複雑性)。ステップごとに詳細を見てみましょう。 O(n^2) : 入力シーケンス内の各トークンは、通常は埋め込みを使用してベクトルとして表現されます。 入力表現 : 各トークンに対して、クエリ ベクトル ( )、キー ベクトル ( )、値ベクトル ( ) の 3 つのベクトルが計算されます。これらのベクトルは、学習された線形変換を使用して入力表現から導出されます。 クエリ、キー、値のベクトル Q_i K_i V_i : 注目スコアは、現在のトークンのクエリ ベクトルと、入力シーケンス内のすべての以前のトークンのキー ベクトルのドット積を取ることによって計算されます。これにより、各トークンにどの程度の焦点を置くべきかを示すスコアが生成されます。 注目スコア : 次に、ソフトマックス関数を使用して注目スコアを正規化し、注目重みを取得します。注目重みの合計は 1 になります。 ソフトマックス正規化 : 最後に、現在のトークンの出力表現は、アテンション重みを使用して、値ベクトルの加重合計として計算されます。 加重合計 マルチヘッドアテンション マルチヘッド アテンションは、アテンション メカニズムの拡張であり、モデルが異なる位置にある異なる表現サブスペースからの情報を共同でアテンションできるようにします。マルチヘッド アテンションは、単一のアテンション ウェイト セットを持つ代わりに、それぞれが学習した線形変換を持つ複数のアテンション スコア セットを並列に計算します。 これらのアテンション ヘッドの出力は連結され、線形変換されて最終的な出力表現が生成されます。 このメカニズムにより、入力データ内のさまざまな関係や依存関係をキャプチャするモデルの能力が強化され、さまざまな NLP タスクのパフォーマンスが向上します。 推論計算プロセスの概要 LLM とトランスフォーマー アーキテクチャを理解した上で、推論計算プロセスの概要を説明しましょう。推論では、指定された入力シーケンスに対して次の $n$ 個のトークンが生成され、次の 2 つの段階に分けられます。 : このステージでは、入力シーケンスのモデルを通じてフォワード パスが実行され、各トークンのキーと値の表現が計算されます。これらの表現は、後でデコード ステージで使用するために KV キャッシュに保存されます。各レイヤーのすべてのトークンの表現は並列に計算されます。 事前入力ステージ : このステージでは、モデルは自己回帰方式で出力トークンを 1 つずつ生成します。トークンごとに、モデルはプレフィル ステージ中に保存された KV キャッシュからキーと値の表現を取得し、現在の入力トークンのクエリ表現とともに、シーケンス内の次のトークンを計算します。 デコード ステージ このプロセスは、停止基準が満たされるまで（最大長に達するか、シーケンス終了トークンを生成するなど）継続されます。新しいキーと値の表現は、後続のトークンの KV キャッシュに保存されます。この段階では、トークン サンプリング戦略も適用され、次に生成するトークンが決定されます（貪欲検索、ビーム検索、トップ k サンプリングなど）。 推論計算の複雑さ 長さ のプレフィックス、埋め込みサイズ 、および 個のヘッドと 個のレイヤーを持つモデルの場合、推論計算の複雑さは次のように分析できます。 L d h n : 事前入力ステージでは、入力内のすべてのトークンの初期表現を計算します。ここでの複雑さは次のとおりです。 事前入力ステージ ここ： 最初の項 : レイヤー間で各トークンを独立して処理するフィードフォワード計算を表します。これは、シーケンスの長さ とレイヤーの数 の両方に比例して増加します。 O(Ln .d^2) L n 2 番目の項 : アテンション メカニズムのコストを表します。ここでは、各トークンが他のすべてのトークンと相互作用し、レイヤーごとのアテンション計算の複雑度は になります。複雑度はシーケンスの長さの 2 乗で増加するため、長いシーケンスでは大きなボトルネックになる可能性があります。 O(L^2. nh d) L^2 : デコード段階は自己回帰部分であり、複雑さは次のとおりです。 デコード段階 ここ： : 生成されたトークンごとに、すべてのレイヤーでフィードフォワード操作を実行します。これは一度に 1 つのトークンに対して実行されるため (シーケンス全体に対してではありません)、トークンあたりの複雑さは です。 フィードフォワード計算 O(nd^2) : 各新しいトークンは、以前に計算されたキーと値のペアを使用して、アテンションを通じて既存のシーケンスと対話します。生成された各トークンに対して、このアテンション計算はシーケンスの長さ L に比例し、次のようになります: キャッシュによるアテンション計算 O(Lnd .h) ご覧のとおり、推論計算の複雑さは、入力シーケンスの長さ ( )、レイヤーの数 ( )、アテンション ヘッドの数 ( )、および埋め込みサイズ ( ) によって影響を受けます。この複雑さは、特に長い入力シーケンスや大規模なモデルを扱う場合に、リアルタイム アプリケーションのボトルネックになる可能性があります。 L n h d KVキャッシュの重要性 KV キャッシュは、特にデコード段階での LLM 推論にとって重要な最適化手法です。事前入力段階で計算されたキーと値の表現を保存することにより、モデルは以前に処理されたトークンの冗長な計算を回避できます。 これにより、モデルは入力シーケンス内のすべてのトークンのキーと値の表現を再計算するのではなく、生成される新しいトークンのアテンション スコアを計算するだけで済むため、推論中の計算コストとレイテンシが大幅に削減されます。 これにより、コストは入力の長さに対して 2 次ではなく、生成されるトークンの数に対して線形になります。 ただし、KV キャッシュではキーと値の表現を保存するために追加のメモリが必要になるため、リソースが制限された環境ではトレードオフになる可能性があります。 サンプルモデルの計算 LLaMA 7B モデルのメモリ要件を計算してみましょう。 モデル構成 パラメータ: 億 70 埋め込みサイズ ( ): 4096 d_model レイヤー数: 32 注意ヘッドの数 ( ): d_head 32 ヘッド寸法（ ）： （4096/32） d_head 128 最大シーケンス長 (L): 2048 データ型: float16 (要素あたり2バイト) メモリ計算 : レイヤーごとにキーと値の両方を保存する必要があります レイヤーごとのキャッシュサイズ トークンあたりのキーサイズ = = 128 × 32 = d_head × num_heads 4096 要素 トークンあたりの値のサイズ = = 128 × 32 = 4096 d_head × num_heads 要素 レイヤーごとのトークンあたりの要素の合計 = 4096 + 4096 = 8192 要素 : 長さL = のフルシーケンスの場合 フルシーケンスのレイヤーあたりのメモリ 2048 トークン 層あたりの要素数 = L × 8192 = 2048 × 8192 = 16,777,216 要素 レイヤーあたりのメモリ（バイト単位） = 16,777,216 × 2 = 33,554,432 バイト = 33.55 MB : レイヤーが$32$あるため 全レイヤーの合計KVキャッシュメモリ 合計メモリ = 33.55 × 32 MB = 1073.6 MB 総メモリ要件 モデルの重み: 70億パラメータ × 2バイト/パラメータ = 14 GB KV キャッシュメモリ: 1073.6 MB その他のメモリオーバーヘッド（アクティベーション、中間結果など）: ~1-2 GB したがって、合計メモリ要件は、14 GB (モデルの重み) + 1～2 GB (オーバーヘッド) + 1073.6 MB (KV キャッシュ) = となります。この計算により、推論中の LLaMA 7B モデルのメモリ要件の見積もりが得られます。LLaMA 7B は、モデルの重みと KV キャッシュの両方に大幅に多くのメモリを必要とする GPT-3 (1750 億のパラメータ) などのモデルと比較すると比較的小さいです。 15～16 GB また、同時ユーザー数が $m$ にまで拡大すると、リソース要件は $m$ 倍になります。したがって、リソースが制限された環境で大規模なモデルを展開するには、最適化技術が不可欠です。 推論最適化を評価するための指標 推論最適化技術の有効性を評価する際には、いくつかの指標を考慮することができます。 : 推論の事前入力段階を実行するのにかかる時間。最初のトークンまでの時間 (TTFT) レイテンシとも呼ばれます。このメトリックは、ユーザーが素早い応答を期待するインタラクティブ アプリケーションにとって非常に重要です。モデル サイズ、入力の長さ、ハードウェア機能などの要因がこのメトリックに影響を与える可能性があります。 事前入力レイテンシ : 事前入力段階の後に後続の各トークンを生成するのにかかる時間。トークン間待ち時間 (ITL) とも呼ばれます。このメトリックは、テキスト生成中のモデルの応答性を測定するために重要です。チャットボットなどのアプリケーションの場合、ITL が低いことは良いことですが、速いことが常に良いとは限りません。人間とのやり取りには、1 秒あたり 6 ～ 8 トークンで十分な場合が多いからです。影響する要因には、KV キャッシュ サイズ、サンプリング戦略、ハードウェアなどがあります。 デコード待ち時間 : 入力の受信から最終出力の生成までにかかる合計時間。このメトリックは推論プロセスの全体的なパフォーマンスを理解するために不可欠であり、事前入力、デコード、およびその他のコンポーネントのレイテンシ (JSON 解析など) の影響を受けます。影響要因には、モデルのサイズ、入力の長さ、ハードウェア、およびパイプライン全体の効率が含まれます。 エンドツーエンドのレイテンシ : 1 秒あたりに処理できる推論リクエストの数。このメトリックは、実稼働環境でのモデルのスケーラビリティを評価するために重要です。モデル サイズ、ハードウェア、最適化手法などの要因が QPS に影響を与える可能性があります。たとえば、1 つの GPU で P90 レイテンシに対して 15 QPS が提供される場合、300 QPS を提供するには 20 個の GPU が必要になります。影響を与える要因には、ハードウェア リソース、負荷分散、最適化手法などがあります。 最大リクエスト レート (QPS (1 秒あたりのクエリ数)) : モデルが 1 秒間に実行できる浮動小数点演算の数。このメトリックは推論の計算コストを理解するのに役立ち、さまざまなモデルや最適化手法の効率を比較するために使用できます。影響する要因には、モデル アーキテクチャ、ハードウェア、最適化手法などがあります。 FLOPS (1 秒あたりの浮動小数点演算) 推論最適化手法の種類 これらの最適化については、このシリーズの今後の記事で取り上げる予定です。 : レイヤーやアテンション ヘッドの数を減らしたり、より効率的なアテンション メカニズム (例: スパース アテンション) を使用したりして、モデル アーキテクチャを変更し、推論効率を向上させます。 モデル アーキテクチャの最適化 : 特殊なハードウェア (TPU、GPU など) の使用やソフトウェア スタックの最適化 (効率的なライブラリやフレームワークの使用など) など、基盤となるハードウェアとソフトウェア インフラストラクチャを最適化します。これは次のように分類できます。 システム最適化 : メモリ使用量を効率的に管理してオーバーヘッドを削減し、パフォーマンスを向上させます。 メモリ管理 : 並列処理を活用して計算を最適化し、レイテンシを削減します。 効率的な計算 : 複数のリクエストを同時に処理してスループットを向上させます。 バッチ処理 : リソースの使用率を最大化するためにタスクを効率的にスケジュールします。 スケジューリング : 量子化、プルーニング、蒸留などの手法を使用すると、パフォーマンスを大幅に犠牲にすることなく、モデルのサイズを縮小し、推論速度を向上させることができます。 モデル圧縮 : より効率的なサンプリング戦略の使用やアテンション メカニズムの最適化など、推論に使用されるアルゴリズムを改善します。たとえば、モデルが複数のトークンを並列に生成できるようにする投機的デコードにより、デコードの待ち時間を大幅に短縮できます。 アルゴリズムの最適化 結論 この投稿では、LLM 推論の概要、その重要性、およびそれに関連する課題について説明しました。また、今後の投稿で最適化手法を探求する上での指針となる重要な問題の定式化についても概説しました。 LLM 推論の複雑さとそのパフォーマンスに影響を与える要因を理解することで、LLM を実際のアプリケーションでより実用的にするための最適化手法の重要性をより深く理解することができます。次の投稿では、モデルのパフォーマンスを維持しながらレイテンシとリソース消費を削減することに焦点を当て、特定の最適化手法とその実装についてさらに詳しく説明します。 参考文献 必要なのは注意だけです。 AIアクセラレータ上の基盤モデルの推論最適化