Routing

Routing 在控制台里可视化配置。你可以把一条路由搭成 fallback chain：每一层可以是单个 backend、负载均衡池、条件分支，或另一个 model group。

Routing 控制什么

Fallback 顺序

当 Provider 失败、超时或达到阈值时，决定 ModelPlane 依次尝试哪些后端。

Load Balancing

把流量分配到多个兼容 backend，用于消耗 plan 容量或分散 Provider 压力。

Conditional Branching

按用户等级、工作负载类型、模型需求或产品 metadata 走不同路径。

Safety Triggers

根据错误、plan quota、预算或实时并发切换到下一层。

常见路由模式

Plan First

把 Coding Plan backend 放在第一层。再添加一个按量计费 backend 作为下一层，避免 plan quota 接近耗尽时影响用户。

Provider Resilience

先使用主 Provider，再添加备用 Provider，应对限流、服务不可用或超时。

Cost Control

把常规工作负载路由到低成本池，把高能力模型留给高价值或复杂任务。

Customer Tiering

用条件分支让付费用户使用更强模型，让免费用户使用高效默认模型。

基于并发的路由

机制说明： 任何 backend 都可以设置并发上限——网关同时会向它发出的最大在途请求数。一旦某个 backend 达到上限，网关会把它当作这次请求不可调度，直接切到下一层，处理方式和错误、超时一样。

使用方式： 给某个 backend 设置并发上限，然后在同一条 fallback 路由里，把一个有更多余量（或没有上限）的 backend 放在它后面。

使用场景： 你运行的基础设施里最贵的部分，往往是花钱买了但闲置的那部分容量——按峰值流量配置的私有集群或预留 endpoint，大部分时间都跑在远低于峰值的水平；而一旦真的超出它的实际上限，请求还是会先打到它上面排队、超时或体验下降，而不是溢出到还有余量的地方。自动扩缩容也解决不了这个问题：它是在流量已经涌入之后才反应过来，而排队或失败恰恰发生在这段滞后期。并发限制是按每个请求实时判断的，溢出决策是瞬间做出的，不需要"等一个新实例起来"。

基于 plan quota 或额度的 fallback，解决的是"这个账号额度用完了"的问题。并发限制解决的是另一种、和负载形态相关的问题，它带来两种此前不好实现的用法：

• 私有和公有算力混合使用。 把自建或私有部署的模型放在第一层，按它实际能承受的并发设上限。超出这个上限的流量会自动溢出到公有 Provider——不需要提前精确估算容量，也不需要在超出时手动分流，更不会为闲置的私有算力多付钱。
• 把 Coding Plan 用于生产环境。 Coding Plan 账号通常能承受的并发远低于按量计费的 API 账号。给 Coding Plan backend 设置并发上限，再搭配一个按量计费的 fallback，就能让这份 plan 容量在正常负载下承接真实的生产流量，一旦超出上限则平滑切换，而不是在 Provider 那一侧撞上不可预测的限流——这是仅靠 quota-based fallback 做不到的。

并发限制可以和本页其他能力组合使用：可以串联两层以上的 tier，每一层各自设置上限；可以搭配条件分支，让不同来源的流量获得不同的容量优先级；也可以搭配加权负载均衡——此时并发上限是硬性天花板，权重则是天花板之下的软性偏好。

发布前检查

保存路由后，打开 model group detail 页面。确认 fallback 标记、quota meter、费用、错误率和延迟都符合预期。