Cherry Studio 多通道负载均衡怎么开启，开启后请求会按什么规则分流？

Cherry Studio 的多通道负载均衡要分两步开启：先在模型服务里准备多个同模型通道，再到 API 服务器或高级设置里启用轮询或故障转移；它只在同一模型有两个以上可用通道时生效，单通道和不同模型混用不适用。 只有当你同一个模型有多个 API Key、多个服务商账号或本地与云端双通道时，负载均衡才值得开启。它的作用是把请求分散到多个通道，降低单 Key 限流和单点故障的影响；如果只有一个通道，开启后只是多一层配置，不会提升速度。客户端对话和 API 服务器是两条路径，前者更多是手动切换模型，后者才适合做自动分流。 第一步是在设置里的模型服务中把同一模型的多个通道都添加为可用状态，并让模型名称、接口协议和上下文长度保持一致。每个通道都要单独填 API Key、Base URL 和可用模型，保存后先点测试，确认返回正常再进入下一步；名称不一致的通道即使填了同一个模型，也可能在路由时被当成另一个模型。 第二步是在 API 服务器或模型服务的高级设置中打开负载均衡或轮询开关，并选择轮询、加权轮询或故障转移策略。常见桌面版本没有名为“多通道负载均衡”的全局按钮，入口通常分散在 API 服务器的多 Key 配置和模型服务的高级项里；如果当前版本确实找不到开关，客户端对话只能靠助手绑定多个模型手动切换，不能等同于自动负载均衡。 策略选择要看通道是否同质：配额、速度、价格接近的通道用轮询最省心，配额差异大的用加权轮询，主备关系明确的用故障转移。不要把不同模型强行放进一个池，负载均衡按模型名和协议匹配，混放会导致请求被分到不支持的模型上，表现为 404 或参数错误；加权值也不要设成零，否则该通道等于被禁用。 开启后必须同时设置超时、重试次数、失败冷却和并发上限，否则一个慢通道会拖垮整个池。建议把单次请求超时设在业务可接受范围内，连续失败两次就临时摘除该通道，冷却后再放回；重试只对幂等请求生效，流式对话和工具调用要谨慎，避免一次请求在多个通道上重复计费。 验证方法是连续发起多次请求，查看 API 服务器日志、通道用量和返回耗时，而不是只看设置页的开关是否变绿。可以先用短提示词跑十到二十次，确认请求分布到不同 Key；再用一个失效 Key 测试故障转移，看是否自动切换到可用通道；最后检查流式输出是否完整，避免轮询导致连接中断。 开启后仍然只走一个通道，常见原因是模型名不一致、通道被禁用、权重设为零、API 服务器没有重启，或者客户端请求没有走本地 API 地址。排查时先看通道测试是否通过，再看日志里命中的是哪个通道，最后检查模型映射和路由规则，不要反复改负载均衡开关；每次改完配置都应重新发起验证请求。 需要会话粘性、长连接流式输出、工具调用强一致或严格按通道计费的场景，不宜直接开轮询。这类请求一旦中途换通道，可能出现上下文断裂、工具结果丢失或账单归因困难；更稳妥的做法是按会话绑定通道，或用故障转移而不是全程轮询，把负载均衡限定在无状态、可重试的请求上。 生产环境应把多通道负载均衡当成可用性策略，而不是免费扩容手段。每个通道都要有独立限额、健康检查和密钥轮换计划，日志里避免记录完整 Key 和用户原文；当所有通道都触发限流时，负载均衡不会创造额外配额，只会让失败更快暴露。成本核算也要按通道分别看，否则容易把分流后的账单误判成单一通道涨价。 把以上步骤压成一条操作线：准备同模型多通道、测试通道可用、在 API 服务器或高级设置启用轮询或故障转移、设置超时与冷却、用日志验证分布、再按业务边界决定是否长期开启。单通道用户、不同模型混用、强会话依赖场景不必开；只有多通道同质且请求可重试时，负载均衡才会带来稳定性和限流缓冲。