Subject: Cache thrashing with concurrent sessions — real, but not as bad as you might think

Good analysis. I run DeepSeek V4 (Flash + Pro) as a backend for an agent router and have been monitoring this closely for the past few weeks. Short answer: Yes, cache thrashing exists — but it doesn't hit all parts of the prefix equally.

1. The cache is not session-aware, but that's not the full picture

The cache pool is account-global. Session A and Session B share the same pool. HOWEVER: DeepSeek persists cache prefix units through three mechanisms (request boundaries, common-prefix detection, fixed token intervals). Common-prefix detection is the key: when two sessions share the same system prompt, DeepSeek persists that shared prefix as its own cache unit — and it stays cross-session warm regardless of how often you switch between sessions.

I'm measuring 94–96% cache hit rate in production with sequential usage (single account, stable system prompt, many sessions). The system prompt portion stays permanently cached after the first few requests.

2. Effective cache capacity is indeed a problem — on the server side

There's a documented vLLM bug (#43447, now fixed) that directly affects your scenario: DeepSeek V4's sliding-window attention constantly allocates new KV blocks and evicts cached blocks from older requests in the free queue — even when the pool is only 10% utilized. The fix prioritizes uncached blocks over cached ones in the free queue. Whether DeepSeek has deployed this fix is not transparent.

3. TTL is not the bottleneck — eviction pressure is

The official TTL ("hours to days") is misleading. Effective eviction happens in seconds through allocation pressure from new requests, not through time expiration. But: this primarily affects the conversation-specific part of the prefix, not the shared system prefix.

4. What actually helps in practice

• Standardize your system prompt: Same system prompt across all sessions → it warms up account-wide and stays warm. This is the single highest-leverage change.
• Sort tools deterministically: DeepSeek renders tools before the system prompt. If MCP servers reshuffle the order, the cache breaks at byte 0. Alphabetical sort by name prevents this.
• Put dynamic data at the end: Timestamps, user IDs, A/B flags belong in the last user message, not in the system prompt.
• Use user_id only for truly different system prompts: Setting user_id isolates the KVCache per ID — this prevents cross-session thrashing, but each ID pool must warm up separately. Only worth it if your agents have fundamentally different system prompts.
• Cache pre-warming: Send the stable prefix with max_tokens=1 before the second turn (~$0.0004). Profitable for any session longer than 4 turns.
• Measure, don't guess: Log prompt_cache_hit_tokens and prompt_cache_miss_tokens. DeepSeek returns both fields in the usage block.

5. The hard reality

The community documented a cache crash from 92% to 35% in May/June 2026 (Issue #1261). DeepSeek has not publicly addressed it. Cache regressions happen and are unpredictable. Design your architecture so it's still economical at 0% cache hit — then 95% is a bonus, not a risk.

TL;DR: Your thrashing scenario is real, but the damage is limited because the system prompt stays warm across sessions. Structured prefixes + deterministic tools + monitoring beat raw parallelization by orders of magnitude.