按 token 计费在骗你：2026 年按任务核算 LLM 成本的可观测性指南

这是 2026 LLM 价格战主题集群的第三篇。第一篇 价格战战略分析 论证没有哪家厂商在价格上占据绝对主导。第二篇 API 路由与 fallback 实操指南 论证厂商选择应当是可逆的、配置驱动的决策。两篇都落在同一个实操主张上：按任务核算成本，而不是按 token 核算，才是唯一诚实的指标。本文就是这个主张的"怎么做"——如何真正测出一个任务花了你多少钱，让你能对价格战采取行动，而不是只读它的新闻。

我通读了可观测性文档与从业者资料后的结论很直接：大多数团队回答不了"总结这份文档到底花了我们多少钱"这个问题，因为他们的账单是 token 级的，而他们的产品是任务级的。这个鸿沟就是真正漏钱的地方。在 2026 年，如果你每月在 LLM API 上花超过几百美元，按任务核算的可观测性是你能建设的杠杆最高的一件事——比换厂商影响更大，比加 fallback 影响更大，因为它告诉你这两件事到底有没有真的帮上忙。

核心问题：你的账单用错了单位

LLM 厂商按 token 计费：这么几百万输入 token、这么几百万输出 token，各自按公开单价。这是他们开票的单位。但你的业务交付的不是 token，而是任务：一次总结、一次分类、一次代码评审、一次跑了三轮的 agent 执行。一个任务可以扇出成很多次按 token 计费的调用——一次 prompt、一次检索、一次重试、一次工具调用、又一次模型做校验——而你的账单把所有这些压扁成每个模型每月两个数字。

后果：账单告诉你花了多少，但无法告诉你为什么。它无法告诉你哪个功能贵、哪个用户不盈利、哪个模型按 token 看便宜但按任务看因为不停重试反而贵、或者你上周加的 fallback 到底是省了钱还是只是把花费挪到了更贵的备选上。在价格战不断逼你做的那个决策——"哪段工作该用哪个厂商"——上，你在盲飞。

这就是按任务可观测性要补上的鸿沟。它不再把 token 向上聚合成月度账单，而是把 token 向下聚合成任务：任务里的每次 LLM 调用都打上任务 id 的标签，最终你就知道这个具体任务、跨它触碰的每个模型/重试/工具调用，到底花了多少钱。

真正重要的指标

忘掉虚荣仪表板。真正能改变决策的指标是：

1. 按任务类型的已完成任务成本。 一次"总结"任务、算上重试、端到端到底花多少？这是唯一能让你公平比较模型的数字——一个按 token 便宜 3 倍但需要 2 倍调用次数才能收敛的模型并不便宜，而这件事只有在任务级才看得见。
2. 按模型的同任务类型成本。 同样的任务类型、不同模型、按"完成工作实际花了你多少"排名，而不是按价格表。这是基于成本路由的输入。
3. P50 / P95 成本，不只是平均。 平均值会隐藏长尾。一个平均便宜但 P95 很贵（因为某些输入撑爆上下文窗口或触发重试）的任务类型是预算风险。追踪百分位，不只是均值。
4. 按用户（或按功能、按租户）的成本。 这个数字告诉你哪些用户或功能是盈利的。没有它，你无法给产品定价、设配额、或决定投资哪个功能。
5. 按模型的错误与拒绝率。 一个拒绝或出错 15%、然后触发 fallback 的模型，实际比它按 token 的标价更贵——因为 fallback 那次调用也要计费。

注意这个清单上没有什么：月度总 token 花费。那个数字该出现在你的账单上，不该出现在你的决策仪表板上。它告诉你比分，不告诉你打法。

按任务归因到底怎么工作

不管用什么工具，机制都一样：一条 trace。

trace 是一棵共享同一个根（用户或系统发起的那个任务）的调用树。当用户说"总结这份文档"时，你开启一条 trace。在这条 trace 里，你把每次 LLM 调用、检索、工具调用、重试都记为一个子 span。每个 span 记录它的输入、输出、token 数、延迟、模型、以及（按厂商公开价算出的）成本。当 trace 完成时，你把所有 span 的成本求和，得到这个任务的真实成本。

这正是 Langfuse、Helicone、Portkey、Datadog LLM Observability 等所有工具在底层做的事。区别在易用性、托管模式、以及它们自动化了多少插桩。共享的原则——也是按任务归因之所以可行的原因——是：成本由 token 数 × 公开价计算得出，再按 trace 聚合，而不是从月度账单上读出来。

2026 工具格局（带诚实提醒）

可观测性领域很吵。以下是值得了解的选项，附它们真正的适合场景：

