KubeAI 大規模モデル推論高速化の実践 | Dewu Technology

[深セン] 源創輝: 午後 5 時 26 分、パーティー会場があなたを待っています。」

1.背景

最近では、大規模モデルの専用推論クラスタを本番環境に一括デプロイし、70Bを含む大規模モデルの推論速度を50%高速化することに成功し、導入コストを大幅に削減し、本番環境への安定適用を実現しました。この記事は、大規模モデル推論クラスターのデプロイに関する経験の一部に基づいており、大規模モデルの推論速度を効果的に向上させるいくつかの方法を共有します。最後に、私たちが評価し、良好なパフォーマンスを示したいくつかの大規模なモデル推論フレームワークを推奨します。これらの提案が、読者がプロジェクトに適切な推論フレームワークを選択するのに役立つことを願っています。

OpenAIの科学者であるHyung Won Chung氏は、2023年の公開講演「大規模言語モデル」[8]で、大規模モデルの特定の機能は、パラメータの数が一定の規模に達した場合にのみ明らかになることがわかると指摘しました。大型モデルの開発は今後確実に増加します。パラメーターの数が増加するにつれて、大規模モデルの推論速度に対する要件はますます高くなっています。大規模モデルの推論速度またはスループットを向上させるにはどのような方法が使用できるでしょうか?

まず、大型モデルの加速最適化の方向性について説明します。次に、タイムラインに基づいて、「FlashAttendant」などの、業界で最も古典的で実用的な大型モデルの高速化テクノロジをいくつか紹介します。 [1]」と「PageAttend[3]」。

以下に、業界における古典的な大規模モデル推論高速化テクノロジを時系列で示します。この記事では、開発の時系列に沿って大規模モデルの高速化手法を読者に紹介します。

上記の技術以外にも、大規模モデルの推論速度を向上させるための、大規模モデル向けの定量化技術もありますが、今回はここでは説明しませんので、機会があれば別途記事で紹介したいと思います。。

2.大型モデル開発の課題

将来的には、大規模モデルのパラメータ数はますます増加することは間違いなく、これは大規模モデルの開発傾向でもあり、推論の高速化に対する要件はますます高くなります。

OpenAI は、論文「神経言語モデルのスケーリング則」[7] で大規模モデルの拡張ルールを導入しました。これらのルールは、モデルの機能とそのサイズの関係を示しています。具体的には、モデルの機能は、モデルパラメーターの数、データセットのサイズ、トレーニング中に必要な計算量などのサイズに大きく依存します。さらに、OpenAI の科学者 Hyung Won Chung は、2023 年の公開講演「大規模言語モデル」[8] で、大規模モデルの特定の機能は、一定の規模に達した場合にのみ明らかにされると指摘しました。

上の写真は、Hyung Won Chung 氏のスピーチの ppt[8] から抜粋したものです。この図は主に視点を表しています。GPT3 から GPT4 へなど、モデルの規模が大きくなるにつれて、モデルの機能はますます強力になり、新しい機能も登場します。

ただし、モデルのサイズが大きくなるにつれて、パラメーターが増えるとより多くの GPU 計算が必要になるため、大規模なモデルの推論速度は徐々に低下します。推論速度の低下はさらにユーザーエクスペリエンスの悪化につながるため、大規模モデルの推論をいかに高速化するかがますます重要になります。

3.大規模モデル推論高速化のための最適化の方向性

Llama2 モデルの構造

まず、Llama 2 の論文 [9] を参照して、Llama 2 モデルシリーズの構造を簡単に見てみましょう。現在、Llama シリーズなどのほとんどの生成言語モデルは、主に Transformer アーキテクチャの Decoder モジュールを使用しています。 Huggingface プラットフォームでは、このタイプのモデル構造は通常、因果言語モデルである CausalLM と呼ばれます。

上の図は Llama2 の大型モデルの構造を示しており、その中心となるのはアテンション計算 (Llama Attendance) です。これは、推論プロセス全体の中で最も時間がかかるモジュールでもあり、その後の最適化のほとんどはアテンションに基づいて実装されます。 Llama 2 モデルの構造をより深く理解するために、まず Llama2 モデルの推論プロセス全体を簡単に分解します。興味のない学生は直接スキップしてください。

