一、计量模型：从请求级到 Token 级

计量是计费的基础。早期系统往往只记录请求次数，但不同请求消耗的 Token 数量差异巨大，仅按请求次数计费无法反映真实成本。因此，计量需要下沉到 Token 级。

具体来说，需要在网关层或推理服务层捕获每次请求的输入 Token 数和输出 Token 数。对于多模型场景，不同模型的 Token 计算方式可能不同，需要抽象出统一的计量接口。计量数据需要带上租户标识、模型标识、时间戳、请求来源等维度，以便后续按不同粒度聚合。

计量过程中需要考虑几个问题。第一，流式响应的 Token 计数。流式输出时，Token 是逐步产生的，需要在流结束时汇总，或者边流边计。第二，重试和失败的请求如何处理。如果请求失败但已经消耗了部分 Token，是否计费需要明确策略。第三，缓存命中场景。如果命中缓存，Token 消耗可能为零或很少，需要在计量中体现。

计量数据的存储需要支持高吞吐写入和快速聚合查询。通常采用时序数据库或列式存储，按租户和时间分区。数据保留策略也需要考虑，原始明细数据保留一段时间，聚合数据长期保留。

二、配额策略：多租户下的资源分配

配额是控制租户消耗、防止滥用、保障服务质量的手段。在多租户环境中，配额需要支持多个维度：按 Token 总量、按请求次数、按并发数、按模型类型等。

配额策略可以分为硬配额和软配额。硬配额在达到上限时直接拒绝请求，软配额则允许超额但会触发告警或降级。实际系统中，通常结合使用：日常用软配额，防止突发流量；关键资源用硬配额，保障核心租户。

配额的分发需要考虑租户层级。大型租户可能有多级子账号，配额需要在层级间分配和继承。配额变更需要实时生效，这意味着配额数据需要缓存在网关或推理服务的内存中，并通过消息通道同步变更。

配额与计费的关系也需要明确。配额是事前控制，计费是事后核算。两者需要共享同一套计量数据，但计算逻辑可能不同。配额可能按简单的 Token 总量计算，而计费可能按模型单价、时段折扣等复杂规则计算。

三、实时结算：从计量到账单

实时结算要求系统在请求完成后尽快算出费用，并更新租户余额或配额使用量。这对系统的延迟和一致性提出了较高要求。

一种做法是异步结算：请求完成后，计量数据写入消息队列，结算服务消费消息并计算费用，更新余额。这种方式延迟稍高，但吞吐量大，适合大多数场景。另一种做法是同步结算：在请求返回前就计算费用并扣减余额。这种方式延迟低，但需要结算服务与推理服务紧密集成，复杂度高。

实时结算需要处理价格模型。不同模型有不同的输入和输出单价，可能还有阶梯定价、时段折扣、套餐包抵扣等规则。价格模型需要可配置，并支持版本管理，因为价格变更后，历史账单需要按当时的价格计算。

结算过程中还需要处理预扣和补扣。预扣是在请求前冻结一部分余额，请求完成后按实际消耗扣减，释放多余部分。补扣是在余额不足时允许透支，后续补缴。这些机制需要与风控和告警联动。

四、对账机制：保障数据一致性

对账是计费系统可信度的保障。由于计量、结算、账单生成涉及多个环节，数据不一致的风险始终存在。对账机制需要定期比对各环节的数据，发现差异并修复。

对账的维度可以按租户、按时间、按模型。常见的不一致包括：计量数据丢失、结算重复计算、账单生成遗漏。对账系统需要能够定位差异来源，并提供修复工具。

除了内部对账，还需要支持租户侧的对账。租户可以查看自己的用量明细和账单，并与自己的记录比对。这要求系统提供透明的用量查询接口和账单导出能力。

对账的频率可以根据业务需求设定。日对账、小时对账、实时对账各有优劣。日对账实现简单但发现问题的延迟高，实时对账复杂但能及时止损。通常采用分层策略：核心指标实时监控，全量数据日对账。

五、架构考量与可观测性

整体架构需要兼顾性能、一致性和可扩展性。计量采集点应尽量靠近请求入口，减少数据丢失。结算服务应独立部署，避免影响推理服务。数据存储应分层：热数据用于实时查询，冷数据用于长期分析。

可观测性方面，需要监控计量延迟、结算成功率、配额拒绝率、对账差异率等指标。告警需要区分不同级别：计量中断是严重告警，配额拒绝率上升是容量告警，对账差异是小额告警。

此外，系统需要支持灰度发布和回滚。价格模型变更、配额策略调整、结算逻辑升级都需要能够灰度验证，避免全量故障。审计日志需要记录所有配置变更和资金操作，满足合规要求。

结语

Token 计量、配额与实时计费是多模型服务商业化的重要支撑。计量要准确到 Token 级，配额要灵活到多租户，结算要实时到请求级，对账要透明到租户侧。四个环节相互配合，才能构建可信、可持续的服务体系。