只有当 LLM 成本计算器衡量的是一个真实工作流的全部成本，而不只是 token 费率时，它才有用。增长团队关心的是发布预算、实验速度，以及模型选择是否会在首个响应之后带来隐藏的审核或重试支出。
有用的单位是每个已接受任务的成本：产生一个活动、代理、工作流或产品界面能够实际使用的输出所需的总支出。也就是说，LLM 成本计算器应跟踪模型账单、重试、回退调用、工具费用、人工审核时间，以及运行测试的运营开销。
本指南为增长团队提供一个实用的 LLM 成本计算器工作流，可在推出新的 AI 功能、内容流水线、外联实验、支持助手或研究代理之前使用。
简要版
当模型支出与可重复的增长工作流相关，而不是一次性提示词时，请使用 LLM 成本计算器。计算器应回答五个问题：
- 一次发起的请求成本是多少？
- 有多少发起的请求会变成已接受输出？
- 重试、回退、工具调用和审核会增加多少费用？
- 哪种模型或路由的每个已接受任务成本最低？
- 团队应在什么阈值停止、设上限或改道实验？
如果你只比较每百万 token 的价格，就会忽略最重要的成本：那些产生了却从未上线的输出所花掉的钱。
为什么增长团队需要不同的 LLM 成本计算器
工程团队通常从模型层面的计算开始：输入 token 数乘以输入价格，再加上输出 token 数乘以输出价格。这是必要的，但对增长团队来说还不够。
增长工作流通常有更多环节：
- 一次活动或自动化中有多个提示词
- 针对不同受众、渠道和优惠的测试单元
- 发布或发送前的人审
- 丰富工具、搜索工具、图像工具或数据 API
- 因速率限制、schema 失败或低置信度输出而重试
- 当更便宜的模型未完成任务时，回退到更强的模型
- 按客户、市场、账户或实验设置预算上限
面向此类环境的 LLM 成本计算器必须将模型支出与团队实际管理的业务对象连接起来：合格线索、已批准素材、已分流工单、已丰富账户、已接受的研究简报，或已转化的实验单元。
核心公式
先从请求级模型成本开始：
request cost =
input tokens * input token rate
+ cached input tokens * cached input rate
+ output tokens * output token rate
+ tool, image, audio, video, search, or data charges
然后上升到已接受任务成本：
cost per accepted task =
(model cost
+ retry cost
+ fallback cost
+ tool and data cost
+ human review cost
+ failure recovery cost
+ operating overhead)
/ accepted tasks
第二个公式才是大多数有价值决策发生的地方。更便宜的模型如果产生更多无效输出，反而会输。更强的模型如果能减少审核时间、重试循环或下游修正，就可能胜出。
关于AI API 支出预测的文章涵盖了更广泛的月度规划。这套 LLM 成本计算器工作流更为聚焦：它帮助增长团队决定某个特定实验或自动化应该运行、扩展、停止，还是切换到另一条路径。
工作表：在计算器中填写的字段
每个工作流单独占一行，不要把多个账户的总量混在一起。落地页文案测试、线索补全工作流、支持摘要器和编码代理评估不应共用一个平均值。
| 字段 | 填写内容 | 重要原因 |
|---|---|---|
| 工作流 | 活动、功能、代理或自动化名称 | 将支出与决策负责人关联起来 |
| 路由 | 直接提供商、网关、模型家族或路由策略 | 便于比较模型和提供商选择 |
| 模型 | 请求所使用的准确模型 | 避免含糊的“AI 支出”报表 |
| 发起请求数 | 每一次首次尝试 | 定义流量基数 |
| 重试次数 | 失败后的自动重复 | 显示重复支出 |
| 回退次数 | 转移到另一模型或提供商的调用 | 将故障切换与普通重试区分开来 |
| 接受的任务 | 通过 QA 或业务规则的输出 | 建立真正重要的分母 |
| 平均输入 token | 提示词、上下文和工具指令 | 暴露过大的提示词 |
| 平均输出 token | 生成的答案、资产或结构化对象 | 暴露冗长和 schema 漂移 |
| 缓存输入占比 | 可复用的稳定上下文（如果支持） | 显示缓存是否能带来实质帮助 |
| 工具和数据费用 | 搜索、浏览器、数据 API、图像、音频或视频费用 | 防止非 token 成本被忽略 |
| 审核分钟数 | 每个输出所需的人工审核时间 | 将审批摩擦转化为金钱成本 |
| 修复成本 | 重跑、人工修复、退款、支持时间 | 捕捉失败输出的成本 |
| 每个接受任务的成本 | 总成本除以接受的任务数 | 主要比较指标 |
用于内部报告时，请保留原始 token 和请求字段的可见性。用于管理层审阅时，先展示每个接受任务的数字。
示例计算器逻辑
在你拥有真实生产数据之前，请使用占位符：
accepted tasks = requests started * acceptance rate
model spend =
requests started
* (average input tokens * input rate
+ average output tokens * output rate)
retry spend =
retry attempts
* retry request cost
fallback spend =
fallback attempts
* fallback request cost
review spend =
review minutes
* loaded reviewer cost per minute
cost per accepted task =
(model spend + retry spend + fallback spend + tool spend + review spend)
/ accepted tasks
然后在候选路由上运行相同的工作负载。不要把易处理流量上的廉价模型与难处理流量上的高端模型进行比较。请使用相同的提示集、接受规则、流量组合和审核标准。
实用的对比矩阵
LLM 成本计算器应让路由取舍一目了然。
| 选项 | 最适合 | 成本风险 | 质量风险 | 决策规则 |
|---|---|---|---|---|
| 单一低成本模型 | 简单分类、抽取、标注、初稿 | 重试和人工审核可能抹去节省 | 在复杂任务上更高 | 如果通过率仍高于下限，就继续使用 |
| 单一高端模型 | 高风险推理、困难写作、复杂代理 | 简单任务也按高价计费 | 较低，但并非为零 | 当失败成本高于模型成本时使用 |
| 小模型到大模型兜底 | 具有清晰失败检测的混合工作负载 | 兜底路径会重复支出 | 取决于兜底触发质量 | 当首轮节省大于兜底成本时使用 |
| 基于任务的路由 | 有多种工作流类型的增长团队 | 规则维护和可观测性 | 误分类 | 当任务类别稳定时使用 |
| 网关加计算器 | 经常比较提供商、模型和预算的团队 | 需要路由和计费纪律 | 取决于模型选择 | 当一个仪表盘和一把密钥能降低运营开销时使用 |
这正是 Flatkey 可以融入工作流的地方。Flatkey 为团队在不同模型和工具之间提供一把密钥和一个计费入口，而公开定价和模型目录页面则提供了一个当前可用的位置，让你在把某个活动或自动化方案提交到某条路由之前，先比较模型选项。
在增长发布前应衡量什么
在增加流量之前，先收集一个小型基线：
| 基线指标 | 最低可用样本量 | 通过条件 |
|---|---|---|
| 接受率 | 100 到 300 个具有代表性的任务 | 满足工作流的质量下限 |
| 重试率 | 与接受率相同的样本 | 稳定且可解释 |
| 兜底率 | 与接受率相同的样本 | 足够低，以至于兜底不是默认路径 |
| 平均输入 token 数 | 所有采样请求 | 没有明显重复的上下文 |
| 平均输出 token 数 | 所有采样请求 | 没有不必要的冗长 |
| 人工审核分钟数 | 已审核的输出 | 不会抹去 token 节省 |
| 每个已接受任务的成本 | 已接受的输出 | 低于活动的预算上限 |
具体阈值取决于工作流。对于低风险的元数据任务，85% 的接受率可能就足够了。对于面向客户的消息，则可能需要高得多的下限。计算器应把这一标准明确展示出来。
仅按 Token 计算的计算器会在哪些地方失效
许多 LLM 成本计算器工具只停留在 token 计算上。对于初步估算，这很有用，但增长工作流还需要额外检查。
仅按 token 计算会忽略：
- 仍然会产生费用的失败输出
- 重试后产生的重复请求
- 回退调用到更昂贵的模型
- 审阅者时间
- 工具或数据费用
- 活动级预算上限
- 当慢速输出错过发送窗口时产生的延迟成本
- 来自独立供应商账户的采购开销
这就是为什么计算器应该尽量靠近实验跟踪和使用日志。模型账单告诉你被收了多少钱。增长工作流则告诉你这笔费用是否产生了可用结果。
在实验过程中如何使用计算器
分三个阶段运行 LLM 成本计算器。
1. 上线前估算
在发送生产流量之前，先估算：
- 预期请求量
- 平均提示词长度
- 预期输出长度
- 预期接受率
- 预期审阅时间
- 重试和回退预算
- 每个被接受任务的最高成本
速率输入请使用当前模型定价页面。供应商定价、缓存行为、批处理条款和模型可用性都可能变化，因此在承诺月度预算前要重新检查。
2. 受控流量切片
将一小部分具有代表性的流量切片通过候选路径发送。确保样本在简单、中等和困难案例之间保持平衡。记录每一次重试和回退。不要从数据集中删除失败尝试。
比较：
- 估算的每个被接受任务成本
- 实际的每个被接受任务成本
- 估算的接受率
- 实际的接受率
- 被拒绝的主要原因
如果估算与现实出现偏差，在扩大实验规模之前先修正计算器。
3. 扩大规模或停止的决策
只有当工作流始终处于以下三个护栏内时，才进行扩展：
| 护栏 | 何时停止或改路由 |
|---|---|
| 质量 | 接受率跌破预定义下限 |
| 支出 | 每个被接受任务的成本超过预算上限 |
| 稳定性 | 重试、回退或延迟突然飙升且没有明确原因 |
计算器不仅仅是一个报表电子表格。它是增长运营的控制面板。
用于深入工作的内部链接
将这些 Flatkey 资源与计算器一起使用：
- 当你需要预测多个工作流的月度用量时，使用 AI API 支出预测。
- 当计算器暴露出昂贵路径后，你需要更广泛的节省方案时，使用 AI API 成本优化。
- 当计算器显示速率限制、重试或预算控制问题时，使用 AI API 配额限制。
- 当直接供应商账户变得难以管理时，使用 AI API 网关指南。
- 在选择路径之前，请查看 Flatkey 定价 中的当前选项以及 模型目录。
常见错误
在构建 LLM 成本计算器时，避免这些错误：
- 对每个工作流只使用一个账户均值
- 忽略被拒绝的输出
- 把重试和兜底当作免费的可靠性
- 在不同任务样本上比较模型
- 忘记审阅者时间
- 只统计输出量而不统计接受量
- 使用过时的模型费率
- 为了节省 token 而优化，却降低了转化质量
最后一点对增长团队最重要。如果某个活动产出了更少可用素材、更差的回复质量、更糟的线索补全，或更慢的实验周期，那么更低的模型账单并不算改进。
Flatkey 的位置
当 LLM 成本计算器需要把支出、模型选择和路由控制连接起来时，Flatkey 最有用。Flatkey 现有网站将产品定位于一个 key、更多模型、更多工具以及更低成本。模型目录为团队提供了一个可随时比较模型选项价格、上下文、速度和健康状况的地方。定价页面则将 Flatkey 套餐围绕生产用量控制来呈现。
当增长团队想测试多个模型，而不把每次实验都变成单独的供应商账户操作时，这种组合就很重要。计算器仍然需要良好的工作流数据，但统一的网关可以让输入更容易收集和比较。
最终检查清单
在你信任某个 LLM 成本计算器之前，请确认它包含：
- 每个工作流一行
- 当前模型费率
- 输入、输出和缓存输入字段
- 重试和兜底成本
- 已接受任务数量
- 审阅和修复成本
- 停止阈值
- 路由变更阈值
- 预算决策负责人
结论
LLM 成本计算器应该帮助增长团队做决策，而不仅仅是估算 token。真正要关注的指标是每个已接受任务的成本。一旦你能按工作流、路由、模型和实验看到这个数字，下一步就更清晰了：扩大量级、设定上限、改进提示词、把工作转移到另一个模型，或者停止测试。
如果你的团队需要一个地方来比较模型、测试路由，并保持 AI 工作流支出可见，Flatkey 可为 LLM 成本计算器提供所需的计费和路由层。
常见问题
什么是 LLM 成本计算器？
LLM 成本计算器用于估算运行语言模型工作流的成本。一个有用的计算器会包含 token、重试、兜底、工具费用、审阅时间以及已接受任务数量。
增长团队应该使用什么指标？
增长团队应该使用每个已接受任务的成本，因为它把 AI 支出与可用的活动、工作流或产品输出联系起来。
LLM 成本计算器应该只跟踪 token 吗？
不。token 计算只是起点。计算器还应跟踪接受率、重试、兜底、人工审阅、工具使用和预算阈值。
网关在 LLM 成本计算中什么时候有帮助？
当团队比较多个供应商或模型、需要一个统一的计费界面，并希望路由决策与成本审查在同一工作流中可见时，网关就会有帮助。
