2026 年 LLM 成本计算器：算每个任务，不算每个 Token
评估 LLM 账单时，真正有用的单位不是一百万 token，而是一个完成的任务：一个客服工单被回答，一张发票被抽取，一个 pull request 被审阅，一个内部问题被解决。每 token 价格只是价格表。每任务成本才是经过重试、工具调用、上下文、缓存命中、路由、批处理折扣和失败输出之后，最后落到发票上的数字。
这是工程视角，不是价格建议。下面的公式稳定，但示例价格是方向性的，投入预算前必须换成当前供应商价格。截至 2026 年 7 月 8 日：OpenAI Batch API 标注 50% 折扣和 24 小时完成窗口，OpenAI prompt caching 从 1,024 个 prompt token 起生效，Anthropic cache read 按基础输入价格的 0.1x 计价，Batches API 按标准价格 50% 计价，Gemini 对 Gemini 2.5 和更新模型默认开启隐式缓存。预算前请复核下方一手来源。
想用你的流量跑一遍？
预约免费咨询一个公式看懂计算器
从一个任务开始，而不是从一个 API 调用开始。一个任务可能包含多次模型调用、检索、工具调用、验证器，有时还有重试。完整成本是：
| 项目 | 公式 | 要测什么 |
|---|---|---|
| 未缓存输入 | input_tokens_uncached / 1M * input_price | Prompt、检索片段、工具 schema、对话状态 |
| 缓存输入 | input_tokens_cached / 1M * cached_input_price | 稳定前缀、工具定义、系统 prompt |
| 输出 | output_tokens / 1M * output_price | 最终回答、可见推理输出、生成物 |
| 每任务调用数 | sum(call_cost) across the task | Agent 轮次、验证器、分类器、fallback |
| 重试 | task_cost * retry_rate | 超时、schema 失败、低置信度、工具错误 |
| 批处理折扣 | eligible_async_cost * batch_multiplier | 评测、数据增强、抽取、夜间任务 |
| 失败成本 | failed_task_rate * human_rework_cost | 人工修复、QA、工程审阅、客户影响 |
每个完成任务的成本 = 所有模型调用成本 + 检索和基础设施 + 重试成本 + 人工返工成本。
这就是为什么我们写过 每 token 成本与每任务成本。一个更便宜的模型，如果需要更多轮、生成更长输出、失败更多次，可能比价格表上看起来更贵的模型还贵。
计算器应该输入哪些字段？
- 任务量。统计真实业务单位：工单、文档、报价、pull request、检查、研究简报。只统计聊天消息通常太粗。
- 每任务调用数。Agent 工作流常常把钱花在循环里：分类、检索、草稿、工具、验证、改写、审计日志摘要。
- 每次调用输入。拆分稳定前缀、检索上下文、历史、工具 schema、易变用户数据。
- 每次调用输出。推理和编码 agent 可能输出很重。输入便宜但输出昂贵时，价格表容易误导。
- 缓存命中率。测缓存 token，而不是只测缓存 request。OpenAI 暴露 `cached_tokens`，Gemini 暴露 cached token count，Anthropic 区分 cache write 和 cache read。
- 可批处理比例。能等的任务先走 batch：eval、离线抽取、enrichment、分类、摘要。
- 升级率。如果便宜模型做第一遍，强模型处理困难案例，升级比例就是产品 KPI。
- 质量底线。把 eval pass rate 放在成本旁边。否则你只是在比较账单，而不是比较有效工作。
"如果你的计算器不能告诉你一个成功任务花了多少钱，它就不是 AI 成本计算器。它只是 token 收据。"
示例：客服工单分流
设想一个客服 workflow：读取工单，检索政策片段，起草答案，再用验证器检查答案是否有依据。天真的表格会写：一次回答调用，大约 4,000 输入 token 和 600 输出 token。生产 trace 往往是这样：
| 步骤 | 调用 | 输入 | 输出 | 优化杠杆 |
|---|---|---|---|---|
| 工单分类 | 1 | 700 | 60 | 小模型或规则 |
| 检索并起草 | 1 | 5,500 | 700 | Prompt cache、更好的检索 |
| 验证 grounding | 1 | 3,200 | 120 | 便宜验证器，先做确定性检查 |
| 低置信度时改写 | 平均 0.18 | 4,800 | 500 | 改 prompt 或选择性升级 |
模型成本不是一次回答调用，而是平均 3.18 次调用，加上检索和重试尾部。如果草稿输入里 60% 是稳定系统 prompt、政策框架和工具 schema，prompt caching 可能比换模型更重要。如果只有 20% 的工单需要强模型，routing 可能比默认模型便宜几分钱更重要。这就是我们的 LLM token 成本削减 playbook，换成计算器表达。
Prompt caching 怎么进入公式
输入成本 = uncached_input * normal_input_price + cached_input * cache_read_price + cache_writes * cache_write_price。
操作上的技巧很朴素：稳定内容放前面，易变内容放后面。OpenAI 的 prompt caching 文档说，1,024 token 以上的 prompt 可用缓存，并建议把静态或重复内容放在开头。Anthropic 把 cache read 定价为 0.1x，但 cache write 比普通输入更贵，所以前缀必须复用才划算。Gemini 当前文档说，Gemini 2.5 和更新模型默认开启隐式缓存，并建议把大型共同内容放在开头。
- 好的缓存前缀：系统指令、工具定义、输出 schema、产品政策、稳定检索上下文。
- 差的缓存前缀：时间戳、用户 ID、随机 trace ID、当前请求文档、工单正文。
- 要跟踪的指标：缓存输入 token / 总输入 token，按 feature 和模型拆分。
一手文档：OpenAI prompt caching、Anthropic prompt caching 和 Gemini context caching。
Batch API 怎么进入公式
总模型成本 = live_cost + batchable_cost * batch_multiplier。
Batch 不是降低延迟，而是给可以等待的工作降价并提高吞吐。OpenAI Batch API 文档写明，相比同步 API 有 50% 成本折扣，完成窗口为 24 小时。Anthropic Message Batches API 页面也写明成本降低 50%，大多数 batch 在一小时内完成，全部消息完成或 24 小时后可拿结果。Eval、夜间文档处理、离线抽取、回填、审核和分析摘要，都应该优先考虑 batch。
不要把用户正在等待的聊天体验放进 batch。要把你的 eval harness 放进 batch。很多团队持续花钱重测 prompt 和模型，却忘了这些测试不需要 live latency。我们在 LLM eval 什么时候回本 里详细讲过。
一手文档：OpenAI Batch API 和 Anthropic batch processing。
Routing：省钱，但有质量陷阱
路由成本 = cheap_path_cost * (1 - escalation_rate) + strong_path_cost * escalation_rate + verifier_cost。
RouteLLM 对这个问题的表述很清楚：简单查询走便宜模型，困难查询留给强模型，并在接近你真实流量的数据上校准阈值。它的 README 报告，在基准上可降低最高 85% 成本，同时保持 95% GPT-4 性能。把这个当研究参考，不要当你的生产数字。你的流量可能完全不同，特别是有行业 edge case 时。
- 便宜默认模型。从能通过简单多数任务的最低成本模型开始。
- 验证器。检查 schema、grounding、policy 和 confidence。
- 升级。不确定、高风险或失败案例交给强模型。
- Eval gate。在真实样本上比较便宜路径、强路径和路由路径。
- 监控升级率。强模型占比上升时，要么流量变了，要么便宜模型被过度使用。
这里 LLM gateway 和 router 会很有用。LiteLLM、Portkey、OpenRouter 或自建 RouteLLM 层，可以集中日志、模型组合、fallback、预算和路由。计算器告诉你为什么需要这一层，gateway 让你真正测到这一层。
研究和工具：RouteLLM、RouteLLM paper、batch-level query routing 和 routing with batch prompting。
本地模型和自托管
自托管不会让推理免费。它只是把可变 token 成本换成 GPU 成本、利用率风险、运维、冗余和 eval 维护：
自托管每任务成本 = (gpu_hour_cost + ops_hour_cost + redundancy + monitoring + eval_upkeep) / completed_tasks_per_hour。
分母决定一切。一块全天 80% 负载的 GPU 可能让本地推理合理。一块因为流量突发而只有 12% 利用率的 GPU，会变成很昂贵的主权姿态。所以我们的 欧盟 LLM 自托管成本指南 从流量和数据驻留开始，而不是从 GPU 规格开始。
- 数据驻留或治理强制要求。如果数据不能离开你的基础设施，成本就是第二个问题。
- 高且稳定的流量填满硬件。相对便宜的 hosted open-weight API，自托管需要持续负载，而不是偶发峰值。
模型选择在这之后。我们的 open-weight LLM 对比 从欧洲部署视角比较了 DeepSeek、Qwen、Kimi、GLM 和 Llama。你的计算器应该包含模型在你自己 eval 上的通过率，而不只是 tokens per second。
上下文压缩和语义缓存
- 语义缓存。如果新请求与旧请求足够接近，直接返回旧答案或轻微调整。它在重复客服和内部助手里很省钱，但如果权限和失效机制做差，会产生过期答案、错误个性化或越权答案。
- 上下文压缩。给模型最小的正确上下文：摘要、文件地图、相关片段、裁剪后的工具输出，而不是每一轮重发整个 workspace。
这与 为什么编码 agent 失败在上下文而不是智力 直接相关，也与我们关于 把文本渲染成图像来省 token 的文章相关。压缩很强，但精确值、ID、金额、哈希、法律条款和权限必须保持精确。如果优化是有损的，计算器就必须加入失败成本。
可以照抄的表格结构
| 列 | 示例 | 为什么重要 |
|---|---|---|
| 任务类型 | 客服回答 | 业务单位，不是 API 单位 |
| 月任务量 | 25,000 | 放大账单 |
| 每任务调用 | 3.18 | 捕捉 agent 循环 |
| 每次调用输入 | 3,900 | 主要缓存目标 |
| 缓存 token 占比 | 55% | 显示 prompt cache 空间 |
| 每次调用输出 | 420 | 常常支配推理 agent 成本 |
| 可 batch 比例 | 20% | 应用异步折扣 |
| 强模型升级率 | 18% | 路由经济性 |
| 重试率 | 7% | 隐藏成本和质量信号 |
| Eval 通过率 | 94% | 避免假省钱 |
| 人工返工分钟 | 0.6 | 把失败换算成钱 |
| 每个成功任务成本 | 计算值 | 真正要优化的数字 |
优化顺序
- 先埋点每任务成本。记录 task ID、模型、token、cache hit、retry、latency、结果状态和 eval 判断。
- 认真做缓存。稳定前缀放前面，易变数据放后面，按 feature 跟踪缓存 token。
- 离线任务走 batch。Eval 和 enrichment 不该付 live 价格。
- 用验证器做路由。便宜默认模型，强模型 fallback，监控升级率。
- 按任务选模型。在你的 eval set 上测试 open-weight 和小模型。
- 压缩上下文。移除无关历史和重复 workspace 上下文。
- 只在流量或治理要求下自托管。计算利用率和工程时间，而不只是 GPU 小时。
最终思考
2026 年的 LLM 成本计算器从任务开始。统计每一次模型调用，拆分缓存输入和未缓存输入，单独计算输出，只对能等待的工作应用 batch 折扣，用升级率建模路由，并加上重试和人工返工。最后除以成功任务数，而不是请求数。
最佳顺序是：测每任务成本，修 prompt caching，把离线任务移到 batch，把简单工作从 frontier 模型路由出去，用 eval harness 调整模型，压缩上下文，然后只在流量或数据驻留要求让它合理时自托管。赢家不是最便宜的 token，而是仍然通过质量线的最便宜任务。
想从你的日志构建计算器？
预约免费咨询