昇腾 910B 上开了 Prefix Caching 反而更慢？三个硬约束没对齐，缓存命中率是零

在昇腾 910B 上用 vLLM-ascend 部署一个多轮对话服务，看到官方推荐“多轮对话场景命中率 60% 以上时 Prefix Caching 收益明显”，就直接打开了 enable_prefix_caching。结果 TTFT（首 token 延迟）不但没降，反而比关闭时高了约 15%，显存占用还涨了一截。排查后发现，Prefix Caching 在昇腾上的收益有三个硬约束，任何一个不满足，缓存命中率就是零，而额外的哈希和显存开销照付不误。

一、 约束一：Prefix Caching 不能和 Chunked Prefill 同时使用

华为云 ModelArts 的文档写得很清楚：Prefix Caching 特性不能和 Chunked Prefill 同时使用。我们的启动参数里 --enable-chunked-prefill 是开着的（为了长 prompt 的显存平滑），Prefix Caching 虽然也打开了，但框架内部实际上处于一种“名义开启、实际不生效”的状态。额外的 Prefix Cache 显存被预留着，但缓存命中逻辑并没有真正走通，所以 TTFT 没有受益，显存却实打实被吃掉了。这两个特性在昇腾上是互斥的，必须先确认 Chunked Prefill 是否真的需要，再决定是否用 Prefix Caching 替换它。

二、 约束二：公共前缀长度必须 ≥ block-size 才可能命中

Prefix Caching 的复用粒度是 Page Attention 的 block。文档明确：只有当跨请求的公共前缀 token 数大于等于 block size 时，才会进行 KV Cache 复用。我们的对话场景中，system prompt 本身只有约 80 个 token，而 block-size 设的是默认的 128（或者在某些 UCM 配置下推荐 128）。80 < 128，意味着 system prompt 根本不够组成一个可复用的 block，每一轮对话都在重新计算完整的 prompt，Prefix Caching 从第一条消息起就没有命中过。

把 block-size 降到 32 后，80 token 的 system prompt 可以覆盖两个完整 block，前缀复用的条件才真正满足。block-size 的选择不是孤立的“长文本调大、短文本调小”，它同时决定了 Prefix Caching 的命中门槛，需要和业务中公共前缀的典型长度一起考虑。

三、 约束三：显存 utilization 没有为 Prefix Cache 让出空间

即使前两个条件都满足，启动 Prefix Caching 本身会占用额外显存来维护缓存结构。文档建议在 max_model_len 为 64k 时，把 gpu_memory_utilization 降到 0.85。我们沿用了不开缓存时的 0.92，结果缓存结构和 KV Cache 争抢显存，vLLM 的调度器为了避免 OOM 频繁触发重算，反而增加了延迟。把 utilization 降到 0.85 之后，显存水位回到合理区间，缓存的复用才稳定生效。

四、 还有一个版本与模型的约束

补充一条排查中发现的隐性条件：多模态模型目前不支持 prefix cache，部分模型系列（如 Qwen2.5/Qwen3）在特定版本下支持。如果业务是多模态或混合模型路由，需要在服务层面按模型区分是否开启该特性，而不是一刀切全局打开。

五、 总结

昇腾上 Prefix Caching 的启用判断，不能只看“是不是多轮对话”，而要过一遍三个硬条件：Chunked Prefill 是否已关闭（两者互斥）→ 公共前缀长度是否 ≥ block-size → gpu_memory_utilization 是否为缓存开销让出了空间。三个条件缺一个，命中率就是零，额外的显存和哈希开销就是纯成本。先关掉 Chunked Prefill 跑 baseline，再按条件逐项对齐，用 TTFT 的数据决定是否保留，而不是看到“推荐开启”就默认打开。