到2026年年中，我们在生产环境中看到的最常见AI架构错误，就是为推理支付过高费用。团队发布LLM功能，看到它们正常工作，随后却收到随使用量增长的五位数月度账单。有些功能因此无利可图。有些公司甚至砍掉了原本通过更严格的成本管理就能持续运营的功能。
大多数LLM账单都远高于实际需要。节省并非来自某一种神奇技术，而是来自一组优化措施的叠加，其中每一项单独看都不算惊人。
本文介绍这些技术、具体数字和生产纪律。我们假定你已经完成基础模型路由（另一篇文章已有介绍）；这里会进一步深入。
成本构成
LLM成本来自：
- 输入token。 你发送给模型的内容，包括系统提示、上下文和用户查询。
- 输出token。 模型返回的内容。其价格通常是输入的4–6倍（按当前标价，Anthropic为5倍，OpenAI约为6倍——参见模型与定价参考，核验于2026-07-07）。
- 推理token。 对于推理模型，是内部的“思考”token，价格往往与输出一样高。
- 工具调用。 使用工具调用时，每个工具定义都会计入输入token。
- 重试。 失败的调用仍然会产生费用。
每一层都可以优化。
技术1：提示缓存
这是最大的单一杠杆。大多数现代提供商都会缓存重复的输入前缀——第一次按全价付费，之后使用相同前缀的调用则便宜得多。
典型定价：
- Anthropic：缓存输入约为正常成本的10%。
- OpenAI：自动匹配前缀，约为正常成本的50%（因模型而异）。
- Google：显式缓存内容，价格不一。
工作原理：首次使用特定输入前缀调用模型时按正常价格计费。在缓存窗口内（通常为5–60分钟，取决于提供商），后续调用会复用缓存的表示。
实际实现：
组织提示时，将静态内容放在前面，动态内容放在最后：
[已缓存：10K token]
- 系统提示
- 工具说明
- 用户的静态资料
- 不太可能在每次调用时变化的知识库片段
[未缓存：1K token]
- 对话历史（每轮都会变化）
- 当前用户查询
前10K token会在首次调用后缓存。后续调用只需为它们支付约10%的费用，而1K token仍按全价计费。
节省示例：
不使用缓存：
- 11K输入token × €3/百万 = 每次调用€0.033。
- 每天100K次调用 = 每天€3,300。
使用缓存（90%的输入已缓存）：
- 1K全价 + 10K按10%缓存价：
- 1K × €3/百万 + 10K × €0.30/百万 = €0.003 + €0.003 = 每次调用€0.006。
- 每天100K次调用 = 每天€600。
节省82%。 这是真实系统中的真实数字。
实施纪律：
- 识别提示中的静态部分与动态部分。
- 将静态部分放在前面。
- 在提供商支持时使用缓存标记（Anthropic），以便显式控制。
- 测试缓存命中——可观测性系统应显示缓存命中率。如果命中率低，说明提示结构不正确。
这是投资回报率最高的优化。先实施它，再做其他优化。
技术2：模型路由
其他文章已有详细介绍。简而言之：根据复杂度，将不同请求交给不同模型。
- 60%的请求交给小模型。
- 30%交给中档模型。
- 10%交给旗舰模型。
与所有请求都使用旗舰模型相比，通常可节省60–80%。
再结合缓存，相较于朴素基线，节省幅度可达90%以上。
技术3：输出长度控制
在大多数使用场景中，输出token是成本的主要部分。它们的价格通常是输入的4–6倍；数量由模型和提示决定；而且往往比实际需要更长。
策略：
明确的长度指令。
回答不超过100字。
模型通常能够较好地遵循。这可以显著降低输出成本。
结构化输出。
当面向用户的响应是简短的结构化数据（包含特定字段的JSON）时，输出长度有明确边界，不会出现不必要的冗长内容。
max_tokens 参数。
务必设置，不要保留默认值。如果200 token足够，就将上限设为250（留一点余量）。模型无法超出这一限制。
格式约束。
“仅使用项目符号”或“仅用一个段落”，都会比自由格式生成更短的输出。
用项目符号代替长段落。
传达相同信息时，项目符号通常只需长段落一半的token。
不要开场白。
“跳过引言，直接回答。”模型常以“好问题……”或“让我解释一下……”开头——这些都是浪费的token。
节省示例：
某个摘要工作流。默认输出：500 token。约束后：200 token。
- 500 token × €10/百万 = 每次调用€0.005。
- 200 token × €10/百万 = 每次调用€0.002。
输出成本节省60%。没有缓存带来的90%那么显眼，但它作用于最大的成本项。
技术4：输出采样与提前停止
在某些使用场景中，你不需要完整的LLM输出，只需要一个决策或分类结果。
使用logprobs进行分类。
# Use a small NON-reasoning model here: reasoning-family models
# (GPT-5.x thinking tiers and similar) reject logprobs/logit_bias.
response = openai.chat.completions.create(
model=SMALL_NON_REASONING_MODEL,
messages=[{"role": "user", "content": prompt}],
logprobs=True,
top_logprobs=5,
max_tokens=1
)
# Read logprobs of first token to determine likely category
你只要求模型输出一个token（类别）。成本是一次输入处理加1个输出token。速度更快、成本更低，而且效果通常不逊于较长响应。
Logit bias。
对于固定集合的输出，让logits偏向有效选项。
import tiktoken
enc = tiktoken.encoding_for_model("gpt-4o-mini")
# logit_bias keys are token IDs (as strings), not words.
bias = {str(enc.encode(w)[0]): 100 for w in (" yes", " no", " maybe")}
response = openai.chat.completions.create(
model="gpt-4o-mini",
messages=[...],
logit_bias=bias,
max_tokens=1,
)
这会促使模型输出正确类型的结果。用于分类时既便宜又可靠。
技术5：批处理
处理大量项目时，应使用批处理。
API层面的异步批处理。
大多数提供商都支持异步或批处理API，可以以更低成本处理多个请求。
- OpenAI Batch API：优惠50%，SLA为24小时。
- Anthropic Message Batches：优惠50%，SLA为24小时。
如果积压任务不需要实时响应，就通过批处理运行。成本减半。
提示内批处理。
在可行时，通过一次LLM调用处理多个项目。
不要这样做：
[10次单独调用，每次对一个工单分类]
而是这样做：
[1次调用，在一个提示中对10个工单分类]
单次调用的输入更多（10个项目），但固定开销（系统提示、工具说明）只出现一次。总token数少于10次单独调用。
注意：每个提示中的项目过多时，质量可能下降。请为你的使用场景测试最佳点。通常每个提示处理5–20个项目没有问题。
技术6：窄任务使用更小的模型
除了标准路由，还要考虑任务是否真的需要大模型。
分类： 对于简单分类，小档模型通常能达到旗舰模型的效果。按当前标价（核验于2026-07-07）：Claude Haiku 4.5为每百万输入/输出$1/$5，Claude Opus 4.8为$5/$25，固定节省5倍；OpenAI小档模型与GPT-5.5之间也有相近倍数。
提取： 中档模型能够完成结构化提取。只把失败案例交给旗舰模型。
翻译： 专用翻译模型或较小的LLM足以处理大多数情况。
嵌入： 使用专门的嵌入模型，不要用通用LLM生成嵌入。
模式是：识别“简单、窄范围”的工作负载，将其路由到能够充分完成任务的最小模型。把旗舰模型留给复杂且需要大量判断的工作。
技术7：微调小模型
对于吞吐量极高的窄任务，可以微调小模型。
示例：每天100K个分类请求。
- 未修改的GPT-5：API成本为每天€30。
- 在专用推理设施上运行微调后的8B模型：推理成本为每天€5–10，另加一次性微调成本。
达到足够规模后，微调小模型很快就能收回成本。具体计算取决于你的请求量。
微调文章已介绍过这一点。原则是：当规模与任务窄度同时具备时，微调就是成本杠杆。
技术8：预过滤
对于多步骤LLM工作流，先用廉价过滤捕获明显案例，再进入昂贵处理。
示例：客户支持分类与回复。
廉价预过滤：
- “这是真正的支持问题，还是垃圾/噪声？”（使用小模型进行单token分类。）
- “这是已知常见问题吗？”（嵌入搜索；成本低。）
只有通过过滤的请求才会进入昂贵的回复生成环节。
节省：如果传入请求中有30%是噪声或可由常见问题解答，就能消除30%的昂贵调用。
与回复生成（每次调用€0.05）相比，预过滤很便宜（每次调用€0.0001）。投资回报显而易见。
技术9：提示缓存之外的缓存
除模型提供商的提示缓存外，还可以进行应用层缓存：
响应缓存。 相同查询、相同上下文、相同响应。缓存结果并直接返回，无需调用模型。
def cached_call(prompt, model, ttl=3600):
cache_key = hash(prompt + model)
cached = redis.get(cache_key)
if cached:
return cached
response = call_llm(prompt, model)
redis.set(cache_key, response, ttl=ttl)
return response
对于幂等查询，这会彻底消除重复调用。
嵌入缓存。 缓存已计算的嵌入。
检索结果缓存。 在短时间内缓存某个查询的搜索结果。
工具结果缓存。 如果底层数据不经常变化，就缓存工具调用结果。
缓存可以逐层叠加。每一层都能减少调用。
技术10：推测执行
对于能够预测后续步骤、且对延迟敏感的流程，可以推测性地提前调用。
示例：客户支持智能体。客户描述问题后，你知道下一步通常是“总结问题”。在向用户显示确认消息的同时，并行启动摘要。
如果预测正确，需要时响应已经准备好。如果预测错误，就浪费了一次调用。
这更偏向延迟优化而非成本优化，但对某些流程而言，它能显著改善用户体验。
技术11：提供商套利
不同提供商对类似模型的收费不同。利用这种差异。
在廉价推理提供商上运行开源模型。
Together AI上的Llama 3.3 70B：输入和输出均为$0.88/M（标价，核验于2026-07-07）。 与其竞争的闭源模型档位Claude Sonnet 5：输入$3/M，输出$15/M（截至2026-08-31的首发价为$2/$10）。
对于开源70B模型足以胜任的任务，输入约便宜3.4倍，输出约便宜17倍——根据输入/输出比例，可概括为3–17倍。
不同提供商上的同一模型。
有些开源模型由多家提供商托管，价格各不相同。货比三家。
规模化自托管。
达到足够规模时（例如某一特定模型每月支出€10K以上），自托管会比API调用更便宜，但需要运维能力。
提供商套利会增加复杂度：需要多提供商路由和故障回退，还要对每个提供商的模型变体进行质量测试。在规模足够大时值得这样做。
技术12：推理加速
对于自托管，需要优化推理层本身。
vLLM、TGI、SGLang。 优化过的推理服务器。吞吐量比朴素实现高2–10倍。
量化。 以更低精度（4位、8位）运行模型。吞吐量提升2–4倍，质量略有损失。
Flash Attention、分页注意力。 现代服务器中启用的架构优化。
连续批处理。 对执行中的请求进行批处理，以提高GPU利用率。
对于规模化自托管的团队，这一点很重要。使用API的团队则由提供商处理。
技术13：流式传输
流式传输不会减少token数，但能改善用户体验，从而影响用户对成本效益的感受。
对于较长输出，用户会立即看到内容逐步出现，并可在生成完成前开始阅读。相比等待完整响应，体感快得多。
对于智能体，流式展示中间步骤能让用户了解进度。
实现方面：所有现代API都支持流式传输。面向用户的流程应使用它。
技术14：预算护栏
除了优化，还要强制执行硬预算，防止成本失控。
单请求预算。 每个请求允许的最大token数，超出时停止。
单用户预算。 每个用户的每日或每月成本上限，接近上限时限流。
单功能预算。 每个功能都有预算；达到日均值的10倍时自动关闭。
全局预算。 每日/月度总上限；接近上限时暂停非必要工作。
这些措施不会直接省钱，但能防止灾难。如果没有护栏，一个bug或一次攻击就可能迅速推高成本。
完整示例：一次真实的成本削减
某团队运行的客户支持AI每月账单为€12,000。应用这些技术六个月后，账单降至每月€1,800，减少了85%。
具体变更：
-
提示缓存。 重构提示以最大化静态前缀。现在约70%的输入会被缓存。节省约30%。
-
模型路由。 将分类和工单分流从Claude Sonnet迁移到Claude Haiku。节省约15%。
-
输出长度控制。 将原先800–1500字的回复限制为250字。节省约25%。
-
预过滤。 使用廉价分类捕获可由常见问题解答的工单，并通过缓存提供答案。约20%的工单不再进入昂贵流程。节省约10%。
-
常见问题响应缓存。 相同问题返回缓存响应。节省约5%。
列出的百分比，是每种技术在最终降幅中所占的份额——合计约为整体85%。每一项都是相对于应用上一项变更后剩余的账单测得，并不是可以独立套用到你账单上的乘数。
质量：按所有已测量指标（客户满意度、响应正确性、解决率）来看，质量没有变化或略有改善。
运维成本：3个月内约80小时工程工作。投资回报：2周收回成本。
常见错误
我们经常看到以下模式：
错误1：不跟踪成本。 团队无法了解每个功能、用户或调用的成本。没有测量，就无法优化。
错误2：优化错了对象。 花数周把输入token减少5%，而输出token却占账单的80%。先测量，再优化最大的成本来源。
错误3：质量退化。 削减成本时没有监控质量。省了钱，却失去了用户。成本工作必须始终与评估套件配套。
错误4：过度路由。 激进地把任务路由给实际无法胜任的小模型。这是假节省。
错误5：缓存污染。 缓存被罕见查询填满，大多数缓存条目只使用一次，未命中占主导。需要更好的缓存策略。
错误6：跳过批处理API。 本可批处理却坚持实时，白白放弃半价优惠。
错误7：过度工程化。 在本来就无利可图的功能上构建复杂的成本优化。有时正确答案就是“砍掉这个功能”。
错误8：没有预算护栏。 一个bug就会导致成本失控，小麻烦演变成灾难。
文化因素
成本纪律有一部分是文化问题。成功的团队会：
- 将成本视为指标，而不是事后才考虑的问题。
- 明确负责人（通常是工程与财务交界处的成员）。
- 在每周指标中审查成本。
- 立即调查异常增长。
- 为每个功能设置预算，并在越过阈值时发出警报。
- 明确做出取舍（成本、质量与延迟）。
做不到的团队则会：
- 把成本视为别人的问题。
- 到月底才发现账单。
- 在成本激增后才被动应对。
- 没有预算概念。
- 跳过取舍讨论，一次只优化一个维度。
文化改变比技术改变更难，但正是它让技术变更得以持续。
定价趋势
再谈谈更广泛的趋势。
单位能力的成本逐年大幅下降——主要原因是更小的模型不断追平昨日的旗舰，而不是旗舰模型标价大幅下跌。任何“明年价格”的数字都应视为建模假设，引用前请重新核对模型与定价参考。
这意味着：
- 有些优化会随时间推移变得不那么重要（绝对成本本身也在下降）。
- 有些目前无利可图的工作负载将会变得可盈利。
- 为长期构建：清晰架构 > 眼下榨干每一分钱。
话虽如此，即使价格下降，优化仍然重要。低效系统在任何价格水平都会浪费钱。竞争优势也往往属于那些能以更低成本高效运营的团队。
90天成本优化计划
对于处于“我们有一个AI功能，但成本高于预期”阶段的团队：
第1–2周：测量。
- 检测每次调用的成本。
- 构建按功能、按用户划分的仪表板。
- 找出最大的成本来源。
第3–4周：快速见效。
- 在支持的地方启用提示缓存。
- 重构调用量最高的3个提示，以最大化缓存命中率。
- 为所有调用设置max_tokens。
- 实施预算警报。
第5–6周：路由。
- 识别当前使用旗舰模型的简单任务。
- 为调用最多的3–5个端点构建路由器。
- 测试质量是否退化。
第7–8周：输出与缓存。
- 在不面向用户的场景中约束输出长度。
- 为常见查询添加应用层响应缓存。
- 为最高吞吐量的流程添加预过滤器。
第9–10周：高级优化。
- 非实时工作使用批处理API。
- 评估替代提供商。
- 添加嵌入缓存、检索缓存。
第11–12周：加固。
- 为每个功能设置预算护栏。
- 将成本仪表板纳入团队常规审查。
- 记录相关模式，供未来功能使用。
90天结束时：现实目标是成本降低50–80%，同时监控质量并建立成本纪律。
先测量，再叠加节省
LLM成本是可以降低的——通常可在不损失质量的情况下减少60–90%。相关技术已广为人知：缓存、路由、输出控制、批处理、预过滤、响应缓存、模型选择和预算护栏。
孤立使用时，每项技术只能带来有限节省。结合使用时，效果会叠加成显著的成本降幅。
做对这件事的团队，能让无利可图的AI功能转为盈利。做不到的团队，最终不得不砍掉原本可以持续运营的功能。
先测量。优化最大的成本来源。持续监控质量。把成本纪律纳入团队的日常工作。
最终得到的是在经济上和技术上都能扩展的AI功能。正是这一点，让AI成为产品中可持续的一部分，而不仅仅是发布时的宣传标题。
