Summary
When kvcached's vLLM prefix-cache block pool evicts or explicitly frees cached blocks, it removes the block from kvcached's own cache indexes and returns the block id to the kvcached allocator. However, the vLLM KVCacheBlock object can keep its cached block_hash value.
Problem
A returned block object may later be reused for a different prefix. If its old block_hash is still present, vLLM block state and kvcached's prefix-cache indexes can diverge. In vLLM versions where block_hash is write-once until reset_hash() is called, recaching the reused block can also fail or keep stale state.
Expected behavior
Whenever kvcached returns a cached or uncached block to the allocator through eviction, explicit eviction, immediate uncached free, or prefix-cache reset, the associated vLLM block hash state should be cleared before the block can be reused.
Impact
This is a prefix-cache correctness issue. It is most visible when the same KVCacheBlock object is evicted and later reallocated for a different prefix.
Summary
When kvcached's vLLM prefix-cache block pool evicts or explicitly frees cached blocks, it removes the block from kvcached's own cache indexes and returns the block id to the kvcached allocator. However, the vLLM
KVCacheBlockobject can keep its cachedblock_hashvalue.Problem
A returned block object may later be reused for a different prefix. If its old
block_hashis still present, vLLM block state and kvcached's prefix-cache indexes can diverge. In vLLM versions whereblock_hashis write-once untilreset_hash()is called, recaching the reused block can also fail or keep stale state.Expected behavior
Whenever kvcached returns a cached or uncached block to the allocator through eviction, explicit eviction, immediate uncached free, or prefix-cache reset, the associated vLLM block hash state should be cleared before the block can be reused.
Impact
This is a prefix-cache correctness issue. It is most visible when the same
KVCacheBlockobject is evicted and later reallocated for a different prefix.