スケジューラー

概要

スケジューラーは、関連する次の 2 つのタスクを担当します。

スケールアップ： 新しいモデルインスタンスに最適なワーカーと GPU の配置を選びます。
スケールダウン： 既存のモデルインスタンスを順位付けし、レプリカ数を減らすときに優先度の低いものから削除します。

どちらの場合も、スケジューラーは次の 2 段階で動作します。

フィルタリング：実際にモデルを実行できる候補を見つけます。候補一覧を作る処理と考えられます。
スコアリング：各候補にスコアを付け、現在の目的に最も適したものを選びます。

スケールアップのスケジューリング

1. 基本的なワーカーフィルタリング

まずワーカー一覧に基本的なフィルタリングを行います。この段階では、クラスター、ラベル、バックエンドの互換性、選択された GPU、ローカルパスの有無など、主にリソース以外の制約を確認します。

フィルターは次の順序で実行されます。

クラスターフィルター モデルの対象クラスターに属するワーカーだけを残します。
GPU 一致フィルター モデルで GPU が明示的に選択されている場合、ワーカーを絞り込みます。
ラベル一致フィルター モデルのラベルセレクターを満たすラベルを持つワーカーだけを残します。
状態フィルター 状態が READY のワーカーだけを残します。
バックエンドフレームワークフィルター アクセラレーターやランタイムの機能が、選択したバックエンドに適合しないワーカーを除外します。
ローカルパスフィルター GPU が明示的に選択された LOCAL_PATH モデルに適用されます。設定されたモデルパスが存在しないワーカーを除外します。

この基本的なフィルタリングを通過したワーカーだけが、リソースに基づくフィルタリングに進みます。

2. リソースに基づく候補のフィルタリング

この段階もフィルタリングですが、メタデータやワーカーの状態ではなく、モデルを実行するために十分な RAM と VRAM を、そのワーカーや配置で確保できるかを判定します。

必要なリソースの判定方法は、モデルの種類によって異なります。

GGUF モデル： GGUF パーサーで必要なリソースを推定します。
ほかのモデル： vLLM、SGLang、MindIE、VoxBox など、対応するバックエンドが必要なリソースを推定します。

バックエンドの機能が異なるため、利用できるフォールバック方法も異なります。

vLLM、SGLang、MindIE： 主に GPU を使う配置を使用します。ここでは CPU のみの実行や部分オフロードへのフォールバックは行いません。
GGUF、カスタムバックエンド、VoxBox： GGUF パーサーでモデルのリソース要件を推定します。GPU オフロード、部分オフロード、CPU 実行に対応します。
カスタムバックエンド、VoxBox： GPU オフロードまたは CPU 実行に対応します。

候補は順番に評価され、いずれかの戦略が実行可能な候補を返した時点で処理を終了します。一般に、次の順序で試みます。

単一ワーカー、単一 GPU 1 台のワーカー上の 1 基の GPU でモデルの要件を満たせる場合です。
単一ワーカー、複数 GPU 1 基では足りない場合に、同じワーカー上の複数 GPU を組み合わせます。
ワーカー間の分散推論 バックエンドが分散実行に対応する場合、複数のワーカーの GPU を使用できます。
部分オフロードまたは CPU 実行 モデルの種類とバックエンドが、そのフォールバックモードに対応する場合のみ使用します。

注意点は次のとおりです。

リソース適合性のフィルタリングは、最初に候補が得られた戦略で終了します。
分散候補には、プライマリーワーカーに加えて従属ワーカーを含められます。
明示的な GPU 選択は、基本的なワーカーフィルタリングとリソース適合性のフィルタリングの両方で尊重されます。

3. 候補のスコアリング

実行可能な候補が見つかると、スコアラーのチェーンで評価し、合計スコアが最も高い候補を選びます。

現在のスケールアップのスコアリングは、次の構成です。

配置スコアラー
モデルファイルのローカリティスコアラー

候補の合計スコアは、有効なすべてのスコアラーの合計です。

配置スコアラー

配置スコアラーは、スケールアップでは常に有効です。

Binpack

可能な限り多くのモデルインスタンスを、できるだけ少ない「箱」（ワーカーや GPU）に詰め込み、リソース使用率を最適化する戦略です。使用する箱の数を減らしつつ、各箱の容量を超えず効率的に使うことを目指します。残り容量が最も小さい箱にモデルインスタンスを配置し、空き容量を最小化します。 - Spread

複数のモデルインスタンスを異なるワーカーにできるだけ均等に分散し、システムの耐障害性と負荷分散を改善する戦略です。

そのほかの動作は次のとおりです。

GPU を使う配置では、RAM よりも VRAM の使用状況を重視します。
CPU のみの配置では、RAM 使用率だけを考慮します。

モデルファイルのローカリティスコアラー

このスコアラーは、必要なモデルファイルがすでに READY になっているワーカーへの配置を優先します。

具体的には、次の処理を行います。

メインモデルのファイルがすでに準備済みのワーカーを探します。
投機的デコーディングが設定されている場合、ドラフトモデルの準備済みファイルも探します。
参加するワーカーのうち、すでにこれらのファイルを持つワーカーの割合で各候補を採点します。
メインモデルのローカリティをドラフトモデルより重く評価します。

4. 最終選択

採点後、合計スコアが最も高い候補を選び、その配置にモデルインスタンスを割り当てます。

スケールダウンのスケジューリング

必要なレプリカ数が既存のモデルインスタンス数より少ない場合、コントローラーは現在のインスタンスを順位付けし、順位の低いものから削除します。

スケールダウンでは、既存のモデルインスタンスに別のスコアラーチェーンを適用します。

状態スコアラー
オフロードレイヤースコアラー
配置スコアラー

インスタンスをスコアの昇順に並べ、最も低いスコアのインスタンスから削除します。

状態スコアラー

正常なレプリカを優先します。そのため、異常があるレプリカや準備が完了していないレプリカが最初の削除候補になります。

オフロードレイヤースコアラー

total_layers と offload_layers を報告する GGUF モデルでは、オフロード済みのレイヤーが多いインスタンスを優先します。

完全オフロードには最高スコアを与えます。
部分オフロードには割合に応じたスコアを与えます。
オフロードレイヤーのメタデータがないインスタンスのスコアは 0 です。

スケールダウン時の配置スコアラー

スケールダウンでも同じ配置スコアラーを使用しますが、新たな配置ではなく削除の観点から既存の配置を評価します。配置にはモデルの binpack または spread ポリシーが反映されますが、スコアは保持の優先度として扱われ、配置スコアが低いほど削除されやすくなります。