コンテキスト長はローカルLLMのスループットにどのような影響を与えるか？

エヴァ・ウォン

IceWhale author

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

How Does Context Length Affect Local LLM Throughput? - Zima Store Online

コンテキストが長くなると、プリフィル計算、KVキャッシュメモリ、デコード処理、同時実行シーケンス容量の競合が増えるため、通常はローカルLLMのスループットが低下します。

その影響は、トークン毎秒の単一の普遍的な曲線で表せるものではありません。プロンプトの長さは主にプリフィルフェーズを拡大し、アクティブなコンテキストが増えると、後続のデコードステップではより多くのキャッシュ済みキーと値を参照するようになります。メモリが一杯になると、サーバーは受け入れるリクエスト数を減らしたり、シーケンスをプリエンプトしたり、キャッシュをオフロードしたり、処理を拒否したりする可能性があります。そのため、スループットはモデル、アテンションカーネル、ハードウェア、スケジューラー、ワークロードの構成に左右されます。

プロンプトの長さは最初のトークン生成前のプリフィル処理を増やす

プリフィル中、モデルはすべてのプロンプトトークンを処理して、隠れ状態と初期のキー・バリューキャッシュを作成します。標準的なアテンション処理の負荷はシーケンス長に伴って急激に増加しますが、最適化されたカーネルはメモリ転送量と定数倍のコストを減らすだけで、入力処理を不要にするわけではありません。

IOを考慮したアテンションに関する論文では、GPUメモリ階層間の転送を削減する、IOを考慮した厳密なアテンションアルゴリズムが紹介されています。その高速化は、カーネルの選択によって曲線が変わる理由を示しています。一方で、コンテキストの処理には依然として計算とメモリ転送が必要です。

デコードのトークン毎秒だけを報告するサーバーでは、このコストが隠れてしまう可能性があります。RAGや長い会話では、出力スループットに加えて、最初のトークン生成までの時間と、1秒あたりに処理できるプロンプト数も必要です。この違いは、後述する家庭環境でのテストでも確認できます。

アクティブなコンテキストトークンごとにKVキャッシュが増加する

自己回帰型デコードでは、過去のトークンのキーと値を保存することで、それらを再計算せずに済むようにします。キャッシュのメモリ使用量は、アクティブなシーケンス長、レイヤー数、次元数、精度、同時実行シーケンス数に応じて増加します。そのため、コンテキストが長くなるほど、同時に収容できるリクエスト数は減少します。

vLLMのPagedAttentionでは、KVキャッシュの断片化を減らし、柔軟な共有を可能にするPagedAttentionが紹介されています。割り当てを改善することで利用可能な容量は増えますが、保持するコンテキスト自体に必要なバイト数がなくなるわけではありません。自動化を進める前に、中間結果を検証可能な状態に保つ必要があります。

容量を使い果たすと、システムは新しいリクエストをキューに入れたり、キャッシュを削除または再計算したり、ホストメモリへスワップしたり、バッチサイズを下げたりする可能性があります。こうしたポリシーによって、単一ユーザーで滑らかに見えるベンチマークが、不安定なマルチユーザーの実効処理量に変わることがあります。この境界は、現実的な運用条件の下で個別に測定すべきです。

コンテキストの増加に伴い、デコードステップで参照する履歴が増える

生成される各トークンは蓄積されたキャッシュを参照するため、メモリ読み出しとアテンション処理の負荷はシーケンス長に応じて増加します。モデルはメモリ帯域幅に制限され続ける可能性があり、コンテキスト圧縮やキャッシュ量子化では、メモリ削減と精度およびカーネルの対応状況とのトレードオフが生じます。

KVキャッシュの量子化に関する研究では、KVキャッシュを量子化して大幅に長いコンテキストを可能にするとともに、キャッシュ容量が長文コンテキストにおけるボトルネックであることを明確に示しています。これは、宣伝されている最大コンテキスト長と、効率的に維持できるスループットが別の特性であることを示します。実際の影響は、複数の情報源が限られたコンテキストを奪い合うときに現れます。

失敗の境界を測定する際に、プロンプトの構成、出力長、同時実行数、キャッシュ精度を変えたまま2つのコンテキストを比較するのは適切ではありません。証拠を追加すると検索品質は向上する可能性がある一方で、システムスループットは低下する可能性があります。そのため、性能と回答の有用性は別々の軸で評価する必要があります。

Featured

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

ZimaCube2

プロンプト長の区分ごとにスループットをベンチマークする

512、2,048、8,192、16,384トークンなど、出力長を統制した固定のプロンプト区分を作成します。それぞれを1ユーザーおよび段階的に増やした同時実行数で実行し、プロンプトのトークン毎秒、出力のトークン毎秒、最初のトークン生成までの時間、トークン間レイテンシ、キャッシュ使用量、キュー待ち時間、プリエンプション、失敗を記録します。

コンテキストウィンドウの拡大に伴う低速化で説明されている長い会話の低速化と、曲線を比較します。モデル、量子化、サンプリング、スケジューラー、ハードウェアを一定に保ち、その後、プレフィックスキャッシュまたはキャッシュ量子化だけを変更した実験を別々に繰り返します。この依存関係は、最終的なインターフェースでも明示したままにする必要があります。

運用上のコンテキスト予算は、モデルが受け入れられる最大長ではなく、必要なレイテンシ目標の下での実効処理量に基づいて設定します。検索や要約は、それによる品質向上が、測定されたプリフィルコストとキャッシュコストを正当化する場合にのみ行います。