LLM 推理 · 语义缓存与路由

大模型部署服务语义缓存与路由详解：
不换模型，把推理成本砍掉一大半

缓存消灭「重复的问题」，路由消灭「错配的模型」——三层叠加的降本标准组合拳

大模型推理的账单里，有相当一部分钱是「重复支付的」：用户用不同措辞问同一个问题，模型把几乎一样的计算重跑一遍；简单问题也被送进最贵的旗舰模型，杀鸡用牛刀。

两个技术分别解决这两个问题：

  1. 语义缓存（Semantic Cache）：把「相似提问 → 已有答案」直接复用，命中时以亚毫秒级返回，API 成本可降 60%~88%（GPTCache 官方口径是成本降 10 倍、速度提 100 倍）
  2. 语义路由（Semantic Router）：按问题难度把请求分流到强弱模型，RouteLLM 在保持 95% 性能的同时，可节省最高 85% 的调用成本

更妙的是两者天然互补：请求进来先查缓存，命中直接返回；未命中才交给路由器决策走哪个模型。缓存 + 路由 + 前缀缓存三层叠加，是把推理成本砍掉一大半的标准组合拳。

四种缓存

一、先分清四种「缓存」：它们根本不是一个东西

提到「大模型缓存」，至少有四个层级，很多讨论把它们混为一谈：

层级名称缓存什么解决什么代表实现
引擎内KV Cache自回归生成中每层每头的 K/V 张量避免第 n 个 token 重算前 n-1 个 token（否则 O(n²)）所有推理引擎默认
跨请求Prefix Cache（前缀缓存）相同输入前缀的计算结果多请求共享前缀（如 System Prompt）时免重复计算vLLM Automatic Prefix Caching、SGLang RadixAttention
产品化Prompt Cache（上下文缓存）服务商把前缀缓存封装成 API 特性用户侧按缓存命中付费，无需改推理引擎OpenAI/Anthropic、火山方舟上下文缓存
应用层Semantic Cache（语义缓存）相似提问的完整响应语义级复用，连「措辞不同」都算命中GPTCache、Redis+向量插件

一句话区分：KV Cache 是引擎的事，前缀缓存是跨请求的事，语义缓存是应用层的事。本文的主角是语义缓存与语义路由，但四层常常协同部署。

语义缓存

二、语义缓存：把「相似问题」变成「同一个问题」

1. 核心原理：向量化 + 相似度阈值

语义缓存与 Redis 精确匹配缓存的本质区别：它缓存的键不是字符串，而是语义。流程如下：

用户请求 → 嵌入模型向量化 → 在缓存库中做向量相似度搜索
    → 最高相似度 ≥ 阈值？→ 命中：直接返回缓存响应（亚毫秒级延迟）
    → 未命中：调用 LLM API → 响应写入缓存 → 返回用户

两个关键参数决定成败：

2. 能省多少？

3. 主流实现怎么选

方案特点适合
GPTCache开源、可自定义嵌入函数/相似度评估/存储/逐出策略需自主控制的团队
Redis + 向量插件复用现有基础设施，运维简单已有 Redis 集群的团队
Milvus/Qdrant + 自研专业向量库，性能与规模最优大规模高并发场景
托管/开箱即用零配置内置语义缓存想快速验证效果的团队

4. 适用边界：哪里该用、哪里千万别用

语义路由

三、语义路由：让每个问题「买对档位的票」

1. 路由问题的本质

所有请求都打旗舰模型，等于让每个乘客都坐头等舱。语义路由在应用层前置一个「决策器」，把请求按难度/类型分流：

用户请求 → 路由器判断 → 简单问题 → 便宜的小模型（快、省）
                        → 复杂问题 → 强模型（保质量）

注意与两个易混概念区分：它不是 API 网关（不做鉴权限流），也不是 MoE 内部的专家路由（那是模型内部的 token 级调度）。语义路由是系统级、请求级的模型选择。

2. 三大主流实现

方案机制特点
RouteLLM（lmsys）基于 Chatbot Arena 8 万条人类偏好数据，训练 4 种轻量路由器（矩阵分解/相似度加权等）保持 95% 性能下最高省 85% 成本；OpenAI 兼容接口，改动最小
Semantic Router（aurelio-labs）纯语义向量空间决策，不等待 LLM 生成决策速度快 100 倍以上，零训练门槛
vLLM Semantic Router推理层内的可编程 MoM（Mixture-of-Models）路由控制层与推理引擎深度集成，延迟最优

此外还有 xrouter-llm 等新思路：不训练「prompt → 模型」直接映射，而是训练「prompt + 模型 → 完成概率」预测器，再结合成本做决策。

