选LLM别光比token单价——按任务成本评估才准确

Model A 每千 token 成本是 Model B 的一半。但 Model A 要把任务真正正确地完成，几乎需要两倍的 token 数量。等账单寄到的时候，猜猜哪个更便宜？

这就是大家在搜索"最便宜的 LLM API"、然后按输入/输出价格列排序比较表格时，没有任何人去计算的那个差距。表格没有错。它只是在回答一个比人们以为自己在问的问题更窄的问题。

所有人都拿来优化的指标，以及它遗漏了什么

每千 token 价格是每个定价页都会突出展示的数字，也是每篇比较文章都会按此排序的数字。但孤立地看，它对任务实际成本是一个不完整的预测指标——因为每千 token 价格根本无法告诉你，一个模型需要多少 token 才能给你一个可用的答案。

两个模型可能有完全相同的按 token 计价，但由于每个成功完成的任务所消耗的 token 数量不同，实际成本可能相差很大，因为 token 数量并非由任务固定——它是模型在该任务上行为的一个函数。一个冗长的模型、会在答案中塞入不必要的前言和重复表述的模型、需要更长、更精心设计的提示词才能产出可靠输出的模型、或者产生需要重试的答案比例较高的模型——所有这些都表现为每个成功完成任务的 token 消耗更多，不管单个 token 有多便宜。

用每千 token 价格回答的"最便宜的 LLM API"，其实只是在回答"哪个模型的标价最低"。大多数人的实际需求更接近于"哪个模型能让我以最少的钱获得正确、可用的结果"——而这两个问题只有在每个模型为了达到同样结果都需要完全相同数量的 token 时，才是同一个问题，这种情况几乎从不成立。

一个能看清差距的具体方式

假设有两个模型，都按输出 token 计价，一个每百万 token 1 美元，另一个每百万 token 2 美元——按定价页来看，第一个看起来便宜一半。现在用同一个任务跑一遍两个模型：比如一个结构化数据提取任务，从非结构化文本中提取五个字段。

便宜的模型输出了一个冗长的回复——有一段前言解释它要做什么，然后是提取的数据，最后又总结复述了一遍刚才提取的内容——每个任务平均消耗 400 个输出 token。而贵的模型直接返回请求的精确结构化输出，没有前言，没有复述——每个任务平均消耗 90 个输出 token。

实际算一下："便宜"模型每个任务花费 $0.0004。"贵"模型每个任务花费 $0.00018。标价贵一倍的模型最终每个完成任务的成本还不到一半，全部是因为两个模型在同一个提示词下行为差异巨大。

这不是假设的边缘案例——冗长度、格式化习惯、指令遵循精确度在不同模型之间确实存在有意义的差异，而这些差异都不会出现在按每千 token 比较的表格中。

为什么这个问题在重试和提示词长度下会变得更糟

还有两个因素会加剧这个差距，而且两者在纯粹的按 token 比较中都会被忽略：

重试率。如果一个模型在一定比例的情况下产生了不可用或格式错误的回复——无效的 JSON、臆造出的字段、没有遵循的指令——每一次重试都是在已经消耗了 token 但任务实际上还没完成的基础上额外支出。一个重试率明显更高的模型，一旦把你浪费掉的尝试计算进去，可能完全丧失其每 token 价格的優勢。

提示词工程开销。有些模型需要一个更长、更明确的系统提示词才能可靠地遵循格式化指令——在每次调用时都额外支付输入 token，永远如此，来补偿另一个模型用更短的提示词就能正确做到的事情。这种成本很容易被忽略，因为它被一次性写进提示词模板后就变得透明了，但它仍然在每次请求中被支付。

这两者都把真实成本进一步推离了定价页上的数字，而且方向一致：让每千 token 价格成为实际成本预测指标的力度，比它看起来要弱得多。

如何真正衡量重要的那个指标

修复方案并不复杂，只是要测量一个不同的东西：每个成功完成任务的价格，计算方式是（输入 token + 输出 token + 重试开销）× 每 token 价格，在你的实际用例的有代表性的样本上取平均——不是通用基准，是你的具体任务。

在没有重型工具的情况下粗略估算的方法：

挑选 15-20 个你实际任务的代表性样本。用每个候选模型跑一遍，记录消耗的 token 总量（包括得到可用结果所需的重试次数）。乘以每个模型每 token 计价。对比每个任务的成本，而不是每 token 费率。

这只需要一个下午，不是研究项目，而这才是真正能预测你账单的那种"最便宜"。这往往也会产生真正令人惊讶的结果——标价更高的模型在这场比较中胜出的次数，远超纯粹按每千 token 排名所能预测的次数，恰恰是因为冗长度和重试率是真实存在的常见差异化因素，定价页并不会捕捉到它们。

这与一个更大的模式如何关联

这也说明了一个有力的论据：相比从价格比较图表上选一个模型然后押注，在你的实际任务上测试多个模型更为重要——因为这里真正的成本差异只有通过经验才能显现，是按任务来的，不是在规格参数表上的。跨多个提供商的标准 OpenAI 兼容访问让这种按任务级别的成本比较变得明显更容易执行，因为测试模型 B 不需要像测试模型 A 那样做一次独立的集成。RouteAI 就是一个围绕这个特定需求构建的基础设施例子——跨 DeepSeek、Qwen、Kimi、GLM 和其他模型提供统一接口，这让运行上述那种按任务成本比较变成了切换一个模型参数的事情，而不是为每个候选重新构建一套集成。

用每千 token 价格来衡量"最便宜的 LLM API"是一个真实有用的数字——只是它不是决定你实际账单的那个数字。决定你实际账单的数字是每个完成任务的价格，而要知道它，唯一的方式就是真正用你的具体任务在具体候选模型上跑一遍并统计。

定价页会告诉你价格。它不会告诉你成本。这两者比你按排序比较表格所认为的更常是不同的事情。

摘要： 按每千 token 比较 LLM API 会忽略每个模型实际完成任务需要多少 token——冗长度、重试率和提示词工程开销可能让"更便宜"的模型在每个已解决任务上的成本反而高于更贵的模型。真正能预测你账单的指标是每个已解决任务的价格：用 15-20 个代表性样本在候选模型上跑一遍，统计包括重试在内的总 token 消耗量，再乘以每个模型的费率。跨多个提供商的标准化访问（如 RouteAI 这样的网关）让运行这种比较更容易，因为测试新模型变成了一次配置变更，而不是新的集成工作。

Here's the tool I referenced in this post: www.fastrouteai.com