语义缓存：降低LLM调用成本的核心技术

将生成式 AI 应用扩展到生产环境，会暴露出一个清晰的基础设施瓶颈：大型语言模型（LLM）那高昂的成本和以秒计的延迟。每次调用 Claude 或 GPT-4o 这类模型的 API，都会迫使模型从头开始计算一个全新响应，即使用户提交的是意图完全相同的查询。传统数据库依赖精确的字节级键值匹配，而 Bifrost——一个用 Go 编写的开源 AI 网关——则在语义层面来处理这个问题。通过理解 prompt 的底层含义，网关可以为那些结构不同但语义相同的请求提供服务。

为什么传统缓存对 LLM 失效

在经典软件开发中，缓存很简单。Redis 这类数据库使用精确匹配的哈希来将传入的请求负载与之前保存的响应进行匹配。这种逐字节的精确匹配缓存在 REST API 中表现出色，因为输入负载结构清晰且可预测。

然而，自然语言具有高度可变性。如果终端用户向客服机器人提问"如何退货？"和另一个人问"你能帮我开始退货流程吗？"，两者背后的意图其实是一致的。但由于原始字符串序列完全不同，精确匹配缓存会报告未命中。结果，两个查询都被路由到模型，产生了双倍的输入和输出令牌费用。对于对话式 AI 和 agentic 工作流，精确匹配缓存命中率历来很低（通常只有个位数），因为人类很少逐字重复一个查询。这种低效率导致了计算资源的浪费、应用响应变慢，以及 API 账单膨胀。

语义缓存的工作机制

语义缓存是一种基于查询的含义或意图来存储和检索响应的技术，而不是基于精确的文本匹配。它使用嵌入向量和向量相似度来识别相关查询，提高了 AI 和搜索系统中的缓存命中率和响应时间。

与标准键值查找不同，语义缓存通过多阶段向量管道处理查询。当应用提交请求时，缓存系统会将文本路由通过嵌入模型，转换成高维数学向量。这个向量封装了词语间的语义关系，使相似概念在向量空间中彼此接近。

一旦生成嵌入向量，网关会查询向量数据库来定位最近的邻居向量。使用距离度量（通常是余弦相似度或 L2 欧几里得距离）来计算查询向量与存储向量之间的距离。如果距离在预定义的相似度阈值内，系统就记录一次缓存命中，并立即返回存储的响应。

典型的查询执行管道遵循清晰的顺序：

• 向量化：系统将原始字符串查询转换为坐标向量（例如，OpenAI 模型的 1,536 维数组）。
• 近似最近邻（ANN）搜索：数据库执行向量搜索，找到位于相同概念区域的候选向量。
• 相似度验证：系统计算查询向量 $A$ 和存储的候选向量 $B$ 之间的精确余弦相似度：$$\text{Similarity}(A, B) = \frac{A \cdot B}{|A| |B|}$$
• 护栏评估：将相似度分数与相似度阈值进行匹配，阈值通常在 0.82 到 0.95 之间，取决于应用对轻微语义漂移的容忍度。
• 缓存返回或模型转发：分数高于阈值则返回缓存响应，而较低的分数则将请求转发给 LLM，并异步缓存新输出。

为了验证向量搜索的开销不会抵消缓存的速度优势，开发者可以运行本地基准测试来测量管道延迟。在重负载下，本地向量数据库查询耗时不到 2 毫秒，而完整 LLM 完成周期平均需要 1,500 毫秒。

以下是相似度计算过程的基本 Python 实现，展示了两个语义相近的查询如何产生高余弦相似度：

import numpy as np

def calculate_cosine_similarity(v1, v2):
    dot_product = np.dot(v1, v2)
    norm_v1 = np.linalg.norm(v1)
    norm_v2 = np.linalg.norm(v2)
    return dot_product / (norm_v1 * norm_v2)

# Simplified mock embeddings for two related prompts
# Prompt A: "What is your subscription cancellation policy?"
# Prompt B: "How do I cancel my monthly subscription plan?"
prompt_vector_a = np.array([0.15, 0.85, 0.23, 0.05])
prompt_vector_b = np.array([0.16, 0.82, 0.25, 0.04])

similarity_score = calculate_cosine_similarity(prompt_vector_a, prompt_vector_b)
print(f"Calculated Semantic Similarity: {similarity_score:.4f}")
# Output: Calculated Semantic Similarity: 0.9982

LLM 成本降低的真实成本数学

在企业部署中，LLM 成本优化是缓存基础设施的主要驱动力。为了对语义缓存的财务节省进行建模，假设一个中型生产应用每天处理 1,000,000 次查询。

假设以下标准基线配置：

• 平均输入 prompt 大小：1,200 tokens（包括系统指南、检索到的上下文和对话历史）
• 平均输出响应大小：300 tokens
• 模型定价（例如 Claude 3.5 Sonnet）：每百万输入 tokens 3.00 美元，每百万输出 tokens 15.00 美元
• 嵌入查询成本：每百万输入 tokens 0.02 美元
• 向量存储查询成本：可忽略（估计每 1,000 次查询 0.01 美元）

计算无缓存层时的每日运营成本：

