スライディングコンテキストウィンドウはローカルAIのメモリ使用量をどのように変えるのか?

エヴァ・ウォンテクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

スライディングコンテキストウィンドウは、保持するウィンドウが設定された上限に達すると古いトークン状態を除外し、アクティブなアテンションメモリを制限します。

完全因果アテンションでは、アクティブなシーケンス全体のキーとバリューを保持するため、会話、文書、生成された回答が長くなるほどKVメモリも増加します。スライディングウィンドウアテンションでは、この関係が変わります。各トークンが直接アテンションを向けるのは、制限された直近の領域だけです。そのため、ローリングストレージに対応した実装では、古いキャッシュエントリを上書きしたり、省略したりできます。モデルはより予測しやすいワーキングセットで長いストリームを処理できますが、破棄された履歴には同じ直接アテンション経路からアクセスできなくなります。

完全アテンションではアクティブなKV履歴が増え続ける

通常のフルコンテキスト推論では、保持される各トークンがモデルのアテンション層全体にわたってキーおよびバリューテンソルに寄与します。そのため、会話が長くなるほど、アドレス可能な状態で維持すべきキャッシュも増加します。

Mistral 7Bは、長いシーケンスを処理しながら推論コストを削減する方法として、スライディングウィンドウアテンションを導入しました。

重みのメモリ使用量は会話の長さによって変わりませんが、KVキャッシュ、ユーザー、そして一時的な処理に利用できるランタイムメモリは変化します。

固定ウィンドウを使うとウォームアップ後のキャッシュ増加を抑えられる

各層が直近のウィンドウ内のトークンだけを保持する場合、新しいトークンが到着するにつれて古いKVエントリをアクティブなワーキングセットから外せます。メモリ使用量は、ストリーム全体の長さではなく、ウィンドウサイズに基づく上限に近づきます。

Longformerは、すべてのトークンペアではなく、選択した近傍に応じて計算量がスケールするローカルウィンドウアテンションを定式化しています。

ローリングKVバッファーは、ウィンドウが満杯になった後に物理スロットを再利用できるため、長時間のローカルチャットや文字起こしストリーム中のメモリ使用量をより安定させられます。

この効果は、ランタイムがウィンドウ外の状態を実際に破棄または上書きすることを前提とします。モデルアーキテクチャがローカルアテンションを使用していても、すべてのサービングエンジンが同じ方法でキャッシュを割り当てるとは限りません。

積み重ねた層によって、1つのローカルウィンドウを超えて情報を伝えられる

ある層のトークンは、前の層から直近の近傍を読み取ります。より深い層は、すでに以前の近傍から混合された情報を含む表現を受け取ります。

Mistralのアーキテクチャは、この積層された受容野について説明しています。複数のTransformer層を通じて、情報は1つのウィンドウより遠くまで伝播できます。

間接的な伝播は、古いすべてのトークンに正確かつ直接アクセスできることと同じではありません。モデルが受け取るのは変換済みの表現であり、無制限に全文履歴を検索できるテーブルではありません。

古いKV状態を破棄すると、モデルが直接取得できる情報が変わる

初期のトークンが関連するすべてのアテンションウィンドウから外れると、後続のトークンは通常のローカルアテンション経路を通じて、その元のキーとバリューにアテンションを向けられなくなります。

StreamingLLMは、単純な直近トークンの退避によって、シーケンスがキャッシュサイズを超えた後にモデルの挙動が損なわれる可能性を示しています。

アテンションシンク、グローバルトークン、要約、検索、またはアーキテクチャ固有のハイブリッド層を使えば、キャッシュメモリの大部分を上限内に保ちながら、選択した長距離情報を保持できます。

したがって、メモリ削減には意味上の境界があります。古い詳細情報は、要約する、再度検索する、または通常のスライディング領域の外部に意図的に保持する必要がある場合があります。

ウィンドウサイズは実際のランタイムとワークフローで検証する必要がある

キャッシュの上限は、ウィンドウサイズ、KVヘッド数、ヘッド次元、層数、精度、バッチサイズ、アクティブユーザー数から見積もります。そのうえで、理論上の上限が完全に実現されると仮定せず、実際のアロケーターの挙動を確認してください。

ZimaSpaceのKimi K3分析では、長いコンテキストのメモリについて説明する際、固定状態とトークン数に応じて増加する状態を分けて扱っています。アテンション設計が異なれば、同じような最大コンテキスト長を掲げていても、異なる制限が生じる可能性があります。

短いチャット、ウィンドウより長いストリーム、冒頭付近に置いた事実、複数の同時ユーザー、クリーンな再起動をテストしてください。ピークメモリ、初回トークンのレイテンシ、出力速度、そして初期の情報が引き続き利用可能かどうかを記録します。

小さなウィンドウは、ローカルワークフローで保持すべき情報を失わせることなく、信頼性や同時実行数を高めるのに十分なメモリを解放できる場合に有効です。

FAQ

スライディングウィンドウは会話を削除することと同じですか?

いいえ。アプリケーションが完全な会話履歴を保存していても、古い内容が要約または再検索されない限り、モデルが直接アテンションを向けられるのは直近のウィンドウだけである場合があります。

スライディングウィンドウアテンションは常に一定のメモリ使用量になりますか?

1つのシーケンスに対するアテンションキャッシュを上限内に抑えることはできますが、メモリ全体には重み、他の層、アクティブユーザー、一時バッファー、ランタイムの予約領域も含まれます。

モデルはウィンドウより古い事実を記憶できますか?

伝播された表現、グローバルアテンション、要約、検索、アプリケーション側のメモリなどを通じて可能な場合はあります。ただし、元のトークン状態への直接アクセスはアーキテクチャによって制限されます。

テック&AIハブ

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.