Prefix Caching（前缀缓存）是什么？怎么靠它省钱提速

先这样答

一个线上服务里，成千上万条请求往往共用同一个长开头：系统提示词、角色设定、少样本示例、RAG（检索增强生成，先检索资料再拼进提示词让模型作答）场景里的说明文字，动辄几千 token。按普通流程，每个请求都要对这段重复的开头完整做一遍预填充（对输入提示词整体算注意力、生成 KV Cache 的过程），算完就扔。前缀缓存的做法是：这段开头算一次就存下来，后来的请求直接复用。

生效条件是前缀按 token 完全一致，从第一个字起一个字都不能差，差一处，缓存就对不上。命中的请求跳过公共部分的预填充，只算自己独有的后半段，首 token 延迟下降，计算费用跟着省。自建框架里，vLLM 靠 PagedAttention 的块共享实现它，相同前缀的键值块一份多用；用托管 API 时，很多厂商也提供提示词缓存，命中部分按更低价格计费。所以把不变的内容放开头、变化的内容放结尾，是直接省钱的写法。

落地要点在提示词结构：稳定内容前置，动态内容后置，让公共前缀尽可能长。一句话总结：预填充是按 token 计价的计算，公共前缀算一次、多次复用，这是推理服务里少有的只赚不赔的优化。

面试官会怎么追问

• 「为什么差一个字就不命中？」 注意力是每个位置看它前面的所有位置，前缀不同，后面每个位置的键值全部不同，复用失去意义。所以系统提示词哪怕改一个标点，对应的缓存就作废，这是机制决定的，不是实现缺陷。
• 「RAG 场景能用吗？」 能，但要设计结构。系统说明稳定可缓存，检索回来的文档每次都变，放在开头会打断命中。常见做法是稳定说明放最前，文档紧随其后，命中比例依然可观。
• 「它和 KV Cache 什么关系？」 KV Cache 是请求内复用：同一条请求里已生成的 token 不重算。前缀缓存是跨请求复用：不同请求共享的开头也不重算。后者建立在前者的存储结构之上，复用范围更大。

回答的坑

• 以为它能缓存任意中间内容。它只认 token 级完全一致的连续前缀，不是语义相似就行，把这层说清楚才显得真懂机制。
• 提示词随手写，静态和动态内容混排。结构不对缓存就命不中，优化用不用得上取决于提示词怎么组织，这是面试官想听的实际考量。