一把 key 调所有模型，也包括你的室友：多人共用同一聚合 key 时的调用混线问题

多人共用一把 API key 调多个模型，表面上看是省事，实际会带来调用日志混线、用量无法归因的问题。这篇文章说明混线是怎么发生的，以及如何判断一笔 USDC 消耗究竟是谁产生的。

混线是怎么发生的

聚合站的一个 key 可以调用 Claude、GPT、DeepSeek、Qwen、GLM、Kimi 等多个模型。当多个使用者同时用这个 key 发请求时，服务端看到的是同一个 key 下的一串请求，而不是多个独立账户。

每个请求有自己的 ID，但这些 ID 是按时间顺序交错出现的，并不天然带有“谁发的”标签。如果你在日志里看到一串请求 ID，只能知道它们属于这个 key，无法直接区分是室友 A 还是室友 B 发的。

为什么用量无法区分

计费是按 key 汇总的：这个 key 下所有请求的用量加在一起，乘以对应的价格系数（用户按官方价 ×1.3 扣费）。聚合站不会自动按人拆分用量，因为它不知道同一个 key 背后有几个人。

结果就是：月底看到一笔总消耗，却无法回答“这笔 USDC 是谁烧的”。如果只是两个人随便用用，可能无所谓；但如果需要分摊成本，或者想控制某个人的用量，混线就是硬伤。

判断 USDC 归属的几种做法

1. 用子 key 隔离

如果聚合站支持创建多个 key（子 key），最直接的做法是每人一个 key。每个 key 的用量独立统计，计费归属一目了然。即使共享同一个主账户余额，也能通过 key 维度区分消耗。

2. 在请求里加命名前缀

如果只能共用一把 key，可以在每次请求的 metadata 或 user 字段里带上使用者标识（比如 user: "roommate-a"）。很多 API 支持在请求头或 body 里传自定义字段，这些字段会出现在日志里，事后可以按标识过滤。

注意：这依赖聚合站是否透传这些字段到日志。使用前先确认日志里能看到你传的标识。

3. 用请求 ID 关联本地日志

每次调用后，客户端会收到响应里的请求 ID。让每个使用者在自己那边记录“请求 ID → 用途”的映射，事后用请求 ID 去聚合站日志里对账。这样即使日志混在一起，也能通过 ID 反查归属。

4. 按模型或时间段拆分

如果使用模式比较固定（比如一个人主要用 Claude，另一个人主要用 DeepSeek），可以按模型维度粗略拆分。但这种方法不精确，只适合粗估。

实操建议

• 优先用子 key，从源头隔离。
• 如果必须共用，统一约定在请求里带使用者标识，并确认日志可见。
• 定期导出日志，按标识或请求 ID 做对账。
• 对于贡献 key 返 USDC 的场景（按官方价 ×1.1 或 ×1.2 返），更要区分清楚每个贡献者的用量，避免返错。

混线问题不是聚合站特有的，任何多人共用凭证的系统都会遇到。关键是在使用前就想好归因方案，而不是等到月底对不上账再补救。