2026 年 LLM 成本计算器：算每个任务，不算每个 Token

评估 LLM 账单时，真正有用的单位不是一百万 token，而是一个完成的任务：一个客服工单被回答，一张发票被抽取，一个 pull request 被审阅，一个内部问题被解决。每 token 价格只是价格表。每任务成本才是经过重试、工具调用、上下文、缓存命中、路由、批处理折扣和失败输出之后，最后落到发票上的数字。

这是工程视角，不是价格建议。本文于 2026 年 9 月 2 日完成全面复核，但供应商价格和模型资格会变化。OpenAI Batch 标示成本低 50%，并在 24 小时内完成。GPT-5.6 及更新模型的缓存最低为 1,024 个可见输入 token，旧模型为 2,048；GPT-5.6 及更新模型写入按 1.25x、读取按 0.1x 计价。Anthropic 的 5 分钟写入为 1.25x、1 小时写入为 2x、读取为 0.1x，batch 为标准价格 50%。Gemini 为 2.5 及更新模型默认启用隐式缓存，并设模型专属最低长度。预算前请核对一手来源与账单。

一个公式看懂计算器

从一个任务开始，而不是从一个 API 调用开始。一个任务可能包含多次模型调用、检索、工具调用、验证器，有时还有重试。完整成本是：

每个成功任务成本 =（初始模型调用 + 重试与 fallback + 检索与基础设施 + 人工返工）/ 成功任务数。

这就是为什么我们写过 每 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 往往是这样：

模型成本不是一次回答调用，而是平均 3.18 次调用，加上检索和重试尾部。如果草稿输入里 60% 是稳定系统 prompt、政策框架和工具 schema，prompt caching 可能比换模型更重要。如果只有 20% 的工单需要强模型，routing 可能比默认模型便宜几分钱更重要。这就是我们的 LLM token 成本削减 playbook，换成计算器表达。

Prompt caching 怎么进入公式

输入成本 = (uncached_input_tokens / 1M × normal_input_price) + (cache_read_tokens / 1M × cache_read_price) + (cache_write_tokens / 1M × cache_write_price)。

稳定内容应放在易变数据之前。OpenAI 按模型规定最低长度：GPT-5.6 及更新模型为 1,024 个可见输入 token，旧模型为 2,048；GPT-5.6 及更新模型写入为 1.25x、读取为 0.1x，旧模型规则不同。Anthropic 的 5 分钟写入为 1.25x、1 小时写入为 2x、读取为 0.1x。Gemini 为 2.5 及更新模型开启隐式缓存，当前列出的最低长度为 2,048 至 4,096 token。应使用实际 usage 类别计算。

• 好的缓存前缀：系统指令、工具定义、输出 schema、产品政策、稳定检索上下文。
• 差的缓存前缀：时间戳、用户 ID、随机 trace ID、当前请求文档、工单正文。
• 要跟踪的指标：缓存输入 token / 总输入 token，按 feature 和模型拆分。

一手文档：OpenAI prompt caching、Anthropic prompt caching 和 Gemini context caching。

Batch API 怎么进入公式

总模型成本 = 同步模型成本 + Σ 按输入、缓存写入、缓存读取和输出类别计算的实际 batch 成本。

OpenAI Batch 文档标明成本低 50%，并在 24 小时内完成。Anthropic 按标准价格 50% 计费；多数 batch 一小时内完成，未完成项目在 24 小时后过期。Batch 适合能接受这些完成规则的 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 时。

1. 便宜默认模型。从能通过简单多数任务的最低成本模型开始。
2. 验证器。检查 schema、grounding、policy 和 confidence。
3. 升级。不确定、高风险或失败案例交给强模型。
4. Eval gate。在真实样本上比较便宜路径、强路径和路由路径。
5. 监控升级率。强模型占比上升时，要么流量变了，要么便宜模型被过度使用。

这里 LLM gateway 和 router 会很有用。LiteLLM、Portkey、OpenRouter 或自建 RouteLLM 层，可以集中日志、模型组合、fallback、预算和路由。计算器告诉你为什么需要这一层，gateway 让你真正测到这一层。

研究和工具：RouteLLM、RouteLLM paper、batch-level query routing 和 routing with batch prompting。

本地模型和自托管

自托管不会让推理免费。它只是把可变 token 成本换成 GPU 成本、利用率风险、运维、冗余和 eval 维护：

自托管每个成功任务成本 = (amortized_compute_per_hour + ops_per_hour + redundancy_per_hour + monitoring_per_hour + eval_upkeep_per_hour) / successful_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、金额、哈希、法律条款和权限必须保持精确。如果优化是有损的，计算器就必须加入失败成本。

可以照抄的表格结构

优化顺序

1. 先埋点每任务成本。记录 task ID、模型、token、cache hit、retry、latency、结果状态和 eval 判断。
2. 认真做缓存。稳定前缀放前面，易变数据放后面，按 feature 跟踪缓存 token。
3. 离线任务走 batch。Eval 和 enrichment 不该付 live 价格。
4. 用验证器做路由。便宜默认模型，强模型 fallback，监控升级率。
5. 按任务选模型。在你的 eval set 上测试 open-weight 和小模型。
6. 压缩上下文。移除无关历史和重复 workspace 上下文。
7. 只在流量或治理要求下自托管。计算利用率和工程时间，而不只是 GPU 小时。

如果算出来的这个数字正是项目卡住的原因，那么解法通常在架构层面，而不是算术层面。先给支出做上埋点，再持续改造路由、缓存和检索，直到「每完成一个任务的成本」真正下降，这正是我们 AI 落地服务所做的事。Hyperstate AI 是一个公开案例：把 GPU 密集的单体拆开之后，延迟和成本同时下降。我们的技术选型指南则讨论如何在账单出现之前就做出这个决定。