ユーザーがモデルにプロンプトを送信した後、モデルによって実行される最初の操作は、次の文字 (トークン) を予測し、予測された文字を入力に追加して予測を続行することです。このプロセスは、モデルが STOP トークンを出力するまで継続され、その時点で予測は停止し、モデルは最終結果を出力します。
次の文字 (トークン) を生成するプロセスで、モデルは Llama Decoder Layer の計算を N 回実行する必要があります。具体的には、Llama-2-7B モデルは 32 回の計算を実行し、Llama-2-13B モデルは 40 回の計算を実行します。
ラマデコーダレイヤーの最も重要な計算リンクは、アテンション (ラマアテンション) の計算です。推論時間のほとんどはアテンションの計算に消費されるため、アテンションの計算の効率を向上させるためにさまざまな最適化手法が設計されています。

大規模モデル推論の加速方向は何ですか?

Llama 2 モデルの構造分析から、大規模モデルは推論計算プロセス中に次の特性を示すと結論付けることができます。

推論プロセス全体の中で、最も時間がかかるのは注意の計算です。アテンション計算の速度の最適化により、全体的な推論パフォーマンスが大幅に向上します。
アテンションの計算プロセス中に、キー値キャッシュ (KV キャッシュ) が大量のビデオメモリリソースを占有します。 13B モデルを例に挙げると、プロンプトシーケンスの処理には約 3GB の追加ビデオメモリが必要であり、ビデオメモリのこの部分は頻繁に割り当てられ、解放されるため、ビデオメモリのフラグメントを削減できた場合、多数のフラグメントが発生します。、大規模モデルのスループットも向上させることができます。
推論プロセス中に、GPU は多数のパラメーターを処理して計算する必要があります。 7B モデルには 70 億個のパラメータがあり、13B モデルには 130 億個のパラメータが含まれており、世界で最新かつ最も強力なモデル DBRX には 1,300 億個のパラメータがあり、これらのパラメータを効率的に処理する必要があります。ここにも最適化の余地がある可能性があります。

上記の 3 つの特性に対応して、業界では現在、次のようなさまざまな効果的な最適化手法が提案されています。

1. FlashAttention-Attendantの計算速度の最適化

Flashアテンション[1]は、アテンションオペレータの計算結果を変えることなく、アテンションオペレータの計算速度を向上させます。 FlashAttention は、さまざまなモデルやタスクで大幅なパフォーマンスの向上を示します。たとえば、BERT-large や GPT-2 などのモデルでは、FlashAttendant は、ベースライン実装と比較して 15% ～ 3 倍のエンドツーエンドアクセラレーションを達成できます。

2. PageAttendant-KV キャッシュメモリ管理の最適化

PageAttendant[3] の目標は、ビデオメモリの断片化を軽減することです。PageAttendant に基づく VLLM システムは、時間消費のスムーズな分散を維持しながら、一般的な大規模言語モデル (LLM) のスループットを 10 倍以上に向上させることができます。

3. 推論中の MOE 削減モデルパラメータ

MOE (Mixture of Experts) [4] の目標は、モデル推論中の計算に関与するパラメータの数を減らすことです。

実験結果: Mixtral モデルは、ほとんどのベンチマークテストで Llama 2 70B モデルよりも優れたパフォーマンスを示し、推論速度は後者より 6 倍高速です。このモデルは複数の言語をサポートしており、強力なコード生成機能を備えており、特定の指示に従うように細かく構成できるため、MT-Bench ベンチマークで高いスコアが得られます。

上記のそれぞれの方向については、後で詳しく紹介します。

4. FlashAttendant 演算子の計算の最適化

FlashAttendant は、FlashAttendant オペレーターの最適化について説明した 2 つの論文を公開しています (FlashAttendant-1[1] と FlashAttendant-2[2])。その最適化原理を理解するために、FlashAttendant 1 [1] を例に挙げてみましょう。

まず、GPU のメモリ階層構造を理解しましょう。以下の図は、論文 FlashAttendant[1] からのものです。

GPU のメモリ階層は、SRAM、HBM、DRAM の 3 つの主要な部分で構成されます。以下は、A100GPU のリファレンス構成です。

SRAM (Static Random Access Memory) はアクセス速度が最も速い (19TB/s) ものの、容量は比較的小さい (わずか 20MB)。

HBM (高帯域幅メモリ) は、大容量のストレージスペース (40GB) と高速データアクセス (1.5TB/秒) を提供します。

DRAM (ダイナミックランダムアクセスメモリ) は、ここでは特に GPU の外部のメインメモリを指し、最大容量 (1TB 以上) を持ちますが、アクセス速度は最も遅くなります (12.8GB/秒)。

上記の構成からもわかるように、メモリ容量が少ないほど処理速度は速くなります。

