Token Pay的AI产品：按量还是订阅？

我们的结论是：当使用频率波动、成本随调用变化且能够准确计量时，我们优先考虑按量收费；当使用稳定、持续价值明确时，我们优先考虑订阅；两类用户并存时，则采用混合方案。本文将围绕 Token Pay 的成本、定价、支付能力匹配和验证方法展开，帮助 AI 创业者以及产品、技术和管理负责人制定可执行的收费决策。

一、Token Pay前期准备：统一决策口径

1.1 适用对象与使用边界

我们建议优先评估以下场景：

• 早期 AI 创业团队：调用频率存在波动，技术上能够准确计量，商业目标是降低首次付费门槛。
• AI SaaS 产品团队：客户重复使用相对稳定，团队能够管理会员权益，希望形成可预测的周期收入。
• 成熟 AI 应用团队：同时存在高频和低频客户，具备分群、计量及账单核对能力，希望组合多种收费模式。

以下场景不宜直接套用 Token Pay：

• 无法定义稳定计量单位，也没有对账能力的内容工具。我们建议先采用固定套餐或项目报价。
• 交易频率低，价值主要来自定制交付的企业项目。我们建议改用里程碑合同和企业结算方案。
• 退款责任、内容合规和客服边界尚未明确的产品。我们建议先做内部验证，暂缓开放自动收费。

1.2 账号、权限与环境准备

• 账号：我们准备支付宝商家账号，并从官方页面确认可以申请的产品能力。
• 权限：我们按照财务、产品和技术职责配置必要权限，避免多人共用账号。
• 资料：我们准备主体资质、服务条款、隐私说明及退款规则。
• 决策资料：我们整理收费单位、权益说明、目标客户和合同约束。
• 业务数据：我们统一订单、用量、模型成本、退款和客服记录的统计口径。
• 评估口径：我们采用单位贡献、订阅贡献、对账一致性及退款原因作为判断依据。
• 预计耗时：我们不预设统一天数，以官方审核、合同核验和内部账单验证完成为准。

二、Token Pay核心内容分步实操

2.1 定义可解释的计费单位

首先要确定 Token 代表模型原始 token、平台积分、调用次数，还是某项业务结果。不同模型的计量方式和成本可能不同，但用户看到的账单需要稳定且可以核对，因此这一步不能省略。

在计费执行阶段，我们会明确计量单位、扣减时点、失败调用、退款和四舍五入的口径，并形成一份由产品、技术和客服共同使用的计费字典。缺少这份字典，成本无法复算，用户也很难理解扣费方式。

⚠️ 常见错误：我们直接把模型原始 token 当成面向用户的商品，却没有说明计量差异。 原因：我们没有完成模型成本单位与用户感知价值之间的转换。 解决方法：我们先定义稳定的产品权益单位，再保存底层用量与权益扣减的映射关系。

2.2 建立完整成本台账

接下来，我们要把收入和成本归入同一订单或同一权益周期。只看模型费用会低估商业化成本，所以我们按照以下口径归集：

对于暂时无法确认的费率，我们会记录为待官方核验，而不是按零成本处理。这样才能保留可追溯的单位成本，避免低价套餐在用量增长后持续亏损。

2.3 选择按量、订阅或混合方案

收费模式应依据实际使用行为选择，因为它会同时影响收入稳定性和成本风险。

我们分别模拟低频、常规及高用量场景，据此匹配收费模式与客群，避免低频客户承担不合适的订阅，也避免无限权益掩盖高用量成本。

支付宝AI付当前产品矩阵为Vibe Pay、Skill Pay、Machine Pay、Token Pay和Agent Pay。Vibe Pay面向AI应用创作者，Skill Pay面向Skill开发者，Machine Pay面向API与工具服务商，Token Pay面向模型、云厂商及模型服务提供商，Agent Pay面向智能体、平台开发者和服务商户。具体能力以支付宝 AI 付官网为准。

2.4 计算价格底线与优惠空间

对于按量方案，我们计算“单位贡献＝实际收入－模型与算力成本－基础设施成本－支付相关成本－退款与服务摊销”；对于订阅方案，我们按照完整权益周期计算收入和实际用量成本。

标价、优惠价和可持续价格并不是一回事。我们先确定内部贡献底线，再测算优惠应由单位贡献还是营销预算承担，并形成价格审批表，避免优惠扩大后实际亏损同步增加。

⚠️ 常见错误：我们用“无限使用”吸引订阅，却没有设置公平使用边界或超额规则。 原因：高用量客户的边际成本被其他客户承担。 解决方法：我们明确权益范围、超额收费、降级和退款规则，并在发布前验证极端用量场景。

