# 如何为 AI 聊天应用定价，真正赚到钱 > 一份帮助 AI 聊天应用实现正向利润率的实用定价指南。了解 token 成本、隐藏的基础设施支出，以及按用量计费的分步框架。 - **Author**: Ayush Agarwal - **Published**: 2026-05-14 - **Category**: AI, Pricing, Usage-based Billing - **URL**: https://dodopayments.com/blogs/zh/profitable-ai-chat-app-pricing --- 为 AI 聊天应用定价，是打造健康业务或快速烧光资金的最快方式。大多数基于 LLM 提供商推出聊天产品的团队，都会先采用看似合理的固定月订阅价格，但几位重度用户的 token 数量一旦超出预期范围，产品就会悄悄开始亏钱。模型成本是可变的，但你收取的价格是固定的，这之间的差额每个月都会体现在利润率上。 本指南将介绍如何思考 AI 聊天应用的定价、实际运营中的单位经济模型、如何设计不会抑制增长的计费模式，以及如何干净利落地完成实现。示例假设产品是典型的 SaaS 或 agent 式聊天产品，而不是电商产品。 ## 为什么固定定价通常不适用于 AI 聊天应用 固定定价背后的逻辑很简单：选择一个高于大多数用户成本的数字，按月收费，然后希望平均下来能够成立。对于计算成本相对价格很低的云 SaaS，这种方式通常没问题。但对于 AI 聊天应用，情况并非如此，因为成本驱动因素是用户在 LLM 中消耗的 token，而 token 数量并不会受到用户认为合理的价格限制。 典型的聊天工作负载会呈现长尾分布。大多数用户每周发送少量消息；一小部分用户会发送数百条；还有极少数用户会运行自动化工作流，发送数千条消息。如果你每月收取固定的 30 美元，重度用户仅原始模型成本就可能消耗 50 或 100 美元，还没算基础设施、支持和管理开销。与此同时，长尾用户支付过多费用，也更容易流失。 解决办法是让价格至少部分跟随使用量变化。这并不意味着每一分钱都必须按量计费，但账单中随 token 数量增长的部分，需要在客户侧有相应的计量方式。 ## AI 聊天应用的真实成本构成 在制定价格之前，你需要清楚了解每次对话的实际成本。最简单的看法只是 LLM 账单，但真实的成本构成包括多个层面。 ### 直接 LLM 成本 按照模型提供商的费率计算输入和输出 token。现代前沿模型对提示词 token 和完成内容 token 的收费不同，而二者的比例很重要，因为聊天应用通常拥有较长的上下文窗口，但回复较短。较长的系统提示词、RAG 上下文以及多轮对话历史，都会推高输入 token 数量。 ### 向量存储和检索 如果聊天应用使用检索增强生成，你需要承担写入时的 embedding 成本、持续产生的向量存储成本，以及查询时的 embedding 或重排序成本。这些成本单次调用都不高，但在活跃用户群体中会不断累积。 ### 后台处理 长对话摘要、语义记忆更新、定期同步和内容审核，都是用户看不到但你仍需付费的真实 LLM 调用。许多聊天应用的 token 消耗有一半都来自这些后台任务。 ### 基础设施 应用服务器、队列 worker、日志管道和可观测性技术栈。这些成本不会随着对话数量线性增长，但也并非免费。计算之后，它们会体现在每位活跃用户的成本中。 ### 支持以及信任与安全 更高的使用量通常意味着更高的升级处理率、滥用审核量以及人工介入工作量。这些成本很难精确建模，但它们确实存在，而且取决于活跃程度，而不仅仅是员工数量。 一次对话的真实单位成本，是上述五个层面的总和，而不只是用户看得到的 token 数量。 ## AI 聊天应用在不知不觉中损失利润的地方 有三种模式会比其他因素更快地摧毁 AI 聊天应用的利润率。提前识别这些问题，可以避免之后频繁重新定价。 第一种是无上限的上下文。一位新用户注册后进行了一次很长的引导式聊天，整段对话记录随后成为每条未来消息的系统提示词的一部分。现在，每次后续回复都会比之前多发送一两千个输入 token。等用户发送了一万条消息时，每条消息的成本可能已经悄悄增加了四到五倍。客户看到的是一致的产品行为，而你看到的却是一条断崖式下跌的利润曲线。 第二种是伪装成聊天的多步骤 agent。单条用户消息会触发 6 次工具调用、3 轮检索以及最后一次摘要处理。从用户角度看，他们只发送了一条消息；但从模型角度看，你为 10 次调用承担了成本。如果你按消息数量收费，那么每次 agent 运行都会让你亏损。 第三种是无声重试。你的代码会自动重试失败的 LLM 调用。模型提供商不稳定的一天，意味着你这边实际上为每位客户支付了双倍成本，而客户支付的金额不变。如果没有对重试率进行可观测性分析，这只会表现为成本线整体变粗，却没人能解释原因。 解决这三个问题的方法相同：对真正驱动成本的因素进行计量，也就是提供商层面的 token、秒数或操作次数，然后在此基础上加上你能够守住的利润率进行定价。把这套基础设施做好，更多是 [LLM token 计量架构](https://dodopayments.com/blogs/metering-llm-token-usage-architecture) 问题，而不是定价理论问题。 ## 设计定价模型的框架 AI 聊天应用的定价模型需要做到四点：回收可变成本；为买家提供可预测性；随着价值增长而扩展；并且能够在不从零开始编写计费引擎的情况下实现。 ### 第一步：选择价值单位 价值单位就是客户付费购买的内容。对于面向消费者的聊天产品，价值单位通常是消息或交互；对于面向开发者的聊天产品，通常是 token 或 API 调用；对于基于聊天构建的工作流自动化产品，可能是运行次数或已完成任务数。请选择一种客户能够直观统计、并且与其获得的价值相关的单位，而不仅仅是与你的成本相关的单位。如果你的消费者版本产品通过移动应用商店发布，也要评估 [RevenueCat 的替代方案](https://dodopayments.com/blogs/revenuecat-alternatives) 作为订阅基础设施，因为应用商店佣金会从你刚刚计算出的同一部分利润中扣除。 ### 第二步：选择成本单位 成本单位是内部计量器读取的内容。对于由 LLM 驱动的应用，成本单位几乎总是输入 token 加输出 token，也可能对两者采用不同权重。成本单位不必与价值单位一致，但你需要充分了解两者之间的换算比例。如果一条典型消息平均包含 2,000 个输入 token 和 300 个输出 token，那么你可以放心按消息定价。如果消息长度呈现明显的两极分化，则应该按 token 定价。 ### 第三步：加入缓冲空间 你面对的是一个不断变化的目标。模型提供商会调整费率，你的提示词会变长，新功能会增加后台调用。无论当前单位成本是多少，可持续的价格都至少需要在此基础上乘以 2 到 3 倍，这大致符合普通 SaaS 的毛利率水平。如果你无法证明需要这样的空间，那么在买家能够接受的价格下，该模型目前还不可行。你需要使用更便宜的模型、更短的提示词、缓存，或采取不同的市场定位。 ### 第四步：结合固定费用和可变费用 几乎没有 AI 聊天应用应该完全按量计费。少量月度基础费用可以覆盖固定成本、建立客户关系锚点，并降低注册时的阻力。在基础费用之上，超出包含配额的使用量按超额用量计费。这是电信、云基础设施和现代 CDN 公司数十年来采用的模式。它之所以有效，是因为能让双方都觉得价格公平。 合理的结构可以是：基础订阅中包含一定数量的 token 配额，超过配额后按每千个 token 收取超额费用，并为重度用户提供可选的大规格套餐，在更高承诺量下提供更低的单 token 费率。 ## 无需编写计费引擎即可实现按用量计费 你可能会考虑自行构建整套系统：在应用数据库中追踪 token，运行每月定时任务，生成发票，扣款已保存的银行卡，处理支付失败后的催收，在客户升级时按比例计算费用，并在正确的司法管辖区申报税务。上述每一步都是一个项目，全部加起来，就是一整年的工程工作，而且与你真正的产品没有关系。 Dodo Payments 以 MoR（名义商户）的身份处理这部分工作，因此你无需自行构建。流程如下。 你可以在控制台中定义产品和计量器。计量器代表可计费单位，例如输入 token 或已完成的消息。一个产品可以关联一个或多个计量器，并设置单价、包含配额以及任何承诺量。 在应用代码中，每次聊天完成后，你都可以调用事件采集 API，将使用量记录到客户名下。Dodo Payments 会聚合事件、应用正确的定价层级、按照配置的周期生成发票、扣款已保存的支付方式，并通过重试和邮件处理失败的扣款。税费会自动计算并代为缴纳。 应用侧的工作量很小。你的代码只需要准确统计 token、发送事件，并处理你关心的响应，例如客户达到硬性上限。其他工作都由计费平台完成。 聊天应用的端到端实现模式，可以参考文档中的 [构建带按用量计费的 AI 聊天应用](https://docs.dodopayments.com/developer-resources/build-an-ai-chat-app-with-usage-based-billing)蓝图。将它与本文一起阅读，你既能了解战略框架，也能掌握具体的实现步骤。 ## 一个完整示例 假设有一款面向技术写作者的 AI 助手。团队在几家模型提供商之间进行选择后，确定采用混合方案。每次对话的平均原始模型成本为 0.60 美元，主要由较长的检索上下文造成。按照当前规模计算，向量存储和基础设施每月为每位活跃用户增加约 0.08 美元；后台摘要处理则每月增加约 0.12 美元。 团队选择 token 作为价值单位，因为目标买家是已经习惯以 token 思考的开发者。他们选择每月 15 美元的基础套餐，包含 100,000 个 token，超出部分按每百万个 token 3 美元收取超额费用。更高一级的套餐价格为每月 50 美元，包含 500,000 个 token，超额费率相同，并额外提供更长的历史记录保留时间等功能。 以一位每月使用 300,000 个 token 的典型付费用户计算，其中只有 200,000 个 token 超出包含配额。按照每百万个 token 3 美元计算，超额费用为 0.60 美元，因此总收入为 15.60 美元。模型提供商处的综合成本约为每百万个 token 1 美元。因此，可变部分的毛利率约为 3 倍，处于健康水平。基础费用可以轻松覆盖固定基础设施成本。 一位每月使用 2,000,000 个 token 的重度用户，在较低档套餐下支付基础费用，外加约 5.70 美元的超额费用。由于两个套餐的超额费率相同，50 美元套餐只有在该用户同时需要其中包含的更长历史记录保留时间时，才会成为更划算的选择。团队从重度用户身上赚取的收入高于轻度用户，这正是目标所在，同时不会在任何一类用户身上亏损。 这就是 AI 按用量定价的全部意义：让收入随着消费增长，而不是与消费背离；并将利润率作为价格结构的固有属性保留下来，而不是寄希望于平均值。 ## 需要避免的常见错误 有几种模式几乎必然会带来问题。提前避免它们，可以减少返工。 当消息长度差异很大时，却按每条消息的价格收费。你应该改为按 token 计费，或者以客户无法钻空子的方式定义一条消息。 隐藏计量器。如果用户无法在产品中看到当前使用量和预计账单，那么每次超额都会让他们感到意外。意外账单是 AI 产品流失的首要原因。应在用户界面中显示使用量，并在达到可预测的阈值时发送通知邮件。 永远不会触发的软上限。如果你声明了配额，却从不真正执行，那么你运营的就是无限量产品。你需要决定采用哪种方式：需要明确升级的硬上限、带超额费用的软上限，或两者结合。 忘记税费和汇率。如果你向多个国家的客户销售产品，税务合规并不简单，货币转换费用也会侵蚀利润。像 Dodo Payments 这样的 [MoR（名义商户）](https://dodopayments.com/blogs/what-is-a-merchant-of-record)可以处理这两项工作；如果你自行构建系统，就必须将其计入成本。 忽略重试和后台工作。最干净的做法是对所有 LLM 调用进行计量，包括后台调用，但只向客户收取面向用户部分的费用。这样，即使只有一部分成本会计费，你仍然可以在内部掌握完整的成本情况。 ## Dodo Payments 如何发挥作用 MoR（名义商户）平台会代表你完成三件事。它是发票上的销售方，因此负责税务和合规；它是支付处理方，因此负责银行卡、钱包和银行支付方式；它是计费引擎，因此负责计量器、发票、催收和按比例计费。 对于 AI 聊天应用来说，最重要的部分是计量和全球税务处理。计量功能让你无需编写自定义用量聚合器，就能实现上文设计的定价模型。全球税务处理则意味着你可以向美国、欧洲、印度以及世界其他地区销售产品，而不必自行搭建税务引擎。 如果你想了解完整的集成流程，聊天应用蓝图会从 API 密钥设置一直讲到事件采集。本文的定价策略为你提供框架，而蓝图则提供代码。 ## 结语 采用固定费用的 AI 聊天应用，通常会在运营几个季度后被迫大幅重新定价，或者因为单位经济模型始终无法成立而关闭。按照价值单位定价，同时用基础费用覆盖固定成本，并为可变部分设置清晰计量器的应用，通常能够经受真实用户的考验，并在不意外压缩利润率的情况下实现增长。 这种模式并不新鲜。电信、云、CDN 和可观测性公司已经采用它运营了数十年。只是 AI 让它变得更加重要，因为底层计算成本相对于软件产品而言异常高。把 token 账单视为真实的销售成本，在其上加上真正的利润率进行定价，并使用能够处理繁琐工作的计费平台，这样你就能把工程时间投入到产品本身。 ## 常见问题 ### 我应该按 token 还是按消息定价？ 如果你的产品界面类似 API 或面向开发者，请使用 token。如果产品面向消费者或工作流，并且消息长度相对稳定，请使用消息。无论选择哪一种，都应在上线前根据真实流量进行换算计算，并每季度重新检查。 ### 可变部分的利润率应该设定为多少？ 将原始 LLM 成本乘以 2 到 3 倍，是一个合理的起点。低于 2 倍，你就没有足够空间应对重试、模型价格变化或后台工作；高于 4 倍，你很可能会因为价格失去交易。可以参考同品类 AI 产品的收费水平确定锚点，然后根据数据逐步调整。 ### 我需要执行严格的使用量上限吗？ 硬性上限可以保护客户免受失控账单的影响，也能保护你免受单个账户造成的失控损失。最干净的模式是：先设置软上限，触发邮件和产品内警告；随后设置硬上限，要求客户明确升级或充值。纯软上限既容易造成账单意外，也容易被滥用。 ### 我应该如何处理国际税务？ 如果你面向全球销售，最简单的方式是使用像 Dodo Payments 这样的 MoR（名义商户），自动计算并代缴 VAT、GST 和销售税。自行构建则意味着搭建税务引擎、在数十个司法管辖区注册，并定期提交申报，这需要投入大量工程和财务资源。 ### 我能多快推出按用量计费？ 如果你已经为每次 LLM 调用准备了清晰的事件，那么集成支持计量器和超额费用的计费平台只需要几天，而不是几个月。定义产品、接入事件采集 API，并在应用中加入使用量视图，就能覆盖大部分工作。通常真正困难的是内部就定价模型达成一致，而不是构建系统。 --- - [More AI articles](https://dodopayments.com/blogs/category/ai) - [All articles](https://dodopayments.com/blogs)