高性能 LLM 推論フレームワークの設計と実装

1. 大規模言語モデル推論の概要

従来の CNN モデル推論とは異なり、大規模言語モデルの推論は通常、事前入力とデコードの 2 つの段階に分かれています。各リクエストが開始された後に生成される推論プロセスは、まず事前入力プロセスを実行します。事前入力プロセスでは、すべてのユーザー入力を計算し、対応する KV キャッシュを生成します。次に、複数のデコード プロセスを実行します。各デコード プロセスでは、サーバーが文字を生成して KV キャッシュに格納し、順番に繰り返します。

デコード処理は文字ごとに生成されるため、各回答の生成には長い時間がかかり、多くの文字が生成されます。そのため、デコード段階の数は非常に多く、推論処理全体の 90% 以上を占めます。

事前入力処理では、ユーザーが入力したすべての単語を一度に計算する必要があるため計算量は多くなりますが、これは 1 回限りのプロセスであるため、推論時間全体の 10% 未満しか占めません。

大規模言語モデルの推論では、スループット、最初のトークンのレイテンシ、レイテンシ、QPS (1 秒あたりのリクエスト数) の 4 つの指標がよく使用されます。これら 4 つのパフォーマンス指標は、システムのサービス提供能力を 4 つの異なる側面から測定します。

まず、スループットについて紹介します。モデル推論の観点から、まず注目すべきはスループットです。スループットとは、単位時間あたりに実行できるデコード数、つまりシステム負荷が最大に達したときに生成できる文字数を指します。スループットをテストする方法は、すべてのユーザーが同時に到着し、全員が同じ質問をし、同時に開始および終了でき、生成するテキストの長さが入力するテキストの長さと同じであると仮定することです。まったく同じ入力を使用することで、完全なバッチが形成されます。この場合、システムのスループットが最大化されます。しかし、このシナリオは非現実的であるため、これは理論上の最大値です。システムが 1 秒間に実行できる独立したデコード段階の数を測定します。

2 番目の指標は、最初のトークンの遅延です。これは、ユーザー グループが推論システムに入ってから事前入力フェーズを完了するまでにかかる時間を指します。これは、システムが最初の文字を生成するのに必要な応答時間でもあります。多くの要件はこの指標に重点を置いており、ユーザーがシステムに質問を入力した後、回答を得るまでの時間が 2 ～ 3 秒未満であることを期待しています。

3 番目の指標はレイテンシです。各デコードに必要な時間を指します。これは、大規模言語モデルシステムのオンライン処理中に各文字が生成される時間間隔、つまり生成プロセスがどれだけスムーズであるかを反映します。ほとんどの場合、50 ミリ秒未満の遅延、つまり 1 秒あたり 20 文字を生成することが期待されます。このような大規模な言語モデルの生成は比較的スムーズです。

最後のメトリックは QPS (1 秒あたりのリクエスト数) です。これは、オンライン システム サービスで 1 秒間に処理できるユーザー リクエストの数を反映します。この指標の測定方法は比較的複雑なので、後ほど詳しく紹介します。

私たちは、ファースト トークン レイテンシとレイテンシ インジケーターの両方について、比較的完全なテストを実施しました。これら 2 つの指標は、ユーザー入力の長さとバッチ サイズが異なるため、大きく異なります。

上記の表からわかるように、同じ 7B モデルの場合、ユーザーの入力長が 8 から 2048 に変更されると、プリフィル時間は 6.78 ミリ秒から 2078 ミリ秒、つまり 2 秒に変更されます。ユーザーが 80 人いて、各ユーザーが 1,024 語を入力する場合、サーバー上で Prefill を実行するのに約 2 秒かかりますが、これは許容範囲を超えています。ただし、ユーザー入力が非常に短い場合、たとえば、1 回に 8 語しか入力されない場合、768 人のユーザーが同時に到着したとしても、最初の語の遅延はわずか 165 ミリ秒程度になります。

