MG-03-003 调度重试与回退

状态说明：以当前有效边界为准。供应执行规则与历史实现证据保留；客户身份、售价、结算、全量旧跨仓契约及图像开放计划不代表当前验收范围。

1. 设计目标

调度必须同时满足：

能力正确；
用户内容错误不重复提交；
故障 Provider 能够快速隔离；
多个健康供给共同承接并发；
成本可估算、可限制；
选择和排除原因可解释；
精确供给全部不可用时可以按已批准规则降级出片。

2. 调度输入

每次选择使用冻结输入：

规范化请求
Public Model 与 Dispatch Policy
Supply Binding 和能力版本
Cost Rule Version
Channel Health 快照
Supply Health 快照
Channel/Supply Capacity 快照
本任务已经尝试过的 Supply
已经发生的 Provider 成本

3. 调度顺序

顺序固定，不使用综合权重：

检查用户、Key、客户组和 Public Model 权限；
验证公开模型参数与素材限制；
取得 exact Supply；
过滤 Channel/Supply 管理状态；
过滤视频或图像硬能力；
视频过滤真人素材政策；
真人请求存在 allowed 候选时，不让 restricted 候选进入同一排序层；
过滤 Channel/Supply 健康；
过滤剩余容量；
对每个候选计算当前请求 Quote；
应用成本护栏；
按策略字典序排序；
原子预占 Channel 与 Supply 容量；
保存选择快照和 Attempt；
事务结束后调用 Provider。

管理端必须把以上顺序压缩成可理解的四步说明：硬能力匹配、健康与容量、稳定性/成本策略、最多换一次 Supply。运营调整只影响后续 Attempt；在途 Attempt 保持创建时快照。图像和视频分别展示自己的硬能力步骤，视频额外展示真人政策，图像页面不出现该字段。

容量预占失败时，追加新的选择轮次，不能覆盖旧快照。

4. 稳定优先

stable_first 顺序：

健康状态：healthy 优先于 degraded；
统计置信度足够时，成功率更高；
预计成功成本更低；
可用容量更多；
稳定的 Supply ID 作为最终确定性排序。

为防止稳定优先无限提高成本，候选 Quote 不能超过正常成本基准乘 stable_cost_multiplier_limit。

用户明确要求恢复人工优先级实际选路，新增 manual_priority。SupplyBinding.priority 为 0–1000000 整数，旧绑定默认 0。先执行上述能力、健康、容量、成本护栏以及 exact/fallback/degraded 和真人策略层级，再按 priority 降序。同优先级沿用现有预计成功成本、健康、成功率、容量、Supply ID 确定性比较。 stable_first/cost_first 不读取人工优先级。高优先级不可用时才在可用候选中选取后续供给。不改变 BillingMode 的既有硬过滤：当前视频请求未填写 billing_mode 默认 per_second；按条请求需要显式 per_request。本次未实现 Token 执行计价、跨计费方式自动成本比较或试算界面。保存绑定/策略会清除模型 enabled/published；单独发布通过生产门禁后生效，快照保存候选 Priority。

多个 Supply 同时处理不同请求。调度器根据可用 Capacity Lease 自动铺满健康供给。

示例：

20 个排队视频任务
Supply A 可用容量 5
Supply B 可用容量 8
Supply C 可用容量 3

本轮最多并行分配 16 个任务，剩余 4 个等待容量释放事件。

默认禁止将同一个请求同时提交给多个 Provider。首版不实现 Hedged Request。

7. 错误分类

Provider Adapter 返回统一错误：

category    content / request / supply / capacity / unknown
scope       request / supply / channel
retryable   true / false
code
message

错误	分类	范围	是否换供给
内容审核拒绝	content	request	否
真人政策拒绝	content	request 或 supply policy evidence	默认否
参数或素材损坏	request	request	否
模型不存在	supply	supply	是
模型级 5xx	supply	supply	是
429/模型并发满	capacity	supply	是
API Key 失效	supply	channel	是
Provider 余额不足	supply	channel	是
DNS/TLS/连接故障	supply	channel	是
提交结果未知	unknown	attempt	禁止立即重提

普通内容审核拒绝不能降低 Channel 或 Supply 基础设施健康。

8. 重试

异步请求

max_attempts = 2：首次加一次换供给；
优先选择尚未尝试过的 Supply；
只有 supply 或 capacity 错误且 retryable=true 才能换供给；
创建时间超过 20 分钟后不再开始新 Attempt；
已经被 Provider 接受并正常处理的 Attempt 不受 20 分钟限制；
第二次失败后进入终态；
所有尝试和最终错误对管理员可见。

同步图像

不进入持久队列；
可以在同步请求总超时内透明换供给一次；
内容和请求错误不重试；
没有容量时立即返回 429 或 503 与 Retry-After；
总超时必须包含两次 Provider 调用，不能无限延长用户连接。

