按量计费的 AI 定价死亡螺旋：为什么按 Token 计费会惩罚你最好的功能

Token 成本在两年内下降了 280 倍。企业 AI 账单却上涨了 320%。如果这听起来像个悖论，那是因为你还没有仔细研究按 Token 计费如何与那些真正让 AI 产品有价值的功能相互作用。

最有用的 AI 工作流——深度研究、多步推理、迭代优化、智能体工具调用——恰恰是消耗最多 Token 的。在纯按用量计费模式下，你最好的功能就是你最大的利润杀手。这不是暂时的规模化问题，而是 AI 创造价值的方式与计费方式之间的结构性错配。

价值反转问题

传统 SaaS 的每用户边际成本几乎为零。Notion 或 Figma 上的重度用户和轻度用户的服务成本大致相同。AI 产品彻底打破了这一假设。传统 SaaS 的毛利率在 70-80%，AI 产品则在 20-60%，而且每增加一个让产品更有用的功能，这个差距就会进一步扩大。

以构建 AI 编程助手为例。一个简单的自动补全建议只需不到一分钱。但那些让你的产品脱颖而出的功能——跨文件重构、深度代码库分析、迭代调试循环——每次交互消耗的 Token 是前者的 10 到 50 倍。一个在每次 API 调用时重新发送完整对话历史的智能体工作流，成本会随上下文增长而复合增长：一个 200K Token 的对话成本是 20K Token 对话的 10 倍。一个调试会话通过 47 次重试迭代，可能从 0.50 美元暴涨到 30 美元。

这就产生了一种扭曲的动态：交互越有价值，提供它的成本就越高。 你的重度用户——最有可能转化、留存和传播的那些人——同时也是服务成本最高的。

Anthropic 承认在其最初的 200 美元/月计划下，重度 Claude Code 用户每月亏损"数万美元"。GitHub Copilot 在发布时每用户都在亏损。OpenAI 在 2025 年烧掉了 80 亿美元的算力费用，预计到 2026 年底累计亏损将达 140 亿美元。这些不是早期的低效问题，而是定价模型未能考虑用户实际行为差异的可预见后果。

50 倍用户问题

按用量计费假设消费分布相对集中。实际上，AI 产品呈现极端的幂律分布。你的前 5% 用户可能消耗的 Token 是中位数用户的 50 倍。在固定费率下，这些用户会摧毁你的单位经济模型。在纯按用量计费下，他们会遭遇账单冲击并流失。

Cursor 在这方面吃了大亏。2025 年 6 月，它将固定的"快速请求"配额替换为按用量的积分池。一些开发者在一天之内就耗尽了月度配额。反弹激烈到 CEO 不得不公开道歉，公司也进行了退款处理。核心问题不在于价格水平，而在于不可预测性。原本乐意支付 20 美元/月的开发者突然面临每周 350 美元的超额费用。

教训不是按用量计费本身有问题，而是原始 Token 消耗是错误的计量单位。 Token 无法反映用户是否获得了价值。一个在失败的调试循环中消耗 10 万 Token 的开发者和一个消耗 10 万 Token 成功上线功能的开发者被收取相同的费用，但他们的体验——以及续费的可能性——完全不同。

为什么传统的成本控制方法不奏效

面对成本压力的显而易见的对策是增加护栏：速率限制、上下文窗口限制、对常规任务降级模型。这些在基础设施层面有帮助，但会产生产品问题。每一个减少 Token 消耗的护栏，同时也在削弱产品交付核心价值的能力。

速率限制迫使用户精打细算地使用交互次数。上下文窗口上限会在执行过程中打断多步工作流。激进的模型路由——将简单查询发送给更便宜的模型——在"简单"查询实际上需要更深层推理并给出糟糕答案之前一直有效。节省成本的优化恰恰是让产品变差的优化。

这就是死亡螺旋：成本迫使约束，约束降低体验，体验降低付费意愿，这又迫使更多成本约束。陷入这个循环的公司，正是那些试图用基础设施来解决定价问题的公司。

企业环境使问题更加复杂。84% 的公司报告 AI 成本导致超过 6% 的毛利率侵蚀，只有 15% 能将 AI 支出预测控制在 ±10% 的准确范围内，问题不仅仅是每用户经济模型——而是组织可见性。各自为政的团队重复建设 AI 能力。高级模型被用于常规分类任务。废弃的实验持续消耗资源。"碎片化税"在悄无声息中累积，直到利润率遭受结构性损害。