最初の単語の遅延は、ユーザーの入力の長さに最も関連しています。ユーザーの入力が長くなるほど、最初の単語の遅延は大きくなります。ユーザー入力の長さが短い場合、最初の単語の遅延は、大規模言語モデルの推論プロセス全体のボトルネックにはなりません。

その後のデコード遅延については、モデルが兆レベルにならない限り、通常はデコード遅延は 50 ミリ秒以内に抑えられます。主にバッチサイズによって影響を受けます。バッチサイズが大きいほど推論遅延は大きくなりますが、基本的に増加はそれほど大きくありません。

スループットは実際にはこれら 2 つの要因によっても影響を受けます。ユーザー入力の長さと生成された長さが非常に長い場合、システムのスループットはあまり高くなりません。ユーザー入力の長さと生成された長さの両方がそれほど長くない場合は、システムのスループットが異常なレベルに達する可能性があります。

QPS をもう一度見てみましょう。 QPS は非常に具体的な指標で、システムで 1 秒あたりに処理できるリクエストの数を示します。このテストを実行するときは、実際のデータを使用します。 (このデータはすでにサンプリングしてgithubに載せてあります。)

実際に大規模な言語モデルシステムを使用する場合、各ユーザーの到着時間は不確実であるため、QPS の測定はスループットとは異なります。早く来るユーザーもいれば、遅く来るユーザーもいるかもしれませんし、各ユーザーが Prefill を完了した後に生成されるデータの長さも不確実です。ユーザーによっては 4 つの単語を生成して終了する場合もありますが、20 を超える単語を生成する場合もあります。

実際のオンライン推論中の事前入力段階では、ユーザーが生成した実際の長さが異なるために問題が発生します。つまり、事前に生成を完了するユーザーもいれば、多くの長さを生成するまで終了しないユーザーもいます。このようなビルド中は、GPU がアイドル状態になる場所が多数あります。したがって、実際の推論プロセスでは、QPS はスループットの利点を十分に発揮できません。スループットは高いかもしれませんが、グラフィック カードが使用できない穴だらけの処理のため、実際の処理能力が低い可能性があります。したがって、QPS 指標に関しては、計算の穴やグラフィック カードを効果的に利用できない状態を回避し、スループットがユーザーに十分に役立つようにするための、多くの具体的な最適化ソリューションを用意します。

2. 大規模言語モデルの推論パフォーマンスの最適化

次に、大規模言語モデルの推論プロセスに移り、QPS やスループットなどの指標に関してシステムが優れたパフォーマンスを達成できるようにするためにどのような最適化を行ったかを確認します。

1. LLM推論プロセス

まず、大規模言語モデルの推論プロセスを詳しく紹介しましょう。前述のように、各リクエストは事前入力とデコードの 2 つの段階を経る必要があります。事前入力段階では、少なくとも次の 4 つのことを行う必要があります。

まず、ユーザー入力をベクトル化します。トークン化プロセスとは、ユーザーが入力したテキストをベクトルに変換することです。事前入力段階全体と比較すると、約 10% の時間がかかり、コストがかかります。

その後、実際の事前入力計算が実行され、これに約 80% の時間がかかります。

計算後、サンプリングが実行されます。このプロセスは通常、Pytorch の sample と top p を使用して実行されます。 Argmax は大規模言語モデルの推論に使用されます。つまり、モデルの結果に基づいて最終的な単語を生成するプロセスです。このプロセスには 10% の時間がかかります。

最後に、補充結果が顧客に返されますが、これには約 2% ～ 5% の時間しかかかりません。

デコード段階ではトークン化する必要はありません。各デコードは計算から直接開始されます。デコードプロセス全体には 80% の時間がかかり、その後のサンプリング、つまりサンプリングと単語生成のプロセスにも 10% の時間がかかります。しかし、トークン化解除には時間がかかります。トークン化解除とは、単語が生成された後に、生成された単語がベクトルであり、テキストにデコードする必要があることを意味します。この操作には約 5% の時間がかかり、最終的に生成された単語がユーザーに返されます。

新しいリクエストが届くと、事前入力が完了した後に繰り返しデコードされます。各デコード段階の後に、結果がその場で顧客に返されます。この生成プロセスは大規模な言語モデルでは非常に一般的であり、この方法をスト​​リーミングと呼びます。

