PromptCache：让 LLM 应用省下 80% 成本的智能语义缓存

PromptCache 架构演示

图1：PromptCache 工作流程示意

一、痛点场景：一个 RAG 助手背后的隐形成本

想象你开发了一款企业内部 RAG 助手，上线后每天处理员工的各种查询。运营三个月后，你打开账单发现：LLM API 费用是预期的三倍。

问题出在哪里？仔细看日志后发现了规律——员工反复问同一类问题，只是措辞略有不同：

"如何申请年假？"
"年假要怎么申请？"
"请告诉我申请年假的流程"

这三条在语义上完全等价，但传统字符串缓存根本识别不出来。AI 应用中有大量这样的"隐性重复请求"，据项目作者调查，这类请求在实际生产环境中占比往往超过 30%。

传统的解决方案是加一层内存缓存，但关键词匹配无法处理同义不同词的表达方式。

PromptCache 就是来解决这个问题的——它是一个专门为 LLM 应用设计的语义缓存层，部署在你的应用和 LLM API 之间，通过理解语义来判断当前请求是否可以用历史答案来回答。

二、项目背景：一个人从痛点出发的工程实践

PromptCache 由独立开发者 messkan 开发，首个版本发布于 2025 年 11 月。从 GitHub 提交记录来看，作者在真实生产环境中遇到了 RAG 应用的 API 成本问题后，决定用 Go 从头实现一个专门的语义缓存方案。

作者在 Medium 上详细讲述了开发动机：

"Same intent → same answer → but three full OpenAI calls."

这个项目选择了 Go 语言而不是更常见的 Python，主要出于三点考量：

性能优先：语义缓存追求低延迟，Go 的并发模型和接近 C 的执行效率适合这类 I/O 密集型中间件
部署简单：Go 编译成单一静态二进制，配合 Docker 可以零依赖运行
BadgerDB 原生支持：BadgerDB 是纯 Go 编写的嵌入式 KV 数据库，和 Go 项目集成零摩擦

项目已发布 4 个正式版本（v0.1.0 ~ v0.4.0），最新版本为 2026 年 4 月的 v0.4.0，正在向 v1.0.0 迈进。

三、核心原理：三层语义匹配策略

PromptCache 的核心技术是语义相似度匹配，但其设计亮点在于三层安全策略，避免"语义接近但意图不同"导致的错误命中。

第一层：向量相似度初筛

每个请求的 prompt 会被转换为高维向量（通过 OpenAI text-embedding-3-small / Mistral embed / Voyage-3 等 embedding 模型），存入 ANN（Approximate Nearest Neighbor）索引。

当新请求到达时，计算其向量与缓存中所有条目的余弦相似度，取最高分。

Benchmark 数据（项目内置测试）：

BenchmarkCosineSimilarity-12    2593046    441.0 ns/op
BenchmarkFindSimilar-12           50000   32000 ns/op  2048 B/op

单次相似度计算仅需 441 纳秒，FindSimilar 约 32 微秒，完全在毫秒级以内。

第二层：双阈值过滤

项目设计了高/低两个可配置阈值：

高阈值（默认 0.70）：相似度 ≥ 此值，直接返回缓存结果，不触发任何额外调用
低阈值（默认 0.30）：相似度 < 此值，直接跳过缓存，转发给 LLM
灰度区（高阈值 ~ 低阈值之间）：进入第三层验证

第三层：LLM 意图校验

这是项目最有价值的设计——当相似度落在灰度区时，系统会调用一个小型便宜的 LLM（默认 gpt-4o-mini 或 haiku）问一个简单问题：

"Do these two prompts ask for the same thing?"

这个设计解决了语义缓存的核心风险：两句话可能表面相似但意图不同。例如：

"怎么删除我的账号？"
"怎么删除别人的账号？" 向量相似度可能很高，但意图完全不同。小模型验证后就能安全地拒绝缓存命中。

四、技术架构：模块化的 Go 中间件设计

项目采用 Go 1.24+，整体代码组织清晰，分为以下核心模块：

