OPC/chorus
2
0
Fork 0
Code Issues 11 Pull Requests Actions Packages Projects Releases Wiki Activity

ops: 将图片生成超时调至 300 秒并受控复验 #58

New Issue
Closed
opened 2026-08-25 15:27:04 +08:00 by ila · 8 comments
ila commented 2026-08-25 15:27:04 +08:00
Owner
Copy Link
Copy Source

基本信息

  • 类型：本机 Provider 运维配置与受控验证
  • 所属 Epic：#3
  • 所属 MVP / 版本：#35 / MVP-2
  • 阶段：已完成
  • 关联工单：#54（真实 Provider 配置验证）、#56（Portal YAML 实现，已部署并待正式验收）
  • 并行说明：#56 的代码、部署和自动测试已完成；本工单只使用其已部署配置接口做本机运维值调整，不修改 #56 代码或代替人工验收。

原始需求

  • 来源：用户对话
  • 提出与确认时间：2026-08-25
  • 用户确认：按诊断建议建工单并执行，允许调整三层超时并进行一次真实图片生成验证。

目标

确认 gpt-image-2 在当前 Provider 上是否能在 300 秒内完成同步 OpenAI-compatible 图片生成，区分“超过 120 秒的正常/排队响应”和“网关持续挂起或协议不兼容”。

非目标

  • 不修改 Provider 协议、retryable、SSRF 或数据库结构。
  • 不重复提交图片任务，不继续把超时提高到 300 秒以上。
  • 不记录 API Key、生成响应正文、真实用户数据或图片到工单/Wiki。

已确认方案

  • 本机 portal/config/settings.yml：provider.http_timeout_seconds=300、worker.lease_seconds=360，端口和其他参数不变。
  • 管理端 ProviderModel gpt-image-2：timeout_ms=300000，其他字段不变。
  • 重启 Supervisor chorus-user 并确认 --config、登录页和进程稳定。
  • 等待既有 60 秒熔断窗口结束，只提交一次合成、低复杂度图片 Prompt；轮询现有 generation 状态，不重复提交。

风险与回退

  • 真实请求可能产生一次上游费用并占用 worker 最多 300 秒。
  • 回退为 YAML 恢复 120/150、模型恢复 120000，重启 Portal；不删除 generation/attempt 审计。

验收标准

  • YAML 和 ProviderModel 三层超时值正确，Portal 重启后可访问。
  • 仅创建一个新的真实 image generation，形成可审计终态。
  • 成功则核对存在受保护输出；失败则记录脱敏分类与准确耗时并停止。
  • 没有凭据、响应正文、生成图片或真实用户数据进入工单、Wiki、Git 和日志。

文档影响

本机 Provider 特定数值和一次验证结果只进入任务归档，无长期核心文档影响；Portal YAML 的通用规则已由 #56 记录。

## 基本信息 - 类型：本机 Provider 运维配置与受控验证 - 所属 Epic：#3 - 所属 MVP / 版本：#35 / MVP-2 - 阶段：已完成 - 关联工单：#54（真实 Provider 配置验证）、#56（Portal YAML 实现，已部署并待正式验收） - 并行说明：#56 的代码、部署和自动测试已完成；本工单只使用其已部署配置接口做本机运维值调整，不修改 #56 代码或代替人工验收。 ## 原始需求 - 来源：用户对话 - 提出与确认时间：2026-08-25 - 用户确认：按诊断建议建工单并执行，允许调整三层超时并进行一次真实图片生成验证。 ## 目标 确认 `gpt-image-2` 在当前 Provider 上是否能在 300 秒内完成同步 OpenAI-compatible 图片生成，区分“超过 120 秒的正常/排队响应”和“网关持续挂起或协议不兼容”。 ## 非目标 - 不修改 Provider 协议、retryable、SSRF 或数据库结构。 - 不重复提交图片任务，不继续把超时提高到 300 秒以上。 - 不记录 API Key、生成响应正文、真实用户数据或图片到工单/Wiki。 ## 已确认方案 - 本机 `portal/config/settings.yml`：`provider.http_timeout_seconds=300`、`worker.lease_seconds=360`，端口和其他参数不变。 - 管理端 ProviderModel `gpt-image-2`：`timeout_ms=300000`，其他字段不变。 - 重启 Supervisor `chorus-user` 并确认 `--config`、登录页和进程稳定。 - 等待既有 60 秒熔断窗口结束，只提交一次合成、低复杂度图片 Prompt；轮询现有 generation 状态，不重复提交。 ## 风险与回退 - 真实请求可能产生一次上游费用并占用 worker 最多 300 秒。 - 回退为 YAML 恢复 120/150、模型恢复 120000，重启 Portal；不删除 generation/attempt 审计。 ## 验收标准 - [x] YAML 和 ProviderModel 三层超时值正确，Portal 重启后可访问。 - [x] 仅创建一个新的真实 image generation，形成可审计终态。 - [x] 成功则核对存在受保护输出；失败则记录脱敏分类与准确耗时并停止。 - [x] 没有凭据、响应正文、生成图片或真实用户数据进入工单、Wiki、Git 和日志。 ## 文档影响 本机 Provider 特定数值和一次验证结果只进入任务归档，无长期核心文档影响；Portal YAML 的通用规则已由 #56 记录。
ila commented 2026-08-25 15:33:44 +08:00
Author
Owner
Copy Link
Copy Source

