智谱 GLM-5.2 费用明细为什么有 4 条？3 次 API 请求与 10,880 Tokens 的完整对账

上一篇文章中，我记录了一篇 WordPress 历史文章在调用 GLM-5.2 整篇翻译时持续返回 HTTP 400，以及最终通过调整 Plaintext 保护策略、缩减模型 Payload 后成功完成翻译的过程。

最终文章 ID 4652 的执行结果为：

模式: execute
完整性: ok
selected_count: 1

- zh=4652 result=completed category=completed returncode=0 error=

模式: execute
完整性: ok
selected_count: 1

- zh=4652 result=completed category=completed returncode=0 error=

翻译终于成功以后，我原本只是想顺手确认一下 GLM-5.2 资源包究竟消耗了多少 Tokens。

没想到打开智谱开放平台的“费用明细”以后，又发现了一个很容易让人误解的问题：

这次翻译明明只有 3 次 GLM-5.2 API 请求，为什么费用明细里却出现了 4 条记录？

于是我又把服务器 Trace、智谱网页费用明细、导出的 Excel 和资源包余额全部对了一遍。

最后终于把这套费用明细的统计方式搞清楚了。

一、服务器 Trace 明确显示只有 3 次请求

在上一篇排查过程中，我已经通过服务器上的：

/tmp/swq-glm52-execution-trace.jsonl

记录 GLM-5.2 的真实请求情况。

4652 最终成功的这一次执行，对应三个翻译单元：

正文在大约 17:12:00 完成。

进一步统计 HTTP 请求事件：

grep -c '"event":"http_request_args_before"' \
    /tmp/swq-glm52-execution-trace.jsonl

grep -c '"event":"http_request_args_before"' \
    /tmp/swq-glm52-execution-trace.jsonl

结果为：

3

3

因此从我自己的程序执行日志来看，这件事没有什么歧义：

这一次完整的 WordPress 文章翻译实际调用了 3 次 GLM-5.2 API。

分别用于：

Title → Excerpt → Content

二、费用明细页面却出现了 4 条记录

然后我打开智谱开放平台：

费用账单 → 费用明细

筛选 2026 年 8 月的记录以后，在刚才这次 GLM-5.2 调用对应的时间段中，却看到了 4 条：

【glm-5.2】模型推理

其中：

乍一看，很容易理解成：

4 条费用记录 = 4 次 GLM-5.2 API 请求。

我最开始也是这样理解的。

但这和服务器 Trace 明确记录的 3 次请求对不上。

而且网页中的这些费用明细本身不能点击展开，所以没办法直接查看每一条到底消耗了多少输入和输出 Tokens。

好在右上角提供了“导出数据”。

于是我把费用明细导出成 Excel，继续往下查。

三、Excel 终于解释了这 4 条记录

导出的费用明细比网页展示的信息完整得多。

其中有几个字段尤其重要：

用量、用量单位、抵扣资源包名称、抵扣用量、消费时间、请求次数 (仅API)、价格类型

把本次 GLM-5.2 对应的 4 条记录单独整理出来以后，结果如下：

看到这里，问题基本就清楚了。

四、费用明细的一行，并不代表一次 API 请求

关键在两个字段：

请求次数 (仅API)

以及：

价格类型

先看第一组：

这里并不是两行各代表一次 API 请求。

实际上，这是同一组 2 次 API 请求分别产生了：

输入 Token 费用明细

和：

输出 Token 费用明细。

而服务器 Trace 中刚好有：

17:11:25 → Title

以及：

17:11:27 → Excerpt

也就是两次请求。

再看第二组：

这里对应的是：

Content

也就是正文那一次请求。

所以真正的请求数量是：

2 + 1 = 3 次 API 请求

而费用明细行数则是：

2 个时间段 × 输入/输出两种价格类型 = 4 条费用记录

这就和服务器 Trace 完全对上了。

五、为什么标题和摘要会被合并统计？

我的程序实际调用时间分别为：

17:11:25 → Title

17:11:27 → Excerpt

两次请求非常接近。

在智谱导出的费用明细中，它们没有分别形成独立的标题请求账单和摘要请求账单，而是统一进入：

17:11:00～17:12:00

这个消费时间范围。

所以导出的记录显示：

请求次数 (仅API) = 2

然后再分别统计这两次请求的输入 Tokens 和输出 Tokens。

这也意味着：

不能根据费用明细的“行数”反推 API 请求次数。

如果想知道实际有多少次请求，导出数据中的：

请求次数 (仅API)

才是更有意义的字段。

而如果像我这里一样程序本身还有 HTTP Trace，则可以进一步进行交叉验证。

六、这次翻译到底消耗了多少 Tokens？

既然已经拿到了 Excel，就顺便把这次完整翻译的 Token 消耗也算清楚。

标题和摘要所在的第一组：

输入：

910 Tokens

输出：

147 Tokens

合计：

1,057 Tokens

正文所在的第二组：

输入：

5,746 Tokens

输出：

4,077 Tokens

合计：

9,823 Tokens

最终整篇文章：

也就是说，这一次完整的 GLM-5.2 WordPress 文章翻译实际消耗：

10,880 Tokens

其中绝大多数都来自正文。

七、资源包余额又刚好对上了 10,880 Tokens

