分组、流量与调度操作

流量管理的目标是：用户请求只进入正确的协议和价格池，单个账号故障时能切换，维护时能平滑摘流，并且切换不会造成错误计费。

调度前先过资格检查

账号不是“在 Group 里就一定会用”。候选通常还要满足：

Group 和账号平台兼容。
持久状态为 active，且 schedulable=true。
未到期、未临时不可调度。
未处于限流、过载或配额自动暂停窗口。
支持请求模型或模型映射。
满足 API Key/OAuth、privacy、客户端类型等规则。
有可用并发容量。

因此无可用账号时要检查完整候选链，不要只数数据库里有多少账号。

优先级与负载

实践上可以将账号分为：

层级	用途	配置思路
主池	稳定、成本可控	较高优先级，承接大部分流量
备用池	SLA 或价格次优	较低优先级，只在主池不足时使用
灰度池	新供应商/新凭证	独立 Group 或少量账号、低流量观察
隔离池	异常排查	不对普通用户授权

不要依赖极端并发值“强迫”流量走向。优先级、load factor、并发和账号状态共同影响结果，应一次只调整一个维度。

平滑摘流

维护单个账号时：

设置 schedulable=false。
在 Ops 并发视图观察该账号 in-use 下降。
等待长流式请求完成。
再修改凭证、代理或模型。
在测试 Group 验证。
恢复调度并观察切换率。

重启服务不会替代摘流；多实例环境还可能把流量立即送到其他副本。

粘性会话

粘性会话尽量让同一对话继续使用同一账号，减少上下文或上游缓存变化。运维时要知道：

Redis 异常会影响粘性绑定和运行时状态。
客户端需要提供稳定的会话 metadata；代理不能丢弃相关 Header。
账号限流、过载、停用时，系统会打破粘性并切换，这是正确行为。
underscores_in_headers off 可能导致 Nginx 丢弃 session_id 等头。

不要为了追求 100% 粘性而继续使用已经不可用的账号。

模型映射变更

模型有至少三个名字：requested model、upstream model、billing model。变更前回答：

用户请求的名字是否保持兼容？
上游真实支持哪个名字？
本地价格表应按哪个模型扣费？
fallback 后 billing model 是否仍正确？

变更流程：导出旧映射 → 测试 Group 修改 → /v1/models → 非流式/流式 → 检查 Usage Log → 灰度生产。

扩容账号池

先判断瓶颈类型：

account in-use 接近容量且 queue 增长：增加账号或合理提高并发。
上游 429 比例升高：提高本地并发通常会更糟，应增加独立额度来源。
TTFT 高但并发不满：检查上游、Proxy、模型或网络。
DB/Redis 等待升高：账号扩容无效，应处理基础设施。

总账号并发不是安全吞吐量。要以实测成功率、TTFT、429 和成本为准。

紧急切流

单供应商故障时：

确认影响范围和错误来源是 provider/upstream。
将故障账号批量设为不可调度，保留现场。
确认备用池模型和计费映射完整。
逐步提高备用池优先级或授权。
观察成功率、切换率、TTFT 和费用。
主供应商恢复后先灰度，不要一次性全量切回。

如果备用供应商价格更高，应同时通知业务方并记录成本影响。