2. 最適化: パイプラインの前処理と後処理、高性能サンプリング

ここで紹介する最初の最適化は、グラフィック カードの使用率を最大化することを目的としたパイプライン最適化です。

大規模言語モデルの推論プロセス中、トークン化、高速サンプル、およびデトークン化のプロセスはモデルの計算とは無関係です。大規模言語モデル全体の推論は、このようなプロセスとして考えることができます。事前入力プロセス中に、高速サンプルの単語ベクトルを取得した後、結果がすでに GPU 上にあるため、結果が返されるのを待たずに、すぐに次の段階のデコードを開始できます。 1 つのデコードを完了すると、デトークン化が完了するのを待たずに、すぐに次のデコードを開始できます。デトークン化は CPU プロセスであるため、次の 2 つのプロセスでは結果がユーザーに返されるだけで、GPU 計算は行われません。そして、サンプリング プロセスを実行した後、次に生成される単語が何であるかがすでにわかっています。必要なデータはすべて取得されており、次の 2 つのプロセスの完了を待たずにすぐに次の操作を開始できます。

PPL.LLM の実装では、次の 3 つのスレッド プールが使用されます。

最初のスレッド プールはトークン化プロセスの実行を担当します。

3 番目のスレッド プールは、後続の高速サンプルの実行と、結果を返してトークン解除するプロセスを担当します。

中間のスレッド プールは、コンピューティング プロセスを実行するために使用されます。

これら 3 つのスレッド プールは、これら 3 つの部分の遅延を非同期的に分離し、それによってこれら 3 つの部分の遅延を可能な限りマスクします。これにより、システムの QPS が 10% ～ 20% 向上します。これは、私たちが行った最初の最適化です。

3. 最適化: 動的バッチ処理

この後、PPL.LLM は動的バッチ処理と呼ばれるさらに興味深い最適化も実行できます。

前述のように、実際の推論プロセスでは、ユーザーの世代長が異なり、ユーザーの到着時間も異なります。そのため、現在の GPU が推論処理中であり、すでにオンライン推論の要求がある場合、推論の途中で 2 番目の要求が挿入されると、2 番目の要求の生成処理が 1 番目の要求の生成処理と競合する状況が発生する可能性があります。 GPU は 1 つしかないため、この GPU はタスクをシリアルでしか実行できず、GPU 上でタスクを単純に並列で実行することはできません。

私たちが行っているのは、2 番目のリクエストが到着すると、その事前入力フェーズと最初のリクエストに対応するデコード フェーズを混合して、マージ ステップと呼ばれる新しいフェーズを生成することです。このマージ ステップでは、最初のリクエストのデコードだけでなく、2 番目のリクエストの事前入力も実行されます。この機能は多くの大規模言語モデル推論システムで利用可能であり、実装により大規模言語モデルの QPS が 100% 増加します。

具体的なプロセスとしては、最初のリクエスト生成プロセスが半分完了しており、デコード中に長さ 1 の入力があるのに対し、2 番目のリクエストは新規であり、プレフィル プロセス中に長さ 48 の入力があることになります。 2 つの入力は最初の次元に沿って連結されます。連結された入力の長さは 49 で、非表示の次元は 4096 です。この長さ 49 の入力では、最初の単語が最初の要求であり、残りの 48 単語が 2 番目の要求です。

大規模モデル推論では、RMSNorm、行列乗算、アテンションなどの経験が必要な演算子は、デコードに使用されるか事前入力に使用されるかに関係なく、同じ構造を持つためです。したがって、連結された入力をネットワーク全体に直接投入して実行することができます。区別する必要があるのはただ 1 か所だけです。それは注意です。注意プロセス中、または自己注意演算子を実行するときに、データ転送を実行し、すべてのデコード要求を 1 つの波に転送し、すべての事前入力要求を別の波に転送して、2 つの異なる操作を実行します。すべての事前入力要求は Flash Attention を実行します。デコードを実行するすべてのユーザーは、Decoding Attention と呼ばれる非常に特殊な演算子を実行します。分割されたストリームでアテンション演算子が実行された後、ユーザー入力は再度結合され、他の演算子の計算が完了します。