模块	文件	职责
cmd/api	main.go	入口，HTTP 服务器
internal/semantic	semantic.go, providers.go	语义匹配核心，embedding provider 抽象
internal/ann	ann.go	ANN 近似最近邻索引
internal/cache	cache.go	LRU 缓存逻辑
internal/storage	badger.go	BadgerDB 持久化存储
internal/http	client.go	上游 LLM API 调用
internal/middleware	middleware.go	认证、中间件逻辑
internal/metrics	metrics.go	Prometheus 指标暴露
internal/logging	logger.go	结构化 JSON 日志

关键设计决策：

ANN 索引：v0.3.0 引入，将向量搜索性能提升约 5 倍，从 O(n) 降为对数级
BadgerDB 持久化：所有缓存数据（prompt 向量 + 原始 response）存入嵌入式 KV 数据库，支持 LRU 驱逐策略防止无限膨胀
多 Provider 抽象：embedding 和 verification model 均可切换（OpenAI / Mistral / Claude + Voyage），通过环境变量或运行时 API 配置
OpenAI 兼容 API：实现了 /v1/chat/completions 接口，应用侧只需改 base_url，零代码改造

支持的运行环境：

Go 1.24+ 直接编译运行
Docker 单容器
Docker Compose（推荐，带持久化 volume）

不支持 GPU，无需额外硬件，普通云服务器即可运行。

五、使用体验：零改造接入的实测

对于已有 OpenAI SDK 应用，接入 PromptCache 只需要改一行代码：

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8080/v1",  # 之前是 https://api.openai.com/v1
    api_key="your-openai-api-key"
)

# 后续所有 API 调用无需任何改动
client.chat.completions.create(model="gpt-4", messages=[...])

这是项目最有价值的设计理念——drop-in replacement。LangChain、LlamaIndex 等主流框架也原生支持自定义 base_url，接入无压力。

v0.4.0 还新增了 Streaming SSE 支持，缓存命中时自动将 response 组装成 OpenAI SSE 格式返回，streaming 客户端完全透明。

实测性能数据（官方 benchmark）：

指标	无缓存	有 PromptCache	提升
每1000请求成本	~$30	~$6	-80%
平均延迟	~1.5s	~300ms	-80%
吞吐量	受 API 限制	无限	取决于本地硬件

六、局限与风险

PromptCache 并非银弹，以下场景需要注意：

Embedding 成本仍存在：每次新的 prompt 都要调用 embedding API产生费用。如果缓存命中率不高，总体成本可能反而上升。
实时性要求高的场景不适用：缓存数据默认持久化在 BadgerDB 中，如果业务要求答案必须反映最新数据（比如实时股价），缓存需要配合 TTL 策略使用。
向量模型依赖：项目的匹配质量直接取决于 embedding 模型的质量，选择不当会导致误命中或漏命中。
中文语义支持：主流 embedding 模型（text-embedding-3-small）对中文的语义理解能力和英文有差异，生产部署前建议用实际业务数据做命中率测试。
单节点架构：v1.0.0 之前暂无集群支持，高并发场景下需评估单节点性能上限。

七、竞争格局与行业意义

语义缓存并非 PromptCache 独占，同类项目包括：

GPTCache（Zilliz，开源）：支持 LangChain/LlamaIndex 集成，功能更丰富但资源占用更高
Redis Semantic Cache（Azure）：云托管方案，适合不想自运维的团队
各云厂商 AI Gateway 内置方案：AWS Bedrock、Google Vertex AI 等也提供类似能力

PromptCache 的差异化定位是：轻量、Go 编写、零依赖、单二进制部署。相比 GPTCache 的 Python 全家桶，PromptCache 在资源占用和部署便捷性上有明显优势。

从 GitHub topics 可以看出，这个项目同时贴了 llm, cost-optimization, rag, llmops 等多个标签，说明它处于 LLM 应用运维（LLMOps）工具链的核心位置。随着 RAG 和 AI Agent 的普及，语义缓存作为降低 LLM API 成本的基础设施，价值会持续凸显。

本文档基于 GitHub 开源项目 messkan/prompt-cache 生成，分析版本：v0.4.0，发布时间：2026-04-24

