LLM API 的成本优化策略
难度：基础 分类：Production & Deployment
简短回答
LLM API 成本优化可以通过组合策略实现最高 80-90% 的成本削减。六大核心策略：(1) Prompt 优化——精简 Prompt、去除冗余词、使用结构化输出（减少 15-40%）；(2) Prompt 缓存——复用静态 Prompt 前缀的处理结果，Anthropic 缓存可降低 90% 输入成本（$0.30/M vs $3.00/M）；(3) 语义缓存——对语义相似的请求返回缓存结果，Redis LangCache 在高重复场景下减少 73% 成本；(4) 模型路由——按任务复杂度选择模型，简单任务用小模型（RouteLLM 实现 85% 成本削减且保持 95% 质量）；(5) RAG 替代长上下文——用检索替代将整个文档塞入 Prompt（减少 70%+ 上下文 Token）；(6) 批处理——非实时任务批量处理，OpenAI Batch API 50% 折扣。关键认知：输出 Token 成本是输入 Token 的 2-5 倍，限制输出长度有显著的成本影响。当月调用量超过 100 万次时，应考虑自建模型服务（vLLM），6-12 个月内可回收硬件投入。
详细解析
成本优化策略全景
代码块
Plain Text
成本优化策略（按投入产出排序）：
立即见效（0 额外成本）：
├── Prompt 精简：去除冗余词、缩短指令 → -15-40%
├── 限制输出长度：max_tokens 控制 → -20-30%
├── 降低温度：temperature=0 减少重试 → -5-10%
└── 结构化输出：JSON 比自然语言更省 token → -10-20%
短期投入（1-2 周）：
├── Prompt 缓存：静态内容前置 → -50-90% 缓存部分
├── 模型路由：简单任务用小模型 → -40-85%
├── 语义缓存：相似请求复用结果 → -30-73%
└── RAG 替代长上下文 → -70% 上下文 token
中期投入（1-3 个月）：
├── 批处理 API → -50% (OpenAI Batch)
├── 微调小模型替代大模型 → -60-80%
└── 自建推理服务（vLLM）→ 大规模时最经济
具体实施方案
代码块
Python
# 策略 1：Prompt 优化
class PromptOptimizer:
"""Prompt 级别的成本优化"""
def optimize(self, prompt):
"""精简 Prompt 减少 token"""
# 1. 去除冗余指令
# Bad: "请你仔细地、认真地、全面地分析以下文本..."
# Good: "分析以下文本："
# 2. 结构化输出代替自然语言
# Bad: "请用自然语言详细描述你的分析结果"
# Good: "输出JSON: {result, confidence, key_points[]}"
成本监控与预算控制
代码块
Python
class CostMonitor:
"""成本监控和预算控制"""
def __init__(self, daily_budget=100.0):
self.daily_budget = daily_budget
成本优化决策树
代码块
Plain Text
你的月调用量？
│
├── < 10K 次/月
│ → Prompt 优化 + Prompt 缓存（免费/低成本）
│ → 预计月成本 $10-100
│
├── 10K-100K 次/月
│ → + 模型路由 + 语义缓存
│ → + 批处理（非实时任务）
│ → 预计月成本 $100-1000
│
├── 100K-1M 次/月
│ → + RAG 替代长上下文
│ → + 微调小模型替代部分大模型调用
常见误区 / 面试追问
误区："用最便宜的模型就是最省钱" — 便宜模型如果质量差导致用户重试，实际成本可能更高。正确做法是模型路由——让合适的模型处理合适的任务。RouteLLM 证明了这种方法可以在保持 95% 质量的同时削减 85% 成本。
误区："成本优化会牺牲质量" — Prompt 缓存和语义缓存不会影响质量（返回的是同样的结果）。模型路由也不是降质量——简单任务本来就不需要最强模型。真正的风险在于过度压缩 Prompt 导致指令不清晰。
追问："如何预估 LLM 项目的成本？" — (1) 估算每个用户每天的平均请求数；(2) 估算每个请求的平均 Token 数（输入+输出）；(3) 乘以模型单价；(4) 加上缓存命中率的折扣。公式：月成本 ≈ DAU × 日均请求 × 平均 Token × 单价 × (1 - 缓存率) × 30。
追问："什么时候应该考虑自建？" — 月调用量 > 100 万次、对延迟有严格要求（< 200ms）、数据隐私要求不能发送到第三方、或使用开源模型已满足质量需求时。自建的关键工具：vLLM（推理引擎）+ 开源模型（Llama/Qwen）。
场景追问："你的系统突然收到一笔 $5000 的 API 账单，而正常月份只有 $500。如何快速定位超额消费的原因？" — 这是成本异常的紧急情况。快速定位路径：(1) 检查监控 → 找出消耗激增的时间点和对应功能模块；(2) 分析 Token 分布 → 是输入 Token 还是输出 Token 激增（输出成本高得多）；(3) 检查异常请求 → 是否有某个查询触发了无限循环或过度检索；(4) 检查模型使用 → 是否有错误配置导致大量请求使用了昂贵模型；(5) 立即止损：(a) 限制单请求 Token 上限；(b) 暂时禁用可疑的功能模块；(c) 启用预算熔断。
场景追问："你的语义缓存命中率从 70% 降到 30%，导致成本显著上升。如何诊断和恢复？" — 这是缓存失效问题。诊断路径：(1) 检查查询模式变化 → 用户行为或业务场景是否发生了根本变化；(2) 检查相似度阈值设置 → 阈值可能需要调整；(3) 检查缓存存储空间 → 是否达到容量上限导致驱逐；(4) 检查模型更新 → embedding 模型版本变更会导致向量空间漂移；(5) 恢复策略：(a) 重新计算所有缓存的向量；(b) 调整相似度阈值；(c) 扩大缓存容量；(d) 针对新模式重新训练缓存策略。
场景追问："你的模型路由器频繁错误地将简单任务路由到昂贵的大模型，导致成本超标。如何优化路由策略？" — 这是路由器失效问题。优化路径：(1) 分析错误路由的查询特征 → 找出导致误判的查询模式；(2) 重新训练路由器 → 用新的正负样本更新路由模型；(3) 加入成本敏感的评估指标 → 不仅考虑质量，也考虑成本；(4) 实施路由后验证 → 对路由到高成本模型的请求进行二次检查；(5) 设置路由阈值 → 对边界情况倾向于使用便宜模型。