Token 标价是个坑

Jan Iłowski 在 Price per 1M tokens is meaningless 一文里，纠正了一个糟糕的采购习惯。他的论点很直接：两家模型都能挂出一个漂亮的 $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 指南就写明，不同模型使用不同编码，而 Token 数量直接决定 API 使用成本。

Anthropic 在 Claude Sonnet 5 文档里说得更直白：Sonnet 5 用了新 tokenizer，同样的输入比 Sonnet 4.6 多出大约 30% 的 Token，具体比例随内容变化；这会直接影响 Token 计数、上下文容量、输出预算和每次请求的成本——即便 Token 单价没变。

于是一张干净的价格表反而带来了测量问题。一个模型可能 Token 单价更低，同样的 prompt 却消耗更多 Token；另一个模型可能 Token 单价更高，却用更少的 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 说明，它的 cost-per-task 指标把输入 Token、缓存 Token、推理 Token 和输出 Token 的价格分别乘以实际消耗的 Token 数量。它也指出，即便 Token 单价相同，输出更长或推理 Token 更多的模型，每个任务的成本也会更高。

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

隐藏工作量会改账单

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

这里 TensorZero 的分析作为独立参考很有价值。TensorZero 报告，同样的输入在不同提供商和不同内容类型下会产生显著不同的 Token 数量，并认为团队应该测量自己实际发出的量，而不是只比标价。它自己的工作负载不等于所有人的工作负载，但结论和运营问题一致：当输入形态变化时，最便宜的提供商也会变。

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

方向对，但要画清边界

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

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

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

我实际会怎么做

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

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

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

我的结论

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

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