LLM 降本增效，省钱才是硬道理

从 Prompt 缓存、语义缓存、缩短 Token，到模型路由、蒸馏、量化与观测层，这篇文章系统解释了为什么 LLM 会烧钱，以及如何用 8 个工程化手段把 API 成本显著降下来。

很多团队第一次做 LLM 产品时，最容易忽略的一件事就是：模型不是按“问题难度”收费的，而是按 Token 收费的。

例如，某创业公司做了一个客服机器人，它每天都要回答同样的几十个问题。结果到了第二个月，OpenAI 账单已经涨到 14000 美元。不是因为产品有多复杂，而是因为团队从一开始就没有认真设计调用成本。

AI 世界最反直觉的事实之一是：即便你只是拿顶级模型回答一个非常简单的问题，也一样会被完整计费。

这篇文章想回答的核心问题是：

• 为什么 LLM 比预期更容易烧钱。
• 为什么现代 AI 应用，尤其是 Agent 类产品，会把这个问题放大。
• 面对不同业务场景，应该优先使用哪些降本手段。

一、LLM 到底是怎么收费的

在谈优化之前，必须先理解 LLM 的计费模型。

绝大多数 LLM API 都按 Token 收费，Token 可以粗略理解为文本切分后的最小计费单元，英文大约每 4 个字符对应 1 个 Token。

付费的部分通常有两类：

• 输入 Token：发给模型的所有内容，包括系统提示词、上下文、用户输入。
• 输出 Token：模型返回的所有内容。

而且，输出 Token 往往比输入 Token 更贵，常见区间是 2 到 4 倍。

2025 到 2026 年的近似价格区间可以概括为：

模型档位	输入价格（每百万 Token）	输出价格（每百万 Token）
Frontier 顶级模型	$5 -$15	$15 -$75
Mid-tier 中档模型	$0.50 -$3	$1.50 -$15
Small/Fast 小型快速模型	$0.10 -$0.50	$0.30 -$1.50
Open-source 开源自托管	主要是算力成本	主要是算力成本

一个常见的例子是，如果你的系统提示词有 2000 个 Token，每天处理 10000 次请求，那么你每天仅仅为了重复发送系统提示词，就在支付 2000 万输入 Token 的费用。

不是业务复杂，不是用户太多，而是把同样的提示词一遍又一遍地重新计算了。

二、Agent 应用真正烧钱的地方

普通聊天机器人已经不便宜了，Agent 应用则又要贵上一个量级。

原因很简单：Agent 不会只发起一次 API 调用，而是会循环。

• 调一次模型，判断任务意图。
• 调一次工具，读数据库或调用外部服务。
• 再调一次模型，分析工具返回结果。
• 再调一次模型，把结果格式化成用户可读输出。

一个单次任务的成本拆解如下：

用户请求：“总结上个月的销售表现”

步骤 1：调用 LLM 识别意图            -> 约 800 tokens
步骤 2：调用数据库工具                -> 返回 5000 tokens 数据
步骤 3：调用 LLM 分析数据             -> 6000 tokens 输入，1500 tokens 输出
步骤 4：调用 LLM 格式化响应           -> 2000 tokens 输入，800 tokens 输出

总计：单次查询约 10000 tokens

如果按 GPT-4o 这类模型价格估算，单次查询大约 $0.06。一个月 50000 次，就是约 3000 美元，而这还只是一个功能。

更糟的是，真实 Agent 往往还有记忆、上下文注入、多步推理、工具错误恢复等额外环节，单次任务烧掉 30000 到 100000 Token 并不罕见。

问题不在于 Agent 用了 LLM，而在于很多 Agent 对每一步都默认使用昂贵模型，不做缓存，也不判断“这一步到底值不值得用顶级模型”。

三、LLM 费用失控的 5 个根因

最常见的资金流失有 5 类原因：

• 重复计算相同前缀：同一个 2000 Token 的系统提示，每次都从头算。
• 重复回答同类问题：像“营业时间是什么”这样的 FAQ，每次都完整跑一次推理。
• 用顶级模型处理普通任务：并不是每个任务都需要 GPT-5 级能力。
• 提示词太啰嗦：本来 400 Token 能说清楚的系统提示，实际写成了 2000 Token。
• 输出失控：你只需要 3 个要点，却让模型输出“详细分析”。

接下来的 8 个技巧，就是分别针对这些根因给出的解决方案。