诚实提醒：大多数"2026 最佳 LLM 可观测性工具"榜单都是厂商关联或内容营销驱动的。上面的能力说法可以在各家自己的文档上验证（尤其 Langfuse、Portkey、Datadog）；榜单里的排名顺序应当当营销看，不是中立评测。资料里报道的一个常见从业者模式是：把一个网关工具（Helicone 或 Portkey，做成本/路由）和一个评测工具（Phoenix、TruLens 或 Braintrust，做质量）配对使用——因为成本没有质量上下文，只是半张图。

营销稿会淡化的锋利之处

采纳前值得知道的几个风险：

• 成本估算是估算。 每个工具都把成本算成 token 数 × 一个存储的价格。如果工具的价格表过时了，或厂商调价而工具滞后，你的"成本"就是错的。把工具报的成本当指示性看，每月与真实账单对账。Langfuse 和 Portkey 显式记录了这一点；有些工具没有。
• Agent 的 trace 才是预算真正爆掉的地方。 一次面向用户的任务，如果让 agent 循环五次、调用两次检索、再用第二个模型校验，可能花掉朴素"一次 LLM 调用"估算的 10 倍。如果你只插桩了外层调用，你只看到了真实成本的 1/10。追踪整棵树。
• 缓存在两个方向上扭曲按任务成本。 缓存命中让任务看起来人为便宜（仪表板好看，容量规划却糟）。缓存未命中让任务看起来人为昂贵。把缓存命中率与成本一起追踪，否则你的均值会误导你。
• 没有质量的归因只是半个决策。 "模型 A 按任务更便宜"这句话，如果模型 A 同时产出更差、需要人工返工，就毫无用处。在仅凭成本路由之前，永远把成本与一个质量信号（评测分、用户反馈、返工率）配对。
• 自托管用云成本换运维成本。 在单台 EC2 上自托管 Langfuse 是常见模式，但你现在是运营一个数据库、一条摄入路径和升级。对小团队，托管版的总拥有成本往往比"免费"自托管更低——一旦算上运维时间。

2026 年到底该怎么落地

我现在会给一个团队的实操路径：

1. 先插桩 trace，再选工具。 哪怕你只是先日志到一个已有的数据库，开始给每次 LLM 调用打上 trace_id、task_type、user_id、model、tokens in/out、延迟。这是每个工具都需要的数据；现在收集意味着以后采纳工具是一次配置变更，不是重构。
2. 从公开价计算成本，而不是从账单。 把 token 数乘以厂商当前公开价。这立刻给你按调用的成本，无需任何工具，而且它本就是每个工具用的构建块。
3. 挑覆盖你技术栈、最轻的工具。 如果你已经在 Datadog 做 APM，它的 LLM Observability 附加是"最少新东西"的选项。如果你想要开源和 trace 级深度，自托管 Langfuse。如果你想要托管且与路由配对，Portkey 闭环了上一篇的 fallback 模式。
4. 建四个决策仪表板，而不是十个虚荣仪表板。 按任务类型（分模型）的成本、按用户/功能的成本、P95 成本、按模型的错误/拒绝率。任何不改变路由或定价决策的，都是噪音。
5. 每月对账。 把工具估算的花费与真实账单对比。如果偏差超过几个百分点，你的价格表或插桩就偏了。

我的看法

2026 价格战不断压低按 token 的单价，但同时也在让按 token 的数字作为决策指标更没用——因为 token 越便宜，agent 就越乐意烧它们，你就越难看清一个任务到底花了你多少。价格战里状态最好的团队不是追最便宜厂商的那些，而是能实时看见每个任务跨每个厂商、重试、工具调用实际花了多少、并据此路由的那些。

如果 2026 年你只建一个 LLM 基础设施，就建按任务成本可观测性。它是其他一切的前提：基于成本的路由、按用户定价、功能盈利性，以及当下一个厂商价格表发布、有人问"我们该不该换"时的诚实回答。没有按任务的数字，这个问题是猜。有了按任务的数字，它是一次配置变更。

本文完结 2026 LLM 价格战主题集群三篇。如果还没读，先读 价格战战略分析 看"为什么"，再读 API 路由与 fallback 实操指南 看"怎么在厂商之间迁移"。本文是"怎么看它到底花了多少"。想找涉及厂商的常驻参考，见我们的 AI 价格数据页。

来源

• Langfuse：Token 与成本追踪文档
• Portkey：AI 成本可观测性实操指南
• Datadog：LLM Observability 成本文档
• Braintrust：2026 生产环境追踪 LLM 成本最佳工具
• Cekura：Helicone vs Langfuse vs Cekura 2026 实测
• Tracelo：如何按用户追踪 LLM token 用量与成本
• Maxim AI：LLM 运营中监控延迟与成本
• Langfuse：AI agent 可观测性、追踪与评测
• 我们的姐妹篇：2026 LLM API 价格战
• 我们的姐妹篇：2026 API 路由与 fallback 实操指南