更新于

LLM 成本优化 30 条 checklist

成本优化LLMAPI 使用token工程实践

LLM 成本优化是一个系统工程，不存在单一的”银弹”。有人靠换模型省了 80% 费用，也有人换了模型反而因为质量下降导致多轮对话增加、总成本更高。

下面这 30 条 checklist 覆盖了成本优化的主要维度，按”最容易落地 → 需要改代码 → 需要调整架构”的难度排序。每条都有可操作的具体做法，不是泛泛的”减少 token”。

一、模型选择层（优先级最高）

✅ 1. 按任务复杂度选模型，而不是默认用最贵的

把你的任务分类：

  • 简单分类、意图识别、格式转换 → Haiku / Mini 级别（约 1/10 成本）
  • 标准问答、代码补全、文档生成 → Sonnet / Standard 级别
  • 复杂推理、多步规划、困难代码生成 → Opus / Pro 级别

做一个月的任务分类统计，你可能会发现 60-70% 的请求根本不需要最贵的模型。

✅ 2. 用评测脚本验证”降级是否可接受”

不要主观判断，用实际数据说话。抽取 100-200 个真实请求，同时发给贵模型和便宜模型，对比输出质量。构建评测黄金集的方法可以参考。

✅ 3. 对高频、低复杂度任务单独维护 prompt 版本

同一任务用不同模型时，prompt 需要调整。不要把 Opus 级别的 system prompt 直接用在 Haiku 上，效果差的根因往往是 prompt 而非模型本身。

✅ 4. 测试开源/自托管模型的可行性

Llama 3.1 405B、DeepSeek Coder、Qwen2.5 等开源模型在部分任务上已经接近闭源模型水准。如果你有 GPU 资源或者愿意使用云端推理服务，部分场景下自托管成本可以显著低于调用 OpenAI/Anthropic 官方 API。

二、Prompt 工程层

✅ 5. 审查 System Prompt 长度，删掉冗余内容

很多 System Prompt 是历史遗留的，里面有大量重复、矛盾或已不适用的指令。每 1000 个 input token 在 Sonnet 级别模型上约增加 $0.003。如果你的 System Prompt 有 3000 token，一天 10 万次请求的额外成本是 $900/天。

✅ 6. 使用 few-shot 时控制示例数量

few-shot 示例每个通常 200-500 token，3 个示例就是 1500 token。测试 2 个示例和 3 个示例的效果差异，如果不显著就去掉一个。

✅ 7. 指令优先于示例

能用清晰指令说明的任务，不要用大量示例来”凑效果”。指令通常比同等数量的示例更 token-efficient。

✅ 8. 输出格式控制：只要你需要的字段

如果你只需要 JSON 中的 3 个字段，明确告诉模型”只输出这三个字段，不要其他内容”。不做限制时模型可能输出 5-8 个字段（含 explanation、confidence 等），这些 token 全部计费。

✅ 9. 设置合理的 max_tokens

根据任务的实际输出长度，设置 max_tokens 上限。代码生成设 2000，简单分类任务设 50。默认不设置或设过高会浪费预算（即使模型没输出那么多，也会影响部分计费场景）。

✅ 10. 使用 stop sequences 提前终止输出

如果输出结构固定（比如 JSON 或特定格式），用 stop sequences 在完成后立即停止，避免模型继续生成不必要的文字。

三、Prompt Caching 层

Prompt Caching 是目前收益最高的单点优化，Claude 和 GPT-4o 都支持。详细配置可参考Prompt Caching 降本指南。

✅ 11. 识别你的”高复用内容”

缓存适合的内容：固定的 System Prompt、不变的工具/函数定义、长文档（让模型分析的参考材料）、few-shot 示例。

不适合缓存的内容：每次都变化的用户输入、动态插入的上下文。

✅ 12. 确保缓存内容放在 prompt 开头

Claude 的 Prompt Caching 是前缀匹配的，需要缓存的内容必须放在 prompt 的最前面，且每次请求都保持完全一致（包括空格、换行）。一个字符的差异都会导致缓存失效。

✅ 13. 监控缓存命中率

API 响应里有 cache_read_input_tokens 和 cache_creation_input_tokens 字段。如果缓存命中率低于 50%，说明你的缓存设计有问题（可能是前缀不稳定）。

✅ 14. 对会话历史也使用缓存

多轮对话场景下，前 N 轮历史 + System Prompt 可以整体缓存。每次请求只新增最新一轮对话，之前的内容命中缓存。这在客服机器人、代码审查等多轮交互场景下效果显著。

四、批处理与调度层

✅ 15. 非实时任务一律走 Batch API

OpenAI Batch API 和 Anthropic Batch API 均提供约 50% 的折扣（具体以官方定价为准），适合不需要即时响应的任务：数据标注、内容生成、邮件分类、历史数据分析等。