PromptCache：让 LLM 应用省下 80% 成本的智能语义缓存

PromptCache 架构演示

图1：PromptCache 工作流程示意

一、痛点场景：一个 RAG 助手背后的隐形成本

想象你开发了一款企业内部 RAG 助手，上线后每天处理员工的各种查询。运营三个月后，你打开账单发现：LLM API 费用是预期的三倍。

问题出在哪里？仔细看日志后发现了规律——员工反复问同一类问题，只是措辞略有不同：

"如何申请年假？"
"年假要怎么申请？"
"请告诉我申请年假的流程"

传统的解决方案是加一层内存缓存，但关键词匹配无法处理同义不同词的表达方式。

二、项目背景：一个人从痛点出发的工程实践

作者在 Medium 上详细讲述了开发动机：

"Same intent → same answer → but three full OpenAI calls."

这个项目选择了 Go 语言而不是更常见的 Python，主要出于三点考量：

性能优先：语义缓存追求低延迟，Go 的并发模型和接近 C 的执行效率适合这类 I/O 密集型中间件
部署简单：Go 编译成单一静态二进制，配合 Docker 可以零依赖运行
BadgerDB 原生支持：BadgerDB 是纯 Go 编写的嵌入式 KV 数据库，和 Go 项目集成零摩擦

项目已发布 4 个正式版本（v0.1.0 ~ v0.4.0），最新版本为 2026 年 4 月的 v0.4.0，正在向 v1.0.0 迈进。

三、核心原理：三层语义匹配策略

PromptCache 的核心技术是语义相似度匹配，但其设计亮点在于三层安全策略，避免"语义接近但意图不同"导致的错误命中。

第一层：向量相似度初筛

每个请求的 prompt 会被转换为高维向量（通过 OpenAI text-embedding-3-small / Mistral embed / Voyage-3 等 embedding 模型），存入 ANN（Approximate Nearest Neighbor）索引。

当新请求到达时，计算其向量与缓存中所有条目的余弦相似度，取最高分。

Benchmark 数据（项目内置测试）：

BenchmarkCosineSimilarity-12    2593046    441.0 ns/op
BenchmarkFindSimilar-12           50000   32000 ns/op  2048 B/op

单次相似度计算仅需 441 纳秒，FindSimilar 约 32 微秒，完全在毫秒级以内。

第二层：双阈值过滤

项目设计了高/低两个可配置阈值：

高阈值（默认 0.70）：相似度 ≥ 此值，直接返回缓存结果，不触发任何额外调用
低阈值（默认 0.30）：相似度 < 此值，直接跳过缓存，转发给 LLM
灰度区（高阈值 ~ 低阈值之间）：进入第三层验证

第三层：LLM 意图校验

这是项目最有价值的设计——当相似度落在灰度区时，系统会调用一个小型便宜的 LLM（默认 gpt-4o-mini 或 haiku）问一个简单问题：

"Do these two prompts ask for the same thing?"

这个设计解决了语义缓存的核心风险：两句话可能表面相似但意图不同。例如：

"怎么删除我的账号？"
"怎么删除别人的账号？" 向量相似度可能很高，但意图完全不同。小模型验证后就能安全地拒绝缓存命中。

四、技术架构：模块化的 Go 中间件设计

项目采用 Go 1.24+，整体代码组织清晰，分为以下核心模块：

模块	文件	职责
cmd/api	main.go	入口，HTTP 服务器
internal/semantic	semantic.go, providers.go	语义匹配核心，embedding provider 抽象
internal/ann	ann.go	ANN 近似最近邻索引
internal/cache	cache.go	LRU 缓存逻辑
internal/storage	badger.go	BadgerDB 持久化存储
internal/http	client.go	上游 LLM API 调用
internal/middleware	middleware.go	认证、中间件逻辑
internal/metrics	metrics.go	Prometheus 指标暴露
internal/logging	logger.go	结构化 JSON 日志

关键设计决策：

