DSV4.1-Flash on CMP170HX — hourly update #17

LMCache validated on PP8 (heterogeneous stages). The layout AGENTS.md warns about for cache-group registration works:

• startup: KV cache group edits applied: {'unified-attention-view': 6..9} per rank, Excluding non-prefix-cacheable engine group 5, Resolved LMCache MP geometry: group_tokens_per_block=[32,32,32,32,128,0].
• cold KEY-PP8LM1721 (ext 0) → repeat 0.55 s (ext 128) → after full vLLM restart: 9,728/9,759 tokens restored from LMCache, answer identical to cold (0.96 s). 100% cold-vs-restore equality on PP8.

Real-OpenCode c1 on PP8: median ~24.8 tok/s (fix_bugs 22.4/9.8, add_feature 37.3/29.8, docstring 27.4/7.4) vs ~30 tok/s on PP6. So PP6 remains the c1 layout; PP8 trades ~17% per-stream real-usage speed for 2.75x KV capacity.

Kernel research: folded in VLLM_SPARSE_DECODE_HEAD_BLOCK_SIZE=32 (+2-4%, bit-identical); found VLLM_SPARSE_DECODE_MAXNREG is dead code. TOPK_CHUNK_SIZE=16 hurts c1. Confirmed our tree does not have the upstream #50576 int32 indexer overflow (fix from #47629 already present).

Best recommended setup:

• Ideal c1: PP6 util 0.96 → 65 tok/s raw, real OpenCode ~30 tok/s e2e.
• Max KV / concurrency: PP8 util 0.96 + HEAD_BLOCK_SIZE=32 → 9.35M-token pool, 8.9x @1M.
• At length: ~116 tok/s @128k, ~62 @512k aggregate (thinking tokens included). 500 tok/s @512k remains kernel-blocked on SM80.

Code: campaign e08f120, public 789cd25.