一个公式抓住本质

LLM API 成本 = (输入 token + 输出 token) × 单价

每一个优化杠杆，要么减少 token，要么降低单价。 这就是全部。

杠杆一：模型分层路由（收益最大）

不是每个 prompt 都需要最强模型。

这是多数项目能省下 60% 以上 的单项操作。

                  [ 用户请求 ]
                        │
                        ▼
                ┌───────────────┐
                │  语义意图路由  │
                └───────┬───────┘
        ┌───────────────┼───────────────┐
        ▼               ▼               ▼
   简单任务         分类抽取         复杂逻辑
        │               │               │
        ▼               ▼               ▼
   小模型          中档模型         旗舰模型
  (微调 SLM)      (mini/haiku)   (sonnet/gpt-4o)

小模型在窄而明确的任务上可以匹敌旗舰（分类、抽取）。它们在长程推理和复杂代码生成上才会落后。

所以按任务路由，不要一刀切降级。 保留旗舰作为低置信度场景的 fallback，而不是全部切换。

杠杆二：管好上下文

这是纯工程手段，收益不依赖换模型。

一个具体的数字感受：把 system prompt 缩短 150 token，在百万次请求下就是省下 1.5 亿 token。

审查你的 prompt，要像审查任何热点代码路径一样。

杠杆三：设置输出硬上限

输出 token 的单价通常是输入的数倍。

这意味着限制回复长度往往比缩短 prompt 更省。而不设上限的 max_tokens 是你能上线的最贵的默认值之一。

一个模型在你不允许它发挥的时候是无法发挥的。硬上限是最简单的杠杆。

澄清一个常见误解：流式输出不省钱。 流式改变的是响应送达方式，不改变模型生成多少 token，计费完全一样。流式用于改善感知延迟，降本要靠限制输出长度。

杠杆四：多级缓存

精确缓存

确定性请求走精确缓存。用完整的规范化请求做 key，TTL 与答案需要的新鲜度匹配，可缓存任务用低温度以确保相同输入产出相同输出。

不要缓存按用户个性化的内容，除非 user ID 是 key 的一部分。

语义缓存

自然语言变化太大，纯字符串匹配失效：

• "如何重置我的密码？"

• "在哪改密码？"

语义缓存的做法：把用户 prompt 向量化，查询向量库看是否存在超过相似度阈值（如 0.95）的语义等价查询，命中则直接返回。

在典型客服或搜索密集型应用中，语义缓存可以减少 20-35% 的总请求量，延迟降到 50ms 以内、接近零 token 成本。

前缀缓存

这是最被忽略但最容易用的一种。

很多 API 提供 prompt caching：当系统提示、few-shot 示例、稳定上下文被反复发送时，服务端识别相同或可复用的稳定前缀，按折扣价计费。

工程要求很简单：把稳定前缀放最前面，变化的部分往后放。

一个团队可以做到的前提是：system prompt 保持不变、前缀稳定、把变化的部分往后放。 当成本差距主要来自缓存命中与否时，优化目标会从"怎么写 prompt"转移到"怎么让上下文可缓存"。

杠杆五：批量处理

独立的调用打包成更少的请求。很多 API 对批量请求提供折扣。

适用：离线处理、索引构建、预计算。不适用：需要低延迟的交互式场景。

杠杆六：微调让调用变便宜

微调的成本结构和其他杠杆不同：

判断标准：这是一个固定、高频、模式明确的任务吗？如果是，把它微调到小模型上，长期成本会低得多。

自托管开源权重模型还有一个结构性优势：成本是可预测的固定月费，而不是随 token 用量线性增长的 API 计费。

成本驱动的排查顺序

这五个快速打分，能让多数团队立刻看出该从哪里下手。

预算与护栏

保护账单不被滥用和失控消耗。

生产环境的 AI 功能不是跑完就放的脚本。 它需要和栈里其他部分一样的运营管控。

质量与成本必须一起测

省下的钱如果伴随质量崩塌，一分都不值。

"每个完成的任务成本"才是最早暴露浪费的指标。 按请求计费会让你误判——一次昂贵的长对话可能只完成了一个任务。

上线前的成本预算方法

按任务估算成本，不是按请求。

1. 跑 100 个有代表性的请求
2. 取平均 token 数
3. 乘以预期的月任务量
4. 加 20-30% 的余量（重试、边界情况、增长）

一个具体的降本案例

一个团队的完整改造路径：

效果几乎没打折。 关键是前三步都只是工程手段，不需要换模型、不需要改架构。

什么时候值得为更大的模型付钱

成本是一方面。有时候更大的模型就是正确的支出。