Escalado adaptativo a la carga
La ruta de servicio MoE de Kvasir crece y se encoge con el tráfico: el coordinador reactiva workers probados bajo saturación, y el bridge recluta nodos ociosos elevando la demanda de expertos — todo basado en pull, así que también se unen dispositivos tras NAT.
La ruta de servicio MoE de Kvasir escala elásticamente con la carga, en dos capas que cooperan. Cuando hay calma, el coordinador sirve todo localmente para la ruta más rápida por token; cuando se satura, las dos capas de abajo hacen crecer el enjambre — y lo vuelven a encoger cuando pasa el pico.
Estado del motor. El sharding al grano de experto se construyó y se demostró sobre el motor anterior de Kvasir, y los resultados de abajo vienen de ese trabajo. El motor actual, [p4](/wiki/p4), sirve hoy al grano de capa; llevar el sharding de expertos hasta él está diseñado y en marcha. Cuando un detalle nombra una herramienta o una ruta, es la que corrió sobre el motor anterior.
Lado del coordinador: dispatch adaptativo a la carga
El coordinador de backbone (un linkcpp-server que corre el modelo completo) sirve los expertos enrutados o bien en su propia GPU (rápido, local) o bien despachándolos a workers remotos. Un hilo en segundo plano decide cuál, cada pocos segundos:
- Sondea sus propios slots de inferencia. Cuando
busy >= saturation threshold(por defecto 2), el coordinador está bajo carga. - Bajo carga, si hay un worker probado vivo — uno cuyo
last_serve_ms > 0, es decir, que realmente ha computado expertos antes — el coordinador le sigue despachando más allá del timeout de inactividad normal, favoreciendo el throughput agregado sobre la latencia por token. - Un worker que se conectó pero nunca sirvió (un teléfono que marcó al relay pero nunca computó) no se recluta bajo carga, porque despacharle reemplazaría la ruta local rápida por un fallback lento. Los workers nuevos aún reciben un primer intento a través de una breve ventana de gracia.
- La autoconsulta está acotada en el tiempo, así que un sondeo atascado nunca puede bloquear el dispatch.
Lado del plano de control: reclutamiento adaptativo a la carga
El plano de control vigila cada coordinador MoE y hace crecer el pool de workers cuando hace falta:
- Un bucle en segundo plano sondea los slots de cada coordinador y registra la saturación por modelo.
- Mientras un modelo está saturado, su objetivo efectivo de réplicas de expertos se eleva (base + boost). El mercado de cobertura entonces vuelve a leer como escasos a los expertos ya cubiertos, y un modelo sin workers vivos se siembra desde su metadata GGUF (número de expertos) para que la demanda sea visible incluso desde cero.
- Los nodos ociosos sondean el mercado de demanda (
/api/expert-volunteer) y reciben una rebanada(layer, expert-range)para servir. Descargan la rebanada, marcan al relay y registran cobertura; el plano de control los cablea automáticamente al mapa de dispatch del coordinador. - Cuando la carga se drena, el objetivo vuelve a bajar y la demanda desaparece, así que a los workers extra ya no se les despacha y expiran.
El diseño es basado en pull: los nodos piden trabajo en vez de que se les empuje, así que un worker tras NAT participa sin conectividad entrante. Un nodo reclutado en la Capa 2 que empieza a servir se convierte en un worker probado que la Capa 1 mantiene entonces activo bajo carga — las dos capas se componen en un solo bucle elástico.
Observabilidad: GET /api/moe/recruitment reporta busy/saturación por modelo y el objetivo base vs efectivo; /api/expert-demand lleva un flag recruiting.