Load-adaptive scaling

Kvasir's MoE serving path grows and shrinks with traffic: the coordinator re-engages proven workers under saturation, and the hub recruits idle nodes by raising expert demand — all pull-based, so NAT'd devices join too.

Kvasir's MoE serving path scales elastically with load, in two cooperating layers. When it's quiet the coordinator serves everything locally for the fastest path per token; when it saturates, the two layers below grow the swarm — and shrink it again when the surge passes.

Layer 1

Coordinator-side: load-adaptive dispatch

The backbone coordinator (a linkcpp-server running the full model) serves routed experts either on its own GPU (fast, local) or by dispatching them to remote workers. A background thread decides which, every few seconds:

  • It polls its own inference slots. When busy >= saturation threshold (default 2) the coordinator is under load.
  • Under load, if a proven worker is live — one whose last_serve_ms > 0, i.e. it has actually computed experts before — the coordinator keeps dispatching to it past the normal idle timeout, favouring aggregate throughput over per-token latency.
  • A worker that connected but never served (a phone that dialed the relay yet never computed) is not recruited under load, because dispatching to it would replace the fast local path with a slow fallback. New workers still get a first attempt through a short grace window.
  • The self-query is time-bounded so a stalled poll can never block dispatch.
Layer 2

Hub-side: load-adaptive recruitment

The control hub watches every MoE coordinator and grows the worker pool when needed:

  • A background loop polls each coordinator's slots and records saturation per model.
  • While a model is saturated, its effective expert-replica target is raised (base + boost). The coverage market then reads already-covered experts as scarce again, and a model with no live workers is seeded from its GGUF metadata (expert count) so demand is visible even from zero.
  • Idle nodes poll the demand market (/api/expert-volunteer) and are handed a (layer, expert-range) slice to serve. They download the slice, dial the relay, and register coverage; the hub auto-wires them to the coordinator's dispatch map.
  • When load drains, the target falls back and demand disappears, so the extra workers are no longer dispatched and age out.

The design is pull-based: nodes ask for work rather than being pushed, so a worker behind NAT participates with no inbound connectivity. A node recruited in Layer 2 that begins serving becomes a proven worker that Layer 1 then keeps engaged under load — the two layers compose into one elastic loop.

Observability: GET /api/moe/recruitment reports per-model busy/saturation and the base vs effective target; /api/expert-demand carries a recruiting flag.