従来のアテンション計算プロセスでは、HBM にアクセスすることで多数の入出力操作が完了します。 Flashアテンションアルゴリズムは、アテンションの計算プロセスを最適化して計算効率を向上させることで、HBM へのアクセス数を削減する、IO を意識した最適化アルゴリズムです。

以下の図は、FlashAttendant の高速化メソッドを示しています (論文 FlashAttendant-1[1])

FlashAttention は、アテンションメカニズムを迅速かつメモリ効率的に計算するための巧妙なトリックを利用しています。つまり、通常は大量のメモリとコンピューティングリソースを必要とする、入力データをタイル化することで巨大なアテンションマトリックス全体を一度に処理することを回避します。巨大な図書館 (マトリックス) があり、FlashAttend メソッドは図書館内の書籍をいくつかの小さな山に分割し、一度に 1 つの書籍の山だけを処理するようなものであると想像してください。こうすることで、一度にすべての本を取り出してテーブルに置く必要がなくなります (大きなテーブルと多くの時間が必要になります)。

具体的には、行列計算を行う場合、FlashAttendant はデータをブロックに分割し、計算に GPU 上の高速だが小容量のストレージ (SRAM) を使用することで、低速だが大容量のストレージ (HBM) の必要性を効果的に削減します。これにより、計算が高速化されるだけでなく、ビデオメモリの必要性も大幅に削減されます。

FlashAttention は、低速ストレージへの依存を減らすことで、モデルのパフォーマンスを維持または向上させながら、モデルのトレーニングの速度を大幅に向上させることができます。たとえば、BERT-large のトレーニングは MLPerf 1.1 の記録より 15% 高速になり、GPT-2 のトレーニング速度は HuggingFace および Megatron-LM ベースラインの 3 倍になり、長いシーケンスフィールドのトレーニング速度が向上します。 2.4倍に。

下の写真は、huggingface が紹介したフラッシュアテンションに関するブログ [14] からのものです。これにより、フラッシュアテンションがマトリックスを分割する方法がよくわかります。

Flash アテンションは計算を高速化できるので、フラッシュアテンションの計算をサポートするフレームワークは何ですか? 記事の後半では、いくつかの優れた推論フレームワークをお勧めします。

5. PageAttendant - ビデオメモリ管理の最適化

PageAttendance[3] の概念は、もともと VLLM の作者である Woosuk Kwon によって提案されたものであり、VLLM 推論フレームワークの最も重要な最適化戦略でもあります。 Woosuk Kwon 氏は論文の中で、PageAttendant を使用して大規模言語モデル (LLM) サービスの重要な問題、つまりメモリを効果的に管理して遅延を増加させることなくスループットを向上させる方法を紹介しました。

まず、推論の場合の大規模モデルのメモリ構造の分布を理解しましょう。次の図は論文 [3] からのものです。

これは、NVIDIA A100 で 13B のパラメータを持つ大規模な言語モデルを提供するためのメモリレイアウトです。13B LLM のパラメータは、QPS として 26G のビデオメモリを占有します。 KVCache が急速に増加すると、割り当てと解放が頻繁に行われるため、システムは大量のビデオメモリフラグメントを生成し、処理されないとシステムが徐々に崩壊します。

では、VLLM は PageAttendant を通じてビデオメモリの断片化の問題をどのように解決するのでしょうか?下の図は、VLLM のビデオメモリ管理テクノロジである記事 [14] から引用したものです。

PageAttendant は、キー値キャッシュ (KV キャッシュ) を固定サイズのチャンク (または「ページ」) に分割し、これらのチャンクをメモリ内に非連続的に格納できるようにすることで機能します。この方法は、メモリリソースをより柔軟かつ効率的に管理するために、オペレーティングシステムの仮想メモリとページングテクノロジからインスピレーションを得ています。

従来のアテンションメカニズムでは、要求された KV キャッシュをメモリに継続的に保存する必要があり、これにより、メモリの断片化とメモリを効率的に共有できないという 2 つの主な問題が発生します。メモリの断片化によりバッチのサイズが制限される一方、メモリを共有できないとデータが重複し、貴重なメモリリソースが無駄になります。

PageAttendant は、次の手順を実行してこれらの問題を解決します。

