大模型调用账单对账：从token口径到请求级差异排查实战

周一对账我盯着两份数据发了十分钟呆。自家平台的日志显示这个月大模型调用量是 1.8 亿 token厂商后台账单对应的却是 2.6 亿差了超过 40%。往下一个请求一个请求地翻才发现事情没那么简单——既有模型别名对不上的也有缓存命中该打折没打折的更有几笔请求根本不在我们自己日志里。这大概是所有认真做 AI 应用的同学都会撞上的问题厂商账单和平台记录不一致到底是谁错了又该怎么核对这篇文章就是把我自己这些年做 AI 调用费用核对的经验完整梳理一遍。从为什么会对不上到自家日志要留下哪些字段再到一步步反推账单金额最后讲清楚几个最常见的差异场景以及如何把核对变成每天自动跑一遍的流程。无论你是刚把大模型接进生产环境还是已经被账单折腾过几轮按这套思路走一遍基本上能把账目差异锁定到具体请求级别。1. 先搞清楚哪里不一致四个最容易出问题的账目口径很多团队一看到数字对不上就开始怀疑厂商乱扣费但真相往往是我们自己的统计口径和厂商账单压根不在一个维度上。在对账之前先把下面四层口径对齐了不然后面每一步都是白费功夫。1.1 时间口径请求发起时间与计费入账时间厂商账单里每一笔钱的归属日期通常取的是服务端开始结算的时间点而不是你客户端发起请求的时间点。这两个时间在绝大多数场景下相差不超过几秒但一旦碰到月末、季末这种大额度对账节点就会出问题。举一个实际例子12 月 31 日 23:59:50你系统里有一个批量任务发起一批摘要请求服务端在 1 月 1 日 00:00:20 才完成计算。厂商把这个费用记入 1 月份的账单而你的业务日志会把时间落在 12 月 31 日。两边一跨月差异就出现了。如果只是少量请求还好要是有定时任务、消息队列延迟消费、异步回调这些场景跨月错位的量级可能相当可观。我的建议是对账时不要用业务时间而是用服务端响应时间或厂商 usage 返回的 created 时间作为归类字段。至少也要把两种时间都记录下来对账时优先采用厂商侧时间。1.2 token 口径输入/输出/缓存/工具不是同一个价这是差异最大的一个坑。我们自己日志里如果只记了total_tokens那基本上无法核对明细。现在主流大模型接口返回的 usage 结构一般是这样的prompt_tokens输入 token包含系统提示词、历史对话、用户消息、工具定义等多部分completion_tokens输出 token也就是模型生成的部分cache_write_tokens写入缓存的 token比如首次请求完整 promptcache_read_tokens命中缓存的 token比如第二次同样前缀的对话tool_call_tokens部分平台单独计费的工具调用内容这几个字段的计费单价完全不同。甚至同一个模型输入、输出、缓存读、缓存写会是四种价格。如果你只记总数厂商账单里拆了四个计费项你只有一列数字根本无从比对。1.3 计量口径流式、多模态与字符换算流式输出是现代模型的标准用法但流式调用下日志记录很容易出错。常见的错误是把每一次流式 chunk 都当成一条独立记录于是同一个请求被记成几十条token 总量当然也对不上。正确做法是按 request_id 聚合把所有 chunk 拼成完整响应后再记录一条 usage。另外多模态模型的token不是直接数文本字符。图片、音频、视频会被转换成若干 patch 或帧再换算成 token比如一张图按长宽切块每个块计一定 token。PDF 文档还会按页数附加开销。如果你自己按字数毛估那和厂商的 token 统计差出一个数量级都不奇怪。1.4 定价口径模型别名、区域版本与阶梯价格一个容易被忽略的事实是同一个模型名在不同区域、不同版本别名下的价格可能不一样。比如某厂商的基础版、增强版、不同 region 的接入点宣传时都叫类似的名字但点击详情页你会发现价格表各写各的。如果你的代码里用的是modelqwen-plus但账号实际计费模型是几个月后新上线的一个小版本单价有变动日志和账单自然对不上。价格还有阶梯的玩法。部分平台针对调用量大户推出阶梯单价或者企业合同里有折扣账单里的单价并不是官网列表价。这时候如果对账脚本里写死一个价格常量差异几乎是必然的。相关参数价格必须放到配置中心统一管理每次厂商调价后更新一次再重新跑历史账单。2. 建好自家基准日志里这几样字段一个都不能少核对的前提是你自己这边有一份可靠的基准账本。大多数团队对不上账不是厂商坑你而是自家日志压根没留下可用于比对的字段。我经历过的最惨情况是只记了发起时间、模型名和一句话文本连 token 都没落库出问题时只能承认没法追溯。2.1 最小字段集与为什么必须记我建议任何接了大模型接口的项目请求日志至少保留下面这个字段清单字段说明为什么必须有request_id厂商返回的唯一请求 ID账单明细里如果能带这个 ID它就是最高优先级的关联主键trace_id / conversation_id业务侧关联 ID用于把一个业务请求和多个底层调用关联model 全名实际传参的模型名包含版本后缀和区域排查价格差异开始时间/结束时间客户端发起和服务端完成的时间精确到毫秒排查跨月错位usage从响应体原样抽取的完整 usage 对象这是对账的最关键数据HTTP 状态码最终响应状态判断请求是否成功、是否需要计费error_type超时、熔断、限流等错误类别部分错误请求也可能产生费用需要单独归类重试次数该业务请求底层重试了几次判断是否出现重复计费区域/接入点base_url 或账号区域标识同模型不同区域价格可能不同这组字段看着多其实实现起来不复杂就是一个拦截器/中间件的事。很多框架在调用完大模型后都能顺手拿到 usage 字段关键是有没有意识把它存下来。存了这张表后面所有核对都有据可查不存一切只能靠猜。2.2 流式调用要按请求聚合不能一条条散记流式接口每次会推回来多个 chunk每个 chunk 里可能只有一小段增量内容。如果你在每个 chunk 到达时都写一条日志那同一个请求会变成几十条记录再算账的时候会把自己绕晕。我在生产环境里的做法是用一个以 request_id 为 key 的聚合器收集所有 chunk在流结束时从最终响应里取完整的 usage 字段整体写一条记录。如果流异常中断也要为这个 request_id 写一条不完整记录标记为stream_interrupted因为这部分请求是可能要计费的。2.3 时间统一到 UTC别让时区背锅这个说起来很基础但实操中翻车率极高。服务器时区设的是 UTC8数据库默认时区又是另一个厂商账单用的又是 UTC三个时间互相一映射就错位。我建议从源头约定所有日志时间一律存 UTC 时间戳展示时再转当地时区。对账脚本里也统一按 UTC 来过滤日期范围。比如要对3 月账单就过滤服务端计费时间 2025-03-01 00:00:00 UTC且 2025-04-01 00:00:00 UTC。千万别用本地时间的3 月 1 日 0 点去切否则会切进一批跨时区的异常数据。2.4 用厂商用量 API而不是控制台页面截图厂商控制台页面看到的数据通常是异步汇总的最早可能延迟数小时个别平台能延迟一天。如果你以页面上的实时数字为准那永远像在和一个影子打架。正确的做法是优先调用厂商提供的用量导出 API 或审计日志接口取到每日/每请求的明细把这些明细落库到一张vendor_usage表留作后续对账对厂商页面里的金额只用来做总量级抽查不能作为明细对账依据。有些厂商会提供按 request_id 维度的日志查询能力这是最理想的。如果只能拿到按天汇总的 token 量那就做总量级核对再做抽样请求级核对。3. 手把手对账从请求明细反推账单金额的完整流程基准建好了现在进入核心环节到底怎么一步步把自家日志和厂商账单对上。我按实际操作的顺序写每一步都是可以直接落到脚本里的。3.1 先确定主键和匹配策略对账要有一个唯一关联键。优先级从高到低建议这样排request_id直接匹配厂商账单明细里带这个 ID 的直接关联最理想。然后换成模型名 结束时间分钟级 token 总量组合匹配注意这只是一条绕回退策略存在误关联的可能需要人工抽查验证。若以上都无法实现就退化为按天/按模型聚合对比定位差异落在哪一天、哪个模型上再缩小范围排查。主键定了之后还要定钱怎么算。建议对账时不要直接拿金额比对而是先比对 token 量再用价格表换算金额。先比对 token 和价位更能精细地判断问题所在再加额外费用权重。3.2 用脚本把两边数据拉到一张表我一般用 Python 写一个轻量对账脚本读取两张表一张是我们自己的request_log一张是从厂商用量 API 拉下来的vendor_usage。核心逻辑就是 merge、比较、输出差异清单。下面是一个简化版的对账脚本思路可以直接参考import pandas as pd # 读取自家日志关键字段request_id, model, prompt_tokens, # completion_tokens, cache_read_tokens, cache_write_tokens, created_at local_df pd.read_csv(local_request_log.csv) # 读取厂商账单明细关键字段request_id, model, input_tokens, # output_tokens, cache_read_input_tokens, cache_write_input_tokens, cost vendor_df pd.read_csv(vendor_bill_detail.csv) # 先按 request_id 关联 merged pd.merge( vendor_df, local_df, onrequest_id, howouter, suffixes(_vendor, _local), indicatorTrue ) # 只有一边存在的记录 left_only merged[merged[_merge] left_only] # 厂商有我们没记 right_only merged[merged[_merge] right_only] # 我们记了厂商没有 # 两边都在的数据对比 token 量 common merged[merged[_merge] both] common[token_diff] ( common[prompt_tokens_vendor] common[completion_tokens_vendor] - common[prompt_tokens_local] - common[completion_tokens_local] ) # 输出摘要 print(厂商有而本地无记录条数:, len(left_only)) print(本地有而厂商无记录条数:, len(right_only)) print(token 总量差异中位数:, common[token_diff].median())注意一点request_id是假定两边都有此字段。如果厂商账单明细没有这个 ID就需要先把本地的组合键模型名时间token 量)在各种自身约束下先构造候选再关联逻辑复杂一些需要写样本比对来确定规则。3.3 差异分类账单多、日志多、对不上合并之后把差异归成以下几类每一类的排查方向都不同现象可能原因排查方向厂商账单数量多于本地日志重试、重复请求、厂商完成但客户端未记录找出厂商有而本地无的 request_id回查业务日志是否超时后自动重试本地日志多于厂商账单本地记录了调用但厂商未计费可能在免费额度内、请求被拒绝、缓存命中为 0 元对比响应状态码和免费额度规则token 量对得上但金额不对价格表过期、区域版本不同、费用计错用账单单价反向推算模型版本两边都有但 request_id 对不上客户端和服务端各自生成新 ID未正确传递关联检查网关是否重新生成 request_id这里的重点是这个心态差异不一定是被多扣费。有些差异是我们多记了有些是厂商和我们都对只是口径不同。先把每一类都清一遍再下结论。3.4 确认差异之后保留证据怎么和厂商沟通当你真的发现一批疑似多计费的请求准备找厂商之前建议做好三件事列出request_id清单最好附带起止时间、模型名、token 量格式整理成表格或 CSV把你本地日志里对应时间段的请求日志也导出一份证明这些 ID 在自己的记录里不存在或已标记为失败写清楚你的判断依据哪个字段、哪个时段、差异金额是多少。多数正规厂商都有账单申诉入口支持工单或者邮件提交。但根据我接触到的经验厂商的客服不一定能看懂技术细节。所以提交时不要只说账单金额不对而是明确说这批 request_id 在我的调用日志中不存在请提供审计日志或调用记录。有 request_id处理速度会快很多没有 request_id只凭日期和 token 量去对大部分厂商只会回复一句建议以后台数据为准。4. 五个让我踩过的差异场景和排查思路这一节我写几个真实发生过的场景不是理论推演每一个都消耗过我和团队大半天时间。你如果能提前知道这些坑对账效率会高很多。4.1 客户端超时重试一笔业务请求两次计费有一次我们发现账单里有个模型的调用次数是本地日志的一倍多。排查后发现某条链路的 SDK 开启了自动重试而重试策略很简单只要请求耗时超过 5 秒就重发。问题是第一次请求其实已经在服务端正常处理了只是响应回传得慢客户端超时后触发重发第二次调用也成功了。结果就是一个业务请求在厂商侧产生了两个 request_id两笔费用我们本地却只有一条业务日志。这种场景的排查要点是找出厂商有而本地无的 request_id然后看它们的时间戳是不是高度集中在某几个业务订单下尤其是网络波动时段。定位到之后要么在业务层面做幂等要么把重试策略改成基于最终响应 status 判断而不是只靠客户端超时时间。4.2 模型别名悄悄变了价格根本不一样某天对账发现一个模型的总金额比按官网价格算出来高了 15%。一开始以为是厂商出 bug后来翻配置才发现平台侧把旧模型下线新版本自动接管但新版本的输入价格比旧版本略高而我们代码里的model参数还写着一个通用别名。厂商账单里模型的 ID 和业务日志里的模型名并不完全一致价格自然对不上。这是最隐蔽的一类问题因为它不涉及漏记纯粹是单价字典不对。解决方式没有捷径每次对账前拉一次厂商最新的模型价格列表和本地价格配置表做 diff确认所有模型名都能在价格表里找到对应单价。找不到的模型名就应该触发告警而不是置为默认价格继续跑。4.3 缓存命中不是免费只是打折计费长对话场景一般都会启用 prompt 缓存。厂商宣传的是缓存命中费用低但很多团队直接理解成缓存命中免费于是本地只统计输入和输出 token不记录缓存相关 token。结果账单多出来一大块cache_read费用怎么都对不上。实际上缓存读通常按输入 token 的某个折扣价计费缓存写可能按一个相对低的单价计费不同模型规则不同而且不是所有模型都提供缓存。正确做法是把 usage 里的cache_read_tokens、cache_write_tokens单独落库并在价格配置表里为它们设置单独的单价。对账时把输入/输出/缓存读/缓存写四项各自比对不要只看 total。4.4 多模态和工具定义平白多出看不见的 token有一次核对图片理解模型费用时我们本地按用户上传图片的压缩大小估算 token以为一张图大概几百 token但账单显示出奇地高。后来仔细看 usage 才发现一张 1024x1024 的图会被切成若干个图像块每个块都要按 token 计算一张图几千 token 很正常。另外Function Calling 场景里每次请求都会把工具定义tool schemas序列化后放进输入如果工具定义写得很长这部分隐藏 token 比用户消息本身还多。这部分的教训是不要自己估算 token更不要按消息字数去猜。模型的 token 化规则里有太多非文本成分唯一的可靠来源就是响应体里的 usage 字段。而且如果你把日志只记录用户文本而不记录最终请求体中的完整 messages那无论如何也还原不了真实的 token 数。4.5 网络中断或前端取消服务端照样算钱有一次我们发现了十几条只有厂商才有记录、自己平台完全没有日志的调用。翻业务日志对应的请求全都是前端页面已取消或网关主动断开。问题在于客户端断连不代表服务端停止生成。对于流式输出部分平台的服务端会继续把剩余内容生成完并结算费用对于非流式请求如果响应已生成但回传时网络断了也一样会被计费。这种差异不是厂商乱计费而是我们产品设计里对取消的定义太乐观。排查时要接受一点凡是请求已经到达服务端并且进入模型执行阶段无论你客户端是否收到都可能产生费用。这个场景建议单独立项治理比如对长输出任务引入任务级取消 API而不是直接断开 HTTP 连接。5. 把核对变成日常习惯自动化对账与成本治理很多人对账是月初拉一次上月账单发现差异花好几天追溯然后该干嘛干嘛。这种月抛式核对效率极低因为差异跨的时间越长能回忆起来的细节就越少。我的建议是把核对周期压缩到按天执行并且用自动化脚本兜底。5.1 按日拉用量别等到月结才回头看几乎所有正规厂商都提供按日维度的用量查询接口或者至少支持按时间范围过滤的明细导出。让定时任务每天凌晨 2 点拉取前一天的用量数据和本地日志做一次自动比对。这样即使有问题间隔也不超过 24 小时回查日志时容易定位。如果你实在没有精力一开始就做完整自动对账至少做一个总量护栏每天把本地日志统计出的 token 总量和厂商用量 API 返回的前一日总量做一次差值计算差值超过阈值就推送告警。这个方案改动成本低但能第一时间发现系统性偏差。5.2 对账脚本的完整结构把账脚本分四层每一层都有独立的职责数据抽取层从本地数据库导出请求日志同时从厂商用量 API 拉取账单明细统一格式化成 DataFrame匹配层按 request_id 或组合键做关联生成_merge标记比较层逐项比较 token 类型、模型名、金额。token 差异、金额差异、单边记录都会被输出为三类文件通知层把差异摘要发送到团队协作群超过阈值的差异单独标记。这样的分层好处是任何一层变动不会影响其他层。厂商 API 字段改动时只需要改数据抽取层切换新模型时只需要改价格配置表。5.3 差异率阈值与告警怎么设置阈值设得太松差个 20% 都不管等于没设设得太紧每天被几十条边缘 case 打扰最后大家都不看了。我建议先跑两周的基线数据统计出正常情况下的差异率和波动范围然后取均值 2 倍标准差作为告警线。比如正常情况下差异率在 0.5% 上下浮动那可以把告警阈值设为 2%超过 2% 才触发人工介入。同时要把汇总级差异和明细级差异分开看待。汇总级差异触发告警说明整体可能有系统性变化明细级差异即使很小也应该记录下来因为它可能意味着某个特定模型或特定时间段的计费规则异常。5.4 对账发现的不只是账目问题最后说一点个人体会。把对账做扎实之后收益远不止把账单看清了。很多生产隐患也是在对账过程中暴露的看到缓存命中率异常低说明 prompt 前缀里混入了动态内容需要优化会话缓存设计发现大量超时重试说明网络链路或模型选型有问题需要调整超时参数发现工具调用的 token 占比过高说明函数定义写得过于啰嗦可以做精简发现某个模型用量突然上涨可能是线上某个业务把模型选型改错了。所以我把对账看作成本治理的第一道入口不只是财务对账。每一次对账都在回答一个更底层的问题我们的钱花在了哪里值不值得。如果你刚准备搭这套体系我给你的建议非常简单先不要追求一步到位做完整自动化。把上一节说的最小字段集落到日志里再用脚本手工跑上两三周把常见差异类型都见一遍你自然对哪里容易出问题有了手感。之后再逐步加上告警、价格表动态管理、按日自动对账。整体周期我从后台记录来看大约需要两到三周但之后再遇到账单问题就再也不用靠猜了。