随负载生长的蜂群
一个只在需要时才借力的巨型模型——MoE 蜂群如今随流量自我伸缩：清闲时紧凑而快速，繁忙时铺开而并行。
Kvasir 服务的模型远大于任何单台机器所能容纳——一个 122B 参数的专家混合（MoE）模型跑在一台协调器加一群 worker 上：LAN 上的 GPU、200 Gb/s 链路对端的 GPU，甚至通过互联网拨入的手机。由于 MoE 模型把每个 token 只路由给少数几个专家，任一时刻大多数权重都处于闲置，而这些闲置专家可以住在主节点之外——住在任何自愿持有它们的硬件上。
新的部分在于蜂群如今会随负载自我伸缩。
行为方式
清闲时紧凑，繁忙时铺开
流量清淡时，协调器在自己的 GPU 上服务一切——每 token 最快的路径，没有网络跳转。当请求开始堆积、其推理槽位饱和时，两件事会自动发生：
- 它重新启用已有的 worker。协调器盯着自己的队列。饱和时它持续把路由到的专家工作外送给已验证（proven）的 worker——那些真正服务过的 worker——以一点点每 token 延迟换来大得多的总吞吐。仅仅连接过却从未计算过的 worker 绝不会被托付负载；而全新的 worker 仍会获得一次公平的首试。
- hub 招募新的 worker。控制 hub 注意到同样的饱和，抬高该模型专家的“需求”。闲置节点——某人口袋里的一部手机、城里另一头的一张空闲 GPU——本就在轮询那个需求市场。需求一旦上升，它们就被提供一份专家切片去服务，下载它、拨入、加入。浪涌过去后，需求回落，多余的 worker 悄然退去。
没有人调度这一切。没有节点被推送。蜂群随负载呼吸：清闲时紧凑而快速，繁忙时铺开而并行——而且即便对家用路由器后的节点也奏效，因为一切都是拉取式（pull-based）的。
这就是一个能在无人独占的硬件上服务万亿参数模型的网络的形态：闲置算力恰好在值得邀请时才被邀请进来，且仅在此时。