大模型 API 高可用：一把 Key 配多个分组，按优先级自动切换

同一个模型通常在好几个分组里都有，每个分组走一条独立的线路。做高可用，就是让一把 Key 同时挂上几个分组：在控制台把 Key 的分组方式设为「多个分组 · 自动切换」，按优先级排好最多 5 个分组，再打开「跨分组重试」。之后每次请求先用排在最前、提供该模型的分组；这个分组出错、重试也失败时，平台把同一个请求换到下一个分组继续尝试。每次请求按实际服务它的分组计价，具体是哪个分组，在操作日志里能查到。

切换规则

一次请求依次经过三步：

1. 选分组：按 Key 设置的顺序，找第一个提供这个模型的分组。排在前面的分组没有这个模型，就直接跳过。
2. 计价：按实际服务这次请求的分组计费，价格 = 模型标准价 × 该分组的倍率。
3. 出错重试：遇到可以重试的错误，平台先在同一个分组里重试 1 次。开启跨分组重试时，重试仍然失败就换到下一个分组，同样最多试 2 次，直到分组用完；没有开启时，错误直接返回给你。

不同情况下的结果：

同一分组内的重试走的还是这个分组的线路，能消化偶发的抖动；线路持续出问题时，要靠跨分组重试换到别的分组。

顺序怎么排

排在第一的分组会承担几乎全部流量，按你最看重的条件选它；后面的分组是备用，切过去的请求按后面分组的价格计费。先看清同一个模型在各个分组的价格：

三种常见排法：

各分组的标签和说明见选择分组；某个模型在哪些分组有，打开它在模型与价格里的详情页就能看到。

在控制台设置

1. 打开控制台「令牌」页，点「添加令牌」，或者编辑一把已有的 Key。
2. 在「令牌分组」里，把分组方式选成「多个分组 · 自动切换」。
3. 在「自动分组顺序」里添加分组，用上移、下移调整顺序，越靠前优先级越高，最多 5 个。分组旁边的 ×1、×0.8 是价格倍率，倍率越低越便宜。
4. 打开「跨分组重试」。
5. 给这把 Key 设额度上限；需要的话再设模型限制和 IP 白名单。
6. 保存。设置立即生效，调用代码不用改。

保存后，令牌列表里这把 Key 显示为「自动」，后面跟着编号的分组；鼠标移到上面，能看到跨分组重试是否开启。

确认请求走了哪个分组

• 「操作日志」：每条消费记录的「分组」一栏是实际服务这次请求的分组，不会显示成「自动」。按令牌名称和分组筛选，就能看到每个分组承担了多少请求、花了多少钱。
• 「数据看板」：「令牌与分组」一栏按令牌、分组和模型汇总消费，主分组和备用分组各占多少一目了然。
• 模型列表接口：用这把 Key 调用 GET /v1/models，返回的是它所有分组提供的模型的合集；开了模型限制时，只包含允许的模型。

上线前检查

1. 用这把 Key 调用模型列表接口，确认要用的模型都在。
2. 打开服务状态，看热门模型在各分组线路近 24 小时的成功率和延迟，作为排顺序的参考；其他模型在模型详情页的「可用性」标签里看。
3. 发一批真实请求，到操作日志里确认分组和扣费符合预期。

客户端还要做什么

平台的切换解决的是线路故障，客户端仍然要有自己的超时和重试：

• 超时别设得太短。平台在分组之间切换需要时间，客户端先超时放弃，平台的切换就白做了。
• 对 429 和 5xx 做退避重试，做法见错误码与重试。
• 流式请求开始输出之后中途断开，需要客户端自己判断和重发，见错误码与重试里「流式请求出错」一节。

什么时候改用多把 Key

多分组 Key 由平台按固定规则切换。下面这些情况，用两把不同分组的 Key、在代码里自己切换更合适，也可以两种方式叠加：

两把 Key 做故障切换的示例代码见如何选分组。团队里怎么按项目和环境分 Key，见团队和多个项目共用一个账号。