大语言模型应用日益复杂，推理成本与延迟越来越重要。一次请求可能包含系统提示、对话历史、检索文档、工具定义和用户输入，累计数千甚至数百万 token。如果不加缓存，服务端每次都把相同上下文重新计算一遍，既耗时又浪费算力。实际上，LLM 服务中的缓存不是一个单一功能，而是位于服务堆栈不同层次的四种机制：KV 缓存、前缀缓存、提示词缓存和语义缓存。
KV 缓存是现代自回归模型推理的基础。模型并不是一次生成完整回复，而是一个 token 一个 token 地生成；每生成一个新 token，注意力机制都要计算它与此前所有 token 的关系，为已处理 token 生成 Key 和 Value 张量。KV 缓存把这些张量存放在内存（通常为 GPU 显存）中。prefill 阶段处理完提示后缓存 K/V 状态，后续解码步骤直接复用并增量追加，避免序列变长后反复从头重建注意力状态。它的局限是通常只服务于当前请求：该请求结束后，相关 K/V 状态不会自动成为另一个无关请求的缓存。
前缀缓存把 KV 缓存的复用扩展到不同请求之间。实际场景中，许多用户的请求共享长长的系统提示、公司政策、工具定义，只有末尾的用户问题不同。若新请求与某先前请求有相同的开头，服务系统直接复用那部分 K/V，无需重新计算。实现上，前缀缓存把提示切成定长的 token 块，并为每个块计算基于内容和位置的哈希；新请求通过哈希检查找到 CACHE HIT，命中块直接复用，只有 CACHE MISS 的部分送入模型计算。缓存空间有限时，系统通常用 LRU 策略淘汰旧块。多模态场景中则要注意：文本相同但图片不同，不能仅凭文本判定可复用。vLLM 等系统已经以块式 KV 管理、哈希、查找和淘汰机制实现了前缀缓存。
提示词缓存则把缓存责任交给 API 提供商。对于通过云 API 使用模型的应用，请求里的系统提示、文档、工具定义等常达数万 token，且几乎不变。提供商可以在基础设施层缓存这些重复内容，使后续请求只按缓存的一部分重新处理。多家大模型 API 采用分区定价：例如缓存命中约为不缓存价格的 0.1 倍，写入缓存约为 1.25 倍或更高（有些还会额外收存储费，有些则自动缓存且不另计费）。因此，提示词缓存能同时改善输入处理成本与延迟。
语义缓存是四种缓存中离模型最远的一种：它可以完全跳过 LLM。当用户提出的问题与历史问题语义相近时，系统直接返回之前生成的答案，而不调用模型。通常会用嵌入向量而不是文本哈希来判断语义相似度。它把响应时间降到最低、避免昂贵推理，但要处理阈值设定、答案新鲜度和多轮语境等问题，适合 FAQ 和知识库等重复性较高的场景。
综合来看，四种缓存解决的是不同环节的重复劳动：KV 缓存服务于单次请求的解码提速；前缀缓存让共享前缀的请求减少 prefill；提示词缓存把固定上下文放到服务商缓存层；语义缓存则在请求进入模型之前就用相似答案命中。实际系统中它们并非互斥，而是可以叠加部署。理解它们之间的差别，有助于针对成本、延迟和缓存命中率做出正确取舍。