3. 生产落地的四个必修课

  1. 路由信号：难度（最主流）、任务类型、预算、延迟 SLA，都可作为分流依据
  2. 评估闭环：路由是「预测」，必须用真实流量评估命中质量，用离线数据集持续回归
  3. 回退策略：弱模型输出不合格时自动升级强模型，保住底线质量
  4. 成本预算：按总预算动态调整阈值——预算越紧，分流到小模型的比例越高

4. 路由不是万能药

一句话要记住：路由器解决不了底层模型弱的问题。如果可用的模型池整体能力不足，路由再聪明也只是「把菜分得更精致」。路由的价值前提是——你的模型池里既有贵的强者，也有够用的便宜货。

协同架构

四、缓存 + 路由的协同架构：标准链路

把两层叠加，就是当下最主流的降本架构（有案例叠加后降本 50%，配合前缀缓存可达 60%~88%）：

用户请求
   ↓
语义缓存（向量相似度 ≥ 阈值？）
   ├─ 命中 → 直接返回缓存响应（0 API 调用，亚毫秒）
   └─ 未命中 → 语义路由（难度判断）
                 ├─ 简单 → 小模型 → 响应回填缓存
                 └─ 复杂 → 强模型 → 响应回填缓存
                      ↓
              调用层再叠加「上下文缓存/前缀缓存」→ 重复前缀免计算

三层各管一段：语义缓存消灭「重复的问题」、语义路由消灭「错配的模型」、前缀缓存消灭「重复的前缀」。

前缀与上下文缓存

五、前缀缓存与上下文缓存：服务商侧的「免费午餐」

语义缓存是你自己搭的，而前缀缓存是推理层自动送你的：

这里有个容易被忽略的细节：缓存红利跟「接入点」强相关。缓存本质是共享的，公共接入点人多手杂、缓存被频繁挤占淘汰，你的命中率就上不去；独享接入点 + 缓存隔离，才能把命中红利稳定吃进自己口袋——这也是向量云「缓存隔离降本」的设计初衷。

落地要点

六、落地设计要点（八条）

  1. 先量化再动手：统计请求的语义重复率与难度分布，重复率低/难度单一的业务，缓存和路由都省不了钱
  2. 阈值用数据说话：相似度阈值 0.9~0.95 起步，用历史数据回测命中率与误命中率，取成本-质量平衡点
  3. 缓存分层不贪心：热点问答走语义缓存，长上下文走前缀缓存，四层缓存各归其位
  4. 嵌入模型别省错地方：嵌入模型太差，语义判断直接失真；它便宜，选好一点的值
  5. 路由必须配评估：离线回归集 + 线上 A/B，监控「误路由率」与「弱模型升级率」
  6. 兜底策略写死：缓存未命中、路由超时、弱模型翻车，全链路要有降级路径
  7. 失效机制要主动：涉及实时信息的缓存设置 TTL，知识更新时主动失效相关条目
  8. 接入点隔离拿红利：用独享接入点 + 缓存隔离，避免公共池挤占把你的缓存命中率稀释掉
总结

七、写在最后

语义缓存与语义路由的迷人之处在于：它们不碰模型、不换硬件，只靠「少算」和「算对」就把成本砍下来。对大模型应用团队来说，这是投入产出比最高的优化之一——但前提是阈值调对、评估闭环、兜底齐全，否则省下的钱会变成用户投诉。

关于向量云：缓存红利，交给平台帮你锁死

语义缓存需要向量库、嵌入模型、阈值调优、失效机制；语义路由需要路由模型、评估体系、回退策略——每一项都是持续的工程投入。向量云（向量云南京科技有限公司）依托字节跳动火山方舟官方授权，把这些机制产品化打包：

向量云能力说明
官方授权接入火山方舟官方授权，提供官方 API 与官方 Key
低折扣 Token专属折扣价，用量越大越划算
独享接入点独立接入点，缓存不被公共池挤占，命中红利稳定落袋
缓存隔离降本缓存隔离机制 + 官方上下文缓存，重复请求近乎免费
计费灵活按量计费、即用即扣、不设账期，注册充值 10 元起
协议兼容OpenAI 兼容协议，业务代码几乎零改动

接入方式：注册后获取官方 API Key，把 base_url 指向向量云接入点即可直接调用火山方舟官方模型——语义缓存与路由的工程复杂性交给平台，降本红利留给你的业务。

获取 API Key：https://ark.tokenrize.cn/ · 火山方舟官方 API 与 Key 直连，注册即用

一句话总结：缓存消灭重复的问题，路由消灭错配的模型，前缀缓存消灭重复的前缀——三层叠加，就是大模型推理降本的确定性答案。

关于向量云
向量云（南京）科技有限公司

面向大模型应用落地的技术服务型企业，依托字节跳动火山方舟能力，为合作方提供低折扣模型 Token、可独立部署的运营支撑平台及全链路运营支持。

