模型账单仅占你推理成本的 30%

一家中型 AI 公司的财务负责人在上个季度告诉我，他们通过将 Agent 骨干模型从 Sonnet 切换到 Haiku，“优化了他们的 LLM 支出”。Token 账单下降了 22%，而每个已解决工单的总推理成本仅下降了 4%。当我们进行完整的成本拆解时发现，模型这一项支出大约仅占单次请求成本的三分之一。检索、重排序（reranking）、可观测性、重试放大以及人工介入（human-in-the-loop）审核队列吃掉了剩下的部分——而且当你更换模型时，这些环节都没有变得更便宜。

这是我目前在 AI 团队中看到的最常见的财务核算错误。Token 成本是你每月支付的发票上的分项，因此它成了每个人都在优化的数字。但对于任何非平凡的生产系统——RAG、Agent、任何带有工具调用或评估门控的系统——模型推理往往只占实际单位经济效益的 30% 到 50%。剩下的部分隐藏在你的工程仪表盘不会显示、且财务团队不会将其归类为 “AI 支出”的地方。

如果你只审计模型账单，你可能将其削减一半，却让 60% 的实际成本结构完全不受影响。更糟糕的是，一些降低 Token 支出的举措——更便宜的模型、更精简的提示词、激进的截断——会通过推高重试次数、人工审核量或检索损耗，转而主动增加剩下的 70% 成本。这种节省是一种用错误货币计价的幻觉。

剩下的 70% 到底是什么

一个生产级 RAG 或 Agent 系统的实际单次请求成本拆解大致如下（根据工作负载会有很大差异）：

• 模型推理（输入 + 输出 Token）： 25–45%
• 上下文组装（嵌入、向量搜索、重排序）： 10–25%
• 可观测性和追踪（trace）保留： 5–15%
• 重试、回退（fallback）和自我修正循环： 5–20%
• 人工审核和升级处理人力： 10–30%
• 护栏（Guardrails）、安全过滤和评估采样： 5–15%

这些类别中的每一个都有其独特的故障模式，这些模式会在不显示在你的 LLM 供应商仪表盘上的情况下放大成本。

上下文组装是一个隐形支出项。每次查询都要支付嵌入（embedding）费用、向量搜索费用，通常还有第二阶段的重排序费用，有时还需要专门的检索 LLM 调用来重写查询。一个检索 50 个候选结果、重排序到 10 个、并将 6,000 个 Token 的上下文塞进提示词的流水线，在模型生成响应之前，就已经在支付嵌入费、向量数据库读取费、重排序 API 调用或 GPU 时间以及 Token 费了。团队通常会低估这一项，认为它仅占真实基础设施支出的 40% 到 60%，因为这些费用分散在 Pinecone 或 Weaviate 的账单、Cohere 或 Voyage 的重排序费用以及一堆内部服务中。

可观测性成本随追踪（trace）量而非请求量扩展。一个带有 8 个工具调用和 3 个推理步骤的单次 Agent 运行可以产生 15 到 30 个 span。按照每个 span 5–50 KB 以及每天数百万次请求计算，一个运行 Langfuse、Arize 或自建 ClickHouse 环境的团队每月在追踪存储和查询计算上的花费可以轻松达到 5 万到 10 万美元。保留政策也很关键：合规团队想要保留一年，分析团队想要六个月，调试需要 30 天。大多数团队选择了最长的期限并为之全额买单。

重试放大是 Agent 系统悄悄破坏成本计算的地方。一个带有指数级退避（exponential backoff）和回退模型的 3% 工具错误率听起来似乎无害。但在每个请求有三次独立重试尝试的工具调用下，它会复合为一个明显的比例，使得部分请求支付了 2 倍或 3 倍的模型成本。当回退方案是一个更昂贵的推理模型时，一次级联重试的成本可能超过十次成功的常规调用。如果你没有明确限制重试次数并为回退方案制定预算，你的成本方差将远大于你的均值。

人工审核是财务部门最讨厌的类别，因为它是人力成本而非 API 支出。但如果你的系统将 20% 的输出标记为低置信度，并将其路由给成本为每小时 30 到 60 美元的审核员，且每次审核耗时 2 到 5 分钟，那么你就在为每个升级的请求增加 0.10 到 0.50 美元的成本——对于许多面向消费者的应用来说，这完全盖过了模型成本。一个成熟的 AI FinOps 规范会将此计入 AI 支出项。大多数团队并没有这样做，这就是为什么模型成本一直在赢得优化预算，而真正的成本驱动因素却是闲置的审核员。

为什么“我们切换到 Haiku 节省了 20%”几乎总是错的

