Toonflow 主子账号的 API 用量怎么拆分统计，才能既对得上账单又能分到每个子账号？

Toonflow 主子账号的 API 用量拆分统计，靠的是在每次调用上带齐主账号、子账号、调用密钥三层标识，再按单次调用明细聚合；如果平台只发一个共享密钥、响应和账单都不返回子账号字段，任何拆分都只能算估算值，需要自建网关补打标才能得到可对账的数字。 拆分的本质是计量模型的设计，不是报表样式问题。一个能用的模型至少要回答四件事：谁调用（子账号）、调用了什么（模型或能力项）、用了多少（输入输出 token 或调用次数）、算给谁（成本中心或项目）。报表只是这四个维度做出来后的投影，维度缺一个，后面的分摊就一定会出现无法解释的差额。 动手之前先确认 Toonflow 的用量出口有几个。通常有三处：控制台的用量页面、账单或结算明细、单次 API 响应里的 usage 字段；控制台适合做月度校验，账单是最终对账依据，响应里的 usage 才能支撑实时统计和子账号自助查看。三处口径是否一致，决定了拆分结果能不能被财务接受。 如果 Toonflow 支持在主账号下创建子账号并各自签发独立密钥，这是最省事的路径。用量天然按密钥归属，聚合时按密钥分组即可得到子账号视图；但密钥与子账号必须一对一，多人共用一个密钥等于把拆分的粒度直接毁掉，事后只能按人头平均分，既不准确也难服众。 平台不给独立密钥时，可以在请求头或请求参数里透传子账号标识。这条路径改动小，但有两个前提：标识必须由服务端校验，不能完全信任客户端自报；聚合逻辑要为漏标请求预留一个未归属池，否则少量无标识调用会直接污染子账号的用量占比。 通用性最强的做法是在中间加一层 API 网关做拆分。子账号持有的是网关签发的虚拟密钥，网关校验通过后替换成主账号的上游密钥发出请求，同时为每次请求落一条明细：请求 ID、子账号、模型、输入 token、输出 token、状态码、耗时。上游只认主账号，成本分摊全部在网关这一层完成，平台侧是否支持子账号都不影响统计。 明细必须留存，不能只存日聚合结果。模型单价会调整，重试、缓存、流式中断都会改变单次调用的实际计费，只保留汇总值的话，一旦计费口径变化就无法重算历史数据。保留到调用级的粒度的另一个好处是，子账号质疑用量时能定位到具体是哪一次请求。 计费口径上有三处差异要提前定规矩。缓存命中的调用按实际计费部分记录，不能按全价算给子账号；失败请求记录尝试次数但不计入计费量，重试只记成功那次；流式输出中途断开的，按已经产生的 token 计。这三条不定清楚，子账号汇总和主账号账单之间必然出现无法解释的差额。 对账节奏建议日结加月结双轨。每天把主账号账单增量与子账号汇总增量比一次，月结时再做一次全量核对；差额不强行摊到子账号头上，而是挂进公共池，比如内部压测、监控探活、共享测试额度。差额超过自定阈值时回到明细逐条查，而不是在汇总层拍平。 配额和限流要和统计用同一套计量单位。统计按 token 算、限流按请求数算，两套口径会在月中对不上，子账号明明没超量却被限、或者超了却查不出来。可行的做法是配额以统计口径为准，限流作为保护手段单独设置，两者在子账号页面上分开展示，避免用户混淆。 权限和留存要一起设计。子账号只能看到自己的用量与明细，主账号看全量并能下钻到任意子账号；明细留存周期按财务和审计要求来定，导出给财务的应当是「用量乘单价」的成本表，而不是原始请求日志。日志里如果带有提示词内容，还要考虑脱敏，别把业务数据顺手带进对账文件。 几个常见坑值得提前避开：密钥轮换时不要切断历史归属，旧密钥的用量仍要映射回原子账号；账期时区要统一，跨时区团队按各自本地时间结算会出现一天的错位；测试账号要单独打标并从业务分摊中剔除，否则测试流量会被当成真实成本摊到各子账号。把这些边界先划清楚，Toonflow 的主子账号用量拆分才能既对得上账单，也经得起子账号逐个核对。