per-call-fee-math-for-hobbyists · ZH · 2026-10-11

一次调用到底花你多少 USDC：给业余开发者的单请求费用清单

很多刚接触 LLM API 聚合站的业余开发者，心里其实没底：发一次请求，到底从 USDC 余额里扣掉多少？这篇文章不给你固定价格表，而是教你一套可复用的心算方法：把输入和输出 token 拆开，各自乘上对应模型的单价，再统一乘以本站的 1.3 倍系数，就能得出自己那一笔请求的扣费。文中用一个假设的提示词例子（不引用任何真实价格），逐步演示六个模型（Claude、GPT、DeepSeek、Qwen、GLM、Kimi）的估算过程，并解释为什么输出 token 比输入 token 更贵、为什么便宜模型适合高频任务、以及如何用 API 返回的用量字段来验证你的估算。最后给出一张可打印的单请求费用检查清单，帮你养成先算再发的习惯。

你刚刚在聚合站充了一笔 USDC，想跑一个小工具，但每次调 API 心里都在打鼓：这一下会花掉多少？

好消息是：只要你知道 token 怎么数、官方价长什么样，再乘上本站固定的 1.3 倍系数，就能在几秒钟内估出一次请求花了多少 USDC。这篇教程会带你一步步手算，不依赖任何具体价格数字。

先搞清楚：一次请求扣的是“输入 + 输出”两笔钱

LLM API 的计费通常拆成两部分：

  • 输入 token（prompt tokens）：你发给模型的内容，包括系统提示、历史对话、用户问题。
  • 输出 token（completion tokens）：模型生成的内容。

两部分的单价往往不同，输出通常更贵。所以输入和输出必须分开算，不能直接拿总 token 数乘一个均价。

本站的计费规则：官方价 × 1.3

本站不另设一套价格。扣费逻辑是：

按各模型官方公布的价格计算输入和输出费用，然后整体乘以 1.3 的系数，从你的 USDC 余额中扣除。

如果你同时是 key 贡献者，你贡献的 key 被调用时，会按官方价 × 1.1（优质 key × 1.2）以 USDC 形式返还给你。这是两套独立的结算逻辑，不要混淆。

手算模板：四步走

不管用哪个模型，都按下面四步算：

  1. 数输入 token：把你的 prompt 交给 tokenizer，或者用模型自带的用量返回字段。
  2. 数输出 token：通常只能事后从 API 响应的 usage 里拿，事前只能估。
  3. 分别乘以单价：输入 token 数 × 输入单价 + 输出 token 数 × 输出单价。
  4. 乘以 1.3：得到本站实际扣费金额，单位是 USDC。

写成公式就是：

单次费用 = (输入token × 输入单价 + 输出token × 输出单价) × 1.3

举个虚构的例子，走一遍六个模型

假设你写了一个小脚本，提示词固定为一段约 500 token 的中文说明，外加一个 100 token 的问题。模型回答约 300 token。于是：

  • 输入 token = 600
  • 输出 token = 300

我们假设每个模型的官方单价（仅为演示，不代表真实价格）：

| 模型 | 输入单价（每百万 token） | 输出单价（每百万 token） |
| --- | --- | --- |
| Claude | A1 | B1 |
| GPT | A2 | B2 |
| DeepSeek | A3 | B3 |
| Qwen | A4 | B4 |
| GLM | A5 | B5 |
| Kimi | A6 | B6 |

那么每个模型的原始费用是：

  • Claude：(600 × A1 + 300 × B1) ÷ 1,000,000
  • GPT：(600 × A2 + 300 × B2) ÷ 1,000,000
  • DeepSeek：(600 × A3 + 300 × B3) ÷ 1,000,000
  • Qwen：(600 × A4 + 300 × B4) ÷ 1,000,000
  • GLM：(600 × A5 + 300 × B5) ÷ 1,000,000
  • Kimi：(600 × A6 + 300 × B6) ÷ 1,000,000

再各自乘以 1.3，就得到本站实际扣的 USDC。

你会发现，便宜模型的单项费用低得可以忽略，贵模型可能一次就吃掉几美分。这就是为什么“先用便宜模型跑通，再用贵模型兜底”是业余项目里很常见的策略。

为什么输出 token 更贵？

输出 token 是模型逐字生成的，计算过程更重，所以绝大多数厂商的输出单价都高于输入。对业余开发者来说有两个实际影响：

  • 让模型少说废话：在系统提示里要求“直接给答案，不要解释过程”，能显著减少输出 token。
  • 限制 max_tokens：设一个合理上限，防止模型跑飞，也防止余额被一次长回答吃掉。

用 API 返回值验证你的估算

不要只靠事前估算。每次请求的响应里通常会带 usage 字段，里面有 prompttokens 和 completiontokens。你可以：

  1. 把这两个数抄下来。
  2. 套用上面的公式，算一遍预期费用。
  3. 过一段时间看 USDC 余额变化，对比是否吻合。

如果差距很大，优先检查：是不是把输入输出单价弄反了，是不是漏乘了 1.3，或者历史对话被重复计入了输入。

常见坑：别把“总额”当成单次成本

  • 多轮对话会累积输入 token：每一轮都要把之前的对话再发一遍，输入会越滚越大。省钱的做法是定期摘要历史。
  • 流式输出不省 token：stream 只是传输方式，输出多少 token 还是扣多少。
  • 重复调用最烧钱：写循环时小心，一次调试失误可能连发几百次请求。

一张可打印的单请求费用检查清单

每次要跑新脚本前，问自己五个问题：

  1. 这次请求大概多少输入 token？
  2. 预期输出多少 token？上限设了吗？
  3. 用的是哪个模型？输入输出单价分别是多少？
  4. 有没有乘以 1.3？
  5. 跑多少次？总预算会不会超过本次充值？

养成这个习惯后，你会发现自己对 USDC 余额的掌控感强很多，也更容易在多个模型之间做出成本合理的选择。