LLM 成本计算器只有在回答正确的业务问题时才有用。同样的 token 计算可以支持创始人估算新功能、增长团队规划上线、产品经理比较模型质量，或者运营负责人尝试阻止失控的 agent 工作流。输入有重叠，但在漏斗的每个阶段，决策都不同。
本指南按漏斗阶段梳理了实用的 LLM 成本计算器使用场景，从认知到留存。当前提是你已经理解基本的 token 定价，并且需要一种可重复的方法来决定该测试什么、该发布什么，以及上线后该监控什么时，可以使用它。
简短答案
在漏斗的每个阶段，用 LLM 成本计算器做一个决策：
| Funnel stage | Calculator question | Best output |
|---|---|---|
| Awareness | 这个用例是否值得探索？ | 粗略的月度成本范围 |
| Evaluation | 我们应该先测试哪个模型或路由？ | 场景比较 |
| Activation | 用户能否在不超出预算的情况下获得价值？ | 每个已激活用户的成本 |
| Conversion | AI 成本是否符合利润模型？ | 每个合格结果的成本 |
| Retention | 哪个工作负载正在偏离或浪费支出？ | 预算护栏和告警 |
大多数团队会把计算器做得过于通用。更好的 LLM 成本计算器应先从阶段出发，再选择映射到下一步决策的指标。
LLM 成本计算器应该衡量什么
基础公式很简单：
estimated_cost =
(input_tokens / 1,000,000 * input_price)
+ (output_tokens / 1,000,000 * output_price)
+ cache_write_cost
+ cached_input_cost
+ tool_call_cost
+ image_audio_or_video_cost
+ retry_and_fallback_cost这个公式是必要的，但还不够。它告诉你的是供应商账单，而不是这个工作负载是否健康。
一个实用的 LLM 成本计算器还应跟踪：
| Field | Why it matters |
|---|---|
| Accepted task rate | 如果人类会拒绝这些输出，那么便宜的结果也会变得昂贵 |
| Retry rate | 隐藏的重试可能会抵消模型价格节省 |
| Cache hit rate | 复用上下文会改变有效输入成本 |
| Tool calls per task | Agent 在工具上的花费可能比文本 token 还多 |
| Human review minutes | 一些“便宜”的工作流会把成本转移给操作人员 |
| Latency band | 更慢的路由可能降低 API 成本，但会损害转化 |
| Budget owner | 支出需要有团队、产品或活动负责人 |
要查看当前的每 token 费率，请始终参考实时定价页面，例如 OpenAI API pricing page、Anthropic pricing page、Google Gemini API pricing page，以及 Flatkey pricing 和 model directory。现在，供应商的定价页面通常会把输入、缓存输入、输出、批处理、区域以及不同模态的成本分开，因此过时的计算器假设可能会得出错误答案。
认知阶段：估算该用例是否可行
在认知阶段，读者会问：“AI 能否帮助完成这个工作流，成本是否大致合理？”
LLM 成本计算器应保持粗略。在没有真实提示、真实输出长度或真实接受率之前，不要假装精确。请使用区间：
| 输入 | 低估值 | 高估值 |
|---|---|---|
| 每月请求数 | 10,000 | 100,000 |
| 每次请求输入 tokens | 500 | 4,000 |
| 每次请求输出 tokens | 200 | 2,000 |
| 重试率 | 0% | 20% |
| 接受输出率 | 80% | 40% |
要做的决定不是“哪个模型最便宜？”而是该用例是否应该进入路线图。如果高估值仍然可以接受，就做一个原型。如果高估值已经破坏了商业可行性，那就先在模型选择之前缩减工作流：总结更少的上下文、限制输出长度、延后富媒体，或者看看是否可以用基于规则的步骤去掉提示词的一部分。
最适合认知阶段的用例：
| 用例 | 计算器输出 |
|---|---|
| 新的 AI 功能想法 | 每月 API 成本区间 |
| 内容或研究工作流 | 每份草稿或简报的成本 |
| 内部编码助手推广 | 每位活跃开发者的成本 |
| 客户支持助手 | 每个已解决工单的成本区间 |
在这个阶段，一个好的 LLM 成本计算器应该让下一次会议更简短，而不是试图成为完整的采购模型。
评估阶段：比较模型和路由选择
在评估阶段，团队已经有了示例提示词，并希望为测试选择模型、路由或网关设置。这时，LLM 成本计算器就变成了场景对比工具。
在每一行中使用相同的工作负载：
| 场景 | 输入 tokens | 输出 tokens | 缓存命中 | 重试率 | 接受率 | 每个已接受任务的成本 |
|---|---|---|---|---|---|---|
| 快速模型 | 1,200 | 450 | 20% | 12% | 72% | 计算 |
| 更强推理模型 | 1,200 | 650 | 20% | 5% | 88% | 计算 |
| 缓存上下文路由 | 1,200 | 450 | 65% | 8% | 78% | 计算 |
| 备用路由 | 1,200 | 450 | 20% | 3% | 82% | 计算 |
关键指标是每个已接受任务的成本：
cost_per_accepted_task =
total_api_cost / accepted_outputs这一点很重要，因为更低的 token 单价并不总能降低运营成本。一个更便宜的模型如果需要更多重试、更长提示词，或者更多人工修正，最终可能输给一个单价更高但接受输出率更好的模型。
对于使用 Flatkey 的团队，这一阶段正是统一的模型目录和一个 OpenAI 兼容的端点发挥作用的地方。你可以在一个采购流程中比较模型价格、上下文长度、路由健康状况和使用情况，而不必在多个供应商仪表板之间切换。计算器仍然需要你的工作负载数据；Flatkey 提供计费和路由层。若要获取更深入的工作表，请将本文与 面向增长团队的 LLM 成本计算器 工作流搭配阅读。
激活阶段：为第一次真实用户旅程制定预算
激活是第一个用户行为变得重要的阶段。你不再是在计算一个提示词。你是在计算一段旅程：
activation_cost =
signup_intake
+ first_generation
+ rewrite_or_retry
+ explanation_or_chat_followup
+ optional tool calls用于激活阶段的 LLM 成本计算器应回答："新用户能否在我们的预算内达到 aha 时刻？"
有用的激活阶段指标：
| 指标 | 示例用途 |
|---|---|
| 每个激活用户成本 | 免费试用和入门引导经济性 |
| 每个成功首个任务成本 | 产品驱动增长护栏 |
| 每次入门引导会话成本 | 销售辅助演示规划 |
| 每个代理设置成本 | 开发者工具激活 |
这也是加入预算上限的合适阶段。免费用户可能会获得更低成本的模型、更短的上下文或更少的重试。合格的试用用户可能会获得更强的模型，因为激活时刻更有价值。销售演示可能会使用高端路由，因为目标是建立信任，而不是最小化单位成本。
你的 LLM 成本计算器应该让这些策略可见。如果团队只能看到合并后的月度支出，它就无法知道激活是否过于昂贵，或者留存工作负载是否正在吞噬预算。
转化阶段：将 AI 成本与收入或管道挂钩
在转化阶段，计算器不应只用 token 来说话。它应将模型支出与收入、销售管道或利润率连接起来。
使用漏斗成本视图：
| 转化工作流 | 计算器指标 | 决策 |
|---|---|---|
| AI 销售调研 | 每份合格账户简报成本 | 如果它提升了销售代表吞吐量则保留 |
| AI 提案起草 | 每份被接受提案成本 | 如果毛利率支持则保留 |
| 电商创意生成 | 每个获批创意成本 | 如果创意测试速度提升则保留 |
| 支持升级工单起草 | 每个已解决升级工单成本 | 如果它降低了处理时间则保留 |
| 开发者代理工作流 | 每个合并变更或被接受任务成本 | 如果工程周期时间改善则保留 |
LLM 成本计算器在这里应包含非 token 成本：
gross_workflow_cost =
api_cost
+ tool_cost
+ review_minutes * loaded_hourly_rate
+ failed_output_cost然后将其与价值指标进行比较：
cost_as_percentage_of_value =
gross_workflow_cost / revenue_or_pipeline_value你不需要一个完美的归因模型，也能做出更好的决策。你需要的是一个能区分低成本演示和高利润工作流的计算器。
留存阶段：监控漂移、浪费和路由健康状况
留存阶段是计算器逻辑转化为运营的地方。上线后，同一份工作表应当变成仪表盘或定期复盘。
关注以下信号：
| 信号 | 可能意味着什么 |
|---|---|
| 每个任务的输入 token 上升 | 提示词在累积上下文，但没有进行裁剪 |
| 输出 token 上升 | 回复过于冗长，或最大 token 设置过高 |
| 缓存命中率下降 | 复用的上下文没有被正确结构化 |
| 重试率上升 | 提示词、模型或路由质量发生了变化 |
| 每个已接受任务的成本上升 | 用户拒绝了更多输出 |
| 每个任务的工具调用次数上升 | Agent 规划在循环，或者过度搜索 |
这就是请求级账本发挥作用的地方。Flatkey 将其使用界面围绕一个 key、一个余额，以及跨模型和工具的按请求使用可见性来构建。对于留存阶段的成本控制，这意味着团队可以在同一操作层中查看 token 数量、美元支出、请求 ID、预算和 allowlist，而不是对多个提供商导出的数据进行对账。如果这一阶段是你的主要问题，也请查看 AI API 支出预测 和 AI API 配额限制。
留存阶段也是告警应当部署的地方：
| 告警 | 触发条件 |
|---|---|
| 预算负责人告警 | 项目达到月度上限的 80% |
| 提示词漂移告警 | 中位输入 token 按周环比上升 25% |
| 重试告警 | 重试率超过约定阈值 |
| 模型切换告警 | 回退路由变成主路由 |
| 接受率告警 | 已接受任务率低于目标 |
LLM 成本计算器不再只是一个规划文件。它成为解释支出为何变化的标准。
可复制的漏斗计算器模板
可将其用作工作表结构：
| 列 | 说明 |
|---|---|
| 漏斗阶段 | 认知、评估、激活、转化、留存 |
| 工作流名称 | 具体任务，而不是宽泛的产品领域 |
| 负责人 | 团队、项目、活动或产品负责人 |
| 每周期请求数 | 预期的月度或周度量 |
| 每次请求的输入 token | 可用时使用中位数和 p90 |
| 每次请求的输出 token | 可用时使用中位数和 p90 |
| 缓存输入占比 | 可复用上下文的百分比 |
| 每次请求的工具调用次数 | 搜索、浏览器、增强、文件、图像或其他工具 |
| 重试/回退率 | 由错误、低质量输出或回退策略导致的额外调用 |
| 被接受的任务率 | 达到用户或业务目标的输出百分比 |
| API 成本 | Token、多模态和工具成本 |
| 审查成本 | 人工审查或修复时间 |
| 每个被接受任务的成本 | 最终比较指标 |
| 阶段决策 | 探索、测试、上线、扩展、设上限或退役 |
保持阶段决策明确。没有它，这张工作表就会变成另一份人人都会看、却没人会采取行动的报告材料。
常见错误
LLM 成本计算器最常见的错误是把 token 价格当作最终答案。token 价格只是输入。决策指标通常是每个被接受任务的成本、每个激活用户的成本，或每个合格结果的成本。
其他错误：
| 错误 | 修正 |
|---|---|
| 忽略输出 token | 在冗长的工作流中，模型输出可能主导成本 |
| 忽略重试 | 跟踪失败调用、低质量输出和回退尝试 |
| 将所有用户平均在一起 | 按漏斗阶段和工作负载负责人细分 |
| 忘记缓存行为 | 将新输入与缓存或重复上下文分开 |
| 遗漏工具 | Agent 工作流可能会调用搜索、浏览器、增强、图像或视频工具 |
| 使用过时价格 | 将计算器链接到实时定价页面，并在上线前刷新 |
| 只按成本比较模型 | 纳入被接受输出率、延迟和审查负担 |
Flatkey 的作用
当计算器需要从电子表格进入运营工作流时，Flatkey 很有用。团队可以通过一个兼容 OpenAI 的基础 URL 路由模型调用，在模型目录中比较模型，监控使用情况和成本，并将模型调用和工具调用保留在同一个计费平面上。更广泛的架构决策见 AI API 网关指南，而定价基础知识则见 什么是 AI 模型定价以及它何时重要？。
这并不会消除对计算器规范性的需求。你仍然需要定义阶段、负责人、被接受输出指标和预算上限。不同之处在于，当模型调用、工具调用、预算、允许列表和请求级使用记录都存在于同一层时，使用数据和控制更容易集中管理。
如果你正在构建 LLM 成本计算器的第一个版本，先从简单开始：
- 选择一个漏斗阶段。
- 选择一个工作流。
- 估算请求量和 token 形态。
- 加入重试、缓存和工具调用的假设。
- 计算每个已接受任务的成本。
- 比较两到三个模型或路由选项。
- 设定预算负责人和复盘频率。
然后，在工作流规模扩大之前，把计算器连接到实时使用数据。
常见问题
LLM 成本计算器的主要使用场景是什么？
LLM 成本计算器的主要使用场景，是判断一个 AI 工作流是否值得测试、上线、扩展或限流。最合适的计算器输出取决于漏斗阶段：认知阶段看月度区间，评估阶段看每个已接受任务的成本，激活阶段看每个已激活用户的成本，转化阶段看利润率影响，留存阶段看漂移告警。
LLM 成本计算器应该直接比较模型价格吗？
可以，但直接比较模型价格只是第一层。还要比较输入价格、输出价格、缓存输入、批处理选项、延迟、重试率、已接受输出率和工具成本。真正有用的输出不是“最便宜的模型”，而是在特定工作流下能带来最佳每个已接受任务成本的模型或路由。
团队应该多久刷新一次计算器假设？
在重大上线前、切换模型后、重写提示词后、流量激增后以及每月预算复盘时，都应刷新假设。提供方定价和模型行为都可能变化，因此实时定价页面和请求级使用记录应作为事实来源。
网关如何改变 LLM 成本计算器的工作方式？
网关不会改变核心计算，但它可以让数据更容易采集。如果模型调用、工具调用、预算、允许列表和请求账本都位于同一个密钥和同一计费层之后，计算器就可以使用一个统一的运行视图，而不必整合多个提供方仪表板。
结论
LLM 成本计算器不应只是一个通用的 token 小工具。它应该是一个决策系统。在认知阶段，它用于衡量机会规模；在评估阶段，它比较不同场景；在激活阶段，它保护首个用户旅程；在转化阶段，它检查利润率；在留存阶段，它解释漂移。
当这个决策系统需要实时模型定价、一个密钥、一个计费层，以及跨模型和工具调用的请求级可见性时，Flatkey 会很有帮助。先从计算器所处的阶段开始，然后在支出变得不可见之前，把它连接到真实使用数据。要测试这套配置，可以从 Flatkey 文档 开始，或在 模型目录 中比较当前的模型选项。
