--- title: "2026 年 LLM 成本计算器：每任务成本" canonical: https://wavect.io/zh/blog/llm-cost-calculator-2026/ language: zh description: "一份实用的 2026 年 LLM 成本计算器：覆盖每任务成本、prompt caching、Batch API、路由、自托管、重试和 eval 质量。" image: "https://wavect.io/img/blog/headers/header_llm-cost-calculator-2026.png" --- [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 12 分钟 阅读 · 2026年7月8日 [**下一篇**](/zh/blog/the-factory-returns/) # 2026 年 LLM 成本计算器：算每个任务，不算每个 Token 要点速览 LLM 账单里真正有用的单位是一个完成任务，而不是一百万 token。2026 年的真实计算器要统计任务中的每一次模型调用，拆分未缓存输入和缓存输入，单独计算输出，只把 batch 折扣用于异步工作，用升级率建模路由，并加入重试和人工返工。Prompt caching 通常是第一个杠杆：稳定前缀放前面，易变数据放后面，并按 feature 测量缓存 token。Batch API 适合 eval、enrichment 和离线抽取，不适合 live UX。Routing 只有在验证器和 eval harness 证明便宜路径守住质量时才安全省钱。自托管只有在数据驻留强制要求，或稳定流量在计入运维、冗余和 eval 维护后能填满 GPU 时才合理。优化顺序是：埋点每个成功任务成本、缓存、batch、路由、按任务选模型、压缩上下文，然后只在数学或治理要求时自托管。数字是 2026 年 7 月快照；预算前请重新核对供应商文档。 评估 [LLM](/zh/glossary/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 成本与每任务成本](/zh/blog/cost-per-token-vs-cost-per-task/) 。一个更便宜的模型，如果需要更多轮、生成更长输出、失败更多次，可能比价格表上看起来更贵的模型还贵。 ## 计算器应该输入哪些字段？ - 任务量。 统计真实业务单位：工单、文档、报价、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 放在成本旁边。否则你只是在比较账单，而不是比较有效工作。 ![Kevin Riedl](/img/team/kevin.webp) "如果你的计算器不能告诉你一个成功任务花了多少钱，它就不是 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](/zh/blog/reduce-llm-token-costs-2026/) ，换成计算器表达。 ## 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](https://developers.openai.com/api/docs/guides/prompt-caching) 、 [Anthropic prompt caching](https://platform.claude.com/docs/en/build-with-claude/prompt-caching) 和 [Gemini context caching](https://ai.google.dev/gemini-api/docs/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 什么时候回本](/zh/blog/llm-evaluation-cost-roi-production/) 里详细讲过。 一手文档： [OpenAI Batch API](https://developers.openai.com/api/docs/guides/batch) 和 [Anthropic batch processing](https://platform.claude.com/docs/en/build-with-claude/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](/zh/blog/llm-gateway-router-comparison-2026/) 会很有用。LiteLLM、Portkey、OpenRouter 或自建 RouteLLM 层，可以集中日志、模型组合、fallback、预算和路由。计算器告诉你为什么需要这一层，gateway 让你真正测到这一层。 研究和工具： [RouteLLM](https://github.com/lm-sys/RouteLLM) 、 [RouteLLM paper](https://arxiv.org/abs/2406.18665) 、 [batch-level query routing](https://arxiv.org/abs/2603.26796) 和 [routing with batch prompting](https://arxiv.org/abs/2605.28268) 。 ## 本地模型和自托管 自托管不会让推理免费。它只是把可变 token 成本换成 GPU 成本、利用率风险、运维、冗余和 eval 维护： 自托管每任务成本 = (gpu_hour_cost + ops_hour_cost + redundancy + monitoring + eval_upkeep) / completed_tasks_per_hour。 分母决定一切。一块全天 80% 负载的 GPU 可能让本地推理合理。一块因为流量突发而只有 12% 利用率的 GPU，会变成很昂贵的主权姿态。所以我们的 [欧盟 LLM 自托管成本指南](/zh/blog/self-hosting-llms-eu-cost/) 从流量和数据驻留开始，而不是从 GPU 规格开始。 - 数据驻留或治理强制要求。 如果数据不能离开你的基础设施，成本就是第二个问题。 - 高且稳定的流量填满硬件。 相对便宜的 hosted open-weight API，自托管需要持续负载，而不是偶发峰值。 模型选择在这之后。我们的 [open-weight LLM 对比](/zh/blog/open-weight-llm-comparison-2026/) 从欧洲部署视角比较了 DeepSeek、Qwen、Kimi、GLM 和 Llama。你的计算器应该包含模型在你自己 eval 上的通过率，而不只是 tokens per second。 ## 上下文压缩和语义缓存 - 语义缓存。 如果新请求与旧请求足够接近，直接返回旧答案或轻微调整。它在重复客服和内部助手里很省钱，但如果权限和失效机制做差，会产生过期答案、错误个性化或越权答案。 - 上下文压缩。 给模型最小的正确上下文：摘要、文件地图、相关片段、裁剪后的工具输出，而不是每一轮重发整个 workspace。 这与 [为什么编码 agent 失败在上下文而不是智力](/zh/blog/ai-coding-agents-context-not-intelligence/) 直接相关，也与我们关于 [把文本渲染成图像来省 token](/zh/blog/text-as-image-token-savings/) 的文章相关。压缩很强，但精确值、ID、金额、哈希、法律条款和权限必须保持精确。如果优化是有损的，计算器就必须加入失败成本。 ## 可以照抄的表格结构 | 列 | 示例 | 为什么重要 | | --- | --- | --- | | 任务类型 | 客服回答 | 业务单位，不是 API 单位 | | 月任务量 | 25,000 | 放大账单 | | 每任务调用 | 3.18 | 捕捉 agent 循环 | | 每次调用输入 | 3,900 | 主要缓存目标 | | 缓存 token 占比 | 55% | 显示 prompt cache 空间 | | 每次调用输出 | 420 | 常常支配推理 agent 成本 | | 可 batch 比例 | 20% | 应用异步折扣 | | 强模型升级率 | 18% | 路由经济性 | | 重试率 | 7% | 隐藏成本和质量信号 | | Eval 通过率 | 94% | 避免假省钱 | | 人工返工分钟 | 0.6 | 把失败换算成钱 | | 每个成功任务成本 | 计算值 | 真正要优化的数字 | ## 优化顺序 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 落地服务](/zh/services/ai-enablement/) 所做的事。 [Hyperstate AI](/zh/case-studies/hyperstate-ai/) 是一个公开案例：把 GPU 密集的单体拆开之后，延迟和成本同时下降。我们的 [技术选型指南](/zh/software-development-guide/how-to-choose-a-tech-stack-for-mvp/) 则讨论如何在账单出现之前就做出这个决定。 ## 最终思考 2026 年的 LLM 成本计算器从任务开始。统计每一次模型调用，拆分缓存输入和未缓存输入，单独计算输出，只对能等待的工作应用 batch 折扣，用升级率建模路由，并加上重试和人工返工。最后除以成功任务数，而不是请求数。 最佳顺序是：测每任务成本，修 prompt caching，把离线任务移到 batch，把简单工作从 frontier 模型路由出去，用 eval harness 调整模型，压缩上下文，然后只在流量或数据驻留要求让它合理时自托管。赢家不是最便宜的 token，而是仍然通过质量线的最便宜任务。 ## 你可能也喜欢.. [**2026 年如何降低 LLM Token 成本** 这篇计算器背后的执行 playbook：缓存、批处理、路由、模型匹配、压缩，以及只在合理时自托管。](/zh/blog/reduce-llm-token-costs-2026/) [**AI Enablement vs 通用 AI 咨询** 一个给你策略幻灯片。另一个在你的基础设施上交付一个团队真正拥有的可运行 setup。](/zh/compare/ai-enablement-vs-generic-ai-consultancy/) 模型与基础设施 ## 继续浏览此集群 模型选择、推理经济性、本地部署、压缩与服务架构。 [从核心文章开始**在欧盟自托管 LLM：开放权重模型何时才真正划算**](/zh/blog/self-hosting-llms-eu-cost/) - [Netflix 的 vLLM 与 Triton 推理栈：7 个生产经验](/zh/blog/netflix-vllm-triton-inference-stack/) - [Transformers.js 浏览器本地 AI：什么时候适合放进产品](/zh/blog/transformers-js-browser-ai-guide/) - [LiteLLM 生产级自托管指南：2026 架构与安全](/zh/blog/self-host-litellm-production-2026/) - [AI 就绪企业 Wiki：架构与实施指南](/zh/blog/ai-ready-company-wiki/) - [Claude 会给文本加水印吗？2026 API 实战解读](/zh/blog/claude-text-watermark-api-2026/) 只收重要内容 ## 关注与你相关的内容 每当我们发布新文章，你会收到一封简短邮件。你可以关注整个博客，也可以只选感兴趣的主题。 [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 12 分钟 阅读 · 2026年7月8日 [**下一篇**](/zh/blog/the-factory-returns/) 邮件订阅新文章 × × 通过邮件获取新文章 我们发布时给你一封简短邮件。免费，不做跟踪。 ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/zh/blog/llm-cost-calculator-2026/#webpage", "@type": "WebPage", "dateModified": "2026-07-08", "inLanguage": "zh", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-07-08", "url": "https://wavect.io/zh/blog/llm-cost-calculator-2026/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "LLM 账单里真正有用的单位是一个完成任务，而不是一百万 token。2026 年的真实计算器要统计任务中的每一次模型调用，拆分未缓存输入和缓存输入，单独计算输出，只把 batch 折扣用于异步工作，用升级率建模路由，并加入重试和人工返工。Prompt caching 通常是第一个杠杆：稳定前缀放前面，易变数据放后面，并按 feature 测量缓存 token。Batch API 适合 eval、enrichment 和离线抽取，不适合 live UX。Routing 只有在验证器和 eval harness 证明便宜路径守住质量时才安全省钱。自托管只有在数据驻留强制要求，或稳定流量在计入运维、冗余和 eval 维护后能填满 GPU 时才合理。优化顺序是：埋点每个成功任务成本、缓存、batch、路由、按任务选模型、压缩上下文，然后只在数学或治理要求时自托管。数字是 2026 年 7 月快照；预算前请重新核对供应商文档。", "articleBody": " 博客概览/AI 与智能体/模型与基础设施 2026 年 LLM 成本计算器：算每个任务，不算每个 Token 要点速览 LLM 账单里真正有用的单位是一个完成任务，而不是一百万 token。2026 年的真实计算器要统计任务中的每一次模型调用，拆分未缓存输入和缓存输入，单独计算输出，只把 batch 折扣用于异步工作，用升级率建模路由，并加入重试和人工返工。Prompt caching 通常是第一个杠杆：稳定前缀放前面，易变数据放后面，并按 feature 测量缓存 token。Batch API 适合 eval、enrichment 和离线抽取，不适合 live UX。Routing 只有在验证器和 eval harness 证明便宜路径守住质量时才安全省钱。自托管只有在数据驻留强制要求，或稳定流量在计入运维、冗余和 eval 维护后能填满 GPU 时才合理。优化顺序是：埋点每个成功任务成本、缓存、batch、路由、按任务选模型、压缩上下文，然后只在数学或治理要求时自托管。数字是 2026 年 7 月快照；预算前请重新核对供应商文档。 评估 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_pricePrompt、检索片段、工具 schema、对话状态 缓存输入input_tokens_cached / 1M * cached_input_price稳定前缀、工具定义、系统 prompt 输出output_tokens / 1M * output_price最终回答、可见推理输出、生成物 每任务调用数sum(call_cost) across the taskAgent 轮次、验证器、分类器、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 往往是这样： 步骤调用输入输出优化杠杆 工单分类170060小模型或规则 检索并起草15,500700Prompt cache、更好的检索 验证 grounding13,200120便宜验证器，先做确定性检查 低置信度时改写平均 0.184,800500改 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、金额、哈希、法律条款和权限必须保持精确。如果优化是有损的，计算器就必须加入失败成本。 可以照抄的表格结构 列示例为什么重要 任务类型客服回答业务单位，不是", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "dateModified": "2026-07-08", "datePublished": "2026-07-08", "description": "LLM 账单里真正有用的单位是一个完成任务，而不是一百万 token。2026 年的真实计算器要统计任务中的每一次模型调用，拆分未缓存输入和缓存输入，单独计算输出，只把 batch 折扣用于异步工作，用升级率建模路由，并加入重试和人工返工。Prompt caching 通常是第一个杠杆：稳定前缀放前面，易变数据放后面，并按 feature 测量缓存 token。Batch API 适合 eval、enrichment 和离线抽取，不适合 live UX。Routing 只有在验证器和 eval harness 证明便宜路径守住质量时才安全省钱。自托管只有在数据驻留强制要求，或稳定流量在计入运维、冗余和 eval 维护后能填满 GPU 时才合理。优化顺序是：埋点每个成功任务成本、缓存、batch、路由、按任务选模型、压缩上下文，然后只在数学或治理要求时自托管。数字是 2026 年 7 月快照；预算前请重新核对供应商文档。", "headline": "2026 年 LLM 成本计算器：算任务，不算 Token", "image": "https://wavect.io/img/blog/headers/header_llm-cost-calculator-2026.svg", "inLanguage": "zh", "mainEntityOfPage": { "@id": "https://wavect.io/zh/blog/llm-cost-calculator-2026/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/zh/blog/llm-cost-calculator-2026/", "wordCount": 609 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/zh/", "name": "首页", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/overview/", "name": "博客概览", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/topics/ai-agents/", "name": "AI 与智能体", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/clusters/models-infrastructure/", "name": "模型与基础设施", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/llm-cost-calculator-2026/", "name": "2026 年 LLM 成本计算器：每任务成本 | ", "position": 5 } ] } ```