マージステップでは、各リクエストが来ると、実際にこのリクエストをシステム上の既存のすべてのリクエストの入力と連結して計算を完了し、デコードを続行します。これが、大規模言語モデルでの動的バッチ処理の実装です。

4. 最適化: 注意のデコード

Decoding Attention 演算子は Flash Attention 演算子ほど有名ではありませんが、実際にはデコード タスクの処理においては Flash Attention よりもはるかに高速です。

これは、デコード タスク専用に設計された演算子です。計算を完了するために Cuda Core に完全に依存しており、Tensor Core には依存していません。非常に柔軟で変更も簡単ですが、制限があります。デコードテンソルの演算であるという特徴のため、入力 q の長さは 1 である必要がありますが、k と v の長さは可変です。これは Decoding Attention の制限です。この制限の下で、いくつかの特定の最適化を行うことができます。

この特定の最適化により、デコード段階でのアテンション演算子の実装が Flash Attention よりも高速になります。この実装は現在オープンソースであり、上図の URL からアクセスできます。

5. 最適化: VMアロケータ

もう 1 つの最適化は、ページ アテンションの最適化に対応する仮想メモリ アロケータです。リクエストが到着すると、事前入力フェーズとデコード フェーズが実行されます。すべての入力トークンによって KV キャッシュが生成され、このリクエストのすべての履歴情報が記録されます。では、このような要求を満たして生成タスクを完了するには、どのくらいの KV キャッシュ スペースをそのような要求に割り当てる必要があるのでしょうか?分割数が多すぎるとビデオメモリが無駄になります。分割数が少なすぎると、デコードフェーズ中に KV キャッシュの終了位置に到達し、生成を継続できなくなります。

この問題を解決するには、3 つの解決策があります。

Pytorch のメモリ管理方法は、4096 ワードの生成を確実にするために、各リクエストに対して十分な大きさのスペース (通常は 2048 または 4096) を予約することです。しかし、ほとんどのユーザーの実際の世代の長さはそれほど長くはないため、多くのメモリスペースが無駄になります。

Page Attention は、ビデオ メモリ管理の別の方法を使用します。生成プロセス中にユーザーがビデオ メモリを追加し続けることを可能にします。オペレーティング システムのページ ストレージまたはメモリ ページングに似ています。リクエストが届くと、システムはこのリクエストにビデオ メモリの小さなブロックを割り当てます。このビデオ メモリの小さなブロックは、通常、8 文字を生成するのに十分な大きさです。リクエストが 8 文字を生成すると、システムはビデオ メモリのブロックを追加し、結果をこのビデオ メモリのブロックに書き込みます。同時に、システムはビデオ メモリ ブロック間のリンク リストを維持し、オペレーターが正常に出力できるようにします。生成された長さが長くなると、追加のビデオ メモリ ブロックがユーザーに割り当てられ、ビデオ メモリ ブロック割り当てリストが動的に維持されるため、システムは大量のリソースを無駄にせず、この要求のために過剰なビデオ メモリ領域を予約する必要がなくなります。

PPL.LLM は仮想メモリ管理メカニズムを使用して、各要求に必要な世代の長さを予測します。各リクエストが到着すると、連続したスペースが直接割り当てられ、この連続したスペースの長さが予測されます。しかし、理論的には、これは実現が難しいかもしれません。特に、各リクエストに対してコンテンツが生成される期間が明確にわからないオンライン推論の段階では、それが困難です。したがって、これを行うにはモデルをトレーニングすることをお勧めします。なぜなら、Page Attention のようなモデルを採用したとしても、依然として問題が発生するからです。 Page Attention の実行プロセス中、特定の時点で、たとえば、現在のシステムにはすでに 4 つの要求があり、システム内にまだ割り当てられていないビデオ メモリが 6 つあります。現時点では、新しいリクエストが来るかどうか、またそれらに対して引き続きサービスを提供できるかどうかはわかりません。現在の 4 つのリクエストはまだ終了しておらず、将来的に新しいビデオ メモリ ブロックを追加する必要がある可能性があるためです。したがって、Page Attention メカニズムを使用しても、各ユーザーの実際の世代長を予測する必要があります。この方法でのみ、特定の時点で新しいユーザー入力を受け入れることができるかどうかを知ることができます。

