pikasTech-unidesk/docs/MDTODO/details/sub2api-upstream-reliability/R2.2.11_Task_Report.md

R2.2.11 任务报告

范围与口径

• 只读复取 PK01 Sub2API 最近2小时所有分组，并以最近30分钟作为趋势对照。
• 请求分母、客户错误和上游错误以 Sub2API 原生 admin/ops 为主；system-log 缺失时才使用 target runtime 日志。
• 分组与账号数据在滚动窗口内持续变化，报告使用本轮最后一次完整分组快照；共享账号的 upstream cause 不跨组相加。
• 未发送探针，未修改 runtime、YAML、proxy、账号或调度配置。

所有分组概要

最近2小时初始总览：1391请求、37个客户错误，客户错误率2.66%；74个上游错误，上游错误率5.32%。滚动窗口下钻时请求数增长到约1403，但客户错误总数仍为37。

• unidesk-codex-pool：约763请求、26客户错误，错误率3.41%；上游错误率约7.86%。
• 自用：约640请求、11客户错误，错误率1.72%；上游错误率约2.19%。
• grok：0请求、0错误。
• 两个活跃组均无排队，查询时并发约9至10/218；没有证据把主因归为容量不足或需要降低并发。
• 账号29 https://api.lwylink.xyz pro 0.1 与账号30 https://api.lwylink.xyz plus 0.05 因余额不足403不可用；其余7个OpenAI账号当前可用。

最近30分钟对照：412请求、19客户错误，错误率4.61%；27个上游错误，上游错误率6.55%。其中：

• unidesk-codex-pool：251请求、17客户错误，错误率6.77%。
• 自用：160请求、2客户错误，错误率1.25%。
• 错误没有整体消退，而是更集中到 unidesk-codex-pool。

主因一：账号27的Responses兼容性400

账号27 https://sub.yjxm1221.top plus 0.025 是当前客户错误主因：

• 2小时：139次尝试、91成功、48失败，失败率34.53%，评分38/E；26个分组客户错误中占24个。
• 最近30分钟：48次尝试、30成功、18失败，失败率37.50%；17个客户错误全部来自账号27且全部是400。
• 2小时客户错误状态分布中400有21个，另有404、503、524；模型以 gpt-5.6-terra、gpt-5.6-luna、gpt-5.6-sol 为主。
• 代表请求 1f3fe800-a72a-4383-88ba-e7311abb8534 在630 ms内失败，原文为 Input must be a list。
• 代表请求 ee991d2f-08fe-4251-a509-c3d1a4bd8e45 先经历账号33的524和账号28的503，切到账号27后返回 Invalid 'input[213].id'，最终502。
• 另有 invalid_id_prefix 类流式 response.failed。这些更符合该上游对Responses长历史/input item格式的兼容缺陷，不是并发、网络或普通5xx不稳定。
• 通用400不能直接加入临时不可调度或failover，否则会把真实客户参数错误错误切号；若后续治理，应只针对已证实的精确兼容错误短语和未提交响应阶段处理。

主因二：长等待后504，切号已无时间窗

自用组11个客户错误全部是 gpt-5.6-sol：8个504、2个503、1个524，10个为流式。

• lyon9801 2小时109次尝试、100成功、9失败，失败率8.26%，评分75.2/C；8个客户错误，8次failover全部失败。
• 请求 02f0cc91-6f7f-4106-b902-49ee5260ed57 等待约29分31秒后才收到账号15的504；1 ms后选号因 context canceled 失败。
• 最近30分钟 lyon9801 已恢复为34/34成功、TTFT P95约7.8秒；窗口内2个客户错误均来自账号27，不是账号15。
• 当前 OpenAI response-header timeout 为disabled。长等待是客户影响放大器，但现有数据只有端到端耗时，不能断言全部时间都在等待响应头，也不能直接把观测下限当配置值。

上游隔离与切号效果

• 账号28 https://ai.whistlelads.com plus 0.03：2小时24次尝试全部触发失败，但有26次临时不可调度事件，分组客户错误为0；大量错误被换号吸收。最近30分钟7次失败中5次切号恢复、2次失败。
• 账号31 https://sub2.pokexiao.com plus 0.03：2小时215次尝试仅1次失败，评分93.1/A；最近30分钟126次中124成功，2次failover均恢复。
• 账号33 https://api.iceiu.com plus 0.03：2小时约3.6%失败，评分B；最近30分钟失败率升到14.55%，并有6次HTTP 200后forward failure，需要关注。
• 成功切号样本 4d305f0f-3e4f-4e0d-86d1-060a03820d22：账号32返回524、账号28返回503，约14秒后由账号27完成并最终HTTP 200，证明5xx failover链路能工作。

HTTP 200后的客户体验错误

• unidesk-codex-pool 2小时有12个、最近30分钟有6个 forwardFailureWithHttpSuccess。
• 自用 2小时有3个、最近30分钟有1个同类事件。
• 请求 e41f8745-e223-4fbf-9fb8-041a40c8ad94 最终HTTP 200，但约417秒后出现 stream data interval timeout，trace正确标记为degraded。
• 这类请求不会进入普通HTTP客户错误分子，因此37个客户错误不是全部体验损失；分组间存在共享账号证据，不能简单把所有forward failure相加成全局唯一请求数。

调优建议

1. 优先治理账号27的精确Responses兼容错误族，而不是降低全池并发：先按错误短语、请求阶段和模型统计；候选方案是对已证实的 Input must be a list、Invalid input[*].id、invalid_id_prefix 在响应未提交前触发failover或暂时避免把对应请求形态路由到该账号。是否需要Sub2API源码变更取决于现有精确classifier能否配置表达，不能用通用400规则替代。
2. 研究上游超时与客户deadline的预算关系：目标是让504或无响应在客户context取消前暴露并留出切号时间。缺少客户deadline和response-header阶段耗时前，不直接给出安全timeout数值。
3. 保留账号28现有短冷却策略；它已显著避免客户错误，不建议仅因上游失败率高而长期禁用。
4. 对账号33继续短窗口观察，重点看HTTP 200后 response.failed/stream timeout；这类错误无法在响应已提交后安全换号。
5. 账号29、30的余额不足属于静态不可用，应由账号所有者补充余额或退役；当前无排队，暂不构成容量事故。
6. 不因2小时旧错误降权 lyon9801；最近30分钟已恢复。若再次出现长等待504，按request ID同步抓trace和基础设施快照。