接下来再看资源包。

测试账号原本有一个：

【新用户专享】200万通用模型推理资源包

初始额度：

2,000,000 Tokens

这次文章完成以后，资源包页面显示：

1,989,120 Tokens

计算一下：

2,000,000 – 1,989,120 = 10,880 Tokens

和刚才 Excel 中 4 条 GLM-5.2 费用明细加总出来的数字：

10,880 Tokens

完全一致。

至此，服务器、费用账单和资源包三边的数据全部对上。

八、购买的 2000 万 GLM-5.2 资源包为什么一枚 Token 都没扣？

这个测试账号中实际上还有一个刚刚购买的：

GLM-5.2 特价尝鲜包

额度为：

20,000,000 Tokens

但在这次翻译完成以后，这个资源包仍然显示：

20,000,000 Tokens

一开始我还担心是不是购买的 GLM-5.2 资源包没有生效。

但 Excel 给出的答案很明确。

这 4 条 GLM-5.2 模型推理记录中的：

Tokens资源包名称

全部是：

【新用户专享】200万通用模型推理资源包

也就是说，这次实际命中的是新用户赠送的 200 万通用资源包。

智谱官方费用说明也明确表示，模型调用时会优先扣除符合适用场景的资源包，再扣现金余额；如果同时存在多个符合条件的资源包，则优先扣除更早过期的资源包。(大模型文档)

所以这一次 2000 万 GLM-5.2 付费包没有变化，并不意味着它没有生效。

只是当前存在另一个能够抵扣 GLM-5.2 的通用资源包，并且这次实际先使用了它。

九、“后付费”也不代表一定扣了现金

还有一个特别容易产生误解的地方。

网页费用明细里的：

付费类型

显示的是：

后付费

看到这里，很容易理解成：

这几次 GLM-5.2 调用没有走资源包，而是直接产生了后付费费用。

实际上并不是这样。

智谱对“后付费”的定义是：

模型推理属于先使用、后计费的产品类型；而资源包本身属于预付费产品。(大模型文档)

它描述的是产品计费模式，而不是在告诉我：

“这一次最终一定从现金余额扣钱。”

此次导出的 Excel 中：

付费类型 = 后付费

但同时又明确记录：

Tokens资源包名称 = 【新用户专享】200万通用模型推理资源包

抵扣用量 = 实际 Tokens

而：

总消费金额 = 0

应付金额 = 0

未付款金额 = 0

所以最终并没有产生现金费用。

以后看到：

后付费

不能单独凭这个字段判断到底有没有真正扣现金。

还需要结合：

抵扣资源包名称

抵扣用量

以及：

应付金额

一起判断。

十、如果没有资源包，这次大约需要多少钱？

Excel 同时记录了 GLM-5.2 的目录单价。

本次账单显示：

输入：

0.008 元 / 千 Tokens

输出：

0.028 元 / 千 Tokens

这次实际使用：

输入 6,656 Tokens

输出 4,224 Tokens

按照目录价格计算：

输入部分：

6.656 × 0.008 = 0.053248 元

输出部分：

4.224 × 0.028 = 0.118272 元

合计：

约 0.17152 元

也就是说，这篇相当长的历史文章在经过上一篇记录的 Plaintext Payload 优化以后，一次成功完整翻译按目录价格计算，大约只需要：

0.17 元

当然，这一次由于使用了赠送的通用资源包，最终实际支付：

0 元

十一、网页费用明细适合看趋势，Excel 更适合真正对账

经历这一次以后，我对智谱“费用明细”的理解也发生了一些变化。

网页非常适合快速查看：

模型名称、API Key、付费类型、消费时间范围。

但如果想回答：

“到底请求了几次？”

“输入和输出分别用了多少 Tokens？”

“具体扣了哪个资源包？”

“资源包抵扣了多少？”

仅看网页是不够的。

导出 Excel 以后，才真正能看到：

请求次数 (仅API)

价格类型

抵扣资源包名称

抵扣用量

这些非常关键的对账字段。

智谱官方文档也说明，费用账单明细会提供用于对账的字段，并区分账期、入账时间、模型产品和付费类型等信息。(大模型文档)

因此，如果以后再次遇到费用异常或者 Token 消耗对不上的情况，我会优先：

服务器调用日志 + 导出费用明细 + 资源包余额

三边一起核对。

十二、这次终于弄明白了 4 条记录和 3 次请求

回到最开始的问题：

为什么明明只有 3 次 GLM-5.2 API 请求，费用明细页面却出现了 4 条记录？

现在答案已经很明确。

服务器真实调用：

智谱计费：

所以：

3 次 API 请求 ≠ 3 条费用明细

而是：

3 次 API 请求 → 2 个计费时间范围 → 输入/输出分别统计 → 4 条费用明细

最终 Token 消耗：

10,880 Tokens

资源包变化：

2,000,000 → 1,989,120 Tokens

差额：

10,880 Tokens

四组数据最终完全一致。

这次看似只是为了弄清楚“为什么多了一条费用记录”，结果反而把智谱 GLM-5.2 从 API 请求、输入输出计费，到资源包抵扣的整个链路真正对了一遍。

以后再看到费用明细，我至少不会再简单地：

数一共有几行，然后认为就是调用了几次 API。