Submission Unknown

当 Provider POST 超时且无法确认是否受理：

Attempt 进入 submission_uncertain；
不释放为普通失败；
不自动提交到第二个 Provider；
使用 Provider 请求号、查询接口或人工对账；
到达对账期限仍未知时，以稳定错误结束并告警。

9. 健康与熔断

Channel 级

直接触发或快速升级：

401/403；
明确余额不足；
DNS/TLS/连接失败；
多个不同 Supply 同时出现相同基础设施错误。

Supply 级

模型不存在；
单模型 5xx；
单模型 429 或库存不足；
单一分辨率、能力版本或协议故障。

建议初始状态：

healthy
degraded
circuit_open
probing
recovering
disabled

熔断只阻止新 Attempt；已经取得 Provider Task ID 的 Attempt 继续查询原 Supply。

9.1 半开探测与渐进容量恢复

Channel 与 Supply 使用同一套确定性恢复状态机，但各自保存状态、恢复计数和事件，互不代替：

circuit_open 冷却到期后，由 Reconciler 原子进入 probing；
probing 的有效并发固定为 1，前 1 次成功仍保持 probing；
连续第 2 次成功进入 recovering，有效并发为配置值的 25%；
连续第 3 次成功时恢复为 50%；
连续第 4 次成功时恢复为 75%；
连续第 5 次成功才进入 healthy 并恢复完整配置并发。

25%/50%/75% 使用向上取整，但当配置并发大于 1 时，recovering 阶段始终至少保留一个未开放 Slot，避免提前恢复完整并发；配置并发为 1 时只能继续保持单并发。

probing 或 recovering 中任一具有 Channel 或 Supply 健康影响的基础设施失败，不再等待普通连续失败门槛，立即回到 circuit_open，清零恢复成功计数，并从失败时间重新计算完整冷却期。内容和请求错误的健康影响为 none，不会中断恢复计数或改变基础设施状态。熔断前已经在途的成功结果也不能绕过冷却并直接关闭熔断； disabled 不参与自动探测或恢复。

PostgreSQL 的 channel_health、supply_health 保存当前 recovery_successes；每次探测、阶梯成功、完整恢复和失败重开都追加不可变 health_events，事件快照包含对应恢复计数。图像和视频候选加载同一持久快照，并分别对 Channel/Supply 配置并发应用有效并发上限。

10. 精确、兜底与降级

执行层次：

exact：完整能力正常供给；
fallback：完整能力但只在 exact 不可用时使用；
degraded：需要请求变换的已验证供给。

正常阶段没有健康候选时才进入下一层。

933 到 900 示例

请求：seedance-2.0-933
素材：9 图 + 2 视频 + 1 音频

Exact/Fallback 933 全部不可用
Public Model 策略为 best_effort
存在已验证 900 Degradation Rule

变换：
  保留 9 张图片及顺序
  移除 reference_videos
  移除 reference_audios
  模型实际能力标记为 900

响应和使用记录必须包含：

{
  "degraded": true,
  "requested_profile": "933",
  "actual_profile": "900",
  "dropped_inputs": [
    "reference_videos",
    "reference_audios"
  ]
}

管理员收到“精确供给全部不可用”和“能力降级已启用”告警。

11. 降级安全

strict 请求永不降级；
best_effort 只能执行已发布的 Degradation Rule；
模型广场必须披露可能损失；
用户可以通过请求参数选择 strict；
请求变换必须保存前后快照；
不允许任意脚本；
降级仍需健康、容量和成本检查；
降级后仍无法满足目标 Supply 的硬能力时必须失败；
降级不会被伪装成精确生成。

12. 成本护栏

每次选择保存：

各候选 Quote；
正常成本基准；
已产生的 Attempt 成本；
兜底倍率和绝对上限；
实际选择原因。

固定区间价按照整条成本估算。例如 4–15 秒固定 6 元，5 秒请求成本仍为 6 元。

超过成本上限时：

默认不进入候选；
如果 Public Model 明确启用紧急可用性覆盖，可以进入，但必须产生高优先级告警；
紧急覆盖不等于忽略累计重试成本。

13. 容量恢复唤醒

单机 Compose 运行时不依赖进程内通知或 Redis Pub/Sub 作为正确性条件。Capacity Lease 释放后，Dispatcher 最迟在下一次一秒级持久队列扫描中重新认领到期任务；任务的 next_action_at 和重试截止时间仍以 PostgreSQL 为准。这样重启或通知丢失不会导致任务永久沉睡。相对通常约 400 秒的视频生成时间，最坏约一秒的重新调度延迟可接受；未来扩展为多机时再引入带持久 Outbox 的定向唤醒。