これは、PPL を含め、現在の推論システムでは実行できないことです。ただし、仮想メモリの管理メカニズムにより、ビデオ メモリの無駄を大幅に回避できるため、システム全体の QPS が約 200% 向上します。

6. 最適化: KV キャッシュの量子化

PPL.LLM が行っているもう 1 つの最適化は、KV キャッシュの量子化です。サーバー側の推論プロセス中、KV キャッシュはビデオ メモリ領域の大部分を占有するため、システムの同時要求の数が大幅に制限されます。

サーバー側、特に A100 や H100 などの大容量ビデオメモリを搭載したサーバーでは、7B モデルなどの大規模言語モデルを実行すると、KV キャッシュがビデオメモリ領域の 84% を占めることがわかります。176B などの 1000 億レベルのモデルの場合、KV キャッシュもキャッシュ領域の 50% 以上を占めます。これにより、各リクエストに大量のビデオ メモリを割り当てる必要があるため、モデル内の同時リクエストの数が大幅に制限されます。この方法では、リクエスト数を増やすことができず、結果として QPS とスループットを向上させることができません。

PPL.LLM は、グループ量子化という非常に特殊な量子化方法を使用して、KV キャッシュ内のデータを圧縮します。つまり、元の FP16 データを INT8 に量子化しようとします。これにより、KV キャッシュのサイズが 50% 削減され、サーバーが処理できるリクエストの数が 100% 増加します。

Faster Transformer と比較してスループットが約 50% 向上できる理由は、KV キャッシュの量子化によってもたらされるバッチ サイズの増加によるものです。

7. 最適化: 行列乗算量子化

KV キャッシュの量子化後、行列乗算のより細かい量子化を実行しました。サーバー側の推論プロセス全体において、行列乗算は推論時間全体の 70% 以上を占めます。PPL.LLM は、チャネルごと/トークンごとの動的な交互ハイブリッド量子化方式を使用して、行列乗算を高速化します。これらの量子化は非常に正確で、パフォーマンスをほぼ 100% 向上させることができます。

具体的なアプローチは、RMSNorm演算子に基づく量子化演算子を統合することです。この量子化演算子は、RMSNorm演算子の機能に基づいてトークン情報をカウントし、各トークンの最大値と最小値をカウントし、トークンの次元に沿ってデータを量子化します。つまり、RMSNorm 後のデータは FP16 から INT8 に変換され、今回は量子化が完全に動的であり、キャリブレーションは必要ありません。後続の QKV 行列乗算では、3 つの行列乗算すべてがチャネルごとに量子化されます。受信するデータは INT8 であり、重みも INT8 であるため、これらの行列乗算では完全な INT8 行列乗算を実行できます。それらの出力はソフト アテンションによって受け入れられますが、受け入れられる前に逆量子化プロセスが実行され、この逆量子化プロセスがソフト アテンション オペレーターと融合されます。

後続のO行列乗算は量子化されず、Soft Attentionの計算プロセス自体も量子化されません。後続の FeedForward プロセスでは、これら 2 つの行列は同様に量子化され、上記の RMSNorm または Silu や Mul などの活性化関数と融合されます。それらの逆量子化演算子は、下流の演算子と融合されます。

8. 最適化: INT8 と INT4

現在、学術界では大規模言語モデルの量子化に主に INT4 が注目されていますが、サーバー側推論のプロセスでは、実際には INT8 量子化を使用する方が適しています。