批处理的代价是延迟——通常 24 小时内返回。如果任务本身就不需要实时响应，这 50% 的折扣是免费拿的。

✅ 16. 合并小请求

如果你有 100 条短文本需要分类，不要发 100 个单独请求，而是合并成 1 个请求，每条文本 + 期望输出格式放在一起。这样可以节省每次请求的 System Prompt 开销（只付 1 次而不是 100 次）。

具体实现：

# 低效：100 个请求，每个都有 System Prompt
for text in texts:
    classify_single(text)

# 高效：1 个请求处理所有文本
classify_batch(texts)  # 在 prompt 里处理所有 100 条

✅ 17. 实现请求队列和速率控制

避免突发大量请求导致触发速率限制，从而引发重试和额外成本。使用令牌桶算法控制发送速率，尤其是在批量处理场景。

✅ 18. 对相同输入做请求去重

如果你的系统中有大量相同或相似的请求（比如常见问题的回答），在应用层做去重，相同的请求直接返回缓存结果，不重复调用 API。

五、应用层缓存

✅ 19. 实现语义缓存

不是只对完全相同的输入缓存，而是对语义相似的输入也返回缓存结果。工具：GPTCache、SemanticCache。适合问答类应用，对代码生成类应用谨慎使用（代码正确性对细节更敏感）。

✅ 20. 设置合理的缓存 TTL

问答缓存不能永久有效，因为背景信息会过时。根据内容的时效性设置 TTL：

  • 产品功能问答：7-30 天
  • 新闻摘要：1-24 小时
  • 法律/医疗信息：不建议长期缓存

✅ 21. 向量数据库存储历史推理结果

对于复杂的推理任务（比如文档分析、代码审查），把输入的 embedding + 输出结果存入向量数据库。新输入先做相似度匹配，足够相似时直接返回历史结果。

六、监控与告警层

✅ 22. 按功能模块拆分成本追踪

不要只看总 token 消耗，而是按 API 端点 / 功能模块 / 用户分组统计。这样才能发现”哪个功能模块是成本黑洞”。

实现方式：在请求 metadata 里加 module 标签，在日志和监控系统里按 tag 聚合。

✅ 23. 设置成本异常告警

每日 token 消耗超过基准的 150%，立即告警。常见触发原因：循环 bug（无限重试）、某个功能突然被大量使用、上游数据异常导致输入 token 暴增。

✅ 24. 记录 token 效率指标

不只记录成本，也记录”单位成本完成的业务量”。比如”每 $1 处理的文档数”或”每 $1 解决的工单数”。成本下降但业务量也下降，可能是质量问题导致的。

✅ 25. 定期做 token 用量分析

每月跑一次 token 分布分析：哪些请求的 token 用量远超平均值？是否有异常长的输入？是否有 prompt 配置错误导致输入重复？

七、架构层优化

✅ 26. 引入路由层，动态选模型

根据请求特征自动路由到不同模型：

def route_request(prompt, context):
    if len(prompt) < 200 and context.task_type == "classification":
        return "claude-haiku-4-5"  # 便宜模型
    elif context.requires_deep_reasoning:
        return "claude-opus-4-7"  # 最强模型
    else:
        return "claude-sonnet-4-6"  # 默认模型

路由规则可以基于规则引擎或者轻量分类器，成本基本可忽略。

✅ 27. 实现降级策略

当高级模型不可用或响应超时时，自动降级到低级模型（并在结果里标注）。这既提升可用性，也在故障时控制成本。

✅ 28. 对长文档任务做分段处理

不要把整个长文档塞进 context window，而是先做相关性筛选（用 embedding 或关键词匹配），只把最相关的段落传给模型。RAG（检索增强生成）的核心价值之一就是降低 token 成本。

✅ 29. 异步处理 + 结果复用

对于报告生成、数据分析等耗时任务，异步生成后存储结果，后续相同请求直接从存储读取。避免同一份分析被重复生成多次。

✅ 30. 定期审查和清理废弃功能的 API 调用

随着产品迭代，会有一些功能被废弃但 API 调用仍在跑（比如旧的推荐算法、A/B 测试的废弃分支）。每季度做一次清查，关掉不必要的调用。

优先级总结

按 ROI（收益/投入）排序，建议按以下顺序实施：

优先级措施预期节省实施难度
🔴 最高按任务选模型（#1-3）50-80%低
🔴 最高开启 Prompt Caching（#11-14）20-50%低
🟠 高批量 API（#15-16）50%中
🟡 中压缩 System Prompt（#5-6）10-30%低
🟡 中应用层缓存（#19-21）30-70%中
🟢 低架构层路由（#26-28）20-40%高

不要试图同时做所有 30 条。先把前 10 条做完，通常就能看到显著的成本下降。

相关阅读

系统性降低 AI API 成本，YoTradeApi 提供多模型统一接口和灵活的计费方式，支持按量付费，方便你在不同模型间做成本测试和路由优化。

相关阅读