先把当时的情况摆出来。vLLM 0.6.3 启动时加了 --enable-prefix-caching,同一段两万字的 system 反复请求,日志里的前缀缓存命中率始终是 0,首字延迟一点没降。
这类报错背后常见的原因有几处,逐个排除就行。每次请求的 system 前面拼了时间戳 前缀不稳定。另一种情况是多副本部署 请求被轮询到不同实例。
不容易想到的是,块大小与缓存粒度不匹配。还有一种情况,关闭了 CUDA 图 走了另一条执行路径。
上来先确认启动参数和日志字段
python -m vllm.entrypoints.openai.api_server --model Qwen/Qwen2.5-7B-Instruct --enable-prefix-caching 2>&1 | Select-String 'prefix'
随后把时间戳从 system 挪到 user 末尾
python -c "print('move timestamp to user tail')"
接着用同一前缀连发十次观察命中
python bench_prefix.py --n 10 --prefix sys.txt
等前面都确认过,再按会话做粘性路由避免跨实例
python -c "print('sticky routing by session')"
别只看报错消失,验证要多做一步。日志里前缀命中率升到六成以上,第十次请求的首字延迟明显低于第一次。
补一句。前缀缓存要求前缀逐字节一致,任何动态内容放在最前面都会让命中率归零。如果同一现象隔几天又出现,说明根因没找到,别当偶发处理。