Haiku 切换的案例是一个典型的研究课题，因为它以错误的方式影响了每一个成本杠杆。更小的模型对指令的遵循程度较低，因此提示词会变长以进行补偿——更多的少样本（few-shot）示例、更明确的约束、更长的系统提示词。上下文膨胀是检索和重排序成本的倍增器，因为更便宜的模型在忽略无关信息方面表现更差，因此检索必须更精准（或者提示词必须容纳更多候选结果）。

小模型在自身不确定性的校准（calibration）上也往往表现较差，这意味着置信度门控审核会捕获更多它们的输出——因此人工审核的成本桶会增长。重试和回退模式通常会在第二次尝试时静默升级到更大的模型，这意味着“节省”仅在理想路径（happy path）下成立，并在长尾情况下发生逆转。

我见过一些团队将 Token 账单削减了 30%，却导致每个已解决任务的总成本上升了 8%，因为下游效应淹没了直接节省的费用。正确的比较永远不是“单次请求的 Token 数”或“每百万 Token 的美元数”。它是每个成功解决任务的成本，该成本分摊在重试、审核和检索链中。这个数字默认情况下几乎不会出现在任何仪表盘上。

真正影响底线的四个杠杆

一旦你完成了完整的分解，优化的优先级就会重新排序。对于大多数 RAG 和智能体（agent）工作负载，按杠杆作用大小排列的操作如下：

1. 在模型上游进行缓存。 供应商层面的提示词缓存（Prompt caching）处理重复的系统提示词和稳定的上下文前缀 —— Anthropic 的提示词缓存和 OpenAI 的自动缓存通常能为缓存部分减少 30% 到 90% 的成本。更上一层的语义缓存（Semantic caching）处理重复和近乎重复的用户查询，在生产工作负载中，大约 30% 的查询显示出与先前请求的语义相似性。一个位置合理的语义缓存可以完全绕过模型、检索管道和评估环节。这是大多数团队能获得的最有效的单一优化手段，它能同时解决多个成本项。

2. 在模型看到检索结果前进行剪裁。 检索 50 个候选结果并让模型去处理，是回答问题最昂贵的方式。一个优秀的重排序器（reranker）配合紧凑的 top-k（通常为 3 到 5 个，很少超过 10 个以上）可以减少 60% 到 80% 的上下文 Token，并且通常能提高回答质量，因为模型不会被相关性较低的内容块分散注意力。重排序端的嵌入（embedding）成本虽然存在，但与不往主提示词里塞大量内容所节省的 Token 相比微不足道。衡量一下：你的检索阶段应该知道其在评估集上的 precision@k，并且你的回答质量应该根据上下文大小进行图表化分析。

3. 基于真实的置信度而非模型的置信度来触发人工审核。 大多数团队使用模型自我报告的确定性或诸如“是否引用了来源”之类的启发式方法来决定哪些内容需要提交审核。这两者都存在噪声。一个小型且经过专门训练的分类器 —— 在检索评分分布、回答长度、样本间的自一致性以及检索重叠度之上进行逻辑回归 —— 其表现通常远超模型自身的置信度，而且运行成本极低。在保持错误率不变的情况下，将审核量从 20% 降低到 5%，其价值通常比更换任何模型都要大。

4. 按使用层级设置追踪（trace）保留策略。 并非每个 span 都需要保留 12 个月。对生产环境的追踪进行 10% 的采样并全量保留，对错误追踪进行 100% 采样并保留 90 天，其余的在 30 天后存档至冷存储。存储成本曲线随保留期限呈超线性增长，而一个月前的成功追踪记录的分析价值通常接近于零。分层策略可以在不影响调试或合规覆盖范围的情况下，将可观测性成本降低 60% 到 80%。

真正的 FinOps 视角是什么样的

真正能指导决策的成本报告应该每一行对应一个请求类别 —— “从缓存回答”、“RAG 解决”、“转人工审核”、“失败并重试”、“拒绝” —— 每一列对应一个成本项 —— 模型 Token、上下文组装、可观测性、重试开销、人工。你无法从供应商的账单门户中构建出这些数据。你必须在应用层进行埋点，用类别标记 span，并汇总来自多个渠道的成本归因。

当一个团队第一次构建这个系统时，通常会发生两件事。首先，有人会发现 8% 的请求驱动了 40% 的成本，这几乎总是由于特定失败类别的重试级联导致的。其次，CFO 会问为什么人工审核这一项被列为“AI 支出”。这两个对话都非常有成效，而且如果只是盯着 LLM 账单，这两者都不会发生。

另一种选择是不断重复 Haiku 的故事 —— 追逐你唯一能看到的数字，而不对实际的成本结构进行审计。在 Token 价格下降 10 倍而计算支出仍在攀升的一年里，这种计算逻辑很快就会失效。在 2026 年赢得单位经济效益之战的团队，将是那些把“模型成本”视为真实分解中的一个输入项，并对整个技术栈进行优化，而不仅仅是优化供应商碰巧为他们打印出来的那一行账单。