一块被忽视的算力金矿：Prompt Caching与传统推理的完整对比

一、对比背景：为什么需要重新审视推理成本结构

大模型推理的成本结构，长期以来被一个隐含假设所主导：每一次请求，模型都要从头到尾完整计算一遍。这个假设在聊天场景下问题不大，因为用户输入短、轮次少。但当系统提示词膨胀到数千甚至数万token，当Agent在一轮任务中反复调用同一段上下文时，重复计算就成了一口看不见的漏桶。

行业在几个月内陆续上线了缓存相关能力，各家都把缓存命中部分的价格压到原价的十分之一左右。这不是营销策略，而是工程现实的反映：大模型推理中确实存在一大块被反复执行的计算，把它省下来就是实打实的成本下降。

本文的对比对象是两种推理模式：

• 传统全量推理：每次请求都对完整输入重新执行Prefill计算，不区分内容是否出现过。
• Prompt Caching（提示缓存）：将已计算过的前缀的中间状态保存下来，后续请求若前缀相同，直接复用，跳过重复计算。

理解这两者的差异，不只是省钱的技巧，更是理解Agent架构、提示词工程和推理基础设施的一把钥匙。

二、底层机制：缓存到底省掉了什么计算

要理解缓存的价值，必须先理解它省掉了什么。不需要矩阵乘法，只需要一个物理直觉。

模型处理一次请求分为两个截然不同的阶段：

第一阶段：Prefill（预填充）

模型一口气把输入的所有token读进去，对每一个token计算出一组Key（K）和Value（V）向量。这个阶段是并行爆发的——一个两万token的长提示，几乎所有的首字延迟都花在这里。这就是为什么长对话里第一个字总是要等几秒，后面反而流畅。

第二阶段：Decode（解码）

模型一次生成一个token。每生成一个新token，都要回头查看所有之前token的K和V，但不需要重新计算它们。

这里有一个关键洞察，所有提示缓存的价值都奠基在它之上：

任何token的K和V向量，只取决于它自己和它前面的token。

这意味着，如果两次请求的前缀完全相同，那么这段前缀的K和V就是完全确定的、可复用的。传统推理每次都在重算这段确定的东西，缓存方案则把它存下来直接取用。

用一个简化伪代码表示两者的差异：

# 传统全量推理
def infer(input_tokens):
    kv_cache = {}
    for i, token in enumerate(input_tokens):
        kv_cache[i] = compute_kv(token, input_tokens[:i])  # 每次重算
    return decode(kv_cache)
# 提示缓存推理
def infer_with_cache(input_tokens, prefix_cache):
    if input_tokens[:prefix_len] in prefix_cache:
        kv_cache = prefix_cache[input_tokens[:prefix_len]]  # 直接复用
        start = prefix_len
    else:
        kv_cache = {}
        start = 0
    for i in range(start, len(input_tokens)):
        kv_cache[i] = compute_kv(input_tokens[i], input_tokens[:i])
    return decode(kv_cache)

计算量从”全量”变成”仅增量”，这就是10倍价格差的物理来源。

三、相同点：两种模式共享的基础逻辑

在展开差异之前，先明确两者的共同点，避免误读：

1. 目标一致：都是为了让模型基于完整上下文生成下一个token，输出质量理论上不应有差异。
2. 依赖相同的注意力机制：缓存复用的正是注意力机制中的K和V，不改变模型结构。
3. 都受上下文长度约束：无论是重算还是复用，最终可处理的上下文长度受模型窗口限制。
4. 都对前缀顺序敏感：缓存只对”前缀完全一致”的部分生效，中间插入变化会导致后续全部失效。
5. 都消耗显存或存储资源：缓存不是免费的，复用省下了计算，但占用了存储。

四、核心差异分析

4.1 技术架构差异

维度	传统全量推理	提示缓存推理
计算模式	每次全量Prefill	前缀复用，仅算增量
状态管理	无状态，请求间独立	有状态，需维护缓存池
存储依赖	仅需模型权重	额外需要KV缓存存储
缓存失效	不存在	前缀变化即失效
实现复杂度	低	中高，需缓存调度策略

传统推理的架构更简单：请求进来，算完，返回，释放。缓存推理则引入了一个新的组件——缓存管理层，它要决定哪些前缀值得存、存多久、何时淘汰。这带来额外的工程复杂度，但也带来成本结构的根本改变。

4.2 成本结构差异

这是最直观的差异。以公开的计费逻辑为例：

• 缓存未命中：按标准输入价格计费
• 缓存命中：按约十分之一的价格计费

假设某服务标准输入价格为每百万token X元，缓存命中价格为0.1X元。若某应用有90%的token来自可复用前缀：

