ローカルLLMのKVキャッシュには何トークン格納できる？

エヴァ・ウォン

IceWhale author

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

How Many Tokens Can Fit in a Local LLM KV Cache?

KVキャッシュのトークン容量は、利用可能なキャッシュメモリを1トークンあたりのキーとバリューのバイト数で割り、そこからバッチ処理、断片化、ランタイム用の予約領域を差し引いた値です。

ホームサーバーのワークフローでは、KVキャッシュ内のトークンがインタラクティブな動作とバックグラウンドのリソース使用量の両方を変化させる可能性があります。目に見える影響が現れるのは、リクエストが複数の処理段階を通過した後だけなので、1つの平均値だけでは、遅延、品質低下、障害がどこで始まったのかを把握できない場合があります。転送、計算、ストレージ、アプリケーション状態を分離すれば、他の条件が同一の場合にこの関係を検証できます。

KVキャッシュ内のトークンが直接与える影響

直接的な影響は、レイヤー数、アテンション次元、精度によって1トークンあたりのバイト数が決まるときに始まります。この段階で次のコンポーネントが受け取る内容が変わるため、観測された結果を最終インターフェースやモデルだけに帰属させることはできません。入力とワークロードを一定に保つことで、この初期変換を明確に確認できます。

アテンションメモリのモデルは、この段階を解釈する具体的な方法を提供します。レイヤー数、アテンション次元、精度によって1トークンあたりのバイト数が決まります。実用上の価値は、後続のバッファリング、スケジューリング、ストレージ、レンダリングの影響と、変更された変数を分離できる点にあります。これらは似た症状を引き起こす可能性があります。

最初の段階が変化すると、同時実行される各シーケンスがキャッシュブロックを占有するか共有します。その結果は、記事の問いに応じて、レイテンシ、精度、消費電力、容量、体感的な滑らかさとして現れる可能性がありますが、因果経路は最終出力が表示される前から始まっています。

キュー、キャッシュ、状態による変化

キュー、キャッシュ、保持された状態が影響を変えるのは、同時実行される各シーケンスがキャッシュブロックを占有するか共有するためです。そのため、AI、ストレージ、メディア、自動化のジョブを同時に実行すると、単一リクエストのベンチマークでは小さく見える影響が増幅される場合があります。アイドル状態のシステムにおける平均値よりも、テールの挙動が重要です。

KVキャッシュのバイト数の仕組みは、共有リソース層と結果を結び付けます。同時実行される各シーケンスがキャッシュブロックを占有するか共有するためです。この層を個別に測定することで、スループット、キャッシュヒット、確認応答、楽観的なステータス更新を、完了したユーザー向けの処理と誤認することを防げます。

ページ単位の割り当てによって無駄は減りますが、テンソルのサイズは減りません。そのため、同じ主要ハードウェアやネットワーク速度を持つ2台のホームサーバーでも、キューの深さ、データ配置、キャッシュ状態、ポリシーが異なると動作が変わる場合があります。

主要指標の先にある境界

タイトルにある変数が定めるのは1つの境界であり、上限全体ではありません。この場合、最大モデルコンテキストが同時実行で維持できる範囲を超える可能性があります。KVキャッシュ内のトークンを変更しても測定可能な差が現れる前に、別のボトルネックが上限を決めることがあります。

サービング容量の関係は、想定される仕組みと別の説明を区別するのに役立ちます。管理されたテストでは、タイトルにある変数だけを変更し、ソースデータ、ハードウェア、同時実行数、キャッシュ状態、ソフトウェアバージョンを固定する必要があります。この依存関係は、再現可能なホームサーバーテストで常に確認できるようにしてください。

最大モデルコンテキストが同時実行で維持できる範囲を超えると、障害の境界に達します。その時点を超えてさらに積極的なチューニングを行っても、タイトルが示す成果を改善できないまま、コスト、リスク、不安定性が増す可能性があります。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

KVキャッシュ内のトークンに関するFAQ

KVキャッシュ内のトークンの最小値を決めるものは何ですか？

最小値は、レイヤー数、アテンション次元、精度によって決まる1トークンあたりのバイト数から導かれます。同時実行される各シーケンスのピーク要件を加え、オペレーティングシステム、その他のサービス、性能低下、測定の不確実性に備えて余裕を確保してください。

KVキャッシュ内のトークンの見積もりが増えるのはいつですか？

同時実行数、コンテキスト、イベント発生率、保持期間、復旧処理が増えると、見積もりは増加します。圧縮、バッチ処理、キャッシュ、増分処理によって測定単位あたりのコストが下がると、減少する可能性があります。結果は、隣接するパイプライン段階とは分けて評価する必要があります。

KVキャッシュ内のトークンについて、最初に記録すべき指標はどれですか？

空きバイト数、1トークンあたりのバイト数、バッチ、断片化から始めてください。分母、時間枠、精度、レプリケーション、レイテンシ目標を伴わない件数や容量の数値では、有用なしきい値の判断を支えられません。この区別は、家庭内で複数のワークロードを同時に実行する場合に、より重要になります。

KVキャッシュ内のトークンを管理された条件でテストする

代表的なワークロードを作成し、KVキャッシュ内のトークンを変更する前に、空きバイト数、1トークンあたりのバイト数、バッチ、断片化を記録してください。コールド状態とウォーム状態の試行を行い、現実的な同時実行数を含め、すべての比較で同じデータ、バージョン、ハードウェア、ユーザーに見える成功基準を維持してください。

KVキャッシュ内のトークンに関連する仕組みを使って、テスト前に予想される方向性を定義してください。一度に1つの変数だけを変更し、中央値とテールの挙動を記録し、結果に運用上の境界が含まれるよう、失敗したケースや性能が低下したケースも残してください。

測定されたメリットが繰り返しの試行でも持続し、示された境界が許容範囲内にある場合にのみ、変更を採用してください。別の段階が支配的である場合は、相関から因果関係を推測せず、KVキャッシュ内のトークンを変更しないまま、その競合するボトルネックをテストしてください。