意图识别 vs API 缓存 —— 哪种方法更省 Token?

📅 2026/7/16 4:24:34 👁️ 阅读次数 📝 编程学习
意图识别 vs API 缓存 —— 哪种方法更省 Token?

团队每天花 255.6 元(Qwen3.6 Flash)或 426 元(Qwen3.6 Plus)在 LLM 调用上,想降本。有人说"用 API 缓存吧,90% 折扣",有人说"先做意图识别,85% 的请求不用调 LLM"。到底哪个更省?我们算过了——结论可能和你想的不一样。

为什么意图识别比缓存更省?

核心区别在于:意图识别是"从根上省",缓存是"从量上省"

意图识别通过 P0+P1+P2 流水线,85% 的请求在本地完成,完全跳过 LLM 调用——这意味着输入和输出 token 都省了。而缓存只能降低重复输入内容的计费,输出 token 一分不少。

以 Qwen3.6 Flash 为例(输入 1.2 元/M,输出 7.2 元/M),日成本对比:

方案日成本节省比例
无优化基线255.6 元
意图识别(85%命中)14.3 元94%
API 缓存(50%命中)186.4 元27%

换成 Qwen3.6 Plus(输入 2.0 元/M,输出 12.0 元/M),差距同样明显:

方案日成本节省比例
无优化基线426 元
意图识别(85%命中)23.8 元94%
API 缓存(50%命中)310.7 元27%

一句话:意图识别节省 94%,缓存节省 27%——差距不是一点点。

缓存的三个前提:缺一不可

Qwen3.6 的显式缓存不是免费的午餐。它有三个硬性门槛:

前提 1:前缀必须稳定且足够长

缓存创建费比普通输入费贵——Flash 是 1.5 元/M vs 1.2 元/M(贵 25%),Plus 是 2.5 元/M vs 2.0 元/M(贵 25%)。需要缓存命中率超过22%才能覆盖创建成本。如果你的 system prompt + tool schema 只有 730 tokens,前缀太短时首次写入的额外成本可能超过后续节省。

前提 2:请求必须在缓存有效期内重复

TTL 由用户控制,但如果 system prompt 或工具 schema 频繁变更,缓存需要重建,增加创建成本。高频场景(如客服)天然满足;低频场景需要评估缓存有效期内的请求量。

前提 3:前缀必须放在最前面

缓存只匹配最长匹配前缀。如果请求格式是[用户输入][system prompt][工具定义],缓存完全失效。正确格式是[system prompt][工具定义][用户输入]

一句话:缓存不是"开开关关"那么简单,它有明确的适用边界。

交叉点:什么时候缓存更划算?

我们推导了交叉点公式,结论是:只要意图识别命中率 > 0,就始终优于缓存

即使意图识别完全不跳过 LLM 调用(P_full=0%),只要能精简工具集(只传 20% 的 schema),成本仍然低于缓存。缓存唯一的优势是在完全无法做意图识别时作为兜底。

意图识别命中率意图识别日成本(Flash)缓存日成本(Flash)
85%14.3 元186.4 元
50%47.1 元186.4 元
0%92.9 元186.4 元

一句话:意图识别是降本的第一选择,缓存是锦上添花。

混合方案:极致节省

先用意图识别过滤掉 85% 的请求,剩余 15% 的 LLM 调用再用缓存优化——混合方案的日成本仅 11.8 元(Flash)或 19.6 元(Plus),节省 95%。

方案Flash 日成本Plus 日成本节省比例
混合方案(意图识别 + 缓存)11.8 元19.6 元95%

一句话:两者互补,不是替代。

投入产出评估

方案Flash 日成本Flash 日节省Flash 年化节省Plus 日成本Plus 日节省Plus 年化节省工程投入
无优化255.6 元00426 元000
意图识别(P0+P1)14.3 元241.3 元~88,075 元23.8 元402.2 元~146,803 元
API 缓存(50% 命中)186.4 元69.2 元~25,258 元310.7 元115.3 元~42,085 元
混合方案(意图识别 + 缓存)11.8 元243.8 元~88,987 元19.6 元406.4 元~148,336 元

核心要点

  1. 意图识别是降本的第一选择:节省 94%,投入产出比远高于缓存
  2. 缓存是锦上添花:节省 27%,需要满足三个前提条件
  3. 混合方案最优:先用意图识别过滤,再用缓存优化剩余调用,节省 95%
  4. 缓存创建费比输入贵 25%:需要命中率 >22% 才能覆盖
  5. 只要意图识别命中率 > 0,就始终优于缓存