Agent账单降90%：KV Cache前缀缓存与断点实操

Agent 的 API 账单结构和聊天场景有一个根本差异：输出很少，输入极多。一条 ReAct 轨迹跑十几轮，每轮都要把 system prompt、工具定义和累积的对话历史重新送进去，输出可能只有几百 Token，输入却轻易突破几十万。prefill 阶段的算力主要花在 “重新读一遍已经读过的东西” 上，而 KV Cache 命中率直接决定了这部分重复计算是被跳过还是被全额支付。

Anthropic 的定价给出了一个量级参考：缓存读取的价格是标准输入价的 0.1 倍，写入是 1.25 倍。一个 20K Token 的 system prompt 在五分钟内被调用 100 次，不开缓存输入成本是 4 美元，开缓存后降到约 0.25 美元。Agent 场景的调用密度远高于这个例子，命中与未命中的差距会被轮次成倍放大。

一、缓存匹配的底层规则：因果前缀，逐字节精确

KV Cache 的复用建立在因果注意力之上。第 N 个 Token 的 Key-Value 状态依赖于它前面所有 Token 的计算结果，所以缓存只能识别 “从第 0 个 Token 开始逐字节一致” 的最长公共前缀。vLLM 的实现方式是把这个规则工程化：将 KV Cache 划分为固定大小的 Block，每个 Block 的哈希键包含父 Block 的哈希值、块内 Token 以及额外的元数据（如 LoRA ID、多模态输入哈希、多租户隔离盐值），默认哈希算法为 SHA-256。这意味着共享同一段前缀的请求，在 Block 粒度上映射到相同的物理内存，跨请求复用。

DeepSeek 的硬盘缓存遵循同一条规则，并且把边界说得很直白：只有当两个请求的前缀内容相同（从第 0 个 Token 开始相同）才算重复，中间开始的重复不能被命中。这条规则是所有缓存策略的起点 —— 优化不是 “把重复内容放在一起”，而是 “确保可能重复的内容全部排在第一个变量之前”。

二、稳定层放置：Agent 的 prompt 是一份有顺序的布局

一条 Agent 请求通常由四类内容构成：工具定义、system prompt、对话历史、当前输入。Anthropic 的缓存匹配顺序明确是 tools → system → messages，而且按前缀匹配，不是子串匹配。OpenAI 的自动缓存同样作用于完整渲染后的上下文，1024 Token 是触发门槛，低于这个长度不缓存。

一个常见的工程反模式会直接摧毁命中率：把每轮 ReAct 产生的工具输出或中间状态写回 system prompt。system prompt 位于前缀的头部区域，一旦它发生变化，紧随其后的所有对话历史都无法复用。正确的布局是固定不变的指令、工具 schema、静态参考文档全部前置，变量追加到尾部。顺序本身就是缓存策略的一部分，而不是事后可以随意调换的格式问题。

三、缓存断点：放在变化边界，不是放在 “最稳定的地方”

Anthropic 采用显式断点模式，最多标记 4 个 cache_control，每个断点缓存 “从开头到该断点” 的前缀，断点之前任何一个字节的变化都会使整段缓存失效。AWS 在 Bedrock 上做过一组对照实验：同一份 prompt、同一模型、同一流量，唯一变量是断点位置。在分类负载上，把断点放在 “稳定内容结束、变量开始之前” 取得了约 75% 的输入成本节省；而直觉上最常见的做法 —— 在 system prompt 后面放一个断点 —— 只节省了约 13%。原因是 system prompt 之后的对话历史仍在增长，一个过早的断点覆盖不到后续真正可复用的区间。

断点还有一个容易被忽略的陷阱：它缓存的是 “之前的所有内容”。如果断点之前的某个位置混入了时间戳、请求 ID 或会话标识，这个断点对应的前缀在每一次请求中都是唯一的，缓存写入持续产生费用，读取命中几乎为零。写入有溢价，只写不读的缓存比不开缓存更差。

四、Agent 的额外约束：缓存必须在轮次之间存活

对话式缓存的隐含假设是请求间隔很短、前缀稳定。Agent 的节奏不同：一轮任务可能持续几十秒到几分钟，中间穿插工具执行和外部 I/O。如果推理侧采用 scale-to-zero 的 serverless 部署，实例在两次调用之间被回收，KV Cache 随之丢失，下一轮要为同一段前缀重新支付 prefill 成本。

一个被公开记录的生产案例说明了修复的杠杆有多大：ProjectDiscovery 的一个安全情报 Agent，每次请求发送相同的 4,000 Token 系统指令和工具定义，但缓存命中率只有 7%。仅仅把一个动态标识符从 prompt 中间移到末尾，命中率升到 74%，月度推理成本下降 59%。在 DigitalOcean Serverless Inference 上，同样的修复让命中率从 0% 提升到 99.3%，输入成本降低约 90%。这些数字指向同一个结论：Agent 缓存优化的第一优先级不是 “开不开缓存”，而是 “有没有一个放错位置的变量在前缀里”。

TTL 也需要和 Agent 的实际节奏对齐。Anthropic 默认 5 分钟窗口，1 小时 TTL 的写入溢价升到 2 倍。对于轮次间隔密集的 Agent，5 分钟通常足够；如果任务中存在较长的工具执行等待，需要评估 keepalive 策略是否值得，而不是盲目延长 TTL。

五、多模型接入下，缓存语义并不均质

当团队通过统一入口调用多个模型时，一个隐蔽的成本泄漏点会出现：各家缓存机制在触发条件、最小长度、写入溢价和 TTL 上并不一致。Anthropic 的显式断点、OpenAI 的自动前缀缓存、DeepSeek 的自动硬盘缓存，对 “什么算命中” 的判定并不相同。如果接入层只是原样转发请求，开发者可能在一个模型上命中良好，切换到另一个模型后命中率骤降，而账单变化不会立刻暴露原因。

以 KoalaAPI 为例，其接口保持 OpenAI SDK 兼容，base_url 指向 https://koalaapi.com/v1，流式返回和工具调用格式沿用 OpenAI 的请求结构。对于已经按 “稳定层前置、变量后置” 组织 prompt 的 Agent，这种兼容性意味着迁移时不需要重写缓存布局；但底层通道在具体模型上的命中行为，仍需要按各供应商的计费字段（如 cache_read_input_tokens、prompt_cache_hit_tokens）逐模型验证，而不是假设一个入口下的命中率是均质的。

六、结语

Agent 的 KV Cache 优化，核心不在某个参数开关，而在 prompt 的结构顺序和断点的位置选择。稳定内容前置、变量追加到尾部、断点放在变化边界而非只放在开头，这三条规则的成本收益已经被供应商定价和独立基准反复验证。Agent 的调用链更长、前缀更重，一个放错位置的动态字段造成的损失会被轮次成倍放大，同样，一次正确的重排带来的节省也会被成倍放大。把缓存布局当作一项需要逐模型校准的工程决策，而不是一个 “打开就好” 的全局设置，是 Agent 成本治理里回报最确定的一步。

了解更多： https://koalaapi.com/