負荷適応スケーリング

Kvasir の MoE 提供経路はトラフィックに応じて拡大・縮小する：飽和時にはコーディネータが実績のあるワーカーを再稼働させ、bridge はエキスパート需要を引き上げて遊休ノードを募る——すべてプルベースなので、NAT 配下のデバイスも参加できる。

Kvasir の MoE 提供経路は、協調する二つの層で負荷に応じて弾力的にスケールします。静かなときはコーディネータがすべてをローカルで提供し、トークンあたり最速の経路を取ります；飽和すると、以下の二つの層がスウォームを拡大し——サージが過ぎ去ると再び縮小します。

バックボーンコーディネータ（フルモデルを走らせる linkcpp-server）は、ルーティングされたエキスパートを自分の GPU で提供する（高速・ローカル）か、リモートワーカーへディスパッチするかのいずれかで処理します。数秒ごとにバックグラウンドスレッドがどちらかを決めます：

• 自分自身の推論スロットをポーリングします。busy >= saturation threshold（デフォルト 2）のとき、コーディネータは負荷下にあります。
• 負荷下では、実績のある（proven）ワーカーが生きていれば——last_serve_ms > 0 のもの、つまり実際に以前エキスパートを計算したことがあるワーカー——コーディネータは通常のアイドルタイムアウトを越えてそれにディスパッチし続け、トークンあたりのレイテンシよりも総スループットを優先します。
• 接続したが一度も提供していないワーカー（relay にダイヤルしたが計算はしなかったスマートフォン）は、負荷下で募集されません。それにディスパッチすれば、高速なローカル経路を遅いフォールバックで置き換えてしまうからです。新規ワーカーには、短い猶予ウィンドウを通じて最初の一回が与えられます。
• この自己クエリは時間制限付きで、ストールしたポーリングがディスパッチをブロックすることは決してありません。

コントロールプレーンはすべての MoE コーディネータを監視し、必要に応じてワーカープールを拡大します：

• バックグラウンドループが各コーディネータのスロットをポーリングし、モデルごとの飽和を記録します。
• モデルが飽和している間、その実効エキスパートレプリカ目標（effective expert-replica target）が引き上げられます（base + boost）。すると、カバレッジマーケットはすでにカバー済みのエキスパートを再び希少と読み、生きたワーカーが一つもないモデルは GGUF メタデータ（エキスパート数）からシードされ、ゼロからでも需要が可視になります。
• 遊休ノードは需要マーケット（/api/expert-volunteer）をポーリングし、提供すべき (layer, expert-range) スライスを渡されます。ノードはそのスライスをダウンロードし、relay にダイヤルし、カバレッジを登録します；コントロールプレーンはそれらをコーディネータのディスパッチマップに自動配線します。
• 負荷が引くと目標は元に戻り需要は消えるため、余剰ワーカーはもうディスパッチされず、時間とともに離脱します。

可観測性：GET /api/moe/recruitment はモデルごとの busy/saturation と base 対 effective の目標を報告します；/api/expert-demand は recruiting フラグを運びます。