一条请求路径里的两把 key：聚合站何时走你的 BYOK、何时回落到平台 key

路由决策的触发点

当你向聚合站发送请求时，服务端会先解析请求中的模型标识（例如 claude-3-opus 或 gpt-4-turbo），然后根据当前可用的 key 池决定由哪一把 key 来实际调用上游供应商。这个决策过程对调用方透明，但理解其逻辑有助于你优化成本和排查问题。

何时走你的 BYOK key

聚合站优先使用你贡献的 BYOK key 来匹配请求，前提是：

• 该 key 所属的供应商与请求的模型一致（例如 Anthropic key 用于 Claude 模型）。
• 该 key 当前未被限流、未过期，且余额充足（针对按量计费的 key）。
• 平台配置中该 key 的权重允许被路由（通常默认启用）。

如果满足以上条件，请求会直接使用你的 key 调用上游，你也会因此获得按官方价 ×1.1（优质 ×1.2）的 USDC 返利。

何时回落到平台 key

以下几种情况聚合站会改用平台自有的 key（即其他用户贡献的 key 或平台储备）：

• 你的 key 无法服务该模型（例如你用 OpenAI key 请求 Claude）。
• 你的 key 触发了速率限制或配额不足。
• 上游返回错误（如 429、5xx），且故障转移策略允许切换。
• 你在请求中显式指定不使用 BYOK（部分聚合站支持此类参数）。

回落到平台 key 后，你仍然按官方价 ×1.3 付费，但调用能正常完成。

故障转移与重试逻辑

聚合站通常实现多级故障转移：

1. 首先尝试匹配用户 BYOK key。
2. 若失败，立即切换到同供应商的其他可用 key（包括平台 key 或其他用户的 key）。
3. 若同一供应商无可用 key，可能跨供应商切换（仅当模型兼容时，例如同一模型的不同部署）。
4. 每次重试会记录日志，但最终响应只返回一次成功结果。

注意：故障转移可能改变实际使用的 key，但不会改变计费模型——你仍然按 ×1.3 付费，贡献者仍按 ×1.1/×1.2 获得返利。

如何验证响应由哪把 key 提供

聚合站通常不会在响应体中直接暴露 key 标识，但你可以通过以下方式间接判断：

• 查看响应头：部分聚合站在 HTTP 响应头中返回 X-Provider-Key-Source 或类似字段，标明 byok 或 platform。
• 检查用量日志：在聚合站的控制台中，每次调用会记录实际使用的 key 来源。
• 对比返利记录：如果你的 BYOK key 被使用，返利记录中会出现对应条目；若长期无返利，可能请求都走了平台 key。
• 使用调试模式：某些聚合站提供 debug=true 参数，会在响应中附加路由信息。

实践建议

• 如果你希望最大化 BYOK 返利，确保贡献的 key 与常用模型匹配，并保持 key 健康。
• 在关键业务中，不要依赖单一 key；聚合站的故障转移正是为了提升可用性。
• 定期检查用量日志，了解你的请求实际由哪类 key 服务，以便调整贡献策略。

理解这条请求路径上的两把 key，能帮助你更有效地利用聚合站，同时控制成本。