四、8 个真正能省钱的技巧

技巧 1：Prompt Caching，也叫 Prefix Caching

它解决的问题是：你正在为系统提示词的重复计算反复付费。

LLM 内部在处理输入时，会把每个 Token 经过注意力机制计算成一组可复用的中间状态。如果下一次请求的前 2000 个 Token 完全一样，但系统还是从零开始重新计算，那你就是在为同一个前缀多次付费。

Prefix Caching 的思路，就是把这个重复前缀的计算结果缓存起来。后续请求只要共享这个前缀，就可以直接从缓存状态开始。

原文给出的定价示例：

• Anthropic 的缓存写入价格大约是基础输入价的 125%。
• 后续缓存读取价格约为基础输入价的 10%，相当于便宜了 90%。
• 理论上的回本点大约只需要 2 次命中。
• OpenAI 对重复前缀提供自动缓存，重复 Token 可享受约 50% 折扣。

要最大化缓存命中率，提示词结构必须改成：静态内容在前，动态内容在后。

错误顺序：
[用户消息]        <- 每次都变
[系统提示]        <- 每次相同

正确顺序：
[系统提示]        <- 静态，可缓存
[Few-shot 示例]   <- 静态，可缓存
[检索文档]        <- 会话内相对稳定，可缓存
[用户消息]        <- 动态，放最后

实际效果是：一个 RAG 应用如果每次都附带 3000 Token 文档，单靠前缀缓存，就可能把输入成本降掉 80% 到 90%。

技巧 2：语义缓存（Semantic Caching）

它解决的问题是：用户换个说法问同一个问题，你却每次都做一遍完整推理。

语义缓存不是比对字符串，而是比对语义相似度。

一个典型流程如下：

1. 用户请求到来，比如“怎么重置密码？”
2. 系统先把这个问题编码成向量表示。
3. 到向量库里检索相似的历史问题。
4. 如果余弦相似度高于某个阈值，比如 0.93，就直接返回缓存答案。
5. 如果找不到合适匹配，再调用 LLM，并把结果存入缓存。

这样，“我忘记密码了”和“怎么修改密码”就可以命中同一条缓存结果。

实际生产环境数据如下：

• 客服应用：缓存命中率通常有 40% 到 60%。
• FAQ 聊天机器人：命中率可以达到 70% 到 80%。
• Redis LangCache 在高重复负载下报告过 73% 的成本下降。
• 缓存响应时间通常是毫秒级，而不是重新推理所需的秒级。

适合起步的工具包括：

• GPTCache：开源，集成 LangChain，后端灵活。
• Redis + Vector Search：生产可用，并发能力强。
• pgvector：如果你本来就在用 Postgres，这是很自然的选择。

需要注意的是阈值校准。阈值太低，会返回错误缓存；阈值太高，又会损失大部分节省空间，建议从 0.93 开始试。

技巧 3：减少 Token 用量

它解决的问题是：你发送的 Token 比必要的多，而在规模放大后，这些“多一点点”都会变成真金白银。

尤其要注意，输出 Token 往往比输入 Token 更贵。所以控制输出长度，本质上就是直接控制成本。

有 3 个最实用的做法。

1. 强约束输出格式。

# 可能花掉约 800 个输出 Token：
"Analyze this customer feedback and share your thoughts."

# 可能只需约 60 个输出 Token：
"""
Analyze this feedback.
Respond ONLY with:
{
  "sentiment": "positive/negative/neutral",
  "key_issue": "one sentence max",
  "action_needed": true/false
}
"""

2. 压缩系统提示词

原文举了一个非常典型的例子：

压缩前（28 tokens）：
You are a helpful customer service assistant who always remains
professional, responds clearly, and never provides inaccurate information.

压缩后（11 tokens）：
Role: Customer service. Rules: Professional. Accurate. Clear.

单次请求节省不大，但如果你每天有成千上万次调用，差异会非常可观。

3. 在 RAG 系统里压缩上下文

原文提到 Microsoft 的 LLMLingua，可以在尽量保留语义的前提下，把检索上下文压缩到原来的 $\frac{1}{20}$ 左右。对于长文档检索型应用，这对输入成本的帮助非常明显。

技巧 4：使用更小的模型，或开源模型

核心洞察只有一句话：不是每个问题都值得用高级模型。

把工单分成 5 类，不需要 GPT-4。抽取结构化表单里的 3 个字段，也不需要 Claude Opus。总结一个格式固定的报告，更没必要动用最强推理模型。

