Toonflow 主子账号怎么拆分 API 用量，才能分别统计调用量、失败率和费用？

Toonflow 主子账号拆分 API 用量统计，准确做法是在 API 网关按主账号、子账号、API Key 和业务场景四个维度给每次调用打标，记录平台返回的 usage 与状态码，再按账期汇总到子账号账单。只靠客户端自估或所有子账号共用一个 Key，无法支撑内部结算与争议复核。 拆分统计的第一前提是子账号与 API Key 一一对应，而不是先共用 Key 再按调用方 IP 事后猜归属。主账号保留账单主体和充值能力，每个子账号在 Toonflow 侧生成独立 Key，或由网关签发代理 Key，并把映射关系写入账号表。Key 轮换时保留旧 Key 的历史归属，避免换 Key 后历史用量断档。 每次请求必须在入口写入可追溯的标签，否则日志只能看到 Key 而看不到成本中心。网关在转发前追加主账号 ID、子账号 ID、场景编码和请求唯一号，请求唯一号用于重试去重。这些标签随请求日志落库，不依赖客户端事后补报；客户端只传业务场景，不传可篡改的计费归属。 用量计量要按 Toonflow 返回的 usage 字段拆成输入、输出和总量，不能只用字符数估算 token。文本模型分别记录 prompt token、completion token 与 total token；图片、视频或工作流类接口按次、张数、时长或积分记录，计量单位与 Toonflow 账单保持一致。流式响应要在结束帧补记 usage，缺失时以平台账单回填，避免流式调用漏计。 主子账号拆分统计的核心产物是子账号日账单，而不是一张总调用量报表。日账单应包含调用次数、成功次数、失败次数、输入 token、输出 token、总 token、计量单位、预估费用和平台实际费用。主账号汇总所有子账号后再与 Toonflow 账单对账，差异按请求唯一号回查，不能把差额平均摊到各子账号。 失败与重试必须单独记账，否则子账号会把平台侧失败算进自己的成本。请求日志记录 HTTP 状态码、业务错误码和是否计费，重试请求复用同一请求唯一号，成功后才计入用量。Toonflow 是否对失败请求计费以其返回的 usage 和账单为准，内部报表不要把失败 token 直接并入成功消耗。 对账要按固定时区和固定账期做，跨时区或跨月调用最容易造成主账号与子账号数字不一致。统一使用北京时间自然日切分，账单日出后拉取 Toonflow 用量明细，与网关日志按请求唯一号和子账号汇总双向核对。对延迟上报、补扣和退款设置单独的调整流水，不直接改历史日账单。 权限隔离决定拆分统计能不能长期用下去，主账号应只给财务和平台管理员看全量账单，子账号只能看自己的 Key、用量和预算。子账号角色分为只读、开发者和管理员，导出报表带审计日志；主账号可查看子账号汇总但不能替子账号修改业务标签，避免归属被事后篡改。 预算和限额要落在网关层，不能只在报表里事后提醒。给每个子账号设置日限额、月限额和 80% 预警，达到限额后拒绝新请求或降级到低优先级队列；限额按 Toonflow 实际计费单位计算，不按调用次数一刀切，防止短文本高频调用绕过预算。限额变更留操作记录，便于月底解释超支。 共享 Key、客户端自估、模型别名变更和批处理漏记是四类常见失真来源。共享 Key 会让日志无法区分调用方，客户端自估会绕过平台 usage，模型别名变更会导致单价映射错位，异步批处理在任务完成时才返回用量；对应做法是强制一子账号一 Key、以平台 usage 为准、维护模型价格版本表、批处理任务单独记 task_id 并在完成回调中补账。 落地顺序应是先建账号与 Key 映射，再建网关打标和请求日志，然后做日汇总与平台对账，最后开放子账号查询和预算控制。前三步决定数据能不能用于结算，后两步决定能不能日常运营；如果 Toonflow 账号体系暂不支持多 Key，可用自建 API 网关代理并给每个子账号签发代理 Key，否则只能做估算，不适合对外结算。 这套方法适用于主账号统一付费、子账号按部门或项目内部核算的 Toonflow 使用场景，不适用于平台不允许拆分 Key 且无法获取 usage 明细的账户。边界在于平台账单是最终依据，网关日志用于解释差异；当两者不一致时先按请求唯一号定位漏记、重试和时区问题，再决定是否调整子账号账单。