AI应用成本优化#

四大策略”缓级压批”：

另一个常被忽略的手段：Prompt Caching（前缀缓存）。 长 system prompt、工具定义、固定文档放在前面且保持不变，云 API 对命中部分按折扣价计输入费（常见是正常输入价的 0.1 倍左右，写入可能更贵，各家规则以官方文档为准），机制和算账见 [前缀缓存与KV Cache复用](/topics/llm-serving/前缀缓存与KV Cache复用)。它和语义缓存不同：语义缓存省掉整次调用，前缀缓存只省输入费和首 token 延迟。

成本估算公式：（输入、输出单价不同，要分开算）

日成本 = 日均调用量 × (平均输入 token × 输入单价 + 平均输出 token × 输出单价)

示例：1 万次/日 RAG 调用，输入 2600 token（System 500 + Context 2000 + Query 100）、输出 500 token，按中档模型”输入每百万 token 几美元、输出每百万 token 十几美元”的量级（例如输入 $3/M、输出 $15/M；具体以官方价格页为准）→ 10000 × (2600×3 + 500×15) / 10⁶ ≈ 日成本 $153。输出单价通常是输入的数倍，所以控制输出长度和控制输入同样重要。

模型级联架构：

用户请求 → 意图分类器（轻量）
  ├── 简单/FAQ → Haiku（快、便宜）
  ├── 常规任务 → Sonnet（平衡）
  └── 复杂推理 → Opus（最强）

语义缓存实现要点：

• 用 Embedding 向量化 query，余弦相似度超过阈值视为命中（常见取 0.9 以上，用标注样本在命中率和答错率之间定）
• 缓存 key = query embedding，value = LLM response
• 时效性内容设 TTL，非确定性回答不缓存
• Redis + 向量索引 实现低延迟匹配

AI应用成本优化我总结为四个策略”缓级压批”。第一是语义缓存，对相似问题的LLM回答做缓存，用向量相似度判断是否命中，避免重复调用API，这在FAQ类场景命中率很高。第二是模型级联，类似医院分诊——简单问题用轻量小模型（成本低速度快），只有小模型置信度不够时才升级到大模型处理，这样大部分请求不需要走最贵的模型。第三是Prompt压缩，精简System Prompt、去除冗余上下文、用更短的指令达到同样效果，直接减少input token数量。第四是批量API，把多个请求合并成一次batch调用，很多API提供商对batch请求有折扣。

追问方向：

• 怎么证明降本有效？各个手段分别贡献多少？ → 先按调用链拆账：每类请求的调用次数 × 输入/输出 token × 单价，找出大头；再逐项上优化，用同一批请求对比单次成本和总成本。常见组合是模型级联 + 语义缓存 + 高置信度时跳过自检/反思调用 + 用规则替代简单的 LLM 决策（如按规则选工具）。结合项目时可以讲：每个手段单独省了多少、用什么数据验证
• 语义缓存命中率怎么提升？缓存失效策略怎么设计？ → 只缓存重复出现过的 query（例如第 2 次出现才写入），避免冷 query 占空间；相似度阈值越低命中越多、答错风险越大，用标注样本定阈值。失效靠 TTL + 数据源版本号：知识库内容变更时版本号自增，缓存条目带版本号，不一致即失效
• 模型路由的分类器怎么训练？误判了怎么办？ → 简单方案用规则（关键词/意图分类），进阶用轻量分类器（BERT-tiny）。误判的补救：小模型置信度低时自动升级到大模型
• Prompt 压缩会不会影响回答质量？怎么平衡？ → 会。关键信息不能压缩，只压缩冗余指令和历史对话。实践中先精简 System Prompt（效果最大），再压缩检索上下文（用摘要替代全文）

易错点：

• ❌ “缓存所有 LLM 回答” → 时效性内容、个性化回答不能缓存
• ❌ “只用最便宜的模型” → 复杂任务质量严重下降，用户体验差
• ❌ “Batch API 适合所有场景” → 只适合非实时场景（离线分析、批量标注）