For quick start instructions, see the Router README. This document provides further examples for using the Dynamo Router, including Python API usage, Kubernetes deployments, and custom routing patterns.
Instead of launching the KV Router via command line, you can create a KvRouter object directly in Python. This allows per-request routing configuration overrides.
Multiple Routers in Same Process: If you need to run multiple KvRouter instances for fault tolerance or load distribution, you must launch them in separate processes (e.g., using python -m dynamo.frontend with different ports). Creating multiple KvRouter objects in the same Python process is not supported - they share the same cancellation token from the component’s primary lease, so dropping one router will cancel all routers in that process. For in-process routing, use a single KvRouter instance.
The KvRouter provides the following methods:
generate(token_ids, model, ...): Route and execute a request, returning an async stream of responses. Automatically handles worker selection, state tracking, and lifecycle management.
best_worker(token_ids, router_config_override=None, request_id=None, update_indexer=False): Query which worker would be selected for given tokens. Returns (worker_id, dp_rank, overlap_blocks).
request_id: Query-only, doesn’t update router staterequest_id: Updates router lifecycle state to track the request. Note: If used with request_id, you must call mark_prefill_complete() and free() at the appropriate lifecycle points to maintain accurate load trackingupdate_indexer=True: Records the selected worker in the approximate indexer for future overlap predictions. This is only meaningful when use_kv_events=Falseget_potential_loads(token_ids): Get detailed load information for all workers, including potential prefill tokens and active decode blocks. Returns a list of load dictionaries.
mark_prefill_complete(request_id): Signal that a request has completed its prefill phase. Only used for manual lifecycle management when using best_worker() for manual routing instead of generate().
free(request_id): Signal that a request has completed and its resources should be released. Only used for manual lifecycle management when using best_worker() for manual routing instead of generate().
dump_events(): Dump all KV cache events from the router’s indexer as a JSON string. Useful for debugging and analysis.
First, launch your backend engines:
For basic Kubernetes deployment with the KV Router, see the Kubernetes Deployment section in the Quick Start guide.
For A/B Testing and Advanced K8s Setup: See the comprehensive KV Router A/B Benchmarking Guide for step-by-step instructions on deploying, configuring, and benchmarking the KV router in Kubernetes.
You can also pass CLI arguments directly in the container command:
Recommendation: Use environment variables for easier configuration management and consistency with Dynamo’s K8s patterns.
The KvRouter supports multiple usage patterns depending on your control requirements:
Call generate() directly and let the router handle everything:
Use best_worker(request_id=...) to select and track, then manage the request yourself:
mark_prefill_complete() and free() at correct lifecycle pointsupdate_indexer=True when use_kv_events=False so the router learns from manual worker selectionsQuery without state updates, then route through a chosen router:
Use get_potential_loads() to implement custom routing logic:
All patterns support router_config_override to adjust routing behavior per-request without recreating the router.
Here’s an example of using get_potential_loads() to implement custom routing that minimizes Time To First Token (TTFT) by selecting the worker with the least prefill work:
This approach gives you complete control over routing decisions, allowing you to optimize for different metrics based on your specific requirements. As some examples:
potential_prefill_tokensbest_worker() which considers both prefill and decode loadspotential_prefill_tokens and potential_decode_blocks togetherSee Router Design for architecture details and the cost function algorithm.
For full documentation on implementing KV event publishing for custom inference engines, see the dedicated KV Event Publishing for Custom Engines guide. It covers:
publish_stored() / publish_removed() to push events over the Dynamo event planeKvEventPublisher subscribes to the ZMQ socket and relays events automaticallyFor deployments with multiple worker pools, the Global Router enables hierarchical routing by sitting between the frontend and local routers. It selects the appropriate pool for each request based on configurable policies, supporting disaggregated topologies where pools are tuned for different workload characteristics.
components/src/dynamo/global_router/examples/global_planner/