价格对比：

GPT-4o:      $5.00 / 百万输入 Token
GPT-4o-mini: $0.15 / 百万输入 Token

价格差：33 倍

如果一个更小的模型已经能在 95% 的请求上满足质量要求，那你其实是在为剩下 5% 的边缘场景，多付 33 倍的价格。

几种适合生产使用的开源选项：

• Llama 3.1 8B / 70B（Meta）：通用能力强，可自托管。
• Qwen 2.5 7B（阿里）：代码与推理任务表现突出。
• Mistral 7B：速度快，适合分类和简单抽取。
• Phi-3.5 mini（微软）：参数量约 3.8B，性价比高。

如何评估？建议非常务实：准备 100 条具有代表性的测试样本，逐个跑不同大小模型，选出那个刚好能通过 90% 以上质量门槛的最小模型。

技巧 5：模型路由（Model Routing）

它解决的问题是：你正在用昂贵模型处理本该交给便宜模型的请求。

模型路由的基本思路，是先对请求做分级，再发给合适档位的模型。

请求进入
   ↓
分类器（规则或小模型）
   ↓
简单请求（50% - 70%） -> 便宜模型
中等请求（20% - 35%） -> 中档模型
复杂请求（5% - 15%）  -> 顶级模型

常见的路由信号包括：

• 请求长度：短问题通常不需要顶级模型。
• 关键词：如 analyze、compare、reason through 往往意味着更高复杂度。
• 任务类型：分类、抽取适合小模型；多步推理适合大模型。
• 预期输出长度：如果答案只需要一个词，就不必上高价模型。

原文提到，在多个企业部署案例中，模型路由加缓存一起使用，常见能带来 40% 到 60% 的成本下降。

但有一个重要提醒：路由策略一定要保守起步。只有在你高度确信请求简单时，才把它下放到便宜模型。否则错误路由会直接导致输出质量明显下降。

技巧 6：模型蒸馏（Model Distillation）

它适合的场景是：有一个高频、明确、单一的任务，需要接近顶级模型的效果，但又承担不起顶级模型的长期价格。

蒸馏的思路，是让一个小模型专门学会某个大模型在特定任务上的行为模式。

典型流程是：

1. 用顶级模型跑成千上万条代表性输入。
2. 收集输出结果，最好连概率分布一起保留，而不仅是最终答案。
3. 用这些数据训练一个更小的模型。
4. 让小模型复现大模型在该任务上的决策模式。

经典例子是 DistilBERT：它在参数量减少 40% 的前提下，仍保持了约 97% 的 BERT 性能，而且运行速度快约 60%。

什么情况下适合蒸馏：

• 任务单一且定义清晰。
• 能生成足够多的高质量样本。
• 团队有训练与评估的工程资源。
• 请求分布相对稳定，不会天天变。

什么情况下不适合：

• 通用型助手，输入范围过于宽泛。
• 无法定义清晰质量指标的任务。
• 调用量很小，不值得投入蒸馏工程。

一项 2025 年的研究认为，压缩的最佳顺序通常是：剪枝 $\rightarrow$ 蒸馏 $\rightarrow$ 量化。先删冗余参数，再恢复性能，最后进一步降低推理成本。

技巧 7：量化与剪枝（Quantization and Pruning）

对于自托管模型的团队，这往往是最先应该做的优化。

模型训练时通常用 32 位浮点权重，推理时可以把它压缩到 8 位甚至 4 位整数。损失的是一点点精度，换来的是大幅下降的显存占用和算力成本。

以 Llama 3.1 70B 为例：

FP16: 约 140 GB 显存，需要多张 GPU
INT8: 约 70 GB 显存，单张 A100 有机会承载
INT4: 约 35 GB 显存，甚至能放到消费级硬件

GPU 越少，云成本越低，这就是量化的基础设施价值。

极简实现示例如下：

from transformers import AutoModelForCausalLM

model = AutoModelForCausalLM.from_pretrained(
    "meta-llama/Meta-Llama-3-8B",
    load_in_8bit=True,
)

剪枝的作用则是删除网络中冗余连接。一个采用 2:4 稀疏化的 Llama 模型，在准确率恢复到 98.4% 的同时，实现了约 30% 更高吞吐和 20% 更低延迟。

量化和剪枝并不冲突，组合使用通常能得到更好的压缩效果。

技巧 8：建立观测与评估层

