投機的デコーディングはホームAIサーバーをどのように高速化するのか？

投機的デコーディングは、高速なドラフト機構が複数のトークンを提案し、ターゲットモデルがそれらをまとめて検証することで、ホームAIサーバーを高速化します。

通常の自己回帰生成では、フルモデルが1つのトークンを生成し、それを追加してから再度実行し、次のトークンが確定できるようになります。この逐次的な依存関係により、高性能なアクセラレーター上でも、デコーディング中に並列化できる処理は限られます。投機的デコーディングでは、より低コストな計算で候補トークンを生成し、その後、ターゲットモデルを1回実行して複数の位置を検証します。得られる効果は、ドラフト生成の速度、受け入れられる候補の数、追加のメモリや検証オーバーヘッドがローカルハードウェアに収まるかどうかによって決まります。

標準的なデコーディングはターゲットモデルを1ステップずつ進める

自己回帰モデルは、新しい各トークンをプロンプトと、それまでに受け入れたすべてのトークンに基づいて予測します。現在のトークンがサンプリングされるまで、次のステップを確定することはできません。

投機的デコーディングに関する初期の研究では、削減を目指すレイテンシーのボトルネックとして、逐次的なターゲットモデルの実行が説明されています。

バッチ処理を使えば複数のリクエストで1回の反復を共有できますが、個々のシーケンスが1回のターゲットモデル実行で受け入れられるトークンは、通常1つだけです。

高速なドラフト機構が複数の未来のトークンを予測する

ドラフトコンポーネントには、より小型のモデル、ターゲットモデルを縮小したモデル、補助予測ヘッド、またはフルモデルを繰り返し実行するよりも低コストな別の機構を利用できます。

投機的デコーディングでは、候補のドラフト生成を行い、ターゲットモデルが評価する前に、可能性の高いいくつかの続き方を用意します。

ドラフトがターゲットの権限に取って代わるわけではありません。目的は、簡単に予測できる未来のトークンを低コストで推測し、ターゲットが並列に検査できるブロックを作ることです。

ドラフトモデルが大きすぎると予測精度は高くなる可能性がありますが、この最適化で削減するはずだったレイテンシーとメモリの大半を消費してしまうことがあります。

ターゲットモデルは1回の並列パスで候補を検証する

ターゲットモデルはドラフトされたシーケンスを評価し、提案されたトークンが自身の確率分布と整合するかを判断します。受け入れられたトークンはまとめてシーケンスを進め、最初に拒否された位置は正確なサンプリング手順によって修正されます。

このアルゴリズムでは、並列検証と棄却サンプリングを使用するため、正確な投機的デコーディングではターゲットモデルの出力分布が維持されます。

この違いは、品質に関する主張において重要です。正確な検証であれば、選択したターゲットのデコーディング分布に対して損失はありません。一方、ヒューリスティックな先読み手法では、異なるトレードオフが生じる可能性があります。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

受け入れ長が、削減できる逐次ステップ数を決める

ターゲットモデルがドラフトされたトークンの大半を受け入れる場合、1回の検証パスで通常のデコーディングを複数回実行する代わりになります。最初の候補が繰り返し拒否される場合、サーバーはドラフト処理を行っても、あまり速くシーケンスを進められません。

大規模な実験研究では、投機的デコーディングの性能は、最も性能の高い小型言語モデルを選ぶことだけでなく、ドラフトの効率に大きく左右されることが示されています。

受け入れ率は、プロンプトの分野、サンプリング温度、トークナイザーの互換性、ターゲットモデル、ドラフトの長さ、そしてドラフトがターゲットの次トークン分布をどれだけ近く予測できるかによって変化します。

ドラフトブロックを長くすると、進行できる可能性は増えますが、早い段階で不一致が起きた場合に無駄になる処理も増えます。そのため、最適な深さはワークロードによって異なります。

ドラフトのオーバーヘッドとメモリが家庭での高速化を打ち消すことがある

ホームAIサーバーでは、ターゲットモデルとKVキャッシュがすでにメモリを占有している状態で、ドラフト機構を実行し、その状態を保持し、検証を行う必要があります。2つ目のモデルによって、CPUオフロードが必要になったり、利用できるコンテキストが減少したりする可能性があります。

ハードウェアに関する研究では、CPUおよびGPUの投機的デコーディングにおける高速化の主な制限要因として、ドラフトモデルのレイテンシーが挙げられています。高速なGPU上のターゲットモデルに対してCPUでドラフト生成を行ったり、ドラフトが同じメモリ帯域幅を奪い合ったりすると、ほとんど効果が得られないことがあります。

自己投機的手法では、ターゲットモデルの一部を再利用することで、別個のフルサイズのドラフトモデルを避けられますが、独自の実行上および互換性上の制約が生じます。

計算性能と同じくらい、メモリの余裕も重要です。ドラフトによってモデルの追い出し、コンテキスト上限の縮小、または他のホームサーバーアプリの不安定化が起きるなら、その最適化は有用ではありません。

受け入れトークン数だけでなく、エンドツーエンドのレイテンシーを測定する

通常のデコーディングと投機的デコーディングを比較する際は、同じターゲットモデル、プロンプトセット、サンプリングパラメーター、出力長、ウォーム状態の条件を使用します。初回トークンまでの時間、1秒あたりの出力トークン数、受け入れ長、ドラフト時間、検証時間、ピークメモリを記録してください。

ZimaSpaceによるモデル常駐の分析も関係します。ドラフトを追加すると、どのモデルの状態がウォームなまま残るかが変わる可能性があるためです。デコーディングの最適化は、異なるコールドスタート条件を比較したテストの成果として評価すべきではありません。

投機的デコーディングは、ターゲットモデルが遅く、ドラフト生成が大幅に低コストで、受け入れ率が高く、アクセラレーターが複数の候補を効率よく検証できる場合に、最も効果を発揮しやすくなります。

出力が短い場合、ターゲットモデルのデコーディングがすでに高速な場合、ドラフトとの不一致が頻繁に起きる場合、またはローカルのメモリと帯域幅が本当のボトルネックである場合は、効果が小さくなります。

よくある質問

投機的デコーディングでは、最終回答に低品質なモデルを使うのですか？

ドラフトは候補を提案しますが、正確な検証によって、受け入れられる出力分布についてはターゲットモデルが責任を持ち続けます。

投機的デコーディングはプロンプト処理を高速化しますか？

主な対象は自己回帰による出力生成です。実装が別個のプレフィックス最適化やプリフィル最適化と組み合わされていない限り、プロンプトのプリフィルレイテンシーは同程度のままになる可能性があります。

投機的デコーディングはCPUのみのホームサーバーで実行できますか？

互換性のあるランタイムであれば実行できますが、高速化できるかどうかは、そのCPUとメモリシステム上で、ドラフト生成と検証が通常のデコーディングより低コストになるかによって決まります。