实施与验证结果（2026-08-25）

  • 本机 Portal YAML 已设为 Provider HTTP 300 秒、worker lease 360 秒；ProviderModel #4 已设为 300000 ms，其他模型配置保持不变。
  • 仅重启 chorus-user；进程确认携带 --config，Portal 登录页 HTTP 200。
  • 等待熔断恢复窗口后仅提交 1 个合成图片任务：generation #8，提交 HTTP 202，随后进入 running。
  • 终态：succeeded；数据库审计显示 1 次 Provider 调用，准确上游耗时 70331 ms，retryable=false；受保护输出数量 1。
  • 结论：此前失败根因是 45/120 秒超时低于该 Provider 本次约 70 秒的响应时间；模型、API Key、路由、队列和输出落库链路本次均正常。
  • 未执行第二次生成；未记录 API Key、上游响应正文、图片内容或真实用户数据。
  • 本工单只有忽略的本机配置和数据库运维值，无代码变更，因此不制造 Git 空提交。回退方式仍为恢复旧超时并重启 Portal。

阶段更新为：待验收。

## 实施与验证结果（2026-08-25） - 本机 Portal YAML 已设为 Provider HTTP 300 秒、worker lease 360 秒；ProviderModel #4 已设为 300000 ms，其他模型配置保持不变。 - 仅重启 `chorus-user`；进程确认携带 `--config`，Portal 登录页 HTTP 200。 - 等待熔断恢复窗口后仅提交 1 个合成图片任务：generation #8，提交 HTTP 202，随后进入 running。 - 终态：`succeeded`；数据库审计显示 1 次 Provider 调用，准确上游耗时 70331 ms，`retryable=false`；受保护输出数量 1。 - 结论：此前失败根因是 45/120 秒超时低于该 Provider 本次约 70 秒的响应时间；模型、API Key、路由、队列和输出落库链路本次均正常。 - 未执行第二次生成；未记录 API Key、上游响应正文、图片内容或真实用户数据。 - 本工单只有忽略的本机配置和数据库运维值，无代码变更，因此不制造 Git 空提交。回退方式仍为恢复旧超时并重启 Portal。 阶段更新为：待验收。
ila commented 2026-08-25 15:38:50 +08:00
Author
Owner
Copy Link
Copy Source

归档与一致性

  • Wiki 任务归档：Task-58-图片生成-300-秒受控复验
  • 在线回读 revision：e99ef4969f116029a76c5a9c8cb6733652538c8a
  • python dev_scripts/harness.py sync --check：通过，全部核心 Wiki 镜像一致。
  • 按流程未导出 docs/task/；需由用户明确提出才导出任务归档。
  • Git 工作区未新增本工单的受跟踪改动；现有 config/local-services.yml 和 admin/config/settings.yml 保持不处理。
