Dynamo Router Starter

Problem

Dynamo router setups often stall after the frontend starts: workers are not registered, the wrong mode is selected, KV events are missing and the router waits indefinitely, or a single chat request is mistaken for a performance result. This skill turns “make the router runnable” into an explicit operating checklist.

How It Works

It collects inputs such as the local Python/CLI or Kubernetes recipe path, expected mode, frontend port or Kubernetes service, and whether workers publish KV events, then works through a sequence:

• Establish baseline: choose a workable mode such as round-robin or least-loaded, and verify that /v1/models returns at least one model.
• Enable KV routing: use KV-aware routing when workers publish KV cache events; otherwise switch to an approximate mode so the router does not hang.
• Smoke test: use scripts/check_router_health.py to check /v1/models and one /v1/chat/completions request.
• Compare modes: keep model, workers, prompt set, and concurrency identical, and label results as smoke-level unless benchmark data is collected.

Boundaries

The skill focuses on startup, configuration, and endpoint validation. It does not produce throughput or latency benchmarks; full performance claims require a separate benchmark run. If workers do not publish KV events, it flags approximate mode but does not repair worker configuration; unhealthy endpoints or missing workers should be handled by the troubleshooting path.