意图识别 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），日成本对比：

换成 Qwen3.6 Plus（输入 2.0 元/M，输出 12.0 元/M），差距同样明显：

一句话：意图识别节省 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），成本仍然低于缓存。缓存唯一的优势是在完全无法做意图识别时作为兜底。

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

混合方案：极致节省

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

一句话：两者互补，不是替代。

投入产出评估

核心要点

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