## 归档与一致性 - Wiki 任务归档：`Task-58-图片生成-300-秒受控复验` - 在线回读 revision：`e99ef4969f116029a76c5a9c8cb6733652538c8a` - `python dev_scripts/harness.py sync --check`：通过，全部核心 Wiki 镜像一致。 - 按流程未导出 `docs/task/`；需由用户明确提出才导出任务归档。 - Git 工作区未新增本工单的受跟踪改动；现有 `config/local-services.yml` 和 `admin/config/settings.yml` 保持不处理。
ila commented 2026-08-25 15:58:11 +08:00
Author
Owner
Copy Link
Copy Source

重启后 generation #9 失败诊断（2026-08-25）

  • Portal 进程携带 --config，实际 YAML 仍为 Provider HTTP 300 秒、worker lease 360 秒；ProviderModel #4 仍为 300000 ms。
  • generation #9 使用与成功的 #8 相同的路由池、路由成员和 ProviderModel；Prompt 长度相近，模型 extra_body 为空。
  • #9 底层 Provider attempt 仅 1 次，latency_ms=300014、retryable=true、底层错误 upstream_timeout，无输出。
  • 路由池只有 1 个成员且 max_failover=0，所以超时后没有第二家可切换，生成最终错误被汇总为 route_unavailable；页面显示通用 upstream request failed。
  • 对比：#8 同一路由和模型在 70331 ms 成功。结论是当前 Provider 图片端点响应具有明显波动或偶发挂起，不是重启后超时配置丢失，也不符合模型不存在、凭据无效或内容策略拒绝的错误特征。
  • 本次只读取本机审计和配置，没有再次调用真实上游。建议不继续提高单请求超时；优先增加第二个独立图片 Provider/模型作为 failover，或与上游确认其 300 秒挂起原因。
## 重启后 generation #9 失败诊断（2026-08-25） - Portal 进程携带 `--config`，实际 YAML 仍为 Provider HTTP 300 秒、worker lease 360 秒；ProviderModel #4 仍为 300000 ms。 - generation #9 使用与成功的 #8 相同的路由池、路由成员和 ProviderModel；Prompt 长度相近，模型 `extra_body` 为空。 - #9 底层 Provider attempt 仅 1 次，`latency_ms=300014`、`retryable=true`、底层错误 `upstream_timeout`，无输出。 - 路由池只有 1 个成员且 `max_failover=0`，所以超时后没有第二家可切换，生成最终错误被汇总为 `route_unavailable`；页面显示通用 `upstream request failed`。 - 对比：#8 同一路由和模型在 70331 ms 成功。结论是当前 Provider 图片端点响应具有明显波动或偶发挂起，不是重启后超时配置丢失，也不符合模型不存在、凭据无效或内容策略拒绝的错误特征。 - 本次只读取本机审计和配置，没有再次调用真实上游。建议不继续提高单请求超时；优先增加第二个独立图片 Provider/模型作为 failover，或与上游确认其 300 秒挂起原因。
ila commented 2026-08-25 16:01:50 +08:00
Author
Owner
Copy Link
Copy Source

补充对比结论（2026-08-25）

  • generation #9 从创建到 Provider attempt 开始约 76 ms，300014 ms 基本全部消耗在上游 HTTP 阶段，不是 Chorus 队列、worker 认领或图片落库变慢。
  • Chorus 文生图请求固定调用 /v1/images/generations，JSON 字段为 model、prompt、n=1、response_format=b64_json；当前模型没有 size、quality 等 extra_body。
  • #8 成功输出约 0.82 MB，说明正常 Base64 响应体规模不至于解释额外 230 秒；#9 没有形成输出。
  • 本机可定位到的另一个 GPT Image 2 项目实际使用不同主机、/images/edits 图片编辑端点且默认 600 秒超时，不能作为同条件对照。本机未找到另一个使用当前主机和 /images/generations 的实现。
  • 同 URL/模型之外，API Key 对应上游租户、端点、Prompt、response_format、size/quality、代理和并发都可能改变耗时。现有安全审计没有 DNS/连接/TTFB/响应体分段，因此精确定位需要先增加不记录凭据或正文的 HTTP 阶段计时，再由用户授权一次同请求 A/B。
