按 key 还是按账号：如果真有量级折扣，它挂在哪一层

很多团队在评估 API 成本时，会下意识地把“每个 key 的用量”当成独立账单。但在聚合站这类架构里，key 只是访问凭证，真正的计费边界在账号这一层。理解这一点，能帮你算清轮换 key、多应用并行时，量级到底算在谁头上。

计费边界通常不在 key 上

API key 的设计目的是鉴权与隔离调用来源，而不是划分账单。一个账号可以签发多个 key，分别给不同应用、不同环境或不同同事使用。聚合站在计费时，会把同一个账号下所有 key 的调用汇总到该账号的余额里扣减。

这意味着：

• 你轮换 key 并不会重置或分割用量，只是换了一把钥匙开同一扇门。
• 你新建一个 key 给新应用，用的还是同一个账号余额。
• 想通过“多开 key”来制造多个独立量级，在账号层面并不成立。

为什么量级折扣挂在账号层

聚合站的成本结构是：它从上游拿到模型能力，再以官方价 ×1.3 向你扣费；如果你贡献自己的 key，则按官方价 ×1.1（优质 ×1.2）返 USDC。这里的“官方价”是锚点，倍率是固定的，不随 key 数量变化。

量级折扣如果存在，通常体现为账号维度的政策，而不是单 key 维度的自动累进。原因是：

• 结算对象是账号，余额、贡献记录、返利都记在账号上。
• key 可以随时增删，若折扣绑定 key，用户只需批量建 key 就能套利。
• 账号才是承担付款和收款的主体，风险与信用都集中在这里。

因此，判断“我有没有量级”时，应该看账号下所有 key 的合计消耗，而不是逐个 key 去看。

轮换 key 时，用量怎么算

如果你出于安全或运维需要定期轮换 key，用量不会因为换 key 而清零。例如：

1. 应用 A 使用 key1，应用 B 使用 key2，两者同属账号 X。
2. 月底统计时，账号 X 的消耗是 key1 与 key2 之和。
3. 你把 key1 作废、新建 key3 给应用 A，账号 X 的总消耗仍然连续累计。

也就是说，轮换只影响调用凭证的有效性，不影响计费归属。

多应用、多环境时该看哪个数

如果你同时跑多个应用，建议按以下顺序核对：

• 先确认这些 key 是否属于同一个账号。跨账号的用量不会合并。
• 再确认账号的计费规则：用户侧是官方价 ×1.3 扣费，贡献侧是 ×1.1/×1.2 返 USDC。
• 最后看账号维度的汇总消耗，而不是单个 key 的调用日志。

如果你的目标是让量级“算在一起”，那就把相关应用放在同一账号下；如果想让成本归属清晰，可以用账号隔离不同业务线，但代价是量级也会被拆开。

贡献 key 的返利边界

当你贡献自己的 key 时，返利同样记在账号上，按官方价 ×1.1（优质 ×1.2）返 USDC。这里要注意：

• 返利对象是贡献者账号，不是你贡献出去的那个 key 的使用者。
• 贡献 key 与使用 key 可以是不同账号，但各自的计费边界仍按账号划分。
• 无 KYC、USDC 充值这些特性改变的是结算方式，不改变“按账号汇总”的边界。

实操建议

• 把需要合并量级的应用放在同一账号下，避免人为拆散用量。
• 轮换 key 时保留账号不变，用量累计不会中断。
• 做成本预估时，用账号维度的总消耗乘以对应倍率（使用 ×1.3，贡献返 ×1.1/×1.2），而不是逐 key 计算。
• 如果需要给不同团队独立账单，再考虑拆账号，但要接受量级被拆分的结果。

一句话总结：key 是钥匙，账号才是账本。量级折扣如果存在，它挂在账号这一层，而不是你手上有多少把钥匙。