ANN 索引：v0.3.0 引入，将向量搜索性能提升约 5 倍，从 O(n) 降为对数级
BadgerDB 持久化：所有缓存数据（prompt 向量 + 原始 response）存入嵌入式 KV 数据库，支持 LRU 驱逐策略防止无限膨胀
多 Provider 抽象：embedding 和 verification model 均可切换（OpenAI / Mistral / Claude + Voyage），通过环境变量或运行时 API 配置
OpenAI 兼容 API：实现了 /v1/chat/completions 接口，应用侧只需改 base_url，零代码改造

支持的运行环境：

Go 1.24+ 直接编译运行
Docker 单容器
Docker Compose（推荐，带持久化 volume）

不支持 GPU，无需额外硬件，普通云服务器即可运行。

五、使用体验：零改造接入的实测

对于已有 OpenAI SDK 应用，接入 PromptCache 只需要改一行代码：

from openai import OpenAI

client = OpenAI(
    base_url="http://localhost:8080/v1",  # 之前是 https://api.openai.com/v1
    api_key="your-openai-api-key"
)

# 后续所有 API 调用无需任何改动
client.chat.completions.create(model="gpt-4", messages=[...])

这是项目最有价值的设计理念——drop-in replacement。LangChain、LlamaIndex 等主流框架也原生支持自定义 base_url，接入无压力。

v0.4.0 还新增了 Streaming SSE 支持，缓存命中时自动将 response 组装成 OpenAI SSE 格式返回，streaming 客户端完全透明。

实测性能数据（官方 benchmark）：

指标	无缓存	有 PromptCache	提升
每1000请求成本	~$30	~$6	-80%
平均延迟	~1.5s	~300ms	-80%
吞吐量	受 API 限制	无限	取决于本地硬件

六、局限与风险

PromptCache 并非银弹，以下场景需要注意：

Embedding 成本仍存在：每次新的 prompt 都要调用 embedding API产生费用。如果缓存命中率不高，总体成本可能反而上升。
实时性要求高的场景不适用：缓存数据默认持久化在 BadgerDB 中，如果业务要求答案必须反映最新数据（比如实时股价），缓存需要配合 TTL 策略使用。
向量模型依赖：项目的匹配质量直接取决于 embedding 模型的质量，选择不当会导致误命中或漏命中。
中文语义支持：主流 embedding 模型（text-embedding-3-small）对中文的语义理解能力和英文有差异，生产部署前建议用实际业务数据做命中率测试。
单节点架构：v1.0.0 之前暂无集群支持，高并发场景下需评估单节点性能上限。

七、竞争格局与行业意义

语义缓存并非 PromptCache 独占，同类项目包括：

GPTCache（Zilliz，开源）：支持 LangChain/LlamaIndex 集成，功能更丰富但资源占用更高
Redis Semantic Cache（Azure）：云托管方案，适合不想自运维的团队
各云厂商 AI Gateway 内置方案：AWS Bedrock、Google Vertex AI 等也提供类似能力

PromptCache 的差异化定位是：轻量、Go 编写、零依赖、单二进制部署。相比 GPTCache 的 Python 全家桶，PromptCache 在资源占用和部署便捷性上有明显优势。

本文档基于 GitHub 开源项目 messkan/prompt-cache 生成，分析版本：v0.4.0，发布时间：2026-04-24

prompt-cache

社区活跃度

PromptCache：让 LLM 应用省下 80% 成本的智能语义缓存

一、痛点场景：一个 RAG 助手背后的隐形成本

二、项目背景：一个人从痛点出发的工程实践

三、核心原理：三层语义匹配策略

第一层：向量相似度初筛

第二层：双阈值过滤

第三层：LLM 意图校验

四、技术架构：模块化的 Go 中间件设计

五、使用体验：零改造接入的实测

六、局限与风险

七、竞争格局与行业意义

社区活跃度

PromptCache：让 LLM 应用省下 80% 成本的智能语义缓存

一、痛点场景：一个 RAG 助手背后的隐形成本

二、项目背景：一个人从痛点出发的工程实践

三、核心原理：三层语义匹配策略

第一层：向量相似度初筛

第二层：双阈值过滤

第三层：LLM 意图校验

四、技术架构：模块化的 Go 中间件设计

五、使用体验：零改造接入的实测

六、局限与风险

七、竞争格局与行业意义