INT4 量子化は、重みのみの量子化とも呼ばれます。この量子化方法の重要性は、大規模な言語モデルの推論プロセス中にバッチ サイズが比較的小さい場合、行列乗算計算プロセスの時間の 90% が重みの読み込みに使用されることです。重みの量が非常に大きく、入力を読み込む時間が非常に短いため、その入力、つまりアクティベーションも非常に短く、計算時間もそれほど長くなく、結果を書き戻す時間もそれほど長くありません。つまり、この演算子はメモリを大量に消費する演算子です。この場合、バッチが十分に小さいことを条件に、INT4 量子化を選択します。INT4 量子化を使用して各重みをロードした後、すぐに逆量子化プロセスが実行されます。今回は、逆量子化により重みが INT4 から FP16 に逆量子化されます。逆量子化プロセスの後、後続の計算は FP16 とまったく同じです。つまり、INT4 重みのみの量子化はメモリを大量に消費する行列乗算に適しており、その計算プロセスは依然として FP16 コンピューティング デバイスによって完了されます。

バッチが 64 や 128 などのように十分に大きい場合、INT4 の重みのみの量子化ではパフォーマンスは向上しません。バッチが十分に大きい場合、計算時間が非常に長くなるためです。 INT4 Weight Only 量子化には非常に悪い点があります。逆量子化プロセスに必要な計算量は、バッチ (GEMM バッチ) の増加に伴って増加します。入力バッチが増加すると、逆量子化時間もどんどん長くなります。バッチ サイズが 128 に達すると、逆量子化によって生じる時間の損失と重みのロードによってもたらされるパフォーマンス上の利点が相殺されます。つまり、バッチ サイズが 128 に達すると、INT4 行列量子化は FP16 行列量子化よりも高速にならず、パフォーマンスの利点は極めて小さくなります。バッチ サイズが約 64 の場合、INT4 の重みのみの量子化は FP16 よりも 30% しか高速ではありません。バッチ サイズが 128 の場合、約 20% しか高速ではありません。

しかし、INT8 の場合、INT8 量子化と INT4 量子化の最大の違いは、逆量子化プロセスが不要で、計算時間を半分に圧縮できることです。バッチ サイズが 128 の場合、重みをロードする時間と計算時間は FP16 から INT8 に半分になり、100% の加速が実現します。

サーバー側のシナリオでは、特にリクエストが絶えず流入するため、ほとんどの行列乗算は計算負荷が高くなります。この場合、最高のスループットを実現したい場合、INT8 の効率は実際には INT4 よりも高くなります。これは、これまで完了した実装において、サーバー側で INT8 を主に推進している理由の 1 つでもあります。

9. 最適化: FP8 vx INT8

H100、H800、4090 では、FP8 量子化を実行できます。データ形式 FP8 は、Nvidia の最新世代のグラフィック カードで導入されました。理論的には、INT8 の精度は FP8 よりも高くなりますが、FP8 の方が使いやすく、パフォーマンスも高くなります。今後のサーバー側推論プロセスのアップデートでもFP8の実装を推進していきます。上図からわかるように、FP8 の誤差は INT8 の誤差の約 10 倍になります。 INT8 には量子化サイズ係数があり、サイズ係数を調整することで INT8 の量子化誤差を減らすことができます。 FP8 の量子化誤差は基本的にサイズ係数とは無関係であり、サイズ係数の影響を受けません。つまり、基本的にキャリブレーションを行う必要はありません。しかし、その誤差は一般に INT8 よりも大きくなります。

10. 最適化: INT4 と非線形量子化

PPL.LLM の今後のアップデートでは、INT4 の行列量子化も更新されます。このタイプの重みのみの行列量子化は、バッチ サイズが 1 に固定されている携帯電話などのデバイスのエンド サイドで主に使用されます。今後のアップデートでは、INT4から非線形量子化へと段階的に変更されます。なぜなら、Weight Only の計算プロセスでは、逆量子化プロセスが発生しますが、これは実際にはカスタマイズ可能であり、必ずしも線形逆量子化プロセスであるとは限りません。他の逆量子化プロセスと量子化プロセスを使用すると、今度は計算がより正確になります。

代表的な例としては、論文で言及されているNF4の量子化が挙げられます。この量子化は、実際にはテーブルを使用して量子化と逆量子化を行う非線形量子化です。 PPL.LLM の今後のアップデートでは、このような量子化を使用してエンドサイド推論を最適化しようとします。

