同時負荷がかかるとローカルLLMの応答が短くなるのはなぜですか？

負荷がかかると、上限、デッドライン、プリエンプション、リクエスト失敗によって生成予算と同時実行性の配分が変わるため、ローカルLLMの応答が短くなることがあります。

別のユーザーが到着したからといって、モデル自体が自動的に簡潔な回答を選ぶわけではありません。固定されたプロンプトとサンプリング状態では、同時実行性によって主にキューとトークンのタイミングが変わるはずです。回答が短くなる場合は、ランタイム、ゲートウェイ、クライアント、またはメモリマネージャーが実質的な停止条件を変更した、処理をキャンセルした、あるいは負荷がしきい値を超えた後にストリームの一部だけを返したことを示しています。

同時実行性によってKVメモリが拡大し、サービング制限が作動する

アクティブな各シーケンスは、保持されるコンテキストと生成トークンに応じて増加するKVキャッシュブロックを保持します。複数のリクエストが1つのアクセラレーターを共有すると、ランタイムはバッチをメモリ内に収めるため、最大出力を引き下げたり、受付を拒否したり、シーケンスをプリエンプトしたり、ブロックをスワップしたりすることがあります。

ページ化KVキャッシュ割り当てに基づくサービング設計では、ページ化されたKVブロックを使って断片化を減らし、より高い同時実行性を実現します。この仕組みにより容量は向上しますが、同時に、各実行中のシーケンスが完了または追い出されるまで増加するメモリ割り当てを消費することも明らかになります。

ゲートウェイは、リクエスト単位または全体のトークン予算を別途設定できます。その予算が利用可能な容量、優先度、またはキューの深さから算出される場合、モデルの重みとサンプリングパラメータが変わっていないように見えても、同一のプロンプトに対する最大出力は異なります。

デッドラインとプリエンプションによって、一見有効な部分回答が返されることがある

インタラクティブシステムでは、実時間のデッドライン、アイドルストリームのタイムアウト、またはクライアントによるキャンセルが設定されることがよくあります。負荷によってトークン間の配信が遅くなると、意味的な回答のより早い段階でこれらの制限に達し、一部のAPIは目立つエラーを返す代わりに、すでに出力されたトークンを返します。

チャンク化プリフィル方式では、長いプリフィルによってデコードがブロックされるのを防ぐため、プロンプト処理を小さなチャンクに分割します。この研究は、異なるリクエストによる負荷が混在する状況で、スケジューリングの変更が最初のトークンまでの時間とトークン間レイテンシにどのように影響するかを示しています。この違いは、後の家庭環境でのテストでも確認できます。

プリエンプションは、エンジンによって、リクエストを後で再開できるように保持する場合もあれば、再起動または中止する場合もあります。一時停止中にクライアントが切断すると、サーバーはキャンセルを記録しながら、インターフェースには文法的には自然だが不完全な前半部分が完了した回答として表示されることがあります。

サンプリングだけで負荷と安定して相関することはない

確率的デコーディングでは、温度と乱数シードが異なると、自然に長さが変動します。小規模なサンプルでは、その変動が負荷と同時に発生することがあります。しかし、共有状態、適応型ポリシー、またはソフトウェアの不具合によってデコーディング経路が変化しない限り、同時実行性に直接的な意味上のシグナルはありません。

SLOを考慮したスケジューリングに関する研究では、トークン間時間の目標を保護しながら、ルーティングとスケジューリングをモデル化しています。スループット、TTFT、デコードのデッドラインを分けて考えることで、容量ポリシーをモデル出力の品質とは独立して測定する必要がある理由が分かります。自動化を進める前に、中間結果を検証可能な状態にしておく必要があります。

停止メタデータを確認する前にスケジューラーを原因と決めつけることが、障害の境界です。EOSトークン、明示的な長さ上限、クライアントによるキャンセル、サーバーのデッドライン、OOMエラー、トランスポート切断は、それぞれ異なる原因です。負荷によるメカニズムを裏付けるのは、対応する停止理由を伴う、再現性のある制御済みの長さ変化だけです。

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

同時実行数を一定の段階で変え、長さと停止理由を比較する

固定したプロンプトとシードを、同時実行数1、2、4、8で再生します。要求した最大トークン数、実際の出力トークン数、終了理由、キュー時間、TTFT、トークン間レイテンシ、実時間のデッドライン、クライアント切断、プリエンプション回数、KVバイト数、空きVRAM、サーバーエラーを記録します。

メモリの挙動を同時ワークロードの上限と関連付け、ゲートウェイのタイムアウトなし、かつ受付上限を固定した条件でも繰り返します。プロンプト、テンプレート、サンプリング、クライアントコードを維持し、意図的に変更するのは同時実行性だけにします。この境界は、現実的な運用条件とは別に測定する必要があります。

宣伝されている予算に達する前に完了率や意味的な網羅性が低下するなら、出力の短縮をサービング側の欠陥として扱います。終了理由がEOSのままレイテンシだけが上昇する場合は、シードを固定した試行をさらに増やします。タイムアウトや上限が支配的なら、それらのポリシーを明示し、適切なサイズに設定します。