KV Event Publishing for Custom Engines
This document explains how to implement KV event publishing for custom inference engines, enabling them to participate in Dynamo’s KV cache-aware routing.
Overview
The KV Router relies on real-time events from backend workers to track which KV cache blocks are stored on each worker. When your custom engine allocates or evicts KV cache blocks, it should publish these events so the router can make optimal routing decisions.
There are two main publishing pathways:
- Direct NATS publishing (
KvEventPublisher) - Publishes events directly to NATS. Simplest approach for custom engines. - ZMQ-based publishing - For engines with ZMQ event output (like vLLM). Uses a ZMQ publisher in the engine and
ZmqKvEventPublisherto forward events to NATS.
Event Types
The KV cache supports three event types:
Event Structure
Each event contains:
event_id: Monotonically increasing identifier per workerdp_rank: Data parallel rank (0 if DP not enabled)data: One ofStored,Removed, orCleared
For BlockStored events:
token_ids: List of token IDs for the stored blocksblock_hashes: List of sequence block hashes from the engine’s block manager. These are cumulative hashes that incorporate all tokens from the start of the sequence up to and including the current block (not just the tokens within that block). This enables prefix matching across requests.num_block_tokens: Number of tokens per block (should all equalkv_block_size)parent_hash: Hash of the parent block. Required for all blocks except the first block in a sequence (which has no parent).lora_id: LoRA adapter ID (0 if not using LoRA)
For BlockRemoved events:
block_hashes: List of sequence block hashes being evicted
Option 1: Direct NATS Publishing (Recommended)
The KvEventPublisher class publishes events directly to NATS. This is the simplest approach for custom engines.
When to use:
- Building a custom inference engine from scratch
- Your engine doesn’t have a ZMQ-based event system
- You want the simplest integration path
Basic Setup
Integration with Your Engine
Option 2: ZMQ-based Publishing
For engines that publish events via ZMQ (like vLLM), this option uses two components that work together:
- ZMQ Publisher (in your engine) - Publishes events to a ZMQ socket
- ZmqKvEventPublisher (Dynamo binding) - Subscribes to ZMQ and forwards to NATS
When to use:
- Your engine already has a ZMQ-based event system (like vLLM)
- You’re integrating with a consolidator (like KVBM)
- You want to decouple event publishing from your engine’s main loop
Part 1: ZMQ Subscriber (Dynamo Bindings)
If your engine already publishes to ZMQ, use ZmqKvEventPublisher to subscribe and forward to NATS:
Part 2: ZMQ Publisher (Pure Python)
If your engine needs to publish to ZMQ (e.g., for consolidator integration), implement the ZMQ protocol:
ZMQ Wire Format
The ZMQ message format (compatible with vLLM):
Each event in the payload is a dictionary with type field (BlockStored, BlockRemoved, or AllBlocksCleared).
Best Practices
-
Event IDs must be monotonically increasing per worker (use a thread-safe counter)
-
Block size must match your engine’s actual
kv_block_size -
parent_hashis required for all blocks except the first in a sequence - it links blocks to enable prefix matching
See Also
- Router README: Quick start guide for the KV Router
- Router Guide: Configuration, tuning, and production setup
- Router Design: Architecture details and event transport modes