1.3 缓存与路由在降本中的角色定位

1.3 缓存与路由的定位：它们在降本里到底扮演什么角色

读完这一节，你应该能画出一张「降本全景图」，并清楚地指出来：「缓存负责把重复的请求挡在模型门外，路由负责把对的请求送进对的模型——两者一横一纵，合起来才构成完整的成本治理骨架。」

前两节我们搞清楚了「钱花在哪」（1.1 的计费模型）和「先砍哪类」（1.2 的 Top10 画像）。这一节要做的是升维：把「请求缓存」和「智能路由」放到一张完整的降本地图里，说清它们各自管什么、怎么配合、边界在哪。很多团队把缓存和路由当成两个孤立的「功能」去堆，结果要么重复建设、要么相互打架。本节给它们一个清晰的角色分工，也为第二章动手搭建奠定认知地基。

一、降本全景：四道防线，缓存与路由在其中

回到 1.1 的成本公式 成本 = Q × T × P。所有降本手段，本质上都是在「量 Q、Token 数 T、单价 P」这三个旋钮上做文章。把它们铺开，就是一张分层的「降本防线」图：

可以看到：

• 缓存（第 1 道） 作用于「量 Q」——相同/相似请求不再真正进入模型，直接从缓存返回。它的杠杆在于「一次计算、多次复用」。
• 路由（第 2 道） 作用于「单价 P」和「量 Q」——把简单请求送进便宜的小模型，只把复杂请求留给贵的大模型，相当于「按请求难度动态选价」。
• 第 3、4 道（压缩与选型）是更细的工程优化，本章先埋概念，后续章节展开。

一句话记忆：缓存挡重复，路由分难度，压缩降长度，选型降单价。

二、缓存的角色：系统的「记忆」，而不是「优化技巧」

很多人把缓存理解成「一个能省点钱的小开关」，这是低估了它。更准确的定位是：缓存是 AI 系统的「记忆层」。人类回答问题会依赖记忆，不会每件事都重新推理一遍；一个成熟的 LLM 系统也应该如此。

缓存有两种基本形态，它们的角色略有不同：

• 精确缓存（Exact Cache）：完全相同的请求（逐 Token 一致）直接命中。角色是「去重器」，挡掉刷新、重试、重复任务这类 100% 相同的流量。成本几乎为零，命中即全免。
• 语义缓存（Semantic Cache）：语义相近的请求（「怎么退款」和「退款流程是啥」）也判定为命中。角色是「近似记忆」，覆盖更宽，但需要一个向量相似度判定环节，本身有少量开销。

把缓存当「记忆层」而非「技巧」的关键含义是：它的命中率需要被当作系统的一级指标持续观测（类似缓存系统的命中率/失效率），而不是上线后就再也不看。第三章我们会专门建模「命中率↔成本」的关系。

三、路由的角色：系统的「调度员」，而非「分流开关」

路由的角色定位同样要拔高一层：它是 AI 系统的「调度员」，负责在请求真正执行前，判断「这件事该交给谁做」。一个只会「全扔给大模型」的系统，就像一家公司把所有邮件都让 CEO 亲自回——贵且慢。

智能路由通常依据几个维度做决策：

• 复杂度：问题是否简单、模板化？简单就降级。
• 风险/敏感度：涉及合规、金钱、人身安全的，必须大模型+强约束。
• 延迟要求：实时对话要快（可能用轻模型），离线批处理可以慢（用便宜批价）。
• 成本预算：当前预算余量紧张时，整体偏保守路由。

注意路由和缓存是协作关系：请求先过缓存（命中就直接返回，连路由都不需要），未命中才进路由。这顺序很重要——路由本身也有开销（分类模型调用、向量计算），让缓存先挡一道，能顺带省下路由的开销。

四、缓存与路由的配合：一横一纵，别让它们打架

把两者放到一起，它们构成一张「横纵治理网」：

• 横向（缓存）：同一类请求，跨时间复用。今天问的「退款流程」，明天别人问直接命中。
• 纵向（路由）：不同类请求，跨难度分配。贵的留给大模型，便宜的走小模型。

最理想的状态是「缓存先横挡、路由再纵分」，但题目里提到的「智能路由策略」往往还包含一层：路由决策本身也能被缓存。例如「某类问题恒走小模型」这个判断，不需要每次重新分类，可以直接缓存路由结果。这就形成了双层缓存：一层挡内容，一层挡决策。

五、边界与反模式：什么时候「不该」用缓存/路由

负责任的作者会告诉你边界在哪。以下场景要谨慎：

• 高频变化的内容别缓存：如实时股价、当日新闻。缓存会返回过期答案，得不偿失。这类该用「短 TTL（生存时间）」或干脆不缓存。
• 强一致性要求别用语义缓存：医疗、法律结论若被近似命中返回错误版本，后果严重。精确缓存 + 人工审核更稳妥。
• 路由别过度细分：给每类请求都单独训一个分类器，维护成本爆炸。先用「大模型 vs 小模型」两档，足够覆盖大部分收益。
• 别用缓存掩盖架构问题：如果 80% 流量都是重复「重试」，先解决重试逻辑，而不是用缓存把问题藏起来。

六、今天就该预埋的「架构钩子」

