把 LLM 账单砍掉 60% 的四类手段
原作者：Bhavesh Modi 原文链接：https://webosmotic.com/blog/llm-token-cost-optimization/
结论先行
把 LLM 账单砍掉 60% 的四类手段：缓存、语义缓存、小模型与路由。这篇文章的核心主张是：成本优化是工程问题，不是采购问题——让每次结果花更少的 token，而不是等账单来了再换便宜模型。它给出四类可叠加的手段：提示缓存（缓存读取按标准输入费率约 1/10 计费）、语义缓存（embedding 相似度命中直接返回）、小语言模型（窄任务的每 token 推理成本低一个数量级）、模型路由（按任务层级匹配模型）。
但必须说清楚证据强度：原文明确写了「没有任何单一杠杆能单独实现 60%」，而文中所有百分比（90% 缓存折扣、50–90% OpenAI 折扣、25% 写入溢价、一个数量级）都来自被引用方，文章本身没有提供任何客户案例、实测账单或测量数据。所以 60% 应当视为组合手段的理论上限，不是承诺值。
原文出处
作者：Bhavesh Modi（Project Manager – AI） 原文：LLM Token Cost Optimization: Proven Cuts To AI Spend By 60%（Webosmotic） 发布：2026-08-03 链接：https://webosmotic.com/blog/llm-token-cost-optimization/
文中引用的外部来源包括 Gartner 的市场预测、Anthropic 与 OpenAI 的官方定价文档、NVIDIA Research 的论文，以及 Redis 工程博客。
要点解读
1. 提示缓存：这是见效最快的一档
不同厂商的机制差别很大，这一点值得记清楚：
| 特性 | Anthropic Claude | OpenAI |
|---|---|---|
| 激活方式 | 手动，用 cache_control 标记 | 对 1,024+ token 的提示词自动激活 |
| 缓存读取折扣 | 约低于标准输入费率 90% | 50–90%（取决于模型） |
| 缓存写入成本 | 高于标准输入费率 25% | 多数模型无额外费用 |
| 默认缓存寿命 | 5 分钟，可选 1 小时 | 5–10 分钟，非高峰最长 1 小时 |
注意 Anthropic 的缓存写入更贵 25%——这意味着缓存不是无条件划算的：只有当一个前缀会被重复使用时才值得缓存，一次性长提示写入缓存反而多花钱。
本站判断：这条对三维项目的实际影响很大。系统提示、CLAUDE.md、工具定义、以及那些反复要参考的核心文件（比如渲染管线的约定、坐标与单位规范），都属于典型的「稳定前缀」，缓存收益最高；而一次性的模型清单、贴图说明，缓存了反而亏。
2. 语义缓存：在提示缓存之上再加一层
思路是存储历史 query-response 对，用 embedding 相似度匹配新查询，命中就直接返回缓存答案、完全不调用模型。原文给了四条落地建议：
- 相似度阈值要设得足够高，避免把「相近但不同」的问题答错；
- 定义清晰的 TTL 和失效规则，确保缓存答案不会比它所依据的数据存活更久；
- 构建 fallback 路径，未命中时正常调用模型，并且命中与未命中分开记录日志；
- 把命中率当作一等指标追踪。
文中没有给出语义缓存的具体节省百分比，只引用 Redis 工程博客佐证这个模式。
3. 小语言模型：把窄任务从旗舰模型上摘下来
引用 NVIDIA Research 的结论：小语言模型对大多数狭窄且重复的 agent 任务足够强、运营上更合适，每 token 推理成本低一个数量级。
任务与模型层级的匹配建议：
| 任务模式 | 推荐模型层级 | 原因 |
|---|---|---|
| 意图分类、路由 | 小语言模型，约 10B 参数以下 | 狭窄、重复、变化少 |
| 结构化数据抽取 | 针对 schema 微调的小模型 | 输出格式可预测 |
| 开放式推理、起草 | 前沿 LLM | 需要通用能力 |
| 罕见、高风险决策 | 前沿 LLM + 人工复核 | 准确性优先于单次调用成本 |
4. 模型路由：五条可执行建议
- 写路由规则之前，先按任务类型记录每一次调用——没有基线就没法判断路由有没有效果；
- 每种任务默认用小型或中型模型，仅在超过既定置信度阈值时才升级；
- 对每个端点限制 max output tokens，不要让生成长度无限；
- 把非交互式负载（夜间摘要、批量分类）迁到 batch 定价层级；
- 每季度复核路由规则，因为「某任务最便宜且够用」的模型经常在变。
5. 输出长度：常被忽略的最大单项
文章引用 Redis 的结论：旗舰模型上输出 token 的定价是输入 token 的数倍，因此「响应长度通常比提示长度更能决定账单」。在成本驱动表里，「输出长度」被标为啰嗦响应的最大单项支出，成因是顺序解码本身定价就高。
6. 生产环境的五个成本泄漏点
- 静态 system prompt 和工具定义每次调用都重发，而不是缓存；
- 每一轮都传完整对话历史，而不是摘要后的状态；
- RAG 流水线返回超出答案所需的分块；
- 无论任务复杂度，每个请求都路由到旗舰模型；
- 没有按功能的成本归因，在财务发现问题前，没有人对这笔账单负责。
成本驱动与账单影响对应关系：
| 成本驱动 | 成因 | 典型影响 |
|---|---|---|
| 输出长度 | 顺序解码，定价为输入的数倍 | 啰嗦响应的最大单项 |
| 重复上下文 | 系统提示、工具 schema、历史每轮重发 | 随调用量线性复利 |
| 检索噪声 | 过大的 RAG 分块作为输入 | 抬高 token 却不改善答案 |
| 模型不匹配 | 简单重复任务用旗舰模型 | 为不需要的能力付溢价 |
7. 治理：让账单有归属
- 按功能分配成本归因，让具体团队对应到账单上的具体条目；
- 在财务已经在看的同一块仪表盘上追踪缓存命中率和输出 token 量；
- 对输出 token 尖峰告警，就像基础设施团队对流量尖峰告警一样；
- 用与基础设施成本复核相同的节奏复核 token 支出；
- 特别重访多智能体工作流，因为链式调用会复利式叠加成本。
代码与验证
原文没有给代码，但给了明确的执行顺序建议（也是 FAQ 里「不换供应商情况下最快降本」的答案）：
- 先启用供应商侧提示缓存——OpenAI 自动生效，Anthropic 只需加
cache_control标记； - 再给每个端点限制 max output tokens；
- 最后才做模型路由。
理由是前两步几乎零架构改动，第三步需要先有调用数据才能设计规则。
适用场景与坑
该用：有稳定前缀的生产系统、任务类型可枚举的 Agent、按功能可以归因的团队。缓存那一步几乎没有门槛，值得所有人在今天就把系统提示接进缓存。
别用：一次性脚本、前缀不复用的调用——Anthropic 的缓存写入要贵 25%，缓存了反而更亏。
已知的坑：
- 60% 是理论叠加值，原文无自有实测数据。文中的 90%、50–90%、25%、一个数量级等数字全部来自被引用方。把它当上限看，别当 KPI 定。
- 缓存写入有额外成本，且缓存未命中会让长提示重新变贵——缓存纪律比缓存开关重要；
- 语义缓存的阈值设低了会答错问题，且答案可能比数据源活得更久，TTL 必须设计；
- 输出长度限制过紧会导致回答被截断，需要配合质量验收；
- 多智能体工作流会把上述所有成本乘起来，先算清楚再上。