每日输入成本：$1,000,000 \times 1,200 \times ($3.00 / 1,000,000) = $3,600$

每日输出成本：$1,000,000 \times 300 \times ($15.00 / 1,000,000) = $4,500$

每日总费用：$8,100每天（每月 $243,000）。

现在，集成一个语义缓存层。基于典型的企业使用日志，大约 35% 的生产查询与之前的 prompts 语义相似。通过缓存直接服务这些请求可避免调用昂贵的下游模型。

调整后的每日成本计算如下：

对于 65% 缓存未命中的查询（650,000 次请求）：

• LLM 输入成本：$650,000 \times 1,200 \times ($3.00 / 1,000,000) = $2,340$
• LLM 输出成本：$650,000 \times 300 \times ($15.00 / 1,000,000) = $2,925$

嵌入生成成本（应用于所有 1,000,000 次请求以检查相似度）：$1,000,000 \times 1,200 \times ($0.02 / 1,000,000) = $24$

向量数据库查询成本：可忽略（$10）。

每日总费用：$$2,340 + $2,925 + $24 + $10 = $5,299$ 每天（每月 $158,970）。

通过分流 35% 的请求，每日支出从 $8,100 降至 $5,299。这意味着运营费用减少了 34.6%，每月为组织节省 $84,030。除了财务收益外，350,000 次缓存查询在 10 毫秒内解决，显著改善了用户体验。

在网关层实现语义缓存

虽然开发者可以直接在应用内构建自定义缓存逻辑，但这种方法引入了紧耦合的代码、手动管理的数据库连接池和扩展复杂性。将缓存转移到中间代理是一种更为稳健的架构模式。

作为企业级解决方案，Bifrost 位于应用代码和 LLM 提供商之间的中央代理。通过在网关层运行，Bifrost 支持跨多个应用、SDK 和模型提供商的统一语义缓存，而无需修改代码。

网关使用混合缓存流程来优化性能：

• 精确哈希匹配：Bifrost 首先规范化输入查询，并使用快速哈希查找检查精确字节匹配。如果找到匹配，则立即提供服务，绕过嵌入生成阶段并降低成本。
• 语义匹配：在哈希未命中时，网关将查询路由到其 semantic_cache 插件，生成嵌入向量，并查询配置的向量存储以评估语义相似度。

因为 Bifrost 异步处理写入，主请求路径从不被阻塞。一旦缓存未命中从 LLM 提供商返回响应，网关就在后台将 prompt 和响应写入向量存储。

此外，Bifrost 提供内置弹性功能。如果下游向量存储遇到连接断开，网关激活自动回退，绕过缓存直接将查询路由到 LLM，确保应用零停机。为了管理多租户设置，管理员使用虚拟键来隔离缓存条目，防止跨租户数据泄露。对于高频企业流量，Bifrost 支持集群化以跨多个节点扩展缓存处理。

在 Bifrost 中设置语义缓存只需要对网关的 config.json 配置文件进行少量编辑，以下是部署 Redis 向量存储的示例配置：

{
  "plugins": {
    "semanticCache": {
      "enabled": true,
      "version": 1,
      "config": {
        "provider": "openai",
        "embedding_model": "text-embedding-3-small",
        "threshold": 0.85,
        "ttl": 86400,
        "vector_store": {
          "type": "redis",
          "address": "localhost:6379",
          "db": 0
        }
      }
    }
  }
}

管理权衡：阈值、淘汰与正确性

在生产环境中运行语义缓存会引入独特的权衡。与传统确定性缓存不同，语义评估是概率性的，这意味着工程师必须管理速度与精度之间的平衡。

需要管理的主要变量是相似度阈值。阈值设置过低会提高缓存命中率，但会增加误报风险——返回的缓存响应不能准确回答一个略有不同的查询。例如，"这个服务免费吗？"和"这个服务安全吗？"共享重叠的词汇，但核心含义完全不同。相反，阈值设置过高确保了精度，但降低了整体命中率，将冗余查询路由到 LLM。

新鲜度是另一个关键的生产问题。当底层业务逻辑变更时，必须淘汰缓存数据。团队可以通过在向量记录上定义严格的有效期（TTL）或通过网关 API 触发手动淘汰命令来处理这个问题。

最后，安全策略必须像对待实时 LLM 响应一样一致地应用于缓存数据。采用统一平台可确保缓存策略、访问控制和护栏在整个组织中一致应用。除了网关级治理和安全控制外，Bifrost Edge 还将这些相同的治理和安全保护扩展到端点。Bifrost Edge 目前处于早期访问 alpha 阶段，它提供强大的端点安全性，防止未经授权的本地访问并管理用户与本地桌面应用和基于浏览器的 AI 助手之间的交互。为了保持企业合规性，所有缓存的事务都被捕获在不可变的网关审计日志中。

随着生成式 AI 应用从原型扩展到生产，管理资源约束成为一个主要的运营优先事项。语义缓存通过将优化从模型层转移到网关层来解决这一挑战，用亚毫秒级向量查找替代重复的推理。通过集中部署这一层，组织可以期待 LLM API 费用的立即减少和明显的延迟改善。