大模型服务的计费工程：token 计量与对账

计费从数对 token 开始

API 网关怎么做鉴权、路由与限流，「大模型 API 网关」一篇已经讲过；本篇讲网关背后另一套系统工程——计费。模型服务的计费单位是 token，看起来只是「单价乘数量」，真做起来会发现计量、计价、聚合、对账每一环都有坑：数 token 有口径问题，重试有重复计费问题，失败请求有边界问题，上游调价有追溯问题。计费系统出小错是账目不平，出大错是客户信任崩塌，它是大模型服务从「能跑」到「能卖」的分水岭。

token 的口径问题

第一坑是「数不准」。token 由模型的 tokenizer 切出来，不同模型词表不同，同一段中文在不同模型里的 token 数可以差出不少；服务方对外报价以「每百万 token 多少钱」为单位，但这个 token 是上游模型自己的口径。自建 tokenizer 预估用量可以，做对账不行——计费的权威必须是上游响应里返回的 usage 字段，自算口径只配做预估与异常检测（比如上游报回来的用量与预估差出一个量级，该告警了）。

第二坑是「不是一个价」。输入与输出分别计价，输出单价通常明显更高——生成比理解的计算更重；启用提示缓存后，命中缓存的前缀按折扣价计，未命中部分按原价计；有的服务还有时段档位或批量档位。计费系统必须把一次请求的用量拆成「输入、输出、缓存命中」几个桶分别累计，混在一个桶里算，账单和上游对不上还查不出原因。

计量还有两个工程细节。一是整数化：token 数全程用整数累计，价格折算成「每 token 的最小计价单位」做整数运算——浮点误差在千万次调用后会累积成肉眼可见的账目差异。二是单位统一：上游有的按 token 报用量、有的按百万 token 报价，入库前统一换算，别让两套单位混在一张表里。多模态调用还有第三种口径——图片按 token 折算（常识口径），同样进桶管理。

用量采集：在网关侧统一记账

采集点与记录内容

采集点天然在网关：所有出站调用的必经之路，在这里记账最完整。每条调用日志至少要记：时间戳、租户与密钥标识、模型名、请求标识、输入与输出 token 数、缓存命中量、完成状态、延迟，以及用于幂等去重的上游请求 ID。流式响应有个细节：usage 统计通常在最后一个数据块才返回（部分上游还需要显式开启该选项），网关要保证流式链路把最后一块的用量也摘出来记账，不能流式请求就漏记——流式恰恰是线上流量的主流形态，漏记就是大面积漏账。

高并发下记账是热路径，性能纪律要立住：日志异步写、序列化用轻量格式、聚合后批量刷盘，记账耗时不能进推理请求的关键路径——计费系统再重要，也不能让每次对话多等几毫秒。记账的完整性还有一条：失败请求与被限流的请求也要记，只是状态不同——它们不产生客户费用，但有排障与成本分析价值（限流集中说明什么在拥塞，失败集中说明什么在坏），而且上游可能在失败前已消耗少量用量。只记成功请求的账本，对账时永远差一块。

采集可靠性：先落地再细算

采集链路的第一纪律是宁晚勿丢：调用日志先在网关本地落地（顺序写日志文件或本地队列），再异步批量送入计费管道。计费系统宕机、消息队列堵塞，都不能反过来阻塞推理请求——大不了晚点入账，不能不记。批量入库既省数据库压力，也给对账留了原始凭证：账单算错了，可以拿原始调用日志重放一遍验证。原始日志按保留策略归档，它是所有计费争议的最终裁决依据。

接多家上游供应商的网关还有一道归一工序：各家返回的用量字段名与口径不同，有的缓存命中单独给字段、有的混在总数里，网关要在入口处把用量归一成内部统一格式再落账——归一逻辑放采集侧，别把各家方言直接写进账本，否则对账引擎要为每一种方言单独写解析。

归一之外还要保存「上游原始值」：内部口径与上游口径并存，对账时用原始值对上游、内部值对客户，两边都能精确核对——只存归一值的账本，与上游对不上时连差异都算不出来。

计价引擎与账单聚合

计价引擎的核心是价格表版本化。价格是一种会变的配置：新模型上线、老模型降价、缓存折扣调整，每一次变动都生成新的价格版本，标明生效区间；一笔用量按它发生时刻所属的价格版本计价，调价永不追溯。这个设计让「重新算上个月某客户的账」成为可复现的操作——用同一版价格表重放同一批用量，结果必然一致。若价格直接改在代码或一张无版本的表里，任何一次调价都会把历史账目变成糊涂账。

价格表达力决定商业灵活性。阶梯价（用量越大单价越低）、套餐包月（包量加超额计价）、免费额度（每月前若干 token 免费）都要能表达成价格表的组合。免费额度与预付费余额还引出并发竞态问题：同一密钥的多个请求同时扣减额度，扣减必须是原子操作，否则超发——这类账目问题只在高峰期出现、极难复现，要靠并发设计一次做对。

价格变动的通知义务也别漏：调价提前公告、存量客户是否受影响、生效时点的口径，写进产品条款；计费系统的价格表生效时间与公告时间严格对齐，别出现「公告说下月生效、系统当月就按新价扣」的错位——这种错位每一次都会变成信任事故。