## 补充对比结论（2026-08-25） - generation #9 从创建到 Provider attempt 开始约 76 ms，300014 ms 基本全部消耗在上游 HTTP 阶段，不是 Chorus 队列、worker 认领或图片落库变慢。 - Chorus 文生图请求固定调用 `/v1/images/generations`，JSON 字段为 `model`、`prompt`、`n=1`、`response_format=b64_json`；当前模型没有 `size`、`quality` 等 extra_body。 - #8 成功输出约 0.82 MB，说明正常 Base64 响应体规模不至于解释额外 230 秒；#9 没有形成输出。 - 本机可定位到的另一个 GPT Image 2 项目实际使用不同主机、`/images/edits` 图片编辑端点且默认 600 秒超时，不能作为同条件对照。本机未找到另一个使用当前主机和 `/images/generations` 的实现。 - 同 URL/模型之外，API Key 对应上游租户、端点、Prompt、`response_format`、size/quality、代理和并发都可能改变耗时。现有安全审计没有 DNS/连接/TTFB/响应体分段，因此精确定位需要先增加不记录凭据或正文的 HTTP 阶段计时，再由用户授权一次同请求 A/B。
ila commented 2026-08-25 16:05:30 +08:00
Author
Owner
Copy Link
Copy Source

补充对照结论（2026-08-25，已按用户更正核对 D:\chengma\cmhub，未执行真实上游调用）：

  • cmhub 即使使用相同 Provider URL、模型名和凭据，也不代表请求协议与 Chorus 相同。
  • cmhub 的既定架构中，gpt-image-2 配置为 images_edits，调用 /v1/images/edits，使用 multipart 并要求原图；Chorus 当前任务调用 /v1/images/generations，JSON 请求且固定 response_format=b64_json。两者不是同一种生成请求。
  • 若 cmhub 中该配置实际仍为 api_type=auto 且 URL 仅到 /v1，其代码会将其解析为 chat 并调用 /v1/chat/completions，同样不会走 Chorus 当前的 images generations 路径。
  • cmhub 异步生图对 upstream_timeout/upstream_error 默认最多重试 2 次（最多 3 次调用，退避 10/30 秒）；Chorus 当前 route 只有一个成员且 max_failover=0，本次只调用一次。
  • cmhub 默认单次生图上游硬截止为 180 秒；Chorus 本次 Provider 模型超时为 300 秒。
  • Chorus generation #9 的排队延迟约 76ms，Provider attempt 精确持续约 300014ms 后报 upstream_timeout，因此不是本地队列或 Portal HTTP 超时导致，时间几乎全部消耗在上游响应等待。

结论：用户观察到 cmhub 多数 150 秒内成功，不能据此判断 Chorus 本地处理慢。当前首要差异是 API 类型/请求体，其次是重试和超时策略。由于本机无法连接 cmhub 当前数据库，尚不能只读确认其线上该模型的实际 api_type；后续诊断需先确认这一字段并对齐一次脱敏请求元数据，禁止记录 URL、密钥、prompt、图片或 Provider 原始响应。

补充对照结论（2026-08-25，已按用户更正核对 `D:\chengma\cmhub`，未执行真实上游调用）： - cmhub 即使使用相同 Provider URL、模型名和凭据，也不代表请求协议与 Chorus 相同。 - cmhub 的既定架构中，`gpt-image-2` 配置为 `images_edits`，调用 `/v1/images/edits`，使用 multipart 并要求原图；Chorus 当前任务调用 `/v1/images/generations`，JSON 请求且固定 `response_format=b64_json`。两者不是同一种生成请求。 - 若 cmhub 中该配置实际仍为 `api_type=auto` 且 URL 仅到 `/v1`，其代码会将其解析为 `chat` 并调用 `/v1/chat/completions`，同样不会走 Chorus 当前的 images generations 路径。 - cmhub 异步生图对 `upstream_timeout/upstream_error` 默认最多重试 2 次（最多 3 次调用，退避 10/30 秒）；Chorus 当前 route 只有一个成员且 `max_failover=0`，本次只调用一次。 - cmhub 默认单次生图上游硬截止为 180 秒；Chorus 本次 Provider 模型超时为 300 秒。 - Chorus generation #9 的排队延迟约 76ms，Provider attempt 精确持续约 300014ms 后报 `upstream_timeout`，因此不是本地队列或 Portal HTTP 超时导致，时间几乎全部消耗在上游响应等待。 结论：用户观察到 cmhub 多数 150 秒内成功，不能据此判断 Chorus 本地处理慢。当前首要差异是 API 类型/请求体，其次是重试和超时策略。由于本机无法连接 cmhub 当前数据库，尚不能只读确认其线上该模型的实际 `api_type`；后续诊断需先确认这一字段并对齐一次脱敏请求元数据，禁止记录 URL、密钥、prompt、图片或 Provider 原始响应。
ila commented 2026-08-25 16:06:59 +08:00
Author
Owner
Copy Link
Copy Source