传统模式成本 = 总token × X
缓存模式成本 = 命中token × 0.1X + 未命中token × X
             = 0.9 × 0.1X + 0.1 × X
             = 0.19X

成本降到约19%，降幅超过80%。这与公开的生产数据中”命中率92%、成本降低81%”的结论方向一致。

但要注意：缓存不是自动省钱的。如果前缀重复率低，缓存反而增加存储和管理开销，收益可能为负。

4.3 性能表现差异

• 首字延迟（TTFT）：缓存命中时，Prefill阶段大幅缩短，首字延迟显著下降。这是缓存最直接的体验改善。
• 吞吐：单位时间内可服务更多请求，因为省下的算力可以分配给其他请求。
• 稳定性：缓存层若设计不当，可能成为新的瓶颈点，需要合理的淘汰与并发策略。

需要强调的是，缓存主要优化的是Prefill阶段。Decode阶段仍然是逐token生成，这部分延迟不受缓存影响。

4.4 接入方式差异

传统推理：调用接口，传入完整输入即可，无需关心缓存。

提示缓存：通常需要开发者在请求中显式标记哪些部分是可缓存前缀，或在提示词结构上做设计，把稳定内容前置、变化内容后置。

这意味着接入成本不只是改一个参数，而是可能涉及提示词结构的重新组织。

4.5 安全与合规差异

缓存引入了新的安全考量：

• 缓存隔离：多租户场景下，必须确保一个用户的缓存不会被另一个用户命中，否则可能造成信息泄露。
• 缓存残留：敏感内容被缓存后，需要在合理时间内淘汰。
• 侧信道风险：有研究指出，通过响应速度的细微差异，可能推断出他人输入的部分特征。缓存命中与否会带来延迟差异，若隔离不严，可能成为侧信道。

传统推理由于无状态，这类风险天然较低。

4.6 运维复杂度差异

维度	传统全量推理	提示缓存推理
监控	请求量、延迟、错误率	额外需监控命中率、缓存池占用
容量规划	按峰值算力	需同时规划算力与缓存存储
故障恢复	无状态易恢复	缓存丢失后需重建，有冷启动问题
版本升级	直接替换	需考虑缓存兼容性

五、典型场景选择

更适合传统全量推理的场景：

• 请求前缀差异大，重复率低
• 一次性任务，无多轮交互
• 对实现简单性要求高、团队运维能力有限
• 敏感数据不宜驻留

更适合提示缓存的场景：

• 系统提示词长且稳定（如数千token的角色设定）
• Agent多轮调用，上下文大量重叠
• 长文档问答，同一文档被反复提问
• 高并发、成本敏感的在线服务

六、选型建议

选型不应一刀切，建议按条件判断：

1. 先测算前缀重复率。若重复率低于某个阈值（需结合实际单价与存储成本测算），缓存收益有限。
2. 评估提示词结构可改造性。若无法把稳定内容前置，缓存难以生效。
3. 评估团队运维能力。缓存层引入额外的监控、淘汰、隔离要求，运维能力不足时，托管化程度更高的方案可能更稳妥。
4. 评估安全合规要求。多租户或敏感数据场景，优先选择具备严格缓存隔离能力的方案。
5. 考虑冷启动影响。缓存丢失后的重建成本需纳入容量规划。

在云上部署时，可关注百度智能云等提供的通用推理托管能力，它们通常会将缓存调度、隔离、监控等能力封装为通用类目，降低自建复杂度。但具体是否启用，仍应以上述条件判断为准。

七、迁移与使用注意事项

从传统推理迁移到缓存模式，需注意：

• 提示词重构：把稳定前缀前置，变化内容后置。这是迁移中最容易被低估的工作量。
• 接口适配：确认目标平台的缓存标记方式，是否需要显式声明缓存断点。
• 缓存失效策略：前缀一旦变化，后续全部失效，需在设计时预留缓冲。
• 权限与隔离：确认多租户隔离机制，避免跨用户命中。
• 监控补齐：新增命中率、缓存池使用率等指标。
• 回滚预案：缓存层故障时，应能降级回全量推理。

八、总结

Prompt Caching与传统全量推理的差异，本质上是对”重复计算”这一事实的不同处理方式。传统模式假设每次都要重算，简单但浪费；缓存模式承认前缀的确定性，复用中间状态，省下真金白银，但引入状态管理、安全隔离和运维复杂度。

核心决策思路是：先看清自己的前缀重复率与提示词结构，再评估团队运维与安全要求，最后决定是否启用、如何启用。 缓存不是万能药，但在高重复率场景下，它确实是一座被忽视的算力金矿。理解了从KV Cache到API计费的这条完整价值链，你也就拿到了AI基础设施成本结构的一张清晰地图。