账单聚合走「明细加快照」两级：明细是每条调用日志计价后的记录，支撑任意维度的下钻；快照按日（或按小时）对每个租户、每个密钥聚合成日结账单。报表与展示一律读快照，不让前端查询去扫明细大表。日结时点之后的迟到数据（上游晚些才回调的用量）要有明确的归属规则——常见做法是归入发现当日的调整项，并在对账环节统一处理，而不是悄悄改写已经出账的日期。

出账流程也要仪式化：账单快照生成即不可变，之后的一切修正走调整项（冲正）而不是改写历史——客户看到的每一行都能追溯到原始明细。补账、退款、折扣返还全部以调整项入账，各带业务原因标注，审计时账本从头到尾是一条干净的流水。

对账与防漏：幂等与失败边界

重试的幂等

分布式系统里重试无处不在：客户端超时重试、网关故障重试，同一次用户请求可能在上游产生多次实际调用、多份用量。防重复计费的锚点是请求标识贯穿全链路：网关为每个请求生成全局唯一 ID，透传给上游，上游返回的用量记录带着这个 ID 回来；计费侧按 ID 去重，同 ID 的第二份用量只记成本不重复向客户收费。少了这根线，一次客户端疯狂重试的故障就能生成一份数倍膨胀的账单，等客户拿着截图来对质才发现。

时钟与时区是另一个经典坑：账期按哪个时区日切（协调世界时还是本地时区）、跨日请求归属哪一天，要写成明文并全链路一致。跨国客户按自己时区理解的「这个月」与你按服务器时区出的账单，差额能让双方各说各话——这类问题没有技术难度，全靠口径文档写清楚、写早点。

失败请求算不算钱

失败边界要事先定死并写进 SLA：上游明确报错且无 token 产出的，不计客户费用；但若上游侧已实际产生用量（比如请求其实生成了一半才断），我方成本照记，是否向客户收费按业务口径决定——常见做法是这类边界损失自己吸收，换取客户信任。对账体系按天跑三个核对：我方账单与上游账单的总量核对（差异超阈值告警）、我方收入与上游成本核对（毛利监控，防止卖一个亏一个的定价悄悄上线）、抽查明细核对（随机抽若干请求手工复算）。对账不是财务的事，是计费工程的一部分，差异要能下钻到单条请求。

流式请求的失败边界更细：生成到一半连接断了，已产出的 token 上游照样计费。我方照记成本，是否向客户收这笔半程账要写进条款——常见做法是客户端主动取消的免收、网络异常中断的酌情处理，并把自动重试策略对客户透明。边界定得越细，售后争议越少。

退款与争议的处理流程也要制度化：客户投诉一笔账，处理动作不是直接改数字，而是走「调原始日志、给出复算结果、必要时冲正」的标准流程，冲正记录带原因与经办人，争议处理本身也留痕。争议还要按月复盘：重复出现的争议类型指向系统性问题——是口径没写清，还是采集有洞；把争议当缺陷管理，比当客服工单管理更能根治。

多租户的配额与成本可见化

计费数据攒起来之后，向上长出两套能力。一套是配额控制：按密钥设每分钟请求数与 token 数限流（网关篇的限流机制在这里挂上计费的真实数据）、按租户设月度用量上限与余额熔断——余额耗尽自动降级或拒绝，欠费不再是人工看报表才发现的事。配额执行还有一段灰色地带要设计：达到限额的瞬间是硬拒绝还是软降级（切到便宜模型继续服务），各有客户体验后果，要写进产品条款并让客户可选。另一套是成本可见化：每次调用都能归因到业务方与项目，账单按部门、项目、模型多维拆分；每千次调用成本、每任务 token 成本这类单位成本曲线，是模型降级、缓存策略、路由优化有没有效果的唯一客观裁判。很多团队上了计费系统才发现，某个「不重要」的内部业务烧掉了三分之一的模型预算——成本不可见时，浪费也是不可见的；可见化本身就能带来一轮降本。

成本可见化再往上挂一层是预算管理：给每个业务方设月度预算，用量到八成自动告警给负责人，超预算走审批或自动降级到便宜模型——把成本控制从「月底惊讶」变成「过程管理」。同时维护单位成本台账：每次换模型、调缓存、改路由策略，都记录单位成本的前后变化，降本动作有没有效果、值不值得推广，台账说了算。

小结

大模型服务的计费工程，是用工程手段保证「数得准、算得清、对得平」。计量上认死上游 usage 为权威口径，输入、输出、缓存命中分桶累计；采集上在网关统一记账、先本地落地再异步入账，宁可晚到不可丢失；计价上价格表版本化、调价不追溯，账单走明细加快照两级；对账上用全链路请求 ID 防重试重复，把失败边界写进 SLA，每天跑总量、毛利、明细三层核对；再向上长出配额熔断与成本可见化两套运营能力。

计费系统的特殊之处在于它是「信任工程」：客户可以原谅服务抖动，很难原谅账单出错。所有设计决策——幂等、版本化、留凭证、可重放——都指向同一个目标：任何时候客户质疑一笔账，你都能拿出凭证，在十分钟内给他复算出同一个数字。做到这一点，计费就不再是成本中心里的麻烦事，而是商业化地基里最硬的那一块。

再往远处看，计费数据还是产品与商业决策的原料：哪些模型被真实使用、各档位客户的用量分布、边际成本随规模怎么变——定价调整、模型下线、容量规划都要从这本账里取证。把计费当成本中心做，它是一堆对不上就要命的表；把它当数据资产做，它是整个业务最诚实的仪表盘。