Mise à l'échelle adaptative à la charge
Le chemin de service MoE de Kvasir grandit et se contracte avec le trafic : le coordinateur remobilise les workers éprouvés en saturation, et le bridge recrute des nœuds inactifs en augmentant la demande d'experts — le tout basé sur le pull, si bien que les appareils derrière NAT participent aussi.
Le chemin de service MoE de Kvasir se met à l'échelle de façon élastique avec la charge, en deux couches coopérantes. Au repos, le coordinateur sert tout localement pour le chemin le plus rapide par token ; en saturation, les deux couches ci-dessous font grandir l'essaim — et le contractent de nouveau quand la pointe passe.
État du moteur. Le sharding au grain de l'expert a été construit et démontré sur le moteur précédent de Kvasir, et les résultats ci-dessous proviennent de ce travail. Le moteur actuel, [p4](/wiki/p4), sert aujourd'hui au grain de la couche ; le portage du sharding d'experts vers lui est conçu et en cours. Quand un détail nomme un outil ou une route, c'est celui qui tournait sur le moteur précédent.
Côté coordinateur : dispatch adaptatif à la charge
Le coordinateur backbone (un linkcpp-server exécutant le modèle complet) sert les experts routés soit sur son propre GPU (rapide, local), soit en les dispatchant vers des workers distants. Un thread d'arrière-plan décide lequel, toutes les quelques secondes :
- Il interroge ses propres slots d'inférence. Quand
busy >= saturation threshold(défaut 2), le coordinateur est sous charge. - Sous charge, si un worker éprouvé est actif — un worker dont
last_serve_ms > 0, c'est-à-dire qui a déjà réellement calculé des experts — le coordinateur continue de lui dispatcher du travail au-delà du délai d'inactivité normal, privilégiant le débit agrégé sur la latence par token. - Un worker qui s'est connecté sans jamais servir (un téléphone qui a appelé le relay sans jamais calculer) n'est pas recruté sous charge, car lui dispatcher du travail remplacerait le chemin local rapide par un repli lent. Les nouveaux workers ont tout de même un premier essai via une courte fenêtre de grâce.
- L'auto-interrogation est bornée dans le temps, de sorte qu'un sondage bloqué ne peut jamais bloquer le dispatch.
Côté plan de contrôle : recrutement adaptatif à la charge
Le plan de contrôle surveille chaque coordinateur MoE et fait grandir le pool de workers lorsque nécessaire :
- Une boucle d'arrière-plan interroge les slots de chaque coordinateur et enregistre la saturation par modèle.
- Tant qu'un modèle est saturé, sa cible effective de répliques d'experts est relevée (base + boost). Le marché de couverture relit alors les experts déjà couverts comme de nouveau rares, et un modèle sans worker actif est amorcé à partir de ses métadonnées GGUF (nombre d'experts), afin que la demande soit visible même depuis zéro.
- Les nœuds inactifs interrogent le marché de la demande (
/api/expert-volunteer) et reçoivent une tranche(layer, expert-range)à servir. Ils téléchargent la tranche, appellent le relay et enregistrent leur couverture ; le plan de contrôle les câble automatiquement dans la carte de dispatch du coordinateur. - Quand la charge s'épuise, la cible retombe et la demande disparaît, si bien que les workers supplémentaires ne reçoivent plus de dispatch et s'éteignent avec le temps.
La conception est basée sur le pull : les nœuds demandent du travail au lieu de se le voir imposer, si bien qu'un worker derrière NAT participe sans aucune connectivité entrante. Un nœud recruté en Couche 2 qui se met à servir devient un worker éprouvé que la Couche 1 maintient ensuite engagé sous charge — les deux couches se composent en une seule boucle élastique.
Observabilité : GET /api/moe/recruitment rapporte le busy/saturation par modèle et la cible base vs effective ; /api/expert-demand porte un drapeau recruiting.