# Token 标价是个坑

**Summary:** Jan Iłowski 认为按百万 Token 计价不是比较 AI 成本的好方法；我的看法是，团队需要任务级评估、感知 Tokenizer 的预算，以及按每美元产出做路由。

- Canonical: https://markhuang.ai/zh/news/token-sticker-price-is-a-trap
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-07-06
- Section: News
- Tags: AI, 大模型, FinOps, 模型评估, Token 定价
- Source: [Janilowski.pl](https://janilowski.pl/en/blog/2026/price-per-m-tokens/)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![卡通产品团队盯着 Token 气泡、空白价签和一条卷进成本仪表的长小票](https://cdn.markhuang.ai/news/token-sticker-price-is-a-trap/hero.webp)

*标价看得见，真正要买单的是把任务可靠做完所需的全部工作量。*

Jan Iłowski 在 [Price per 1M tokens is meaningless](https://janilowski.pl/en/blog/2026/price-per-m-tokens/) 一文里，纠正了一个糟糕的采购习惯。他的论点很直接：两家模型都能挂出一个漂亮的 `$X per 1M tokens` 单价，可一旦 tokenizer、隐藏推理、输出长度、缓存计价、实际任务成功率各自独立变化，这个数字就不再可比。

我觉得标题故意说得狠了一点，但教训本身站得住。每百万 Token 单价不是不能当输入，问题在于不能拿它当决策依据。一个团队如果只看 Excel 里的单价来选模型，而不去自己业务场景里测完成一个任务到底花多少钱，那不是在买更便宜的 AI，而是在买一个包装更漂亮的不确定性。

## 答案快照

| 问题          | 我的看法                                                                                           |
| ----------- | ---------------------------------------------------------------------------------------------- |
| 发生了什么？      | Iłowski 在 2026 年 7 月 5 日发文指出，按百万 Token 计价不是比较 AI 模型的好方法，因为不同模型、不同业务场景下 Token 数量和 Token 效率差异很大。 |
| 为什么重要       | AI 支出已经足够日常化，Token 单价再低，只要模型需要更多 Token、更多隐藏推理、更多重试或更多评估清理，最终账单照样更贵。                            |
| 谁能在正确衡量后受益？ | 把常规任务路由给便宜模型，把更强或更贵的模型留给那些能证明每次成功产出更划算的任务——这种产品、财务、工程团队会受益。                                    |
| 我的核心观点      | 真正该比的不是 Token 单价，而是在明确质量门槛下每美元买到多少经过验证的成果。                                                     |
| 难点在哪        | 基准测试有帮助，但基准不是你的业务。最终答案还是要从你自己产品里的任务级评估、日志记录和预算防护中得出。                                           |

## 单位本身就不中立

第一个问题出在 Token 计数方式上。Iłowski 给了一个具体例子：同一段文本用 tiktokenizer 计算，GPT-4o 算出 160 个 Token，GPT-4 1106-preview 算出 200 个。我不会把这个计算器输出当成普适常数，但背后的机制是真实的。OpenAI 自己的 [tiktoken 指南](https://developers.openai.com/cookbook/examples/how_to_count_tokens_with_tiktoken)就写明，不同模型使用不同编码，而 Token 数量直接决定 API 使用成本。

Anthropic 在 [Claude Sonnet 5 文档](https://platform.claude.com/docs/en/about-claude/models/whats-new-sonnet-5)里说得更直白：Sonnet 5 用了新 tokenizer，同样的输入比 Sonnet 4.6 多出大约 30% 的 Token，具体比例随内容变化；这会直接影响 Token 计数、上下文容量、输出预算和每次请求的成本——即便 Token 单价没变。

于是一张干净的价格表反而带来了测量问题。一个模型可能 Token 单价更低，同样的 prompt 却消耗更多 Token；另一个模型可能 Token 单价更高，却用更少的 Token 完成同样的任务。到了这一步，单价本身没错，但比较已经失真。

![卡通研究员看着同一份空白文档经过三台机器，变成三堆大小不同的 Token](https://cdn.markhuang.ai/news/token-sticker-price-is-a-trap/why-it-matters.webp)

*同一份源材料在不同模型手里会变成规模完全不同的 Token 堆。光凭这一点，跨模型比价就不靠谱。*

## 任务成本才是更该问的问题

Iłowski 这篇文章更有力的地方，在于把焦点从 Token 单价转向任务成本。他引用 Artificial Analysis 的数据，从输入和输出单价、Intelligence 基准分数、每个基准任务的成本三个维度对比模型。在他的表里，GPT-5.5 的名义输出单价高于 Claude Opus 4.8 max，但每个基准任务的成本反而更低；DeepSeek V4 Pro max 是成本效率上的特例；GLM-5.2 max 的 Token 单价远低于 GPT 和 Claude 的例子，但按任务成本算并没有便宜那么多。

我不会死磕这几行具体数据。模型价格会变，路由价格和官方价格不一定一致，基准组合也不能替代产品自己的业务场景。但测量方向是对的。[Artificial Analysis 说明](https://artificialanalysis.ai/methodology)，它的 cost-per-task 指标把输入 Token、缓存 Token、推理 Token 和输出 Token 的价格分别乘以实际消耗的 Token 数量。它也指出，即便 Token 单价相同，输出更长或推理 Token 更多的模型，每个任务的成本也会更高。

这才是实际意义上的区别。买家该关心的不是厂商一块钱卖多少 Token，而是一块钱能买到多少经过验证的工作成果。任务是客服分诊，单位就是解决的工单；任务是代码审查，单位就是能过人工复核的有效发现；任务是文档抽取，单位就是被接收的结构化输出，而不是生成的 Token 数。

> **Info:**
>
> 我会在每次 AI 预算评审里，把「明确质量门槛下每美元产出多少成果」这个指标摆在最前面。Token 单价只配放在它下面，不配放在它上面。

## 隐藏工作量会改账单

第二个问题是，可见的输出已经不等于全部成本。Iłowski 把思考 Token 列为成本驱动因素：推理能提升质量，但隐藏的思考链可能主导账单。我会把风险说得更宽一些。账单还包括重试、工具调用、缓存写入、长上下文、护栏拒绝、格式清理和人工审核时间。

这里 [TensorZero 的分析](https://www.tensorzero.com/blog/stop-comparing-price-per-million-tokens-the-hidden-llm-api-costs/)作为独立参考很有价值。TensorZero 报告，同样的输入在不同提供商和不同内容类型下会产生显著不同的 Token 数量，并认为团队应该测量自己实际发出的量，而不是只比标价。它自己的工作负载不等于所有人的工作负载，但结论和运营问题一致：当输入形态变化时，最便宜的提供商也会变。

公开的技术讨论也指向同一个方向。在一个关于 [LLM 定价工具的 Hacker News 帖子](https://news.ycombinator.com/item?id=44682465)里，有评论者直接问怎么跨提供商比较缓存定价，因为 key-value 缓存可能在实际 Token 使用里占很大比例。另一条 [讨论 AI 成本的 HN 帖子](https://news.ycombinator.com/item?id=48683588)则深入到 GLM-5.2 的服务成本计算和假设。我不会把评论当成定论，但它们展示了正确的怀疑方向：价格、提供商路由、缓存行为、吞吐量、自托管成本，是几件不同的事。

![卡通运维人员对比两台 AI 机器，一台内部路径缠绕，一台路径更短直达完成任务图标](https://cdn.markhuang.ai/news/token-sticker-price-is-a-trap/tradeoff.webp)

*标价低不一定赢，隐藏路径长才真烧钱。真正有用的比较是走到任务完成这一步要花多少钱。*

## 方向对，但要画清边界

我想在 Iłowski 的基础上补一句：每个基准任务的成本也可能成为另一种虚假安慰。它比 Token 单价好，但仍然是代理指标。基准告诉我模型在某套公开评测下的表现，却不会告诉我模型能不能遵守我的 schema、守不守得住我的延迟预算、会不会踩进我遇到的边界情况和失败模式，以及能不能过业务负责人的验收。

这很重要，因为 Token 效率可能是以产品不想要的方式换来的。回答更短的模型可能更便宜，但不够用；推理更长的模型可能更贵，但能减少返工；走更便宜提供商路由的模型看上去不错，直到可用性、隐私立场、审核行为或技术支持变成真正的约束。

所以我把教训收窄一点，也更可操作：不要用基准崇拜替代 Token 单价崇拜。用公开基准形成假设，然后在自己的业务场景里跑任务级评估，测量成功率、延迟、重试率、人工审核成本、缓存命中行为，以及每个被接受结果的总花费。

## 我实际会怎么做

如果让我设计采购流程，我会先建一份小型任务目录。把便宜的常规任务和那些模糊、高风险、长上下文、面向客户的任务分开。每一类都用同样的 prompt、同样的工具权限、同样的检索上下文、同样的验收标准去跑候选模型。

然后，我会记录比 Token 多得多的指标。提示 Token、输出 Token、推理/思考 Token、缓存读写、工具调用、延迟、重试、拒绝率、人工干预率、被接受输出率——都要记。只有到这一步，价格表才真正有用，因为它可以乘在观察到的行为上，而不是想象中的行为上。

产品层面的做法，是基于证据的模型路由。便宜模型在常规流量上跑通就让它跑；贵模型在能显著降低失败、足以覆盖成本的时候再接手升级流量；本地和开源模型在隐私、流量或延迟有优势时纳入考虑；前沿模型只在多出来的能力被验证的场景里继续留在链路上。

![卡通运维团队把发光的任务 Token 路由经过抽象检查点、一把上锁的护栏和一个完成托盘](https://cdn.markhuang.ai/news/token-sticker-price-is-a-trap/workflow-risk.webp)

*成熟的工作流让模型选择变得可观测。路由、评估、预算上限和结果检查必须一起动。*

## 我的结论

Iłowski 这篇文章重要，因为它攻击了一个看似客观、但在生产环境里容易误导人的数字。每百万 Token 单价很容易抄进表格，真正难算的是另一组数：模型从你的输入里生成了多少 Token、做了多少隐藏工作、成功率多高、组织事后要掏多少清理费用。

我仍然会在模型卡片里保留 Token 单价，只是不会让它替我做决定。决定应该按每个被接受任务的成本来做，而且要在产品实际处理的业务上测量。再退一步，就等同于把电表读数当成了账单本身。