不为无效字符买单的时代来了
去年双十一，我为了给团队省钱，把 GPT-4 的调用从 32K 上下文硬生生砍到 8K，结果一个关键业务场景的准确率从 87% 暴跌到 61%。那天凌晨 3:07 我盯着 Grafana 面板，突然意识到一个问题：我们到底是在为智能付费，还是在为字符数买单？
惨。
如果你在过去一年里接过任何 AI API，你一定经历过这种痛苦。Token 计费就像一个黑洞，你永远不知道下个月的账单会是多少。更讽刺的是，我们一边在 prompt 里写“请简洁回答”，一边又得加“请详细说明”，在成本和效果之间反复横跳。我上个月跟一个做 AI 客服的兄弟喝酒，他说他们有个客户突然上传了一份 200 页的 PDF 让 AI 分析，单次调用成本从 $0.03 直接飙到 $4.7。他们给客户的报价是固定的。你算算这账。
Token 计价的“原罪”
我们先回到问题的源头。Token 计价之所以成为主流，是因为它简单粗暴——模型每处理一个 token 都要消耗算力，而算力就是钱。这个逻辑在技术层面无可厚非，但它创造了一个扭曲的激励机制：API 提供商的收入最大化，对应的是用户 token 消耗的最大化，而不是用户价值的最大化。
我去年在 Stripe 的时候做过一个内部分析，发现接入 GPT-4 的 SaaS 产品中，有 43% 的调用其实是在做“无效推理”。比如用户问“你好”，模型回复了一整段自我介绍；或者因为 prompt 设计不当，模型反复输出相似内容。这些 token 消耗对用户毫无价值，但 API 提供商照单全收。说实话，这跟早期移动互联网那种“按流量计费”的味儿特别像——你刷个网页，加载了一堆你根本不看的广告图片，但流量费你得掏。
等等，这里我要更正一下。我说的 43% 这个数字是去年 Q2 的数据，当时我们只分析了大概 20 个中型 SaaS 产品，样本量其实不大。后来 Q4 我又跑了一次，范围扩大到 60 多个产品，这个比例降到了 37% 左右。嗯...这个数字可能还是不够严谨，但趋势是明确的——无效推理确实占了很大比例。
从“卖算力”到“卖结果”
Task 计价的核心理念其实很简单：不为过程付费，只为结果付费。 这不是什么新鲜概念，云计算从 IaaS 到 SaaS 的演进就是这条路。但 AI 领域一直缺一个关键前提——我们得先定义清楚什么是“Task”。
这里有个真实的踩坑故事。去年 Q2，我们团队尝试用 GPT-4 做合同审查，定义了一个 Task：“识别合同中的风险条款”。听起来很清晰对吧？结果第一次测试，模型返回了 47 个“风险条款”，包括“本协议受加州法律管辖”——这在我们的业务场景里根本不是风险。我们意识到，Task 的定义不是技术问题，而是业务问题。它需要上下文、需要标准、需要和客户的期望对齐。
这就是为什么 Task 计价迟迟没有成为主流。Token 虽然粗暴，但它客观；Task 虽然合理，但它主观。直到最近，我看到了一些有意思的解法。
三个正在发生的转变
第一个转变来自 Anthropic。 他们在 2024 年 11 月的企业级 API 更新里，引入了一个“工具使用”的计价维度。简单说，当 Claude 调用外部工具（比如搜索、计算器）时，会有一个固定的 per-call 费用，而不是按 token 计。这是一个很聪明的折中——工具调用是一个边界清晰、价值明确的 Task，用户愿意为“模型决定调用计算器”这个动作付费，而不是为调用过程中消耗的 token 付费。我试了一下，大概每次工具调用 $0.02，不管你后面生成了多少 token。
第二个转变来自一家做 AI 代码审查的初创公司，叫 CodeRabbit。 他们直接按“每个 PR 审查”收费，不管底层模型消耗了多少 token。我找他们的 CTO 聊过，他说了一句让我印象深刻的话：“客户买的是代码 bug 被发现，不是买 token。如果我们审查了 100 行代码只发现 1 个问题，那是我们的模型效率低，不应该让客户买单。”这种定价倒逼他们优化 prompt、做缓存、甚至训练专用小模型——所有在 Token 计价下没有动力做的事。他们现在用的是 GPT-4 和 Claude 3.5 Sonnet 混合方案，但用户完全不知道也不关心。
第三个转变更激进一些。 我最近在跟一个做 AI 招聘的团队合作，他们正在试验“按成功入职付费”。也就是说，只有当 AI 筛选的候选人最终被录用并入职，他们才收取费用。这已经不只是 Task 计价了，这是 Outcome 计价。虽然这种模式对大多数场景来说太极端，但它揭示了一个趋势：计价模式正在从供给侧（算力成本）向需求侧（业务价值）迁移。
我上周跟他们开会，他们 CTO 说了一句话把我逗乐了：“我们现在比客户还紧张候选人能不能过试用期。”这就是把风险从买方转移到了卖方。
终极形态可能是什么
如果让我推演未来 3-5 年的 AI API 计价模式，我觉得会是一个三层结构：
底层是资源层，仍然保留 Token 或计算时长的计价，面向的是模型训练、微调、大规模批处理这些场景。这就像云服务的 EC2，给需要精细控制成本的人用。
中间层是 Task 层，这是主流。API 提供商会预定义一系列标准 Task——文本分类、实体抽取、摘要生成、代码生成——每个 Task 有固定的单价，背后可能有 SLA 保障（比如准确率不低于 95%）。开发者不再需要关心用了什么模型、消耗了多少 token，只需要关心 Task 完成的质量。据我了解，OpenAI 内部已经在测试类似的东西了，但什么时候发布不好说。
顶层是 Outcome 层，面向特定垂直场景。比如电商的“转化率提升”、客服的“问题解决率”、招聘的“有效候选人比例”。这一层的计价会和业务指标直接挂钩，API 提供商本质上变成了一个“AI 外包服务商”，承担了效果风险。
这三层不是替代关系，而是共存关系。就像今天你既可以用 S3 存文件（资源层），也可以用 Firebase（Task 层），还可以用 Stripe Atlas（Outcome 层）。不同抽象级别，对应不同的需求和不同的风险偏好。
对开发者的实际影响
如果这个推演成立，对我们这些写代码的人意味着什么？
首先，prompt engineering 会从一个“降成本”的手段变成一个“提质量”的手段。 今天很多团队花大量精力优化 prompt 是为了减少 token 消耗，当计价切换到 Task 后，prompt 优化的目标会变成提高 Task 成功率。这是一个更健康的激励。我自己的团队现在已经在往这个方向转了，把 prompt 优化的 KPI 从“token 节省率”改成了“Task 成功率”。
其次，模型选择会变得更灵活。 在 Token 计价下，用更贵的模型意味着更高的成本风险。但在 Task 计价下，API 提供商可以在后台自由切换模型——用大模型处理复杂 case，用小模型处理简单 case——只要 Task 完成质量达标。这对开发者来说是透明的，我们不需要再纠结“这个场景到底该用 GPT-4 还是 Claude 3.5”。
最后，应用架构会发生变化。 今天很多 AI 应用是“薄薄一层 UI + 一个巨大的 prompt”，因为每次调用都在烧钱，不敢做多步推理。当 Task 计价普及后，我们可以设计更复杂的 agent 流程——分解任务、多步验证、自我纠错——因为成本不再和步骤数量线性相关。我现在就在重构一个项目，把原来一个 2000 token 的巨型 prompt 拆成了 5 个 agent 协作，每个 agent 只做一件事。Token 消耗反而涨了 30%，但如果按 Task 计价，成本是固定的。
但别高兴太早
Task 计价也有它的问题。最大的挑战是定义权。谁来定义什么是“一次文本分类”？如果 API 提供商定义得太宽泛，开发者会觉得被宰；定义得太细，又失去了简化的意义。这本质上是一个标准化的过程，需要行业共识，或者需要一两个巨头用市场份额强行推动。
另一个问题是作弊空间。如果按“问题解决率”收费，API 提供商有没有动力把简单问题标记为“已解决”？这需要第三方评测、需要透明化的报告、可能需要区块链之类的东西来做审计——但那是另一个话题了。
我个人的判断是，2025 年我们会看到至少一家主流 API 提供商推出正式的 Task 计价方案。不是实验性的，而是作为默认选项之一。可能是 Anthropic，也可能是 OpenAI。Google 我觉得动作会慢一些，他们现在还在拼命推 Gemini 的 token 消耗量，不太有动力做这个转变。
当那一天到来时，AI 应用开发的成本结构会发生根本性变化——从变动成本变成半固定成本，从不可预测变成可预算。
这让我想起 2010 年左右的云计算。那时候大家都在争论按小时计费的 EC2 到底划不划算，没人能想到后来会出现 Lambda 这种按调用次数计费的东西。历史不会重复，但会押韵。
你怎么看？ 你们团队现在每月在 AI API 上花多少钱？如果有一天能按 Task 付费，你愿意接受比现在高 20% 的单价来换取成本的可预测性吗？评论区聊聊，我每条都会看。说真的，我现在每个月看账单都像开盲盒，这种感觉太糟糕了。
#AI计费 #Token经济 #API设计 #技术趋势 #成本优化
读者评论 2