构建 AI API 计费账本：报价、预留、结算和协调每个模型调用
多模型网关的实用计费控制模式：在请求之前估算成本、保留租户预算、规范提供商使用情况、结算实际费用以及核对发票，而无需单独依赖原始提供商响应。
面向客户的AI API 计费不能每月导出原始提供商使用情况。如果网关向租户、团队或合作伙伴公开多个模型，则计费必须在发票存在之前回答一个更难的问题：现在是否应该允许此请求，以及稍后将如何解释其成本？
实际的模式是一个包含四个阶段的记账账本：报价、保留、结算和对账。在提出请求之前报价可能的费用。预留足够的租户预算以应对允许的最坏情况。了解使用情况后结算实际费用。将网关分类账与提供商方记录进行核对，以便发票保持合理性。
本文介绍了多模型 API 网关的控制循环。无论网关向内部团队、预付费客户、代理客户还是下游合作伙伴计费，它都很有用。
计费问题：提供商使用情况不是客户发票
事实：主要人工智能提供商不会公开一种通用代币计数器或一种通用价格。 OpenAI 发布每个模型的价格，以及单独的输入、缓存输入和输出代币费率。 OpenAI 提示缓存在 API 响应使用字段中报告缓存的令牌使用情况。人类文档将普通输入令牌、缓存创建输入令牌、缓存读取输入令牌和输出令牌的计数器分开。 Gemini 定价区分输入、输出和其他令牌类别，包括特定于模式的使用，例如音频令牌。
这意味着网关无法通过将 total_tokens 乘以一个价格来安全地计费。它需要在提供商中立的计费模式背后提供特定于提供商的适配器。
在这些情况下问题变得更加明显：
- 预付积分：网关必须在租户支出低于零之前拒绝请求。
- 合作伙伴加价：合作伙伴需要自己面向客户的发票，而不是提供商帐单的副本。
- 流式传输：响应在得知最终令牌使用情况之前开始。
- 提示缓存：缓存的输入可能比未缓存的输入便宜，但前提是单独测量。
- 推理和工具使用：某些模型会公开额外的使用维度、隐藏的输出类或媒体单元。
- 提供商价格变更：价目表变更后，上个月的发票必须仍可重现。
建议：将计费视为仅附加的财务分类帐，而不是对请求日志的仪表板查询。
核心架构
可靠的计费架构有六个组成部分：
- 租户帐户：客户、工作区、经销商客户或内部成本中心。
- 价目表服务：提供商、型号、计费类别、货币和加价规则的版本化价格。
- 估算器：根据请求参数和模型政策计算预检报价。
- 预订分类帐：在提供商呼叫开始之前保存预算。
- 使用规范化器：将提供商特定的使用字段转换为内部计费单位。
- 结算和对账工作：最终确定费用并将其与提供商方记录进行比较。
控制流程如下所示：
客户端请求
-> 验证租户和密钥
-> 选择型号和价目表版本
-> 估计输入和最大输出成本
-> 保留租户余额
-> 呼叫提供商
-> 标准化返回的用法
-> 结算实际成本
-> 释放未使用的预留
-> 发出发票就绪账本事件重要的设计选择是请求不仅仅被遵守。执行前后均受到财务控制。
第 1 步：在提供商调用之前报价
预检报价应该足够悲观以执行预算，但也应该足够解释以向客户或合作伙伴展示。
输入通常包括：
- 租户 ID 和计费计划；
- API 密钥 ID 或项目 ID；
- 应用路由规则后的提供商和模型 ID；
- 估计的未缓存输入令牌；
- 已知的缓存输入资格（如果有）；
max_tokens、max_output_tokens或同等输出上限；- 工具、图像、音频或其他模态参数；
- 合作伙伴加价、折扣或经销商定价规则；
- 货币和舍入政策。
用于文本生成的简单引用公式可能是：
估计成本 =
估计未缓存的输入令牌 * 输入率
+ 估计缓存输入令牌 * 缓存输入率
+ 最大输出令牌数 * 输出率+ 请求费用
+ Partner_markup建议：当最终输出长度未知时，根据配置的最大输出进行保留。如果应用程序使输出上限不受限制，则网关应应用租户或模型默认值。如果没有最大责任，预算执行就不可能具有确定性。
这可以拒绝一些实际上成本较低的请求。这就是权衡。对于预付费系统，更安全的默认方式是悲观预留，结算后释放未使用的资金。对于已开具发票的企业客户，团队可能会允许软超额，并将报价主要用于警报。
第 2 步：预留租户预算
预留可保护租户帐户的支出不会超过允许的余额。它应该是原子的：要么预订成功并且提供商调用可以开始，要么在产生任何提供商成本之前拒绝请求。
预订记录可能包括：
<前><代码>{ "reservation_id": "res_01J...", “tenant_id”：“tenant_123”， "api_key_id": "key_456", “request_id”：“req_789”， “提供商”：“示例_提供商”， “模型”：“模型-a”， “rate_card_version”：“2026-08-01”， "引用金额": "0.032100", “货币”：“美元”， “状态”：“保留”， “expires_at”：“2026-08-11T12:05:00Z” }针对网络故障和客户端断开连接，使用较短的预留过期时间。清理工作应该释放从未达成结算的过期保留。但是，不要仅仅因为客户端断开连接就释放预留；提供商调用可能仍会完成并产生费用。单独跟踪提供者请求状态。
建议：通过请求 ID 或幂等密钥使预留具有幂等性。来自客户端、网关或工作人员的重试不应为同一逻辑请求创建多个预算保留。
第 3 步：规范提供商的使用
提供商响应应转换为小型内部架构。即使提供商添加新的使用字段，也保持稳定。
实用的标准化使用模式：
<前><代码>{ “input_uncached_tokens”：1200， “input_cached_tokens”：800， “cache_write_tokens”：0， “输出令牌”：650， “reasoning_or_hidden_output_tokens”：0， “工具或媒体单位”：[]， “request_fee_units”：1， "provider_request_id": "prov_abc", “usage_source”：“provider_response”， “is_estimated”：假 }此模式故意与任何一个提供商的响应不同。它捕获发票所需的计费维度，同时为特定于提供商的单位保留逃生舱口。
缓存的令牌需要自己的行
事实：提示缓存的定价与未缓存输入的定价不同。如果缓存的令牌合并到总输入令牌中，则客户可能会被多收费，或者网关可能会低估提供商的成本。缓存的输入应在分类帐和发票中显示为其自己的计费类别。
缓存写入和缓存读取并不总是相同
一些提供程序区分创建缓存条目和从缓存读取。规范化器不应假设缓存的输入始终意味着一个计费率。如果提供程序具有缓存写入令牌和缓存读取令牌，请将它们单独映射或将它们保留为特定于提供程序的子单元。
推理和隐藏输出需要策略
某些模型公开与推理相关的用法或隐藏的输出计数器。如果提供商对这些单位进行计费，网关必须决定是直接显示它们、将它们汇总到输出类别中还是将它们列为单独的发票行。
建议：面向客户的发票应使用简单的语言。例如：“推理输出标记”比原始提供者字段名称更清晰。保持原始字段可供审计，但不要强迫每个客户了解提供商的内部结构。
第4步：结算实际成本
结算将标准化使用量转换为最终分类账条目。它应该是仅附加的，并引用用于请求的价目表版本。
已解决的事件可能如下所示：
<前><代码>{ "ledger_event_id": "led_01J...", "event_type": "结算", “tenant_id”：“tenant_123”， “request_id”：“req_789”， "reservation_id": "res_01J...", “提供商”：“示例_提供商”， “模型”：“模型-a”， “rate_card_version”：“2026-08-01”， “行”：[ { "billing_class": "input_uncached_tokens", “数量”：1200， “单位”：“代币”， "单价": "0.00000250", “金额”：“0.003000” }, { "billing_class": "input_cached_tokens", “数量”：800， “单位”：“代币”， "单价": "0.00000125", “金额”：“0.001000” }, { "billing_class": "output_tokens", “数量”：650， “单位”：“代币”，"单价": "0.00001000", “金额”：“0.006500” } ], "总金额": "0.010500", “货币”：“美元”， “状态”：“已解决” }如果请求被保留为 0.032100 并以 0.010500 结算，则账本会将 0.021600 释放回可用余额。
建议：切勿根据当前定价表重新计算旧发票行。存储不可变的价目表版本，并将版本 ID 附加到每个报价、预订和结算事件。否则，在供应商更新型号价格后，发票可能无法复制。
流媒体请求：先预留，后结算
流式传输使计费变得复杂，因为用户在网关知道最终使用情况之前就开始接收输出。答案不是跳过飞行前检查。网关应在打开流之前进行预留。
使用此工作流程：
- 估算输入令牌和最大输出成本。
- 预留租户预算。
- 打开提供商流。
- 将块转发给客户端。
- 在提供商发送最终使用情况或有后续使用记录可用时捕获最终使用情况。
- 结算实际费用并释放未使用的预订。
如果最终使用量不可用，请将结算标记为估计值，而不是假装它是准确的：
"usage_source": "gateway_estimate",
“is_estimated”：正确，
“reconciliation_status”：“待处理”建议：每日调节应优先考虑估计的流事件、失败的请求、超时和重试。这些是最有可能在网关记录和提供商发票之间造成差异的区域。
价目表版本控制和标记规则
价目表应该是版本化的对象，而不是可变的电子表格。
最小字段：
- 提供商；
- 型号 ID；
- 计费类别；
- 单位，例如令牌、请求、图像、音频秒或工具单位；
- 单价；
- 货币；
- 有效的开始和结束时间戳；
- 四舍五入政策；
- 租户计划或合作伙伴加价规则；
- 来源参考和批准元数据。
标记规则应该明确。例如：
- 成本加成：提供商成本加成 20%。
- 固定零售：租户支付固定代币价格，无论提供商价格如何。
- 分层：首先按一个费率发放 1000 万个代币，然后按较低费率发放。
- 包含积分：在超额计费开始之前，使用量会消耗每月津贴。
权衡：价目表版本控制增加了运营工作，但它可以防止发票纠纷成为考古问题。客户支持代理应该能够解释为什么 8 月 3 日的请求按特定费率计费，而无需检查今天的提供商定价。
将帐单与分析分开
分析和计费具有不同的容差。分析可以被聚合、延迟、采样或纠正。计费必须完整、幂等、可审计且可解释。
使用分析来解决以下问题：
- 哪些团队使用的代币最多？
- 哪些型号增长最快？
- 即时缓存可以在哪些方面降低成本？
- 哪些密钥会产生异常昂贵的请求？
使用帐单分类帐来解决以下问题：
- 此请求是否已根据租户的余额获得授权？
- 哪个价目表版本产生了这笔费用？
- 未使用的预订是否已释放？
- 客户发票与已结算的使用情况相符吗？
- 网关使用情况与提供商端使用情况相符吗？
事实：OpenTelemetry GenAI 语义约定包括令牌使用属性，例如输入和输出令牌。这对于可观察性和将跟踪连接到成本事件非常有用。但遥测属性不能替代价目表、预订、结算、舍入和发票状态。
每日对账工作流程
对账将网关的结算账本与提供商端的使用情况进行比较。我们的目标并不是在每个中间领域都完美一致。目标是尽早检测材料差异，以更正发票、价目表或适配器。
实际的日常工作：
- 按提供商、模型、租户或 API 密钥、计费类别和 UTC 日期对网关分类帐事件进行分组。
- 获取按可用维度（例如 API 密钥 ID、型号和日期）分组的提供商端使用情况。
- 尽可能通过用于请求响应的相同适配器代码规范提供程序导出。
- 按计费类别比较数量和成本。
- 标记超出阈值的差异，例如 0.5% 的数量差异或任何较大的绝对成本差异。
- 对差异原因进行分类：流式估算、重试、请求失败、缓存核算、模型别名更改、提供商记录延迟或请求 ID 缺失。
- 创建调整事件而不是编辑旧的结算事件。
建议：在操作可行的情况下，为每个租户使用提供商 API 密钥，因为这样可以简化协调。如果这会产生过多的密钥管理开销，请将内部租户 ID 映射到受支持的提供程序元数据，并保持可靠的请求 ID 桥接。
客户可以理解的发票行
面向客户的发票不应反映提供商 JSON。它应该以稳定的商业术语解释该法案。
有用的发票栏：
- 日期范围；
- 租户、项目或 API 密钥标签；
- 型号或型号简介；
- 请求计数；
- 未缓存的输入令牌；
- 缓存输入令牌；
- 输出令牌；
- 媒体或工具单元（如果适用）；
- 折扣、积分或加价；
- 总金额和货币。
对于合作伙伴，仅当业务模式需要时才包含批发成本和零售费用。许多经销商发票应仅显示零售使用情况，而合作伙伴仪表板可能会单独显示利润。
权衡：统一的发票模式提高了可读性，但特定于提供商的账单详细信息仍然需要逃生舱口。默认情况下保持发票行简单，并为需要详细审核字段的高级客户提供导出。
实施清单
启动前
- 为所有受支持的提供商定义标准化计费类别。
- 创建具有生效日期的不可变价目表版本。
- 要求输出上限或应用网关默认值。
- 使用幂等性密钥实现原子预留。
- 为每种货币设置舍入规则。
- 决定如何对缓存令牌、推理令牌、媒体单元和请求费用开具发票。
- 测试重试、超时、客户端断开连接和提供程序错误。
- 建立调整事件机制，而不是编辑已确定的事件。
请求处理期间
- 对租户和密钥进行身份验证。
- 在路由和后备策略之后解决最终模型。
- 选择正确的价目表版本。
- 引用最坏情况下的成本。
- 保留余额或拒绝请求。
- 记录提供商请求 ID（如果有）。
- 根据响应规范使用情况。
- 结算、释放未使用的预留并发出发票就绪事件。
请求处理后
- 按提供商、密钥、型号、计费类别和日期运行每日对账。
- 查看预计的流媒体结算金额。
- 标记缺少价目表条目的模型使用情况。
- 监控缓存令牌会计造成的差异。
- 在最终结算之前生成客户发票预览。
要计划的预测
预测：AI API 计费将变得更加多维，而不是更少。随着模型功能的变化，令牌类、缓存类、媒体单元、工具执行和推理相关计数器可能会不断扩展。
预测：客户将期望获得请求、密钥、项目和发票级别的使用说明。对于转售 API 访问权限或执行预付费预算的团队来说，没有可追踪行项目的每月总计是不够的。
预测：已经将报价、预订、结算和对账分开的网关将更快地适应新的定价模型，因为它们可以添加计费类别，而无需重写整个发票系统。
可行的结论
如果您通过一个网关公开多个 AI 提供商，请在计费争议造成问题之前构建计费分类账。从四个保证开始：
- 每个计费请求都会收到预检报价。
- 每个预付费或有上限的租户都在提供商通话开始之前预留了预算。
- 每个提供商的响应都会标准化为稳定的计费类别。
- 每张发票都可以根据提供商方的使用情况和当时使用的确切价目表版本进行核对。
该控制循环使统一的 AI API 计费能够为客户所理解，对预付费积分可执行，对合作伙伴加价灵活，并且在提供商定价或使用格式发生变化时可进行审核。