无法优化看不见的东西。

很多团队只看“这个月一共花了多少钱”，这远远不够，真正需要知道的是：

• 哪些提示词最贵。
• 哪些请求高度重复，本来应该被缓存。
• 在不断优化之后，输出质量有没有同步下降。
• 哪些功能、用户群或调用场景在吞噬大部分预算。

一个最低可用的成本跟踪示例：

def track_llm_call(model, prompt, input_tokens, output_tokens):
    cost = calculate_cost(model, input_tokens, output_tokens)
    log({
        "model": model,
        "input_tokens": input_tokens,
        "output_tokens": output_tokens,
        "cost_usd": cost,
        "prompt_category": classify_prompt(prompt),
        "timestamp": now(),
    })

长期来看，这样的观测层会告诉你：

• 哪 10% 的提示词类型，制造了 60% 的成本。
• 缓存命中率到底有没有你想象中那么高。
• 某次模型升级之后，你的成本结构有没有悄悄变坏。

推荐工具包括：

• Helicone：实时查看 LLM 调用成本，适配 OpenAI 和 Anthropic。
• LangSmith：对 LangChain 应用有很强的链路追踪能力。
• Langfuse：开源，适合对数据隐私有要求的团队。

另外一个非做不可的动作，是在 API 层设置硬性支出上限。因为如果 Agent 出现循环 Bug，没有预算上限时，账单失控的速度会非常惊人。

五、先做什么？原文给了一个决策矩阵

常见场景与建议的决策如下表所示：

场景	建议先做什么
高流量、提示词稳定	Prefix Caching -> Semantic Caching
用户问题高度重复	先做 Semantic Caching
系统提示或上下文特别长	先做 Prompt Compression，再做 Prefix Cache
所有请求都在用顶级模型	模型路由 + 更小模型
自托管模型	立刻做量化
单一且高频任务	评估蒸馏
Agent 多步工作流	模型路由 + 步骤级缓存
几乎没有成本可见性	先补观测层

对于大多数团队，建议实施顺序是：

1. 第 1 到 2 周：先做 Token 缩减和观测层。理由很简单，不需要复杂基础设施，能立即看到节省效果。
2. 第 3 到 4 周：做模型路由和更小模型替换。先从保守分类开始，风险较低。
3. 第 5 到 6 周：做 Prefix Caching。很多提供商已经支持，通常只需要工程配置调整。
4. 第 7 到 8 周：做 Semantic Caching。它需要向量库等额外基础设施，但在规模上来后非常值得。
5. 更后面：再评估蒸馏和量化。这些属于更偏重工程投入、适合高流量场景的优化。

六、复利效应

这些优化技巧不是简单相加，而是叠加放大的。

以客服应用为例，如果 8 种优化都做对了，现实中完全可能出现下面这种路径：

基线成本：                     100%
做完 Token 缩减后：             70%
做完模型路由后：               45%
做完 Prefix Caching 后：        20%
做完 Semantic Caching 后：       8%

最终成本：约为原来的 8%
总降幅：约 92%

这不是纸上谈兵，而是高流量、问题重复度高的应用中，很容易发生的工程结果。

七、关键洞察：成本问题，本质上是系统问题，不是模型问题

很多工程师看 LLM 成本时，第一反应是去翻价格页，想找一个“最便宜的模型”。

这恰恰抓错了重点。

真正的成本杠杆在四件事上：

• 发送了什么：Token 缩减、Prompt 压缩。
• 什么时候调用：缓存、评估层、避免无意义调用。
• 调用哪个模型：路由、小模型替代。
• 怎样运行模型：量化、蒸馏、自托管优化。

真正最大的节省空间，通常在前两项，也就是“发送什么”和“什么时候调用”。

一个 2000 Token 的系统提示，如果首轮之后能被缓存，而且 60% 的查询还可以被语义缓存直接命中，总成本完全可能低于一个每次都新鲜发送、虽然只有 200 Token 但始终调用高级模型的方案。

如果你要判断自己的系统应该从哪里开始，建议先回答 3 个问题：

1. 当前每次请求平均输入多少 Token？
2. 这些 Token 里，有多少是跨请求重复的？
3. 请求里有多少在语义上其实是重复问题？

只要这 3 个问题回答清楚，优化顺序通常就已经非常明朗了。

“AI 成本不是模型问题，而是工程问题。既然是工程问题，就一定有工程解法。”