KV キャッシュを分割する: 各リクエストの KV キャッシュを複数の小さなチャンクに分割します。これらのチャンクはサイズが固定されており、モデルとハードウェアの特定のニーズに基づいて調整できます。
不連続ストレージ: メモリ内に連続して格納される従来の KV キャッシュブロックとは異なり、PageAttendant では、これらのブロックを物理メモリ内に不連続に分散できます。このようにして、実際のニーズに応じてメモリブロックを動的に割り当ててリサイクルできるため、メモリの無駄が削減されます。
動的管理: PageAttendant は、オペレーティングシステムの仮想メモリ管理と同様の方法でこれらのメモリブロックを動的に管理します。システムは、現在のメモリ使用量に基づいて、オンデマンドで KV キャッシュブロックを割り当てたり解放したりすることで、メモリ使用量を最適化できます。
メモリ共有: PageAttendant は、異なるリクエスト間、または同じリクエスト内の異なるシーケンス間での KV キャッシュブロックの共有もサポートします。この共有は柔軟であり、ブロックレベルで実行できるため、メモリ使用量がさらに削減され、効率が向上します。

このように、PageAttendant を使用すると、LLM サービングシステムは、同じ遅延を維持しながらメモリの無駄を削減し、メモリ共有を改善することで、処理リクエストのスループットを大幅に向上させることができます。

PageAttendant の最適化により、VLLM は LLaMA 7B および 13B のスループットを 10 倍以上向上させました。以下の図は記事 [11] からのものです。

6.推論中の MOE 削減モデルパラメータ

最近リリースされた DBRX は、1,300 億のパラメーターを備えた世界で最も強力なオープンソースの大規模モデルであり、Mistral の 8x7B オープンソースの大規模モデルは、どちらも MOE アーキテクチャに基づいています。より多くのパラメータを持つモデルが MOE アーキテクチャを使用する必要があるのはなぜですか?ミストラルの 8x7B オープンソース大規模モデルを例として取り上げ、MOE アーキテクチャのパフォーマンス上の利点を紹介します。

MOEの大型モデルについて、まず通常の大型モデルとMOEの大型モデルの構造の違いを比較してみましょう。上の写真を参照してください。 MOE の大規模モデルでは、大規模モデルのパラメータは 8 つのグループとルーターに分割され、各グループはエキスパートグループと呼ばれます。要求が来ると、MOE の大規模モデルでは、まずルータに 8 つの専門家グループから 2 つを選択させ、この 2 つの専門家グループのみが計算に参加します。通常の大規模モデルと比較して、すべてのパラメーターが GPU 計算に参加する必要があります。

したがって、MOE 大型モデルの推論速度は、同レベルの通常の大型モデルに比べて約 4 倍高速になります。

Mistral MOE の実装を見てみましょう。Mistral MOE は、mistral.ai によってリリースされた 8*7B の大型モデル [12] からのもので、そのエキスパート層の構造です。 8×7Bの大型モデル。

Mixtral 8x7B は Sparse Mixture of Experts (SMoE) 言語モデルであり、Mistral 7B のアーキテクチャに基づいていますが、各層は 8 つのフィードフォワードブロック (つまりエキスパート) で構成されています。各トークンが処理されると、各層のルーティングネットワークが 2 人の専門家を選択して現在の状態を処理し、出力を結合します。各トークンは 2 人のエキスパートとのみ対話しますが、各タイムステップで選択されるエキスパートは異なる場合があるため、各トークンは 47B のパラメーターにアクセスできますが、推論中に使用されるアクティブなパラメーターは 13B のみです。

Mixtral は、特に数学、コード生成、多言語理解において、複数のベンチマークで優れたパフォーマンスを示しています。 Llama 2 70B および GPT-3.5 と比較すると、Mixtral はほとんどの評価指標で同等またはそれ以上のパフォーマンスを示します。具体的には、Mixtral は Llama 2 70B (70B) に比べて使用するアクティブパラメーター (13B) が 5 分の 1 少ないにもかかわらず、ほぼすべてのカテゴリで同等または同等のパフォーマンスを発揮します。

環境省大規模モデルは、推論速度を低下させることなくパラメータ数を増やすことができ、今後の大規模モデルの開発トレンドとなります。

7. TensorParallelize - テンソル並列化

複数の GPU カードがある場合は、テンソル並列処理を使用して、大規模モデルの推論速度をさらに加速できます。

非常に厚い本を持っていて、その本全体を一度にコピーしたいと考えていますが、コピー機は一度に数ページしかコピーできません。このとき、本をいくつかの部分に分割し、それぞれを別々にコピーし、最後にコピーしたすべての部分を順番に結合すると、本全体のコピーが完成します。

テンソル並列処理では、私たちが扱っている大きなモデルは分厚い本のようなもので、GPU はコピー機のようなものです。単一の GPU で大きなモデル全体を一度に処理することはできないため、モデル (この場合は重みテンソル) をいくつかの部分に分割し、異なる GPU でそれらを個別に処理させる必要があります (コピーされた本の異なる部分に相当します)。入力データを処理するときは、本の各ページを個別にコピーし、コピーした部分をつなぎ合わせて完全な出力結果を形成するようなものです。