火山方舟官方授权 官方 API Key 独享接入点 缓存隔离降本 低折扣 Token 即用即扣 · 不设账期

向量云（南京）科技有限公司

火山方舟官方 API · 独享接入点 · 低折扣 Token · 缓存红利最大化

获取 API Key：https://ark.tokenrize.cn/

常见问题（FAQ）

火山方舟官方 API 与官方 Key 直连 · 向量云 · 大模型部署降本

Q1. 大模型服务里的「四种缓存」分别是什么？

A. ① KV Cache：推理引擎内部缓存每层每头的 K/V 张量，让自回归生成只做增量计算，避免 O(n²) 重算；② Prefix Cache（前缀缓存）：跨请求复用相同输入前缀的计算结果，代表是 vLLM Automatic Prefix Caching、SGLang RadixAttention；③ Prompt Cache（上下文缓存）：服务商把前缀缓存产品化后的 API 特性，如 OpenAI/Anthropic、火山方舟上下文缓存；④ Semantic Cache（语义缓存）：应用层缓存相似提问的完整响应，连「措辞不同」都算命中。简单记：KV Cache 是引擎的事，前缀缓存是跨请求的事，语义缓存是应用层的事。

Q2. 语义缓存的原理是什么？能省多少钱？

A. 原理：用户请求先经嵌入模型向量化，再到缓存库做向量相似度搜索；最高相似度 ≥ 阈值（常见 0.9~0.95 起步）则直接返回缓存响应（亚毫秒级），否则调用 LLM 并把响应写回缓存。效果：GPTCache 官方口径成本降 10 倍、速度提 100 倍；通用办公场景可削减约三成无效 Token 消耗；客服/问答等高频相似场景 60%~88% 降本案例不罕见。关键参数是嵌入模型质量与相似度阈值——太低误命中、太高命中率上不去。

Q3. 语义缓存哪些场景适合、哪些不适合？

A. 适合：FAQ 客服、知识问答、模板化生成、相似度高的重复请求。慎用：答案依赖实时数据（股价/新闻/库存）、个性化强、开放式创作——误命中旧答案会伤害用户信任。此外实时信息类缓存要设 TTL，知识更新时要主动失效相关条目。

Q4. 什么是语义路由？有哪些主流实现？

A. 语义路由是系统级、请求级的模型选择器：简单问题分流到便宜的小模型，复杂问题走强模型。它既不是 API 网关（不做鉴权限流），也不是 MoE 内部的专家路由（token 级调度）。三大实现：RouteLLM（lmsys，基于 Chatbot Arena 8 万条人类偏好训练 4 种轻量路由器，保持 95% 性能下最高省 85% 成本，OpenAI 兼容）；Semantic Router（aurelio-labs，纯语义向量决策，速度快 100 倍以上）；vLLM Semantic Router（推理层可编程 MoM 控制层）。

Q5. 语义路由生产落地要注意什么？

A. 四个必修课：① 路由信号——难度（最主流）、任务类型、预算、延迟 SLA；② 评估闭环——用真实流量评估命中质量，离线数据集持续回归；③ 回退策略——弱模型输出不合格自动升级强模型，保住底线质量；④ 成本预算——按总预算动态调整阈值。另外要认清边界：路由器解决不了底层模型弱的问题，路由的价值前提是模型池里既有贵的强者、也有够用的便宜货。

Q6. 缓存和路由怎么协同工作？

A. 标准链路：请求先进语义缓存（命中即亚毫秒返回，0 API 调用）；未命中再进语义路由（简单走小模型、复杂走强模型），响应回填缓存；调用层再叠加前缀缓存/上下文缓存，重复前缀免计算。三层各管一段：语义缓存消灭「重复的问题」、语义路由消灭「错配的模型」、前缀缓存消灭「重复的前缀」。叠加后降本 50%，配合前缀缓存可达 60%~88%。

Q7. 火山方舟的上下文缓存怎么用？缓存红利会被稀释吗？

A. 火山方舟上下文缓存有两种模式：隐式缓存（系统自动基于公共前缀缓存复用）与显式缓存（手动指定复用片段），但官方明确「不保证命中」——缓存容量有限、旧缓存可能被淘汰。关键细节：缓存红利与接入点强相关。公共接入点人多手杂，缓存被频繁挤占，你的命中率就上不去；独享接入点 + 缓存隔离才能把命中红利稳定落袋。向量云提供火山方舟官方授权接入：官方 API 与官方 Key、低折扣 Token、独享接入点、缓存隔离降本、按量计费即用即扣（充值 10 元起）、OpenAI 兼容协议几乎零改动。获取 API Key：https://ark.tokenrize.cn/