推測デコーディングの受け入れ率とは何か、なぜ重要なのか？

投機的デコーディングの受理率は、ターゲットモデルによる検証でドラフトトークンの提案がどの程度保持されるかを測る指標であり、検証パスごとに得られる実用的な処理量を直接左右します。

小型のドラフトモデルは複数の未来のトークンを提案し、大型のローカルモデルはそれらを並列で検証できます。提案の大半が受理されれば、コストの高いターゲットパス1回で応答を複数位置分進められます。一方、早い段階で棄却されると、ドラフト処理の多くが無駄になります。したがって、この率はワークロードに依存する効率性の指標であり、単独での精度スコアでも、エンドツーエンドの高速化を保証するものでもありません。

受理数が検証済みドラフトの進捗を示す

標準的な投機的サンプリングでは、ドラフト分布がブロックを提案し、ターゲットがそれらの位置をまとめて評価します。トークンは最初に棄却されるまで順番に受理され、その後アルゴリズムが修正トークンをサンプリングして、別の投機ラウンドを開始します。

投機的デコーディングに関する原論文では、ターゲットモデルの出力分布を維持しながら、ドラフト分布とターゲット分布の関係に基づく受理確率を定義しています。重要なのはモデルの回答同士の見た目の類似性ではなく、受理された進捗です。

実装によっては、受理トークン数を提案トークン数で割った値、平均受理長、または受理確率が報告されます。これらの指標は関連していますが同一ではないため、比較には同じ定義とドラフト長が必要です。この違いは、後の実環境テストでも確認できます。

ドラフトの品質とサンプリング方針が率を左右する

現在の言語、ドメイン、プロンプトにおいてターゲットに近いドラフトほど、受理されやすい続き方を提案する傾向があります。温度、top-p、トークナイザーの整合性、ドラフト長、ターゲットの確信度も、ブロックがどの程度の頻度で維持されるかを変化させます。

Online Speculative Decodingはターゲットからのフィードバックに基づいてドラフトを適応させ、トークン受理率を改善することで、変化するリクエスト分布全体でレイテンシーを削減できると報告しています。この結果は、受理率が固定されたモデルペアの特性ではなく、ワークロードに応じて変動し得ることを示しています。

大きなドラフトは受理率を高める可能性がありますが、実行コストも増えます。小さなドラフトは安価ですが、頻繁に棄却される可能性があります。適切な選択には、受理された進捗とドラフトおよび検証にかかる時間のバランスが必要です。自動化を進める前に、中間結果を確認できる状態にしておく必要があります。

高い受理率は高速化に必要だが、それだけでは十分ではない

エンドツーエンドの向上は、ターゲットがブロックを効率的に検証できるかどうか、ドラフトのレイテンシー、メモリ転送、同期、バッチサイズ、棄却された処理のコストにも左右されます。短いブロックで高い割合を得ても、適切な長さのブロックで中程度の割合を得る場合より、逐次処理のステップを削減できないことがあります。

Medusaは、別個のドラフトモデルの代わりに、ターゲットの表現から複数の続き方を提案する複数のデコーディングヘッドを使用します。その設計は、提案方式と検証が同じスループットのトレードオフを形作ることを示しています。この境界は、現実的な運用条件で個別に測定する必要があります。

失敗する境界は、ドラフトと検証を合わせたコストが通常のデコーディングと同程度になるワークロードです。コード、多言語テキスト、創造的なサンプリング、またはドメインの変化によって受理長が十分に短くなると、投機によって余分なメモリを消費するだけで、レイテンシーを削減できない場合があります。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

ミリ秒あたりの受理済み進捗を測定する

プロンプトの種類ごとに、提案トークン数、受理トークン数、受理されたプレフィックス長、ドラフト時間、ターゲット検証時間、棄却位置、合計レイテンシー、1秒あたりのトークン数、メモリ使用量、出力同値性の検証結果を記録します。複数のソースが限られたコンテキストを奪い合うときに、実際の影響が現れます。

ワークロードをサンプリング方針と関連付けます。ターゲットモデルと要求する分布を固定したまま、ドラフト長とサンプリング設定を変え、通常の自己回帰デコーディングと比較します。この依存関係は、最終インターフェースでも明示しておく必要があります。

合計ミリ秒あたりの受理済み進捗が向上する場合にのみ、投機を有効にします。受理率が高く見えてもレイテンシーが低下しない場合は、その割合を最終的な性能指標と見なすのではなく、提案と検証のオーバーヘッドを最適化します。したがって、結果は元の根拠に照らして確認する必要があります。