sub2api-overdraft

0 Fork 0

Files

T

shaw 56f3d3c9b0 fix(billing-probe): 收口探测资格放宽后的抑制清单与调度信任面

#4896 把上游计费探测从 OpenAI API-key 放宽到全部 API-key 账号后，
遗留了四处需要收口的问题：

- M1 官方域抑制清单补 ollama.com。Ollama Cloud 是本仓一等支持配置
  （platform openai/anthropic + type apikey + base_url
  https://ollama.com/v1），放宽后 anthropic 侧这类账号会每个探测周期
  拿 Ollama Key 请求 ollama.com/v1/sub2api/billing 并恒定落空，正是该
  守卫注释声明要防的行为。后缀匹配已覆盖 www.ollama.com 等子域，
  notollama.com 等形似域不受影响。
- M2 legacy 低倍率优先排序补平台门控。newOpenAILegacyUpstreamRateOrder
  遍历全部候选且无平台门控，与 openAIUpstreamCostFactors 的门控不对称；
  放宽后 grok 账号的上游自报倍率开始影响 legacy 调度排序，而实际结算走
  本地倍率，中转方自报低价即可吸流量。现补上同一道门控，使调度侧信任面
  回到 PR 前状态（探测资格的放宽保持不变）。
- L1 修正 IsUpstreamBillingProbeIdentity 注释。原注释称类型限制的依据是
  "OAuth/Bedrock 没有静态 API key"，但 AccountTypeUpstream（antigravity
  中转账号）同样是 base_url + 静态 api_key 却也被排除。仅改注释如实说明
  取舍，不改行为。
- L2 批量探测空选文案去掉 OpenAI 限定（en/zh 成对）。
- L3 unsupported 状态改用加长退避（interval 的 8 倍，仍按 24h 封顶）。
  放宽后大量官方域账号会落 unsupported 并按常规 interval 重排，占满每周期
  20 个名额，把真正接入 sub2api 的中转账号挤到后面。封顶保证上游后来接入时
  最迟一天内会被重新发现；Retry-After 更长时原样保留不被缩短；手动探测不受
  退避影响。

测试：ollama.com 官方域行为级与 host 匹配矩阵用例、legacy 排序平台门控
（含混合候选集）用例、unsupported 退避上下界与 runner 跳过/手动探测放行
用例；同步更新既有 unsupported 的 next_probe_at 断言。

2026-08-01 21:54:11 +08:00