技术前沿：从 Prefix Caching 到多层架构
Prefix Caching（前缀缓存）
与 Prompt Cache 类似，但只缓存跨请求重复出现的公共前缀段。在批量推理中，多个提示共享相同前缀时，重用该共享段的计算，从而跳过共享段的注意力计算。
- vLLM：自动前缀缓存（APC），存储先前请求的 KV 缓存，新请求共享前缀时直接复用
- TGI：高性能数据结构加速前缀查找，与 FlashDecoding 内核集成
- 局限：只加速预填充阶段，不影响解码阶段。如果瓶颈来自长响应的解码，前缀缓存效果有限
推理引擎的 Prompt Cache 支持
- Ollama：多用户环境中的优化提示缓存
- llama.cpp：支持系统提示缓存
- TensorRT-LLM：系统提示缓存
- PPIO：基于智能缓存策略，识别和缓存可重复使用的文本模式，支持 DeepSeek V3、Kimi K2、GLM-4.6 等模型
Dify 2026 的 4 层缓存架构
Dify 2026 的缓存体系不是简单叠加多级存储，而是重构了从 L1 到 L4 的全栈路径：
- L1（Context Cache）：运行时推理上下文快照，无锁 RingBuffer + SIMD 压缩编码，延迟控制在 8μs 内
- L2（App Cache）：应用级 Prompt/LLM 配置快照，支持 JSON Schema 约束校验与版本灰度发布
- L3（Tenant Cache）：租户隔离的向量索引元数据缓存，集成 FAISS v3.0.2 的增量合并调度器
- L4（Graph Cache）：跨工作区知识图谱缓存，以 RDF* 三元组形式持久化
对开发者的实操建议
1. 把缓存当成成本杠杆来管理
不要把它当成"自动优化"的黑盒。缓存命中率每下降 10%，成本可能上涨 50% 以上。你需要：
- 监控缓存命中率（Claude 和 OpenAI 的 API 响应中都有相关字段）
- 把静态内容（系统提示、知识库、少样本示例）放在提示的开头
- 避免在提示前缀中引入动态变量（时间戳、版本号、随机数）
2. 选择适合你的缓存策略
- 如果你做企业级知识库问答：选 Google 的 CachedContent API，对象化管理适合长文档复用
- 如果你做Agent/编程助手：选 Anthropic 的 cache_control，4 个断点灵活控制
- 如果你做普通对话应用：选 OpenAI 的自动缓存，零学习成本但可控性低
- 如果你做长上下文推理：选 DeepSeek V4，架构压缩让 1M 上下文成为标配
3. 拥抱多模型缓存策略
不要押注单一厂商。不同厂商的缓存策略不同，在 Prompt 结构上不兼容。建议：
- 设计提示时把"可缓存部分"和"动态部分"物理分离
- 用中间层（如 LiteLLM、PPIO）做缓存路由和模型切换
- 定期测试不同模型的缓存命中率，作为成本优化的一部分
4. 关注架构层创新
- vLLM 的 PagedAttention：用操作系统分页思路管理 KV 内存，适合自托管场景
- FP8/INT4 KV 量化：让端侧部署长上下文成为可能
- PML（Prompt Markup Language）：未来可能成为跨平台缓存的标准格式
总结：Prompt Cache 的范式转移
2026 年，Prompt Cache 完成了从工程优化到商业基础设施的范式转移。
- 对开发者：缓存命中率 = 利润率，需要像监控服务器 CPU 一样监控缓存命中率
- 对厂商：缓存策略 = 产品差异化，谁的缓存更聪明、更便宜，谁就能吸引 Agent 开发者
- 对生态：缓存标准尚未统一，PML 可能成为跨平台协议，但短期内仍是厂商割据
---
参考论文：
- Gim, Guojun Chen, Seung-seob Lee, et al. "Prompt Cache: Modular Attention Reuse for Low-Latency Inference." arXiv:2311.04934
- A Survey on Inference Engines for Large Language Models: Perspectives on Optimization and Efficiency. arXiv:2505.01658
- 2026 KV Cache 深度解析（chooseai.net）
- 36氪 "谁能算清'Token账单'？"（2026-04-16）
- Dify 2026 缓存架构白皮书（2026-04-20）
- PPIO Prompt Cache 技术文档（2026-02-25）