按用量计费并非新鲜事物，但人工智能 (AI) 产品已将其推进到标准流程难以应对的程度。token 数量的波动性、蔓延至数百个下游调用的智能体循环，以及可能在数分钟内骤增的工作负载，给事件归因、计量准确性和成本控制带来了传统应用程序编程接口 (API)计费从未需要解决的工程难题。事实上，46% 的 IT 负责人表示，不可预测的定价是其组织实施生成式 AI 的主要障碍。
下文将介绍如何为 AI 服务实施按用量计费、如何将原始事件转化为清晰的应计费总额，以及如何添加在成本失控演变为账单争议之前予以拦截的护栏。
要点
用量事件合约是所有下游环节的基础。早期制定的架构决策将直接影响定价模式变更或需要解决争议时所面临的难度。
去重、延迟事件策略、修正和规则版本控制，是区分能够产出可信账单的系统与最终出现重复计费的系统的关键所在。确定性和幂等性不是可选项。
成本控制必须内置于执行层。信用额度预留、智能体循环的熔断机制以及异常检测，都需要在产生用量之前激活。
什么是 AI 公司的按用量计费？
按用量计费是根据客户的消耗量按比例收费（例如，处理的 token 数、计算秒数、API 调用、智能体操作），而非收取固定费用。
这种模式很灵活，因为不同客户的推理成本可能相差几个数量级。固定费率定价会补贴重度用户或赶走轻度用户。按用量定价需要一个能够发送用量事件、可靠摄取、正确计量并将其转化为账单（通常几乎是实时的）的管道。
AI 公司的按用量计费的运作机制是什么？
在较高层面上，该系统从您产品中的可计费操作转移到客户账单上的行项目。每个阶段都有其自身的故障模式，如果设计不当，这些故障模式就会叠加发生。
以下是各个阶段及其运作机制：
发送：每次发生可计费操作（完成、嵌入请求、工具智能体或智能体步骤）时，您的应用程序都会发送一个用量事件。
摄取：事件流经一个管道，该管道对其进行验证、缓冲和持久化存储。该管道必须能够吸收流量，而不会丢弃记录或降低性能。
计量：在账期内，原始事件会被聚合为可计费的数量。该层始终如一地应用单位定义、定价逻辑和聚合规则。
账单：计量总额会传递到您的计费系统，该系统会生成账单行项目，应用抵扣额或折扣，并向客户扣款。
每一层都应保持独立且正确。您一定不希望在几周后看到收入差异时才发现存在摄取问题。
哪些 AI 特有的行为使得按用量计费更难实施？
传统的 API 假定了一种简单的映射关系：一次请求产生一次响应和一个可计费事件。AI 工作负载并非如此。
以下是导致 AI 特有的行为在按用量计费中更难实施的原因：
智能体循环与工具调用并行分发
一次用户操作（例如，“研究此主题并起草一份报告”）可以激活数十甚至数百次大型语言模型 (LLM) 调用、工具调用和检索步骤。归因很快就会变得复杂。哪些操作可计费？当单个智能体会话跨越多个用户、项目或租户时，费用应由谁承担？如果没有在事件模式层级进行定义，以后修复起来会变得更加困难。
token 可变性
输入和输出 token 的成本不同，并且无法提前预测。包含 200 个 token 提示词的请求可能会返回 50 个或数千个 token，具体取决于任务、模型设置和生成行为。您无法根据请求大小预先计费。您必须在执行后发送包含实际计数的事件。
不均衡的工作负载
凌晨 2 点的企业批处理作业在几个小时内产生的用量，可能比过去两周的总和还要多。摄取系统必须能够处理这些峰值，而不会丢失事件、落后或延迟计费。
非确定性成本
相同的提示词在不同的运行中可能会产生不同的 token 数量，尤其是在使用流式处理、函数调用或智能体链时。这使得确定性测试变得困难，并要求计量逻辑从一开始就被设计为能够容忍这种差异。
非确定性成本
相同的提示词在不同的运行中可能会产生不同的 token 数量，尤其是在使用流式处理、函数调用或智能体链时。
AI 公司的可靠用量事件合约是什么样的？
用量事件是计费系统的原子单元。从计量到开单再到审计，所有下游系统都依赖于稳定且明确的事件合约。
以下是可靠用量事件合约的具体内容：
客户和项目标识符：稳定、不可变的 ID，即使客户重命名其组织或调整其账户层级结构，也不会发生变化。
操作时间戳：记录操作发生的时间，而非事件发出的时间。异步管道可能引入延迟，影响时段归因。
单位和数量：您所衡量的内容（例如，输入 token 数、输出 token 数和计算秒数）及其数量。除非定价方式保持一致，否则请保持单位的原子性。
关联 ID：一个唯一标识符，将用量事件与源请求、会话或智能体运行关联起来。这是您将账单行项目追溯到应用程序日志的依据。
计费标志和原因代码：并非每个操作都是可计费的。在事件中明确标注计费决策，而非将其埋藏在下游逻辑中——后者更难审计。
架构版本：当定价模式发生变化时，新旧事件必须能够共存。版本控制将使这成为可能。
AI 公司应如何设计按用量计费的摄取和存储？
有两个要求主导了这一层：可靠性和不可变性。其他一切（吞吐量、延迟、模式验证）都服务于这两个目标。
以下是 AI 公司设计摄取和存储的方式：
可靠性
写入具有“至少交付一次”语义的持久化队列系统。队列可保护您免受暂时性故障的影响；下游客户负责处理去重。不要将用量事件从您的应用程序直接写入数据库。
确保必填字段存在，标识符解析正确，并且时间戳合理。尽早拒绝格式错误的事件并给出清晰的错误提示，而不是让不良数据泄露到计量环节。
专门针对突发流量进行设计。配置不足的摄取系统通常会因事件丢失而失败。
不可变性
您的原始事件存储应该是仅追加的。这意味着，虽然新数据可以被添加（追加）到文件或数据库的末尾，但现有数据保持不可变（无法被修改或删除）。当发生错误时（例如，计算错误的 token 数量或错误归属的客户），请发送一个引用原始记录的更正事件，而不是编辑源记录。这在争议解决方面是不可协商的。当客户对账单提出争议时，您需要重新播放产生该数字的完整事件序列。
AI 公司如何将原始用量事件转化为准确的可计费汇总？
计量是准确性的关键所在。给定相同的输入事件和规则，输出必须始终相同。
有四个特性使得这一点成为可能：
去重和幂等性：“至少交付一次”保证了会有重复项。这种幂等性（即操作输出提供相同结果的特性）意味着每个事件都需要一个唯一的 ID，并且在聚合计数之前必须进行去重。如果没有这一点，重复计费的可能性就会大得多。
延迟事件处理：事件不会按顺序到达。请定义明确的策略：在账期结束后 X 分钟关闭账期，在该截止时间前接受延迟事件，并标记或拒绝超出该时间的任何事件。一致性很重要。
更正事件：当出现错误时，发送更正事件以调整总数，引用原始事件，并解释发生更改的原因。不要重写历史汇总。
规则版本控制：定价规则可能会改变，但事件必须根据发生时生效的规则进行计量。将当前规则应用于上个季度的用量会导致账单不正确。
诸如 Stripe Billing 等工具在账单端处理聚合，但您的内部计量层应该独立生成其自己的汇总。这些将成为您进行对账的事实来源。
AI 公司如何利用护栏进行成本控制？
AI 工作负载产生支出（包括您的支出和客户的支出）的速度，快到任何人都来不及介入。护栏必须实时运行。
以下是 AI 公司利用护栏防止成本失控的方法：
信用账本与预留
在执行产生用量的操作之前，先从客户余额中预留预计费用。若预留失败，则不执行该操作。执行完成后，按实际用量结算。这与信用卡预授权机制类似，是 AI 计费的正确思维模型。
软限制与硬限制
硬限制会直接停止用量。软限制则在阈值临近时触发提醒。两者均应支持按客户和按项目进行配置。生产工作负载与试用账户对此有不同的容忍度。
智能体工作负载的熔断机制
智能体需要特殊处理。设置最大步骤数、每个会话的最大支出上限以及自动终止开关。在执行时强制执行这些限制，而非事后计费。一旦计费系统收到事件，成本便已发生。
异常检测
追踪每位客户的用量速率，并对超出定义阈值的偏差进行标记（例如，每单位 0.1 美元）。自动暂停并配合人工审查队列通常是正确的应对方案。目标是在失控流程演变为争议或销货成本 (COGS) 意外之前将其拦截。
Stripe Billing 如何提供帮助
Stripe Billing 支持灵活多样的客户计费管理方案——从简单定期计费到按用量计费及销售协商合同。无需编写代码即可在全球范围内快速开通定期付款，亦可借助 API 构建定制化集成方案。
Stripe Billing 可帮助您：
提供灵活的定价：通过灵活的定价模式（包括按用量、分层、固定费率加超额费用等）更快地响应用户需求。内置功能支持优惠券、免费试用、按比例收费和附加服务。
扩展全球业务：通过提供客户偏好的支付方式提升转化率。Stripe 支持 100 多种本地支付方式及 130 余种货币。
增加收入并减少客户流失：通过 Smart Retries 和恢复工作流程自动化技术，提高收入获取率并减少非自愿客户流失。Stripe 恢复工具在 2024 年帮助用户挽回了超过 65 亿美元的收入\。
提高效率：使用 Stripe 的模块化税务、收入报告和数据工具，将多个收入系统整合为一个。轻松与第三方软件集成。
本文中的内容仅供一般信息和教育目的，不应被解释为法律或税务建议。Stripe 不保证或担保文章中信息的准确性、完整性、充分性或时效性。您应该寻求在您的司法管辖区获得执业许可的合格律师或会计师的建议，以就您的特定情况提供建议。