读懂聚合站的用量与请求日志:把 USDC 花费按后端拆开

为什么要在日志层面拆花费

聚合站把 Claude、GPT、DeepSeek、Qwen、GLM、Kimi 放在同一个 API key 后面，调用语法一致，但每个后端的官方计价不同。只看账户总扣费，你只能知道“这个月花了多少 USDC”，却不知道钱花在哪个模型、哪类请求上。

请求日志（或每次响应的元数据）正好补上这一层：它记录了单次调用的后端标识、token 用量和计费信息。把这些字段拆开，就能不依赖任何后台报表，自己还原出“每个后端各花了多少”。

一条调用记录里的关键字段

不同站点的日志排版会有差异，但下面几类信息通常都会出现，读懂它们就能完成拆账。

1. 请求标识与时间

• 请求 ID：单次调用的唯一标识，用于和响应、账单条目对齐。
• 时间戳：区分计费周期，也方便把同一时间段的多次调用归到同一批。

2. 后端与模型标识

• 后端/渠道字段：标明这次请求实际落在哪个上游（Claude、GPT、DeepSeek 等）。同一个模型名可能对应不同后端或不同版本，这个字段是拆账的第一依据。
• 模型名：用于核对你在请求里指定的模型与实际处理是否一致。

3. usage 用量对象

多数 OpenAI 兼容接口会在响应里返回 usage，常见子字段：

• prompt_tokens：输入 token 数。
• completion_tokens：输出 token 数。
• total_tokens：两者之和（部分实现会省略，可自行相加）。
• 部分后端还会细分缓存命中、推理 token 等，按实际字段记录即可。

注意：usage 记录的是 token 数量，不是金额。金额需要结合各后端的官方单价换算。

4. 计费与扣费字段

如果日志里直接给出了扣费金额，通常以 USDC 计价。没有的话，用上一节的 token 数乘以对应后端的官方单价，再乘以聚合站的 ×1.3 系数，就是这次请求的扣费。这一步是整个拆账的核心。

5. 状态与错误信息

失败或重试的请求可能不产生计费，或按不同规则计费。日志里的状态码和错误信息决定这条记录要不要计入花费统计。

把单次调用折算成 USDC

对每条成功请求，按下面的顺序处理：

1. 从日志读取后端标识，确定它对应哪个上游的官方价目。
2. 读取 prompttokens 与 completiontokens（或对应字段）。
3. 分别乘以该后端的输入、输出官方单价，得到官方价口径的费用。
4. 乘以聚合站系数 1.3，得到你实际被扣的 USDC。

如果该后端对输入输出采用不同单价，就分开算再相加；如果日志已直接给出 USDC 扣费，可跳过 2–3 步，直接用该值校验。

按后端汇总：从日志到分账表

单次折算完成后，按后端分组求和即可。实操上可以这样做：

• 以请求 ID 为粒度导出一段时间的日志。
• 每条记录打上后端标签，并算出 USDC 金额。
• 按后端标签聚合，得到每个后端的调用次数、token 总量和 USDC 花费。
• 把各后端金额相加，与账户实际扣费总额比对。差异通常来自失败请求、重试或尚未结算的条目。

这样得到的表，就是“按后端拆开”的花费视图。

贡献 key 场景下的对账思路

如果你同时向站点贡献 key，返还按官方价 ×1.1（优质 key 为 ×1.2）以 USDC 结算，那么同一条日志可以看两个方向：

• 消费侧：按 ×1.3 计算你作为调用方付出的金额。
• 贡献侧：按 ×1.1 或 ×1.2 计算该后端流量对应的返还金额。

两者都建立在同一份 usage 和官方单价之上，差别只在系数。日志里的后端标识和 token 数越完整，双向对账就越容易。

常见坑

• 只看 total_tokens：输入输出单价不同时，用总量乘单一价格会算偏，尽量分开取。
• 忽略后端字段：同名模型在不同后端价格可能不同，按模型名而非后端归类会串账。
• 把失败请求计入：先按状态过滤，再汇总金额。
• 忘记系数：官方价口径和实际扣费相差一个 ×1.3，混用会让总额对不上。

小结

请求日志的价值不在于“记录了什么”，而在于你能用其中的后端标识、usage 字段和计费信息，把一笔总扣费还原成按后端分开的明细。掌握这套逐字段拆解的方法，多模型混用、USDC 充值、无 KYC 的日常使用就能做到成本透明、随时对账。