如何降低 LLM API 成本：按任务复算费用与优化收益

定位 API 账单的主要来源，计算每个合格任务成本，并用算例比较缓存、缩短上下文、选模型和限制重试的收益。

发布 2026-08-15 · 更新 2026-09-29 · KeepRouter Editorial · 4 分钟阅读

降低应用的 LLM API 账单，首先要找出钱花在哪些已完成的任务上。更低的 token 单价可能有帮助，但重试、过长上下文和没有被使用的输出，足以抵消这点优势。先选一个工作流，计算每个合格结果的成本，再一次只修改一个因素。下面的工作表把“请求更便宜”和“有用结果更便宜”分开。

从一个任务推算月度费用

对没有单独缓存写入、工具或存储费的普通文本线路，可以这样计算：

请求费用 = (普通输入 × 输入费率
          + 缓存输入 × 缓存读取费率
          + 输出 × 输出费率) / 1,000,000
月推理费用 = 当月所有尝试的费用之和
每个合格任务成本 = 工作流总费用 / 合格任务数

公式中的费率单位是每百万 token。请使用所选模型的用户价格及其实际计价单位；视频秒数或图片请求数不能作为 token 数填进去。存在单独计费的缓存写入、存储、工具或其他服务时，应另行加入。Anthropic token 计数文档可帮助估算输入，但调用前的估计无法告诉你最终输出多少、任务需要重试几次。

一个算例：单次便宜，结果却更贵

以下是假设的工作负载和价格，并非产品 benchmark。两个方案处理相同的 10,000 个任务，由人工复核的规则判断结果是否合格。所有付费尝试都计入，包括重试；为突出差别，暂时排除其他工作流费用。

方案 B 的单次价格低 20%，但每个合格结果的成本更高。这不代表大模型总会胜出，而是说明选模型时必须同时看任务成功率、重试次数和费率。若是客服场景，每次解决成本工作表还会把人工升级处理和重新打开的工单算进去。不要把一次 HTTP 成功直接视为客户问题已经解决。

先找主要成本，再选优化动作

先处理最昂贵的模式。如果输出占主要部分，缓存实验的收益就有限；如果费用来自少数巨大任务，较小的平均请求长度会误导预算。除了中位数，也记录高成本任务的分布，检查最昂贵的完成任务，但无需因此收集用户的私密提示词正文。对流量波动较大的服务，低、正常和高三种使用量假设比一个平均值更有用。

在任务会扩张的地方设置限制

在应用侧同时限制工具轮数和总尝试次数，再设置线路支持的输出上限。预先决定预算耗尽后的行为：返回部分结果、交给人工复核，或用明确错误停止。若每次工具返回都引发新请求，仅限制单次 token 数仍不能限制整个循环。

例如，内部报告助手可以允许一次初始生成和一次修正尝试。这只是演示策略，并非 KeepRouter 默认配置。累计费用应绑定逻辑任务，不能在修正时清零。超时后的重试也一样处理，因为前一次尝试可能已经完成；否则既低估费用，也可能重复执行后续动作。对付费调用，先用小范围任务确认限制在错误路径上同样生效。

把估算变成付费使用的决定

选择一组固定且具有代表性的任务，包含长上下文和困难案例。记录型号 ID、端点、输入与缓存及输出用量、尝试次数、合格结果、耗时与费用。每次只比较一个改动，期间保持任务集合和质量规则不变，并人工查看两版答案不一致的地方。这样才能知道节省是否来自真实效率，而不是减少了任务难度或放松了质量要求。

打开 API 成本计算器，建立低、正常和高三档场景；再把一个小批次的实际结果与 Usage 对上，之后才扩大调用。计算器输出用于计划，最终付费金额取决于实际数量和支持的操作。缓存成本指南解释输入重复计费的常见错误，故障切换指南则说明尝试次数容易在哪些环节失控。

常见问题

应该默认选择标价最低的模型吗？

不应该。先要求模型通过任务的能力与质量契约，再比较包括重试和失败在内的实测总成本。

token 预估足以用于账单核对吗？

预估适合准入与规划；核对时应使用实际响应 usage 与计费账本，因为 token 化与缓存处理可能不同。

参考的一手资料

本文最近复核 2026-09-29

1. [1] Anthropic token counting
2. [2] OpenAI Responses API reference
3. [3] Cloudflare AI Gateway caching
4. [4] KeepRouter model catalog

继续阅读

• 按用量计费
• API 可观测性
• 不用静态价格快照，比较 Claude Code 模型成本
• 提示词缓存成本：算清读取、写入与实际节省
• models
• RAG 每次查询多少钱：别只计算生成 token
• Ollama 本地模型与托管 API：成本、容量与盈亏平衡