推理成本是一项工作负载属性：模型和区域、未缓存和已缓存的输入、生成和推理的令牌数、工具、重试次数、并发性、存储以及人工审核都会影响成本。应从计费使用情况和追踪数据出发，而非基于行业节省声明进行估算。
当前价格和缓存规则经常发生变化。在使用任何成本模型之前，请重新检查官方的OpenAI定价、Anthropic定价和Gemini定价页面。
本文介绍这些技术、具体数字和生产纪律。我们假定你已经完成基础模型路由（参见多模型编排）；这里会进一步深入。
成本构成
LLM成本来自：
- 输入令牌。 发送给模型的内容。包括系统提示、上下文和用户查询。
- 输出令牌。 模型返回的内容。输入/输出的价格比例因供应商、模型、批量模式和缓存状态而异。
- 推理或隐藏计算费用。 供应商的报告和计费方式各不相同；应使用计费使用字段和当前价格表，而非假设与可见输出一致。
- 工具定义和工具使用。 模式可能会增加输入令牌，而托管工具或外部服务可能会有单独的费用。
- 重试和失败的工作。 某些失败或被放弃的调用会产生使用量；应从供应商的计费和追踪数据中分类失败点。
每一层都可以优化。
技术1：提示缓存
当请求共享一个符合条件的前缀且工作负载产生高命中率时，缓存可能显著降低成本。
阅读每个供应商当前的缓存文档，了解最小前缀大小、读写费用、过期时间、路由限制和可观测性。
总体而言，符合条件的重复前缀可能在供应商定义的时间窗口内被重复使用。但确切的语义在不同供应商之间不可移植。
实际实现：
组织提示时，将静态内容放在前面，动态内容放在最后：
[已缓存：10K token]
- 系统提示
- 工具说明
- 用户的静态资料
- 不太可能在每次调用时变化的知识库片段
[未缓存：1K token]
- 对话历史（每轮都会变化）
- 当前用户查询
该前缀是否符合资格以及如何计费取决于所选的模型和提供商。
节省公式：
daily cost = calls × (uncached input × input rate + cache writes × write rate + cache reads × read rate + output × output rate + tool charges)
用计费的令牌数量和当前的价格表填充它。比较等效的时间窗口，并包括缓存未命中情况。
实施纪律：
- 识别提示中的静态部分与动态部分。
- 将静态部分放在前面。
- 在提供商支持时使用缓存标记（Anthropic），以便显式控制。
- 测试缓存命中。可观测性系统应显示缓存命中率。如果命中率低，说明提示结构不合理。
只有在追踪显示重复的合格输入是主要成本项时，才优先进行缓存。
技术2：模型路由
其他文章已有详细介绍。简而言之：根据复杂度，将不同请求交给不同模型。
构建一个带标签的路由评估数据集，比较候选模型在质量和成本方面的表现，并为不确定或失败的情况保留一个回退方案。最终的路由组合是特定于工作负载的。
技术3：输出长度控制
输出令牌可能会成为主要成本项。在优化响应长度之前，请先在使用数据中确认这一点。
策略：
明确的长度指令。
回答不超过100字。
模型仍可能违反对文本长度的指令。应强制并评估限制，报告实际测量的令牌数和质量变化，而不是承诺显著的节省。
结构化输出。
当所需响应为简短的结构化数据时，严格的模式可以减少无关的叙述。但它不能消除无效输出、字段值过大、重试或截断的风险；请验证每一个结果。
提供方输出令牌上限。
根据实际任务需求测量并设置当前 API 的输出上限，并为有效完成留出余量。不同 API 和模型的参数名称和语义可能不同；过小的上限可能导致结构化输出被截断，并引发更多调用。
格式约束。
“仅使用项目符号”或“仅用一个段落”，都会比自由格式生成更短的输出。
用项目符号代替长段落。
项目符号可能减少某些响应中的连接性叙述。测量令牌数量；过于冗长的项目符号列表可能比简洁的段落更长。
不要开场白。
“跳过引言，直接回答。”模型常以“好问题……”或“让我解释一下……”开头，这些都会浪费 token。
测量示例：
在摘要工作流程中，对相同文档的默认输出和受限输出进行比较。报告计费输出令牌数、事实覆盖率、可读性、用户后续提问率以及任何截断情况。如果用户需要再次调用，令牌数较低并不意味着节省。
技术4：输出采样与提前停止
在某些使用场景中，你不需要完整的LLM输出，只需要一个决策或分类结果。
使用logprobs进行分类。
# Use only a model and API operation whose current documentation supports
# log probabilities; support varies by model and endpoint.
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
这要求兼容模型生成一个简短的标签。确认所选API支持对数概率，标签能清晰映射到令牌，并且分类质量达到目标。
受限标签或对数偏差。
对于已知集合的输出，优先使用可用的文档化枚举/模式约束。对数偏差会影响令牌选择，但其效果取决于分词器和模型。
response = openai.chat.completions.create(
model=COMPATIBLE_MODEL,
messages=[...],
# If used, build logit_bias from every tokenization variant you intend
# to accept; do not assume a class label is exactly one token.
logit_bias=VALIDATED_TOKEN_BIAS,
max_tokens=1,
)
对数偏差会影响令牌选择，但它不会强制执行有效类别或证明分类的可靠性。请验证并拒绝任何意外输出。
技术5：批处理
处理大量项目时，应使用批处理。
API层面的异步批处理。
某些服务提供商支持异步或批量产品，有时价格、完成时间窗口、限制条件和数据处理条款会有所不同。
- OpenAI 和 Anthropic 均在其官方定价和批量页面上记录了异步批量产品。请核实当前的折扣、完成时间窗口、限制条件和数据处理条款。
如果待处理的工作不需要交互式响应，请将当前批量产品的定价和完成行为与同步路径进行比较。
提示内批处理。
在可行时，通过一次LLM调用处理多个项目。
不要这样做：
[10次单独调用，每次对一个工单分类]
而是这样做：
[1次调用，在一个提示中对10个工单分类]
单次调用的输入项更多，但可能会复用一组固定的提示前缀。在某些工作负载中，这可以减少总令牌数；但分隔符、更长的输出、重试和批量级别的失败可能会抵消这种节省。
注意：批量处理可能会影响质量、顺序、截断和故障隔离。应在具有代表性的输入上调整批量大小，而不是采用统一的范围。
技术6：窄任务使用更小的模型
除了标准路由，还要考虑任务是否真的需要大模型。
分类： 在标记的示例上，包括罕见类别和弃权情况，将较小的模型层级与当前生产模型进行评估。在成本比较中使用当前提供商的价格。
提取： 比较小型、中型、确定性和混合提取器在字段级准确性、异常处理、延迟和成本方面的表现。使用经过验证的规则升级案例。
翻译： 在实际语言对、术语、格式、安全性和人工审核要求方面，评估专用翻译系统和大语言模型层级。不要从聚合基准推断覆盖范围。
嵌入： 使用专门的嵌入模型，不要用通用LLM生成嵌入。
模式是：识别“简单、窄范围”的工作负载，将其路由到能够充分完成任务的最小模型。把旗舰模型留给复杂且需要大量判断的工作。
技术7：微调小模型
对于吞吐量极高的窄任务，可以微调小模型。
对于高吞吐量的分类任务，比较提示的小模型、微调模型、确定性规则和混合方法。包括训练和评估数据、服务、空闲容量、监控、重新训练和工程成本。只有在测量的质量/成本曲线证明其经济性时，微调才是经济的。
2026 年的微调一文已介绍过这一点。原则是：当规模与任务窄度同时具备时，微调可以成为降低成本的手段。
技术8：预过滤
对于多步骤LLM工作流，先用低成本过滤器处理明显案例，再进入高成本处理。
示例：客户支持分类与回复。
低成本预过滤：
- “这是真正的支持问题，还是垃圾/噪声？”（使用小模型进行仅输出 1 个 token 的分类。）
- “这是已知常见问题吗？”（嵌入搜索；成本低。）
只有通过过滤的请求才会进入昂贵的回复生成环节。
测量预过滤器在所需精度下能解决的流量占比。误报可能会压制有效请求，因此成本节约必须与质量和升级影响一并评估。
技术9：提示缓存之外的缓存
除模型提供商的提示缓存外，还可以进行应用层缓存：
响应缓存。 在作用域已经批准、且缓存键完整涵盖所有会影响响应的输入时，只要先前响应的新鲜度和语义仍然有效，就可以重复使用。由于结果具有非确定性，这是一项产品决策，不能把两次请求直接视为必然得到相同结果。
import hashlib
import json
def stable_sha256(value):
payload = json.dumps(value, sort_keys=True, separators=(",", ":"))
return "llm:" + hashlib.sha256(payload.encode("utf-8")).hexdigest()
def cached_call(scope, prompt_version, prompt, model, params, ttl=3600):
# Canonicalize all response-affecting inputs and include tenant/user scope
# where a shared answer is not explicitly safe. Use a stable cryptographic
# digest rather than the process-randomized built-in hash().
cache_key = stable_sha256({
"scope": scope,
"prompt_version": prompt_version,
"prompt": prompt,
"model": model,
"params": params,
})
cached = redis.get(cache_key)
if cached:
return json.loads(cached.decode("utf-8"))
response = call_llm(prompt, model, params)
redis.set(cache_key, json.dumps(response), ex=ttl)
return response
对于确定性程度足以使用缓存的查询，在缓存已有可用结果后，这可以避免重复调用。应定义新鲜度和失效机制，隔离作用域，防止缓存雪崩，并且未经批准不得缓存敏感或个性化输出。
嵌入缓存。 缓存已计算的嵌入。
检索结果缓存。 在短时间内缓存某个查询的搜索结果。
工具结果缓存。 如果底层数据不经常变化，就缓存工具调用结果。
缓存可以逐层叠加，每一层都有机会减少调用。
技术 10：推测性执行（延迟权衡，而非成本节约）
对于能够预测后续步骤、且对延迟敏感的流程，可以推测性地提前调用。
示例：客户支持智能体。客户描述问题后，你知道下一步通常是“总结问题”。在向用户显示确认消息的同时，并行启动摘要。
如果预测正确，需要时响应已经准备好。如果预测错误，就浪费了一次调用。
该技术故意执行可能被丢弃的工作，因此可能会增加成本。只有在测量到的延迟收益足以抵消浪费、取消和副作用，并且推测请求不会暴露或修改未经授权的数据时，才应使用该技术。
技术 11：供应商比较
供应商在价格、能力、地区、配额、数据条款、可靠性和模型实现方面存在差异。应在相同的负载和合同假设下，比较质量相当的候选供应商。
在托管推理服务提供商上使用开放权重模型。
只有在候选模型通过相同的负载评估后，才应比较当前供应商的价格。相似的参数规模或营销层级并不等同于质量相当。
不同提供商上的同一模型。
一些开放权重模型由多个提供商提供。请对模型的精确版本、量化方式、服务配置和 API 行为进行基准测试；相同的模型名称并不能保证输出或性能完全一致。
规模化自托管。
在特定工作负载的利用率临界点，自托管可能变得更具成本效益。需考虑模型所需的 GPU 小时数、副本数量、空闲与峰值容量、网络、可观测性、升级、安全性、事件响应和工程责任等方面。
多提供商路由会增加集成、评估、安全、采购、可观测性和故障模式的复杂性。只有在测量到的弹性或经济效益超过该复杂性所带来的成本时，才应采用该方式。
技术12：推理加速
对于自托管，需要优化推理层本身。
vLLM、TGI 和 SGLang。 具有不同模型覆盖范围和优化路径的推理服务器。请在目标硬件上对支持的版本进行基准测试。
量化。 降低精度可以减少内存占用或提高吞吐量，但其对质量的影响取决于任务和方法。请对具体的模型产物和服务配置进行基准测试。
FlashAttention、分页注意力。 现代服务器中启用的架构优化。
连续批处理。 对执行中的请求进行批处理，以提高 GPU 利用率。
对于规模化自托管的团队，这一点很重要。使用 API 的团队则由提供商负责这部分工作。
技术13：流式传输
流式传输不会减少 token 数，但能改善用户体验，进而影响用户对性价比的感受。
对于较长输出，用户会立即看到内容逐步出现，并可在生成完成前开始阅读。相比等待完整响应，体感快得多。
对于智能体，应流式传输已批准的进度事件或状态摘要。不得将私有推理、机密信息、未经审查的工具参数或跨租户数据作为“中间步骤”暴露。
实施：如果所选的 API 和模型支持流式传输，请在面向用户的流程中进行测试。流式传输会改变用户感知的延迟，但不一定影响总成本或任务完成时间。
技术14：预算护栏
除了优化，还要强制执行硬预算，防止成本失控。
单请求预算。 每个请求允许的最大token数，超出时停止。
单用户预算。 每个用户的每日或每月成本上限，接近上限时限流。
按功能划分的预算。 为每项功能指定负责人和预算，并在特定于工作负载的阈值被超过时，触发经过测试的响应。
全局预算。 每日/月度总上限；接近上限时暂停非必要工作。
这些控制措施并不能保证节省成本。它们只是对支出进行限制或重定向，同时可能降低可用性，因此需要对关键和非关键工作负载的告警、限流、降级、排队和断路行为进行测试。
成本降低实验模板
不要把由多项变更合成的结果说成客户的实际结果。对于一个生产环境的工作流，应记录一个基准计费周期，并一次只应用一个变更：
具体变更：
-
提示缓存。 记录符合条件的前缀标记、命中率、缓存写入/读取次数、延迟和计费成本。
-
模型路由。 记录路由分布、每条路由的质量、回退机制、延迟和成本。
-
输出长度控制。 记录输出长度、完成质量、用户重新提示和成本。
-
预过滤。 记录精确度、召回率、升级情况、被抑制的有效请求和避免的调用。
-
FAQ响应缓存。 记录语义等价规则、新鲜度、失效机制、命中率和答案质量。
报告总节省和净节省、评估结果、工程时间、新增运营成本以及在数据和方法支持的情况下不确定区间。除非评估设计能够检测到有意义的退化，否则不得声称质量未发生变化。
常见错误
在你自己的追踪中需要检查的故障模式：
错误1：不跟踪成本。 团队无法了解每个功能、用户或调用的成本。没有测量，就无法优化。
错误2：优化错了对象。 花数周把输入token减少5%，而输出token却占账单的80%。先测量，再优化最大的成本来源。
错误3：质量退化。 削减成本时没有监控质量。省了钱，却失去了用户。成本工作必须始终与评估套件配套。
错误4：过度路由。 激进地把任务路由给实际无法胜任的小模型。这是假节省。
错误5：缓存污染。 缓存被罕见查询填满，大多数缓存条目只使用一次，未命中占主导。需要更好的缓存策略。
错误 6：不评估批处理。 对原本可以容忍服务提供商当前批处理窗口和约束条件的工作，仍然采用实时处理。
错误7：过度工程化。 在本来就无利可图的功能上构建复杂的成本优化。有时正确答案就是“砍掉这个功能”。
错误8：没有预算护栏。 一个bug就会导致成本失控，小麻烦演变成灾难。
运营纪律
推荐的运营实践：
- 将成本视为一个指标，而非事后考虑。
- 在工程和财务职责范围内指定一名负责人。
- 根据支出波动性和业务风险，选择合适的审查周期。
- 依据定义的阈值和操作手册对成本峰值进行分类处理。
- 按功能设置预算；在阈值被突破时发出警报。
- 明确权衡（成本与质量与延迟之间的取舍）。
需要关注的控制漏洞：
- 没有指定的成本负责人。
- 决策窗口关闭后才发现计费情况。
- 警报没有指定响应负责人或操作手册。
- 没有批准的预算或预测范围。
- 不讨论权衡，只顾优化一个维度。
这些是需要通过责任归属记录、评审参与记录、告警响应和已完成的成本措施来验证的治理选择，而不是对团队文化的主张。
定价与能力漂移
再谈谈更广泛的趋势。
供应商的价格、模型能力、批量产品、缓存规则和托管工具费用会按照供应商的时间表发生变化。本文不建立普遍的历史趋势或进行预测。
在发生重大价格、模型、合同或工作负载变化后，重新运行成本和质量模型。不要假设当前无利可图的工作流程将来会变得有利可图，也不要认为未来的价格下降能够挽救一个效率低下的设计。
一个说明性的十二周成本优化序列
对于一个从“我们有一个AI功能，成本高于预期”开始的团队，以下序列是一个规划示例。根据工作负载、证据和运营能力调整持续时间和停止条件。
第1–2周：测量。
- 检测每次调用的成本。
- 构建按功能、按用户划分的仪表板。
- 找出最大的成本来源。
第3-4周：快速改进。
- 仅在追踪显示重复的合格前缀且当前提供商规则适用时，尝试提示缓存。
- 重构成本最高的合格提示，然后测量缓存命中率、延迟、质量和计费成本。
- 仅在测量任务需要支持时，为每个 API 设置当前输出上限；测试截断和重试。
- 实施预算警报。
第5–6周：路由。
- 识别当前使用旗舰模型的简单任务。
- 为调用最多的3–5个端点构建路由器。
- 测试质量是否退化。
第7–8周：输出与缓存。
- 在不面向用户的场景中约束输出长度。
- 为常见查询添加应用层响应缓存。
- 为最高吞吐量的流程添加预过滤器。
第9–10周：高级优化。
- 非实时工作使用批处理API。
- 评估替代提供商。
- 添加嵌入缓存、检索缓存。
第11–12周：加固。
- 为每个功能设置预算护栏。
- 将成本仪表板纳入团队常规审查。
- 记录相关模式，供未来功能使用。
在改进周期结束时，发布测量到的成本变化和质量证据。一个时间表并不能保证节省百分比。
先测量，再叠加节省
LLM成本通常可以降低，但百分比和质量影响因工作负载而异。候选技术包括缓存、路由、输出控制、批处理、预过滤、响应缓存、模型选择和预算保护。
按顺序应用更改，以确保其效果可归因；交互可能叠加、重叠或相互抵消。
根据扣除推理、工具、人工审核、基础设施、维护和支持成本后的净贡献，判断该功能在经济上是否可持续。
先测量。优化最大的成本来源。持续监控质量。把成本纪律纳入团队的日常工作。
最终得到的是在经济上和技术上都能扩展的AI功能。正是这一点，让AI成为产品中可持续的一部分，而不仅仅是上线时的宣传口号。