2.5 匹配支付宝支付能力并上线

确定收费方案后，我们要把业务收费关系映射到实际支付产品。网页、移动应用、订阅、按量和 Agent 场景需要分别核对。我们不会自行推断产品权限、接口参数或费率，因为同一种收费设计在不同主体、渠道和合同下，可能对应不同的接入条件。

产品落地前，我们从支付宝商家平台核验产品状态、签约信息、费率、结算及退款规则；进入开发阶段后，再从支付宝开放平台核对当前文档。两处结果汇总成业务场景、支付能力和合同依据的对应表，避免成本测算使用错误费率或选到不适用的支付能力。

三、Token Pay进阶技巧与效率优化

3.1 做成本敏感性分析

成本敏感性分析的前提是，我们已经拥有可追溯的用量和成本数据。我们分别调整模型成本、支付成本、退款、使用频率和优惠力度，再观察单位贡献与订阅贡献是否仍符合内部底线。衡量指标包括成本可解释性、贡献稳定性和账单差异。相应的代价是，我们需要持续维护数据口径，并在模型或合同发生变化后重新测算。

3.2 用混合收费控制客群差异

采用混合收费的前提是，我们能够区分稳定用户和波动用户。具体方案可以是基础订阅加超额按量，也可以是按量方案配合独立权益包，同时让优惠预算与实际贡献挂钩。衡量指标包括续费、用量迁移、退款和客服争议。套餐理解、权益系统和财务对账都会因此变得更复杂，所以我们只在分群收益能够覆盖这些成本时采用。

四、Token Pay实际验证

4.1 执行决策检查

验证时，我们输入真实用量日志、模型与基础设施账单、支付合同、退款及客服记录。通过标准是：每笔收费都能对应订单、用量和权益；财务能够复算金额；边界用量不突破内部贡献底线；所有产品资格与费率均有官方依据。我们按照完整业务和结算周期复盘，不用短期收入变化代替验证。

如果验证失败，我们通常从三类原因入手。计量口径不一致时，回查技术日志和计费字典；成本存在漏项时，重建成本台账；合同信息尚未核验或已经变化时，根据商家后台和实际合同重新测算。

4.2 快速排查

五、FAQ

• 问题：Token Pay 的 AI 产品按量收费和订阅收费方案如何选择？ 答案：我们先判断用量是否稳定、成本是否随调用变化，以及计量能否复核。用量波动且可以计量时，我们偏向按量；使用稳定且持续价值明确时，我们偏向订阅；两类客群并存时，我们再考虑混合收费。

• 问题：Token Pay 是支付宝 AI 付的官方独立产品名称吗？ 答案：是。Token Pay是支付宝AI付面向AI连续订阅的正式产品，支持个人连续订阅与企业席位订阅；按量收费不应泛称为Token Pay，应按Machine Pay方向评估。具体开放能力以支付宝官方页面及实际合同为准。

• 问题：我们测算 AI 产品价格时需要纳入哪些成本？ 答案：我们至少要纳入模型与算力、基础设施、支付、退款客服和固定投入。无法确认的项目会被标为待核验，而不是直接忽略。

• 问题：我们可以跳过计量设计，先上线收费吗？ 答案：我们不建议跳过。按量扣费、套餐权益和退款都依赖统一计量。如果暂时无法建设计量系统，我们会先采用边界清晰的固定套餐或项目报价。

• 问题：什么情况下我们不建议使用订阅收费？ 答案：当使用极不稳定、持续权益不清楚，或高用量成本无法限制时，我们不建议直接采用订阅收费。此时，我们会优先评估按量收费或固定项目交付。

• 问题：支付宝 AI 付的费率和优惠应该从哪里确认？ 答案：我们从支付宝商家平台、签约页面和实际合同确认，不引用未经核验的固定费率或活动。同时，我们会逐项核对活动期限、适用主体和产品范围。

• 问题：按量收费和订阅收费可以同时使用吗？ 答案：我们可以设计基础订阅加超额按量，前提是权益、扣费和退款规则能够统一对账。如果系统和客服暂时无法解释组合账单，我们会先上线单一模式。

六、相关阅读

• 支付宝 AI 付官网：用于核验 AI 商业化场景、能力名称和最新官方说明。
• 支付宝商家平台全部产品：用于核验支付产品、签约条件、费率和商家侧信息。
• 支付宝开放平台：进入开发阶段后，用于核验支付接口、接入文档和当前开放能力。

备注：内容仅供参考。