부하-적응 확장

Kvasir의 MoE 서빙 경로가 트래픽에 따라 커지고 줄어든다: 코디네이터는 포화 상태에서 proven 워커를 다시 투입하고, 브리지는 전문가 수요를 높여 유휴 노드를 모집한다 — 모두 pull 방식이라 NAT 뒤의 기기도 합류한다.

Kvasir의 MoE 서빙 경로는 부하에 맞춰 탄력적으로 확장되며, 두 개의 협력하는 계층으로 이루어집니다. 한산할 때 코디네이터는 토큰당 가장 빠른 경로를 위해 모든 것을 로컬에서 서빙하고; 포화되면 아래 두 계층이 스웜을 키웁니다 — 그리고 급증이 지나가면 다시 줄입니다.

백본 코디네이터(전체 모델을 실행하는 linkcpp-server)는 라우팅된 전문가를 자기 GPU에서 직접(빠르고 로컬) 서빙하거나 원격 워커로 dispatch합니다. 백그라운드 스레드가 몇 초마다 어느 쪽일지 결정합니다:

• 자기 자신의 추론 슬롯을 폴링합니다. busy >= saturation threshold(기본값 2)이면 코디네이터는 부하 상태입니다.
• 부하 상태에서, proven 워커가 살아 있으면 — last_serve_ms > 0인, 즉 실제로 전문가를 계산해 본 적 있는 워커 — 코디네이터는 정상 유휴 타임아웃을 넘겨서까지 그 워커로 계속 dispatch하며, 토큰당 지연보다 총처리량을 우선합니다.
• 접속했지만 한 번도 서빙하지 않은 워커(릴레이를 dial했으나 계산은 하지 않은 폰)는 부하 상태에서 모집되지 않습니다 — 그런 워커로 dispatch하면 빠른 로컬 경로를 느린 폴백으로 바꾸는 셈이기 때문입니다. 신규 워커도 짧은 grace window를 통해 첫 시도는 받습니다.
• 자기 조회(self-query)는 시간 제한이 걸려 있어, 멈춘 폴이 dispatch를 막는 일이 절대 없습니다.

컨트롤 플레인은 모든 MoE 코디네이터를 지켜보며 필요할 때 워커 풀을 키웁니다:

• 백그라운드 루프가 각 코디네이터의 슬롯을 폴링해 모델별 포화도를 기록합니다.
• 모델이 포화된 동안 그 모델의 유효 전문가-복제본 목표치가 상향됩니다(base + boost). 그러면 커버리지 마켓은 이미 커버된 전문가를 다시 희소한 것으로 읽고, 살아 있는 워커가 하나도 없는 모델은 GGUF 메타데이터(전문가 수)로부터 시딩되어 수요가 0에서도 보이게 됩니다.
• 유휴 노드는 수요 마켓(/api/expert-volunteer)을 폴링해 서빙할 (layer, expert-range) 슬라이스를 배정받습니다. 이들은 슬라이스를 내려받고, 릴레이를 dial하고, 커버리지를 등록합니다; 컨트롤 플레인은 이들을 코디네이터의 dispatch 맵에 자동 배선합니다.
• 부하가 빠지면 목표치가 원래대로 돌아가고 수요가 사라져, 여분 워커는 더 이상 dispatch되지 않고 age out됩니다.

관측성: GET /api/moe/recruitment은 모델별 busy/saturation과 base 대 effective 목표치를 보고하고; /api/expert-demand는 recruiting 플래그를 담습니다.