このように、作業を共有することで、複数の GPU が連携して、単一の GPU では完了できない大きなタスクを完了します。これがテンソル並列処理の仕組みであり、これにより非常に大規模なモデルを処理できるようになります。

記事からの画像[13]

Tensor 並列処理テクノロジーは、大規模なモデルを複数の GPU に分散してデプロイするために使用されます。行列の乗算を例にとると、入力テンソルが最初の重みテンソルで行列乗算される場合、この操作はまず重みテンソルを列で除算し、除算後に各列を除算して入力テンソルと結合するものとみなすことができます。これらの製品の結果。これらの結合された出力は GPU からエクスポートされ、最終的な出力結果を形成するために集約されます。そのプロセスは上の図に示されています。記事 [13] を参照してください。

8.推奨される推論フレームワーク

前回の記事では、フラッシュアテンション、ページアテンション、MOE、テンソル並列テクノロジなど、いくつかの高速化および最適化テクノロジについて説明しました。次に、私たち自身の実際の運用と評価に基づいて、現在パフォーマンスが優れている推論フレームワークをいくつか推奨します。

9.まとめと展望

この記事では、フラッシュアテンション、ページアテンション、MOE、テンソル並列テクノロジなど、大規模モデル推論の速度を向上させるために設計された一連のテクノロジと手法を深く掘り下げます。本番環境に専用の大規模モデル推論クラスタを一括導入することで、70B規模のモデルを含む推論速度を50％削減することに成功し、本番環境への安定適用に成功し、最適化手法の有効性と有効性を実証しました。実用性。

さまざまな分野で大規模モデルの利用が進む中、いかに効果的に推論速度を向上させ、推論コストを削減するかが課題となっています。私たちの実践では、現在利用可能ないくつかの高速化テクノロジーを実証するだけでなく、経験に基づいた評価後に優れたパフォーマンスを発揮するいくつかの大規模なモデル推論フレームワークも推奨します。これらの提案は、読者が多くの選択肢に直面したときに、自分のニーズに最も適した推論フレームワークを選択できるようにすることを目的としています。

将来に目を向けると、技術の継続的な進歩と新しいアルゴリズムの登場により、大規模モデル推論の効率をさらに向上させるための加速最適化技術がさらに開発されると考えられます。最後に、将来の大規模モデル推論の速度を向上させるために、より多くの新しいテクノロジと手法について深く議論し、導入する機会も楽しみにしています。

参考文献

[1] FlashAttend: IO 認識を備えた高速でメモリ効率の高い Exact Attendance (https://arxiv.org/abs/2205.14135)

[2] FlashAttendant-2: より優れた並列処理と作業分割による高速なアテンション(https://arxiv.org/abs/2307.08691)

[3] PagedAttendant を使用した大規模言語モデルの効率的なメモリ管理(https://arxiv.org/abs/2309.06180)

[4] mixtral-of-experts(https://mistral.ai/news/mixtral-of-experts/)

[5] 専門家の混合(https://arxiv.org/abs/2401.04088)

[6] MEDUSA: 複数のデコードヘッドを備えたシンプルな LLM 推論高速化フレームワーク(https://arxiv.org/pdf/2401.10774.pdf)

[7] 神経言語モデルのスケーリング則(https://arxiv.org/pdf/2001.08361.pdf)

[8] Hyung Won Chung(OpenAI)、Large Language Models (in 2023)、ソウル大学で講演

[9] Llama 2: オープンな基盤と微調整されたチャットモデル(https://arxiv.org/abs/2307.09288)

[10] 必要なのは注意だけです(https://arxiv.org/pdf/1706.03762.pdf)

[11] https://blog.vllm.ai/2023/06/20/vllm.html

[12] https://arxiv.org/pdf/2401.04088.pdf

[13] https://huggingface.co/docs/text-generation-inference/en/conception/tensor_Parallelism

[14] https://huggingface.co/docs/text-generation-inference/en/conception/flash_attention

[15] https://blog.vllm.ai/2023/06/20/vllm.html

*テキスト/ リンゴン

この記事は Dewu Technology によるものです。さらに興味深い記事については、Dewu Technologyを参照してください。

Dewu Technology の許可なく転載することは固く禁じられています。さもなければ、法律に従って法的責任が追及されます。

KubeAI 大規模モデル推論高速化の実践 | Dewu Technology

おすすめ