直接回答：Transformer 计算中，前 i 个 token 的 KV 只依赖前 i 个 token 自身（因果注意力），因此相同前缀的 KV cache 可以直接复用，跳过 prefill 计算——这就是前缀缓存。主流 API（Anthropic、DeepSeek 等）按命中前缀的 token 数大幅降价（常为 1/10），自建 vLLM/SGLang 也有对应能力（automatic prefix caching、RadixAttention）。

展开解析：命中的关键是从第一个 token 起完全一致，所以 prompt 组织原则是“稳定的放前面、变化的放后面”：系统指令与工具定义 → few-shot 示例 → 知识库/文档（RAG 场景）→ 对话历史 → 最新用户输入。常见翻车点：在系统提示里塞动态内容（当前时间、用户名、请求 ID）导致每次前缀都不同；检索结果顺序不稳定；JSON 字段顺序随机。多轮对话中历史逐轮增长，天然前缀匹配，但编辑或摘要历史会打断缓存。Agent 场景下工具结果追加在末尾，命中率高；频繁改工具定义则全废。还要注意缓存粒度（有的按 128 token 块对齐，前缀不足一个块不命中）与 TTL（通常分钟级）。成本优化的账：固定系统提示 2 万 token 的应用，命中率 90% 时输入成本能降一个数量级，值得专门设计。

追问方向：prefix caching 与直接压缩 prompt 哪个更划算？如何监控缓存命中率？

（约 480 字）