第 13 讲 | 成本优化：LLM 系统的省钱之道
本节我们将掌握：
- 成本控制六层体系：从 Prompt 设计到商业折扣的完整链路
- 成本监控告警：调用落盘、每日聚合、异常检测的完整工具链
- Prometheus + Grafana 构建 AI 特殊监控区域
LLM 成本失控的真实场景
目前Meta等大公司纷纷下调每个岗位的Token用量。
美国一些典型的大模型应用公司，模型成本贵过了使用者的人力成本。
场景模拟： 一家创业公司的客服系统上线后收到了第一条告警：单日 LLM 成本从 2000 元飙升至 1.2 万元。
排查后发现原因很简单——一个缓存失效 bug 导致相同的问题调用了 500 次 API，每次都走了完整的 GPT-4 流程。
这不是孤例。另一家电商公司在"双11"大促期间，由于促销活动导致用户咨询量暴增 10 倍，LLM 成本从日均 5000 元飙升至 5 万元。事后复盘发现，如果提前做了大小模型分流和缓存优化，这笔成本可以控制在 8000 元以内。
生产环境的 LLM 系统面临两个核心挑战：
- 成本不可控：Token 消耗像流水，不知道花在哪、为什么花、怎么省
- 单点故障风险：依赖单一模型提供商，一旦宕机整个业务瘫痪
2026 年的共识：成本优化不是可选项，而是 LLM 架构的基础设施。企业在 LLM 部署初期如果不做成本控制，很容易在几个月后超出预算数倍。
我们自下而上拆解这套体系。
Russell的成本控制体系：六层优化链路⭐⭐
成本控制是一个系统工程，不是哪一步单个可以做到的，或者说“每一步都有节省的几乎”，我按照经验给大家列一些：
⚠️ 注意：首先我们还是要保证质量，最起码要符合业务目标，不要本末倒置。
- 做好自己——Prompt/Agent流程设计，减少各种冗余(如RAG去重），根据场景减少不必要的步骤，从根本上解决。
- 适合代码的就不要用模型：如“意图识别”使用规则代替80%场景，能用脚本做的“质量门禁”不用LLM。
- 一定要用的，选择合适的模型：根据场景选择不同的模型，在同一场景做好模型路由。
- 哪怕模型定了，也能流程侧优化：通过前面讲的调用链缓存、自主多层级缓存、中间步骤保存（异常场景）、上下文分层管理及压缩、批量请求；以及后面要讲的合理使用RAG这类组件。
- 顺手搭配一些节省Token的工具：如各种Tool Schema，比如开发过程中的代码图谱，比如测试过程中的浏览器内容工具等，其实也有很多。这里做个广告，我做的非常好的Token节省工具TokSlash(https://tokslash.stratsapien.com/index-zh.html)
- 商业节省：如云厂商的商务折扣、资源包、“批量请求”等功能。
① 做好自己：Prompt/Agent 流程设计减少冗余
最直接的省钱方式是从源头减少不必要的调用。
反模式示例：
# ❌ 反模式：一个客服问答拆成 4 次 LLM 调用
step1 = llm("提取用户意图") # 第1次调用
step2 = llm("根据意图查知识库") # 第2次调用
step3 = llm("生成回答") # 第3次调用
step4 = llm("检查回答质量") # 第4次调用好的设计：
合并步骤——把意图提取和知识检索合并到一个 prompt 里，一次调用完成：
# ✅ 合并后的流程：一次调用完成
prompt = """
用户问题：{question}
请：1) 判断意图；2) 从以下知识中提取相关信息生成回答：{knowledge}
"""
answer = llm(prompt) # 第1次调用，完成所有工作减少冗余——RAG 检索结果先去重、排序、过滤，只把最相关的 3-5 条送给 LLM，避免送一堆垃圾内容浪费 token 和降低回答质量。
类似这种还有很多，比如设置一些“高频预置问题”等产品设计方面。做好一些约束，避免不准/反复重跑等。
② 适合脚本的不用模型：规则代替 80% 场景
生产环境最常见的浪费是用 LLM 做简单判断：
| 场景 | LLM 方案 | 规则方案 | 成本对比 |
|---|---|---|---|
| 意图识别 | "用户说'你好'是什么意图？" → LLM 分类 | 关键词匹配："你好/您好/嗨" → greeting | LLM: $0.01/次 vs 规则: $0.00001/次 |
| 格式校验 | "这个邮箱格式对吗？" → LLM 判断 | 正则表达式验证 | LLM: $0.01/次 vs 规则: $0 |
| 简单提取 | "从'我的订单是12345'提取订单号" → LLM | 正则 \d{5} 匹配 | LLM: $0.01/次 vs 规则: $0 |
| 质量门禁 | "这段代码有 bug 吗？" → LLM 审查 | CI 静态检查（eslint/pylint） | LLM: $0.05/次 vs 规则: $0 |
经验法则：典型的企业客服系统中，大部分用户咨询可以用规则或模板回复。强行用 LLM 处理这些简单场景，成本远高于规则方案。
实施建议：
- 先统计流量分布，找出高频简单问题（通常是问候、FAQ、状态查询）
- 用规则引擎（如 Drools）或简单的 if-else 覆盖前 80% 的场景
- 只有规则无法处理的复杂问题才路由到 LLM
行业实践：不少电商团队在客服系统中引入了规则引擎，将高频简单问题用规则处理，只把复杂问题路由到 LLM，成本大幅下降，质量也大幅提高。同时，由于规则响应速度快，用户体验反而更好。
③ 选择合适的模型：根据场景选模型，做好模型路由
不是所有请求都需要最强模型。这是成本优化最有效的手段之一。
详细参考“11讲-模型路由“章节。
包括：
- 模型选择：根据场景选择合适的模型
- 模型路由：模型按照规则、级联、分类器路由。
选型的标准主要考虑：
- 能力：不同场景；主、备、降级的定位。
- 成本：国内外差距较大；套餐额度要调节；
- 测评：公开测评；实际用的体验。
④ 流程侧优化：调用链缓存、上下文分层管理及压缩
即使模型定了，也能从流程侧挤出节省空间。
调用链缓存：
相同请求 → 缓存命中 → 直接返回（零 LLM 成本）
↓ 未命中
正常 LLM 调用 → 结果写缓存- 输入 token 缓存（Prompt 缓存）：各大厂商原生支持，重复前缀可省 50%-90% 的输入 token 费用。Anthropic 的 prompt caching 是最成熟的
- 输出语义缓存：用 embedding 做语义匹配，相似度超阈值（如 0.9）直接返回缓存。Redis、Cloudflare 都有现成方案
- 缓存失效策略：知识库更新后自动清理相关缓存；设置 TTL（默认 24-48 小时）
上下文分层管理：
用户对话历史
├── 最近 3 轮 → 完整保留（高优先级上下文）
├── 3-10 轮 → 摘要压缩（中优先级上下文）
└── 10 轮以前 → 只保留关键信息（低优先级上下文）通过上下文压缩，可以显著降低长对话的 token 消耗，同时保持回答质量。
中间步骤保存：对于多步 Agent 流程，将每步的结果持久化。如果后续步骤失败，可以直接从缓存中恢复，避免重跑整个链路。
⑤ 发现并使用降本工具
开发、测试、部署、运营的各个环节都有可以帮咱省钱的工具。用得好，投入少见效快。
- 沉淀 hook 和经验的产品：避免大模型反复解决同一个问题，一次解决多次复用
- 测试场景专用工具：比如网页探索工具，在 playwright 调用占比高的场景下可以显著降低消耗
- Markdown 处理工具：如 TokSlash（https://tokslash.stratsapien.com/index-zh.html），在读取和编辑环节大大降低用量、提高效果
- 代码图谱工具：帮助 AI 快速理解项目结构，减少不必要的文件读取
只要发现并善用这些工具，不仅投入相比其他方案少很多，而且见效快、效果好，性价比极高。投入就是要提前考察和测试工具的安全性、稳定性和适用范围。
⑥ 商业节省：云厂商折扣、资源包
最后才是商务层面的优化：
- 预留实例/资源包：大多数云厂商提供月付/年付的资源包，价格比按需付费低 30%-50%
- 批量请求折扣：Azure OpenAI、阿里云等都提供批量请求（batch API）功能，延迟更高但价格更低
- 阶梯定价：用量越大单价越低，合理规划计费周期可以享受更低价格
- 谈判折扣：对于大客户，直接与云厂商谈年度合同可以获得额外折扣
注意：商务优化是最后一环。如果前面的技术优化没做好，买再多资源包也是浪费。
省钱技巧：对于用量稳定的企业，可以先买小规格资源包测试，确认用量模型后再购买大规格。很多云厂商支持较长的有效期，并且支持自动转”按量付费”，合理利用这一政策可以避免浪费。
观测与告警：详细的监控落盘数据结构、告警阈值、Prometheus + Grafana 配置，详见第 11 讲（LLM 运行时治理）中的观测与告警章节。补充成本维度的特殊告警：单日成本较 7 日均值突增 50%+、单用户日成本超过均值 3 倍。
选型决策
架构师决策清单：
- 成本控制六层体系：Prompt 设计 → 规则替代 → 模型路由 → 流程优化 → 发现降本工具 → 商业折扣，层层递进，不能只做最后一层
- 成本监控非常推荐：每次调用落盘（模型、token、延迟）、按场景聚合、异常自动告警
- Prometheus + Grafana：在传统监控之上构建 AI 特殊区域（成本、缓存命中率、路由分布）
面试回答要点
Q：生产环境的 LLM 系统怎么做成本优化？
答（抓体系 + 讲分层）：
成本控制——六层递进：① Prompt/Agent 流程设计减少冗余调用；② 规则替代大部分简单场景；③ 大小模型路由；④ 调用链缓存 + 上下文压缩；⑤ 发现并使用降本工具；⑥ 商业折扣。前四层是技术优化，贡献最大；后两层是锦上添花。
深度追问：
"语义缓存和传统缓存有什么区别？" → 传统缓存是精确匹配 key-value；语义缓存用 embedding 做相似度匹配，"你们退款政策是什么"和"退款政策怎么规定的"能命中同一条缓存。
"成本突增怎么排查？" → 先看是哪个场景/用户突增 → 检查是否有缓存失效 bug → 看是否有异常流量（如爬虫/滥用）→ 检查是否有重复调用（同一个请求调了多次 LLM）。
小结
- 成本控制是系统工程：六层优化链路（Prompt 设计 → 规则替代 → 模型路由 → 流程优化 → 发现降本工具 → 商业折扣），层层递进，不能只做最后一层
- 规则替代是性价比最高的手段：能用脚本解决的不用模型，80% 简单场景可以规则覆盖
- 大小模型路由是成本优化最有效的手段之一：简单问题走轻量模型，复杂问题才走顶级模型
- 成本监控必不可少：每次调用落盘、多维度聚合、异常自动告警，Prometheus + Grafana 构建 AI 特殊区域
思考题
我们的团队负责一个日均 10 万调用的客服系统，目前全部使用 Claude Opus 4.6，月成本约 15 万元。从成本控制六层体系的角度，我们会按什么顺序实施优化？预估每层能节省多少成本？（提示：先做流量分布分析，识别规则可替代的场景，再设计大小模型路由规则）
我们上线了一个基于 RAG 的内部问答系统，运行一个月后发现成本超出预算 3 倍。从成本控制的角度，我们会按什么顺序排查和优化？（提示：先看缓存命中率，再看大小模型分流，最后看 Prompt 是否有冗余）