連続バッチ処理は家庭用AIサーバーの公平性にどのような影響を与えるか？
連続バッチ処理は、アクティブなバッチに新しいリクエストを補充することで利用率を高めます。しかし、公平性は、時間の経過に伴ってユーザーがアドミッション、トークンサービス、メモリをどのように受け取るかに左右されます。
家庭用AIサーバーでは、すべてのシーケンスが同時に完了するのを待たずに、複数の会話を組み合わせて処理できます。完了したリクエストが離れ、新しいリクエストが入り、アクティブなユーザーが反復的な推論処理を共有します。これによりスループットは向上しますが、リクエストは同じではありません。短いコマンドを送るユーザーもいれば、長い文書を送るユーザーもおり、数百トークンを生成するエージェントを使うユーザーもいます。公平なスケジューラーは、どの作業単位を基準にするか、新しいリクエストをどのように受け入れるか、予測できない出力長に対して優先度をどう適用するかを決める必要があります。
連続バッチ処理では、スケジューリング単位が固定バッチから反復処理へ変わる
静的バッチ処理では、グループ全体が完了するまで同じグループを維持するため、短いリクエストが早く終わると処理能力が無駄になります。連続バッチ処理では、生成の反復処理の間に空いたスロットを補充できます。
Orcaは、リクエストのシーケンス状態が変化するに応じて参加・退出できるように、反復レベルのスケジューリングを導入しました。
これにより利用率は向上しますが、ユーザーは一体化された単一のリクエスト枠を受け取るのではなく、次の反復処理に参加する場所を繰り返し競うことになります。
アドミッションの順序によって、誰がサービスを受け始めるかが決まる
アクティブなバッチの外にあるリクエストは、モデルの処理がまったく進みません。スケジューラーは、到着時刻、推定長、優先度、利用可能なKVブロック、または公平性カウンターに基づいて受け入れることがあります。
vLLMは、シーケンスの成長に応じてメモリを割り当てられるよう、ページ化されたKVキャッシュ管理と連続アドミッションを組み合わせています。
先着順はシンプルですが、長いリクエストが並ぶキューでは、後から来た短い家庭内コマンドが、すぐに完了できるにもかかわらず遅延する可能性があります。
リクエストを同等に数えても、アクセラレーターのサービス量は不均等になり得る
5トークンの回答と500トークンの回答は、どちらも1件のリクエストです。しかし、占有するデコード反復回数は大きく異なります。プロンプトの長さによって、必要なプリフィル処理量も変わります。
Virtual Token Counterは、リクエスト数だけでは異種のLLMワークロードが消費するサービス量を表せないため、トークンベースの公平性を定義しています。
家庭内のポリシーでは、公平性をトークン処理量の均等、待ち時間の均等、完了機会の均等、あるいはレイテンシーに敏感なタスクへの優先として捉えるのかを決める必要があります。
すべてのワークロードを満たす単一の指標はありません。音声コマンドとバックグラウンドの要約に、必ずしも同じ扱いをする必要はありません。
出力長が未知だと、将来のサービス量を予測しにくい
スケジューラーは受け入れ時点でプロンプトのサイズを把握できますが、通常、モデルが実際に何個の出力トークンを生成するかを正確には知りません。1件のリクエストが予想以上に長くアクティブな状態に留まることがあります。
公平性に関する研究では、LLMサービングに特有の課題として、予測できないリクエスト長が強調されています。
実際に処理したトークンに応じてサービス量を計上すれば、精度の低い長さの推定に全面的に依存せずに済みます。しかし、長いリクエストが多数の反復処理にわたってメモリを占有する可能性は残ります。
大規模なプリフィル処理は、すでにトークンを受け取っているユーザーを妨げる可能性がある
複数のユーザーがデコード中でも、新しい文書プロンプトが入ることがあります。この計算負荷の高いプリフィル処理によって、アクティブな会話が待たされる反復処理の時間が長くなる可能性があります。
Sarathi-Serveは、大規模なプリフィル処理を分割し、進行中のデコードレイテンシーへの影響を抑えるために、停止のないスケジューリングを使用します。
デコードトークンだけを数えるスケジューラーでは、あるユーザーが大規模なプリフィル処理を繰り返し投入し、全員のストリーミング出力を遅らせる場合、公平とは言えません。
したがって、公平な計上には生成トークンだけでなく、入力処理も含める必要があります。
メモリの逼迫は、計算資源が飽和する前に公平性の問題を生み出す可能性がある
アクティブな会話にはすべてKVキャッシュが必要であり、コンテキストが長いほど多くのブロックを消費します。大きなコンテキストを1つ持つユーザーによって、アクティブなバッチに収容できる他のリクエスト数が減ることがあります。
ZimaSpaceのマルチユーザー分析では、家庭内の同時実行を、共有モデルメモリおよびスケジューラーの判断と関連付けています。
リクエストをプリエンプトまたはスワップすれば容量を回復できますが、中断されたユーザーは後から再計算、キャッシュの再読み込み、または完了時間の延長という負担を負う可能性があります。
したがって、メモリのアドミッションと計算スケジューリングは、無関係な制限として別々に動かすのではなく、同じ公平性ポリシーに従う必要があります。
優先度には、エージング、クォータ、ユーザーが確認できる測定指標が必要
音声操作、アクセシビリティツール、短い対話型チャットは、埋め込み生成や夜間の要約より高い優先度に値する場合があります。しかし、純粋な優先度スケジューリングでは、低優先度の処理が枯渇する可能性があります。
Llumnixは、サービング環境の変化に応じてリクエストの配置とリソースに関する判断を適応させるため、動的スケジューリングを使用します。
エージング、ユーザーごとのクォータ、コンテキストまたは出力の最大長、バックグラウンド処理用の予約枠を追加しましょう。これにより、優先度の高い処理がすばやく応答しながら、他の処理を無期限にブロックすることを防げます。
キュー時間、最初のトークンまでの時間、トークン間遅延、完了時間、処理されたトークン数、プリエンプションを、ユーザー別またはワークロード分類別に測定します。連続バッチ処理が公平なのは、総トークン数／秒が高いときではなく、観測された分布が家庭内のポリシーに合致しているときです。
おすすめ商品
テック＆AIハブ
もっと読む
機密ファイルを取り巻くホームAIの信頼境界を実現する機能とは？
家庭用AIの信頼境界は、保存時暗号化、最小権限のアクセス許可、ランタイムサンドボックス化、スコープを限定した検索を組み合わせたものであり、単一の機能だけでは成り立ちません。
プライベート検索結果が頻繁に編集されたファイルを優先する原因とは？
頻繁に編集されるファイルは、更新のたびに鮮度、チャンク、バージョン、またはインタラクションシグナルが追加され、ソースによる正規化が行われない場合、ランキング上の優位性を獲得します。
スマートホームの在宅検知モデルが来客と住人を混同する原因とは？
システムが世帯の活動パターンを観測していても、その活動を生み出している人物の安定した識別情報がない場合、来訪者が居住者のように見えることがあります。