3. 大規模言語モデル推論用ハードウェア

最後に、大規模言語モデルを処理するためのハードウェアを紹介します。

モデル構造が決定されると、その具体的な計算ワークロード、必要なメモリアクセスの量、必要な計算ワークロードの量がわかります。同時に、各グラフィック カードの帯域幅、計算能力、価格などもわかります。モデルの構造とハードウェア指標を決定した後、これらの指標を使用して、このグラフィック カードで大規模なモデルを推論する際の最大スループット、計算遅延、およびメモリ アクセス時間を計算できます。非常に具体的な表を計算できます。この表は、今後の資料で公開される予定です。この表にアクセスして、大規模言語モデルの推論に最も適したグラフィック カード モデルを確認できます。

大規模な言語モデル推論では、ほとんどの演算子がメモリを大量に消費するため、メモリ アクセスのレイテンシは常に計算のレイテンシよりも高くなります。大規模言語モデルのパラメータ行列は非常に大きいため、A100/80G でもバッチ サイズを 272 に設定すると、計算遅延は比較的小さくなり、メモリ アクセス遅延が大きくなります。したがって、私たちの最適化の多くはメモリ アクセスから始まります。ハードウェアを選択する際、私たちが主に重視するのは、より高い帯域幅とより大きなビデオ メモリを備えたデバイスを選択することです。これにより、大規模な言語モデルは推論中により多くのリクエストと高速なメモリ アクセスをサポートできるようになり、スループットが向上します。

以上が今回のシェア内容となります。関連するすべての情報はネットワーク ディスクに保存されます。上の画像のリンクを参照してください。私たちのコードはすべて github でオープンソース化されています。いつでもお気軽にご連絡ください。

4. 質疑応答

Q1: PPL.LLM は、Flash Attention の Softmax などのメモリ アクセスの問題を最適化しますか?

A1: Decoding Attention 演算子は非常に特殊です。その Q の長さは常に 1 なので、Flash Attention のような Softmax での膨大なメモリ アクセスの問題に直面することはありません。実際、Decoding Attention の実行中は Softmax プロセスが完全に実行されており、Flash Attention のように高速に実行する必要はありません。

Q2: INT4 の Weight Only 量子化がバッチと線形関係にあるのはなぜですか? これは固定数ですか?

A2: これは良い質問です。まず、逆量子化は誰もが考えるほど簡単ではありません。INT4 の重みを FP16 に戻すだけではありません。これだけを行うと、重みの数だけ逆量子化する必要があります。実際にはそうではありません。これは行列乗算に統合された逆量子化であるためです。行列乗算を実行する前にすべての重みを逆量子化し、そこに配置してから読み取ることはできません。このように、私たちが行った INT4 の量子化は無意味です。ブロック行列乗算を実行するため、実行プロセス中は常に逆量子化が行われます。各重みを読み書きする必要がある回数は 1 回ではなく、継続的に計算する必要があります。この数は実際にはバッチに関連しています。つまり、これまでの量子化の最適化手段とは異なり、量子化演算子と逆量子化演算子が別々に存在することになります。 2 つの演算子が挿入されると、逆量子化は演算子に直接統合されます。行列の乗算を実行しているため、逆量子化する必要がある回数は 1 回だけではありません。

Q3: KV キャッシュの反量子化計算は、シミュレートされたストレージによってマスクできますか?

A3: 弊社のテストによれば、隠すことが可能であり、実際にかなり残っています。 KV 計算における逆量子化と量子化は、自己注意演算子、具体的にはデコーディング注意に統合されます。テストによれば、この演算子は 10 倍の計算量でもカバーできる可能性があります。メモリアクセスの遅延でもカバーできない。主なボトルネックはメモリアクセスにあり、その計算能力はメモリアクセスをカバーできるレベルにはまだ程遠い。したがって、KV キャッシュ内の逆量子化計算は、基本的にこの演算子にとって簡単に隠蔽できるものになります。