问题出现得很突然，日志倒是留得挺全。vLLM 0.6.3 启动时加了 --enable-prefix-caching，压测 2000 次相同 system 前缀的请求，监控里 prefix cache hit rate 一直是 0，首 token 延迟没有改善。
刚开始盯着「tp 大于 1 时各 rank 的块哈希未对齐」，折腾了半个多小时，排掉了。
把日志和配置对完，能解释这个现象的基本就这几处。请求里带了随机 seed 或时间戳导致前缀不同。另一种情况是每次请求的 system 消息被 SDK 自动加了不同后缀。
另外，指标采集端口没开，看到的是默认值。
第一件事是打开指标端口确认采集到的是真实值
curl -s http://127.0.0.1:8000/metrics | Select-String prefix_cache再往下对比两次请求的完整 prompt 是否逐字节相同
python -c "import hashlib;print(hashlib.md5(open('p1.txt','rb').read()).hexdigest(), hashlib.md5(open('p2.txt','rb').read()).hexdigest())"去掉随机字段后重压一轮
python bench.py --prefix fixed_system.txt --repeat 2000 --no-seed末了按 block 大小对齐前缀长度
python -c "print('pad prefix to multiple of 16 tokens')"改完先别撤，确认这几项。压测中前缀缓存命中率升到 85% 以上，首 token 的 P50 延迟从 420ms 降到 180ms，指标曲线与压测节奏一致。
补一句。前缀缓存按块哈希匹配，任何一处字节差异都会让整段前缀失效，排查时先比字节再怀疑引擎。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。