真正有效的定价模型

行业正在向混合架构趋同，将基础访问与计算密集型使用分离。按估值排名的前 50 家 AI 初创公司中，近一半同时采用两到三种定价模型。有效的模式都遵循一个共同原则：按交付的价值定价，而非按消耗的算力定价。

基于成果的定价将成本与成功结果挂钩。Intercom 的 Fin 聊天机器人每次解决收费 0.99 美元——定义为客户确认满意或未升级即离开。只有当 AI 真正解决了问题，供应商才能获得报酬。这翻转了激励结构：提供商有动力用更少的 Token 解决问题，而非更多。缺点是衡量复杂性高。你需要强大的基础设施来定义、追踪和验证"成果"，而且如果模型性能波动，收入也会变得不稳定。

任务分层定价为工作类别分配固定成本，而非计量原始消耗。对于编程助手，不按 Token 收费，而是按任务收费——"修复这个崩溃"、"重构这个模块"、"编写这些测试"——无论智能体内部消耗了多少 Token。这为用户提供了成本可预测性，同时让提供商在后台优化算力。

基础加突发模型将涵盖正常使用的固定订阅与仅在高消耗阈值时触发的按用量计费相结合。这之所以有效，是因为它明确处理了 50 倍用户问题：轻度和中度用户获得可预测的定价，而重度用户则按比例为不成比例的消耗付费。关键是将突发阈值设置得足够高，使大多数用户永远不会触及。

模型感知加权的积分池分配月度预算，不同模型和任务类型以不同速率消耗积分。Claude Haiku 查询可能消耗 1 个积分，而 Claude Opus 查询消耗 15 个。这保留了用户选择权，同时使成本权衡透明化。失败模式——Cursor 2025 年 6 月的事件——发生在积分消耗速率出乎用户意料时。关于消耗速率的透明度不是可选的。

构建按成果定价的遥测体系

从按 Token 计费切换到基于价值的定价，需要大多数团队尚不具备的遥测基础设施。如果无法衡量成果，就无法按成果定价。如果无法分类任务，就无法实施任务分层定价。如果不了解消费分布，就无法设置突发阈值。

最小可行的定价基础设施需要三个组件：

• 每用户成本归因。 从第一天起就在单个用户和会话级别追踪计算成本。不是汇总的 API 开支——而是按模型、Token 类型（输入 vs. 输出 vs. 缓存）和工作流阶段细分的每次交互成本。没有这个，你就是在盲目定价。

• 价值事件追踪。 定义并埋点那些 AI 交付可衡量价值的时刻：修复了一个 bug、回答了一个问题、完成了一个任务、生成了一份文档。这些将成为你最终可以据此定价的单位。追踪必须是实时的，而非月度批处理，因为定价决策需要在交互时做出。

• 消费分布分析。 映射整个用户群的完整使用分布。识别使用层级应该落在的自然断点。目标是找到少于 10-15% 的用户会遇到超额收费的阈值，这使大多数人的定价可预测，同时从最重度消费者那里获取合理价值。

尽早构建这套遥测体系的团队拥有结构性优势。他们可以用真实数据迭代定价模型，而非靠猜。他们可以识别哪些功能是利润正贡献的，哪些是被补贴的。他们还能在死亡螺旋的早期信号出现时——每用户成本上升但用户感知价值未相应增加——在它变成危机之前就检测到。

战略抉择

AI 定价格局仍处于早期阶段，制胜模型尚未确定。但方向是明确的：纯按 Token 计费是 AI 产品还只是 API 调用薄包装层时代的过渡产物。随着产品转向智能体工作流、多模型架构和深度集成的 AI 功能，定价也必须随之演进。

能够建立持久 AI 业务的公司，是那些解决了对齐问题的公司——不是 AI 对齐问题，而是定价对齐问题。用户支付的价格应该与他们获得的价值成比例，而非与他们的工作流碰巧消耗的算力成比例。每一个未通过这个测试的定价模型最终都会陷入死亡螺旋。唯一的问题是，在你想明白之前，你会烧掉多少 Token。