基础章收尾前，给动手派一个清单——这些钩子现在埋下去，第二章搭缓存层、第四章做案例时直接能用：

1. 统一请求入口（Gateway）：所有 LLM 调用必须经过一个中间层，缓存和路由才有「插桩点」。散落在各处直连模型的代码，是降本的最大障碍。
2. 请求指纹生成器：把「原始文本」规范成「可聚类指纹」（去空白、归一化、提取意图），为缓存键和画像服务。
3. 可替换的模型后端：路由要能切换不同 model，后端接口必须抽象成统一契约。
4. 全链路埋点：每次调用记录「缓存命中? 走哪个模型? Token 多少? 耗时多少?」，这是所有优化的度量基础（呼应 1.2）。
5. 降级开关：路由失败时能安全回退到大模型，保证正确性优先于省钱。

七、怎么度量缓存与路由是否奏效：一组看板指标

埋了钩子（见第六节）之后，你需要一组指标来判断「武器有没有生效」：

• 缓存命中率 = 命中次数 / 总请求次数。这是缓存的一号指标，目标随场景而定，FAQ 类冲 50%~70% 很常见。
• 缓存节省成本 = 命中请求本应产生的模型费用 − 实际缓存读取费用。直接换算成钱，最好看。
• 路由分布 = 各模型承接的请求占比。如果「小模型占比」长期为 0，说明路由没在降级，等于没装。
• 平均单请求成本趋势 = 总成本 / 总请求数，按周看是否下行。
• P95 延迟 = 降级到小模型通常更快，若延迟反而升，要查路由开销是否过大。

把这五个指标做成一个周报看板，成本治理就从「感觉省了」变成「看见省了」。

八、组织落地：谁来做、怎么做、踩坑预警

技术能解决一半，落地靠组织。结合多个团队的经验：

• 所有权：成本治理要有明确 owner，否则「缓存命中率掉了没人管」。建议和「稳定性/效能」职责合并，而非临时运动。
• 左移：把成本检查放进 CI/评审，新接一个 LLM 调用就要回答「它会被缓存吗？会被路由吗？」。
• 别用省钱换事故：降级路由必须有「正确性兜底」，敏感请求宁可多花钱也不能错。省钱是第二目标，正确性是第一目标。
• 警惕「为缓存而缓存」：有人为了刷命中率，把本该实时的结果也缓存了，导致用户看到过期答案。命中率是手段，不是目的。

九、一个端到端的小例子

把本章串起来：用户问「我的退款到哪了」。

1. 请求进入统一网关，生成指纹。
2. 先查语义缓存：命中「退款进度查询」同类问答，直接返回，全程没碰模型——省下全部 Token。
3. 若未命中，路由分类器判断这是「标准 FAQ、低风险」，决策缓存显示「此类恒走小模型」，复用上次路由结果，调用轻量模型生成答案。
4. 答案写回内容缓存 + 路由决策缓存，下次同类请求连路由都省了。
5. 全链路记录：缓存命中、走的模型、Token 数、耗时——喂给看板。

你看，缓存与路由不是两个孤立功能，而是一条「先横挡、再纵分、还顺手记住决策」的流水线。

十、和「传统缓存」的区别：别拿着旧地图找新路

有后端经验的工程师容易把 LLM 缓存和「Redis 缓存数据库查询结果」混为一谈，这会带来误判。两者关键差异：

• 键的模糊性：数据库缓存的键是精确的（用户 ID=123），命中即一致；LLM 语义缓存的键是「相似度」，命中返回的是「近似答案」，需要可接受的误差边界。
• 值的不稳定性：同样的 Prompt，模型两次输出可能略有不同（温度>0），缓存值不是绝对确定值，需要 TTL 和「可重算」兜底。
• 成本结构不同：数据库缓存省的是 DB 查询；LLM 缓存省的是「推理算力 + Token 计费」，后者贵得多，所以 LLM 缓存的 ROI 通常高于传统缓存。

正因为这些差异，LLM 缓存需要「语义层」和「一致性策略」，不能简单套 Redis 那套。

十一、路由与缓存的失败模式对照表

为了让你少踩坑，把两类武器最常见的失败模式列成对照：

记住：两类武器都有可能「越优化越糟」，所以第六节的「全链路埋点 + 看板」不是可选项，是必选项。

小结：本节你带走了什么

• 降本四道防线：缓存（挡重复/降 Q）、路由（分难度/降 P）、压缩（降 T）、选型（降 P）。
• 缓存 = 系统的记忆层（精确缓存去重、语义缓存近似记忆），命中率是它的一级指标。
• 路由 = 系统的调度员（按复杂度/风险/延迟/预算选模型），未命中缓存才进路由。
• 配合方式：缓存先横挡、路由再纵分；路由决策本身也可被缓存，形成「内容+决策」双层缓存。
• 边界清醒：实时多变、强一致场景慎用语义缓存；别用缓存掩盖重试等架构问题。
• 今天预埋 5 个钩子：统一入口、请求指纹、可替换后端、全链路埋点、降级开关。

—— 第一章到此结束。你已经具备「看清账单、找准目标、理解武器」的基础盘。第二章我们将真正动手：搭一套可落地的请求缓存层，并设计能自动选路的智能路由模块。