用户于 2026-08-25 确认：cmhub 中该模型的实际 api_type=auto。结合配置使用的是仅到 /v1 的基础地址，cmhub 的 detect_api_type() 会将其解析为 chat，最终通过 ChatCompletionsProvider.generate_image() 调用 /v1/chat/completions。因此已确认 cmhub 与 Chorus 当前 /v1/images/generations + response_format=b64_json 的调用协议不同，这是两边耗时和成功率不可直接比较的首要原因。

用户于 2026-08-25 确认：cmhub 中该模型的实际 `api_type=auto`。结合配置使用的是仅到 `/v1` 的基础地址，cmhub 的 `detect_api_type()` 会将其解析为 `chat`，最终通过 `ChatCompletionsProvider.generate_image()` 调用 `/v1/chat/completions`。因此已确认 cmhub 与 Chorus 当前 `/v1/images/generations` + `response_format=b64_json` 的调用协议不同，这是两边耗时和成功率不可直接比较的首要原因。
ila commented 2026-08-25 16:07:58 +08:00
Author
Owner
Copy Link
Copy Source

更正上一条判断：用户确认 cmhub 的模型 URL 路径已经包含 /v1/images/edits（此处不记录具体主机）。因此 api_type=auto 会在 detect_api_type() 中优先解析为 images_edits，不会解析为 chat。

已确认的实际差异：

  • cmhub：POST /v1/images/edits，multipart，包含原图、prompt、model、n、size。
  • Chorus：POST /v1/images/generations，JSON，当前任务无原图，包含 model、prompt、n、response_format=b64_json。

因此 cmhub 多数 150 秒内成功与 Chorus 本次 300 秒超时并非同一种上游请求；首要诊断结论仍是协议/输入形态不一致，而不是 Chorus 本地排队慢。上一条关于 cmhub 实际走 chat/completions 的结论作废。

更正上一条判断：用户确认 cmhub 的模型 URL 路径已经包含 `/v1/images/edits`（此处不记录具体主机）。因此 `api_type=auto` 会在 `detect_api_type()` 中优先解析为 `images_edits`，不会解析为 `chat`。 已确认的实际差异： - cmhub：`POST /v1/images/edits`，multipart，包含原图、prompt、model、n、size。 - Chorus：`POST /v1/images/generations`，JSON，当前任务无原图，包含 model、prompt、n、`response_format=b64_json`。 因此 cmhub 多数 150 秒内成功与 Chorus 本次 300 秒超时并非同一种上游请求；首要诊断结论仍是协议/输入形态不一致，而不是 Chorus 本地排队慢。上一条关于 cmhub 实际走 `chat/completions` 的结论作废。
ila commented 2026-08-27 14:57:13 +08:00
Author
Owner
Copy Link
Copy Source

用户验收通过

  • 验收时间：2026-08-27 14:57:05 +08:00
  • 验收人：用户
  • 结论：用户明确确认本工单通过验收，接受当前实现、部署与已记录的验证结果。
  • 文档：沿用工单中已经完成的 Wiki/镜像处理；没有新的长期事实变化。
  • 状态：已完成，关闭工单。
## 用户验收通过 - 验收时间：2026-08-27 14:57:05 +08:00 - 验收人：用户 - 结论：用户明确确认本工单通过验收，接受当前实现、部署与已记录的验证结果。 - 文档：沿用工单中已经完成的 Wiki/镜像处理；没有新的长期事实变化。 - 状态：已完成，关闭工单。
ila closed this issue 2026-08-27 14:57:22 +08:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
admin ila
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: OPC/chorus#58