负载自适应扩展

Kvasir 的 MoE 服务路径随流量伸缩：饱和时协调器重新启用已验证的 worker，bridge 通过抬高专家需求招募闲置节点——全部拉取式，因此 NAT 后的设备也能加入。

Kvasir 的 MoE 服务路径随负载弹性扩展，分为两个协作的层。清闲时协调器在本地服务一切，取得每 token 最快的路径；饱和时，下述两层把蜂群扩大——浪涌过去后再度收缩。

引擎状态。专家粒度分片是在 Kvasir 上一代引擎上构建并演示的，下面的结果来自那项工作。当前引擎 [p4](/wiki/p4) 今天以层为粒度提供服务；把专家分片迁移到它上面已完成设计、正在推进。凡是点到具体工具或路由的细节，都是当时在上一代引擎上运行的那一套。

第 1 层

协调器侧：负载自适应调度

骨干协调器（一台运行完整模型的 linkcpp-server）服务路由到的专家，要么在自己的 GPU 上（快、本地），要么把它们调度给远程 worker。一个后台线程每隔几秒决定用哪种方式：

它轮询自己本机的推理槽位。当 busy >= saturation threshold（默认 2）时，协调器处于负载之下。
负载之下，若有一个已验证（proven）的 worker 在线——其 last_serve_ms > 0，即它此前真正计算过专家——协调器会越过正常的空闲超时继续向它调度，以总吞吐优先于每 token 延迟。
连接过却从未服务过的 worker（一部拨通了 relay 却从未计算的手机）在负载下不会被招募，因为向它调度会用一条慢速回退替换掉快速的本地路径。新 worker 仍会通过一个短暂的宽限窗口获得首次尝试。
自查询有时间上限，因此一次卡住的轮询绝不会阻塞调度。

第 2 层

控制平面盯着每个 MoE 协调器，并在需要时扩大 worker 池：

一个后台循环轮询每个协调器的槽位，并按模型记录饱和度。
当一个模型处于饱和时，其有效专家副本目标被抬高（base + boost）。覆盖市场随即把已覆盖的专家重新读作稀缺，而没有任何在线 worker 的模型则从其 GGUF 元数据（专家数）播种，使需求即便从零也可见。
闲置节点轮询需求市场（/api/expert-volunteer），被交予一份 (layer, expert-range) 切片去服务。它们下载切片、拨通 relay、注册覆盖；控制平面自动把它们接线到协调器的调度图。
当负载退去，目标回落、需求消失，于是多余的 worker 不再被调度并逐渐老化退出。

该设计是拉取式（pull-based）的：节点主动索取工作而非被推送，因此 NAT 后的 worker 无需任何入站连接即可参与。在第 2 层被招募、并开始服务的节点会成为一个已验证（proven）的 worker，随后第 1 层在负载下持续启用它——两层组合成一个弹性回路。

可观测性：GET /api/moe/recruitment 报告每个模型的 busy/saturation 及 base 与有效目标的对比；/api/expert-demand 带有一个 recruiting 标志。