供应商选路导读
默认负载均衡已经够用时，不要过度配置；需要显式选路时，也要先确认每个字段的影响。
provider selection 适合处理明确的业务约束。TheRouter 默认已经会做负载均衡和故障恢复， 只有当你确实有价格偏好、区域约束、BYOK 优先级、合规限制或供应商治理要求时，才值得显式加 `provider` 对象。
先确认是否真的需要显式选路
如果没有成本、合规、治理或稳定性方面的明确要求，先使用默认路由通常更合适。
最小可用形态
provider-fields.json
{
"provider": {
"order": ["openai", "anthropic"],
"allow_fallbacks": true,
"only": ["openai", "anthropic"],
"ignore": ["together"],
"quantizations": ["int8", "fp8"],
"sort": "latency"
}
}这些字段分别意味着什么
优先顺序
order
强制 provider 尝试顺序
allow_fallbacks
当前顺序失败后，是否继续尝试其他 provider什么时候值得显式配置
- 你要优先走 BYOK，再决定是否允许 shared fallback。
- 你所在区域、采购或合规要求限制了 provider 范围。
- 你要把特定高价值流量固定给某几家 provider。
- 你明确知道自己在优化延迟、价格或吞吐中的某一个。
最容易踩的坑
text
1. 一上来就写死 order，结果把默认负载均衡优势废掉
2. 配了 only 但忘了 allow_fallbacks，导致实际冗余很低
3. 把 provider selection 和 model fallback 混成一件事
4. 在没有真实业务约束时过度配置，最后自己都解释不清为什么这样选配置建议
如果你无法清楚说明为什么某类流量必须优先走特定 provider，通常不建议把 `order` 写死。 这样往往只会增加维护成本。