応答速度と加速

Prompt Lookupとn-gram投機的デコーディング

コード内で関数を1つだけ変更してほしいと求めたものの、変更されなかった部分まで長時間再出力しています。すでに入力に存在する文をさらに速く繋げられないでしょうか？Prompt Lookupはその繰り返しを候補として活用します。名称が類似するモデルテーブルのRAM・SSDオフロードとは異なる機能です。

既存の文から次の部分を検出します

最近、入力または以前の出力から同じパターンを持ついくつかのトークンを検出します。一致する箇所があれば、その前に続いていたトークンを候補として取得します。本モデルは、これらの候補をまとめて検証し、一致した部分のみを使用します。

このとき、連続したトークンの束をn-gramと呼びます。別々の言語モデルを実行して案をつくることなく、追加の重みは必要ありません。ただし、照会および候補検証に必要な作業空間や時間はまったく存在しません。

長いコードから一部だけを修正して再出力したり、元のドキュメントのフォーマットを変更する作業では、元の文が多くの場合残る可能性があります。次に出てくる文がすでに入力に含まれているため、候補を検出する機会も生まれます。

逆にまったく新しい説明や話題を生成する質問については、一致する区間が少ない可能性があります。このような場合、検索は行われますが、候補が存在しないか、検証段階で頻繁に除外されることがあります。どの文章でも、まったく同じように加速される共通加速という主張は難しいです。

元の文にある文句でも、現在の回答に一致するかどうかは、このモデルが確認しなければなりません。コード内の変数または数字が1つでも変われば、その場所以降の候補をそのまま受け入れることはできません。繰り返しを利用するということは、検証なしに元の文を再使用することを意味しません。

nを小さくすると一致は簡単に見つかりますが、誤った文脈になる可能性があります。nを大きくすると正確なパターンを検出するのが難しくなる可能性があります。候補の長さも必ず増やさず、基本値から始め、平均承認長と総所要時間の比較を行ってください。

一部のモデルの大きなインベーディングテーブルをRAMまたはSSDに配置するPLEオフロードは、重みの保存位置を変更する技術です。ここでは説明するPrompt Lookupは、文の記録を照会して次の候補を生成する技術です。名前にはn-gramが併記されていても、解決する問題は異なります。

Prompt Lookupを有効にしても、モデル内の大きな重みがGPU外に移動しないです。したがって、メモリ不足によりモデルがロードされない場合、このオプションは解決策ではありません。オフロードガイドでは、モデルが収容される場所およびその実行パスを別々に確認すべきです。

通常のコードの修正や自由な質問をそれぞれ準備した状態と、切った状態を比較してみてください。繰り返しの多い例について、最も優れた結果だけを残さず、候補がうまく出ない作業でも損失が大きいかを確認してください。

コードの修正だけに限って助けが得られる場合、その作業にのみ使用する選択も可能です。すべての質問に対して一致する機能を検索するために、デバイスやモデルを継続的に変更するのではなく、頻繁に行う一連の処理の待ち時間の短縮で十分な改善が可能になります。