応答速度と加速

投機的デコーディング：トークンの先行予測と検証

大きなモデルの回答に満足しながらも処理速度が不満です。小さなモデルは速いですが、同じ回答を期待するのは難しいです。まず小さなモデルに候補を生成させ、大きなモデルが確認するという方法はどうでしょうか？推測デコードは、この役割分担によって生成時間を短縮しようとする方法です。

速く作った草案を、そのまま回答にするわけではない

大きな本モデルは、各トークンを1つずつ生成するたびに計算を繰り返します。小さな初案モデルが次の候補を準備すると、本モデルは複数の位置をまとめて確認できます。候補が適切な範囲は一括で受け入れられ、順次計算の回数を減らします。

誤った候補は回答に含めません。検証で不一致が発生した後ろの部分を切り捨て、モデルの出力に従って進みます。正確な検証を用いる推測デコードは、モデルの出力を維持しようとする方法であり、速度のためランダムに小さなモデルの回答を混ぜる機能とは異なります。

別々の小型モデルを使用する方法以外に、本モデルのMTPヘッドまたはコンテキスト内で繰り返し構文を検出するPrompt Lookupを活用することも可能です。共通点は、候補の生成と本モデルがその検証を行うことを分離している点です。追加モデルがない方法も存在します。

どちら側でも、スケルトンは十分に軽量である必要があります。このモデルと同じくらいの時間をかけて適切なスケルトンを作成すれば、節約できる余地はほとんどありません。別モデル方式では、追加の重みやキャッシュがメモリに読み込まれるかどうかも確認すべきです。

多くの候補が承認されたとしても、候補を作成・検証する時間は長くなる可能性があります。承認率は重要なヒントですが、最終的な目的は同じ回答をより早く終えることになります。全体の所要時間および平均承認時間、メモリの増加を併せて確認する必要があります。

特に短い回答では、準備コストを回収する前に出力が終了する可能性があります。繰り返しの多いコードでは、以前はうまく働いていた設定が、新しい話題を扱う質問に対しては効果を発揮しなくなる可能性があります。一つのタスクの結果をすべてのディスカッションの倍率として使う理由ではありません。

実行プログラムが推奨する本モデル・初案モデルの組み合わせを確認してください。トークンを分割する方法とモデル構造が一致しなければなりません。単に小さいモデルを任意に接続するだけでは終わりません。まず、本モデル単独での正常な回答を基準として残します。

アクセラレーションを有効にした後は、速度だけでなく、反復出力、ツール呼び出し形式、および回答の完了状況も確認してください。実装や設定に問題がある場合、理論的目標と実際の結果が異なる可能性があります。重要な作業であれば、正解を知っている質問も含めて検証するほうがよいです。

メモリの残りをアンサンブルモデルに使用するか、より長いコンテキストに残すか、本モデルの精度を高めるかという選択が可能です。どの選択が良いかは、タスクによって異なります。すでに内容が十分に良く、生成が遅い場合なら、投機的デコーディングを試す価値があります。

逆にモデルがちょうど入るような状況では、基本的な実行を安定させることが最初です。アクセラレーション機能が多数あるからといってすべてをオンにしなければなりません。私の質問において明らかに減った待ち時間があれば、その設定だけを残すことが可能です。