なぜプロンプト処理はローカルAIのトークン生成を上回るのか？

アクセラレーターは多くの入力トークンを並列に評価できる一方、出力トークンは逐次的にデコードする必要があるため、プロンプト処理のほうがトークン生成を上回ることがあります。

家庭用AIダッシュボードでは、1秒あたり数百、あるいは数千のプロンプトトークンを処理しているように表示される一方、ストリーミング出力ははるかに低い速度で届くことがあります。これらの数値は矛盾した測定値ではなく、異なる実行フェーズを示しています。プリフィルでは提供されたコンテキストをブロック単位で処理してアテンション状態を構築しますが、デコードではモデルを繰り返し実行し、一度に1トークンずつ受け入れます。この差は、プロンプトの長さ、モデルサイズ、メモリ帯域幅、バッチ処理、キャッシュ配置、さらにバックグラウンドのリクエストが同じアクセラレーターを共有しているかどうかによって変わります。

プリフィルとデコードは異なる計算問題を解決する

プロンプト処理は、プリフィルと呼ばれることが多く、入力シーケンスを評価して、後続の生成に必要なKV状態を作成します。デコードは、その初期状態が存在してから開始され、シーケンスをトークン単位で拡張します。

LLMサービングに関する研究では、計算負荷型のプリフィルと、メモリ帯域幅依存型のデコードが、ハードウェア上で異なる挙動を示す別々のフェーズとして説明されています。

したがって、同じモデルが高いプリフィルスループットと、はるかに低い出力トークン速度を示しても、故障とは限りません。それぞれの指標は、異なる実行経路を通過するトークンを数えているからです。

プロンプトトークンは大規模な並列行列で評価できる

プリフィル中は、多数のクエリ位置を同時に利用できます。行列乗算では、シーケンス、バッチ、ヘッド、隠れ層の各次元にまたがって処理を組み合わせられるため、アクセラレーターが処理能力を十分に発揮できるだけの並列演算を確保できます。

FlashAttentionは、低速なデバイスメモリ上で完全なアテンション行列を繰り返し生成することを避けるタイル化アテンション計算によって、アテンション処理のオーバーヘッドを削減します。

長いプロンプトはプリフィルの総処理量を増やしますが、メモリ容量、カーネルの制約、アテンションの計算量が支配的になるまでは、演算資源の利用効率を高めることもあります。

これは入力ブロック全体に対するスループットであり、サーバーが同じ数の独立した出力トークンを毎秒生成できることを示すものではありません。

デコードでは現在のトークンが確定する前に次のトークンを確定できない

自己回帰生成では、1つのトークンをサンプリングまたは選択し、それをシーケンスに追加してから、その確定した結果を条件として次のモデルステップを実行します。次に確定するトークンを事前に知ることはできません。

DistServeは、デコードの反復処理がモデルの重みとアクティブなKV状態に繰り返しアクセスする一方、各シーケンスで生成する新しい出力は少量であることから、2つのフェーズを分離しています。

複数のユーザーをバッチ処理すれば、複数のデコードシーケンスを並列化できます。しかし、1つの会話は依存関係のあるトークン判断の連鎖を通じて進行します。

投機的デコードでは、複数のドラフト候補をまとめて検証できますが、候補を事前に受け入れられない場合、通常のデコードは依然として逐次処理になります。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

高いプロンプトスループットでも、最初のトークンが表示されるまで長くかかることがある

トークン毎秒は、完了したプロンプト処理量をプロンプトサイズで割った値です。非常に長いコンテキストでは、スループットが高く見えても、最初に生成されたトークンが表示されるまで数秒かかることがあります。

ZimaSpaceは、AIレイテンシーの段階に関する説明で、読み込み、プロンプト評価、生成を分けて扱っています。モデルがウォームな状態なら再読み込みの遅延はなくなりますが、大規模なプロンプトを評価するコストはなくなりません。

そのため、インタラクティブな用途でプリフィルを評価するには、最初のトークンまでの時間がより適切な指標です。プロンプトトークン毎秒は、ランタイムが異なる入力長をどれだけ効率的に処理できるかを比較するのに役立ちます。

長いプリフィルは、すでにデコード中のユーザーを遅くすることがある

計算負荷の高いドキュメントプロンプトが、別のユーザーにストリーミングトークンを送信している最中に、同じアクセラレーターへ投入されることがあります。ランタイムが両方の処理を制御なしに組み合わせると、大規模なプリフィルによってデコードの反復処理が長引く可能性があります。

DistServeは、2つのフェーズを同じ場所に配置して一緒にスケジュールした場合に、プリフィルとデコードの干渉が大きくなることを報告しています。

サーバーの合計利用率は依然として高く表示されるかもしれませんが、アクティブなチャットではトークン間の間隔が長くなります。スループットと、ユーザーが感じる滑らかさは、反対方向に変化することがあります。

ハードウェアとランタイムが対応していれば、ワーカーの分離、フェーズを考慮したスケジューリング、またはデコード機会の予約によって、インタラクティブな出力を保護できます。

チャンク分割は、応答性向上のためにプリフィル効率の一部を犠牲にする

ランタイムは、1つの長いプロンプトを小さなチャンクに分割し、それらをデコード処理と交互に実行できます。プロンプトはより多くのスケジューリング単位を必要としますが、1回の非常に長い処理がアクセラレーターを独占することを防げます。

Sarathi-Serveは、チャンク化プリフィルを利用して、実用的なバッチ処理の機会を維持しながら干渉を削減します。

最適なチャンクサイズは、プロンプトの長さ、モデルアーキテクチャ、アクセラレーターの容量、アクティブな会話に求められるレイテンシー目標によって異なります。

プロンプト処理時間、最初のトークンまでの時間、トークン間の時間、出力トークン毎秒を個別に測定してください。見出し上のスループットが低いフェーズが、ユーザーの最も長い待ち時間を引き起こしているとは限りません。