docs(real-host): narrow completion blocker root causes
This commit is contained in:
phamnazage-jpg
@@ -12,6 +12,10 @@
|
||||
- 上游直探分流证明：
|
||||
- DeepSeek 上游 `/chat/completions` = `HTTP 200`，因此 host 侧 502 是真实兼容性问题，不是单纯 key 失效。
|
||||
- MiniMax 上游 `/chat/completions` = `HTTP 403 insufficient_user_quota`，因此当前验证 key 本身不具备真实 completion 流量能力。
|
||||
- 2026-05-21 进一步缩圈结果：
|
||||
- DeepSeek managed key 直打 fresh host `http://127.0.0.1:18097/v1/chat/completions` 仍稳定返回 `502`；但同一台 remote43 主机直接 `curl https://aitoken.quanfuli.cn/v1/chat/completions`（同一 upstream key、同一 payload）返回 `HTTP 200`，且 `Content-Type: text/event-stream`。
|
||||
- fresh-host app 日志显示 DeepSeek group `5` 当前挂了 10 个 active account（IDs `14,15,16,17,19,20,23,25,26,28`），chat 请求会在这些重复 account 之间 failover，全部记为 `account_upstream_error 500/502` 后才落成 gateway `502`。
|
||||
- MiniMax group `6` 当前挂了 6 个 active account（IDs `18,21,22,24,27,29`），`temp_unschedulable_reason` 都明确记录为 `insufficient_user_quota`；说明它的 completion 阻断已不是 CRM/host 路由问题，而是验证 key 配额不足。
|
||||
- 汇总证据：`artifacts/real-host-acceptance/20260521_064910_completion_smoke_calibration.md`
|
||||
- 调通细节与经验沉淀：`docs/REAL_HOST_ACCEPTANCE_LEARNINGS.md`
|
||||
- 代码门禁与本地运行态已于 2026-05-21 再次独立复跑：`gofmt -l .`、`go vet ./...`、`go test ./... -count=1`、`go test -race ./... -count=1`、`go test -cover ./internal/... -count=1`、`go test ./tests/integration/... -count=1` 全通过；本机 CRM(18100) 的 `GET /healthz` / 带 token 的 `GET /api/hosts` = `200`，另起 fresh smoke 实例 `127.0.0.1:18101` 也成功返回 `GET /healthz = ok`、`GET /api/hosts = {"hosts":[]}`。
|
||||
|
||||
@@ -12,6 +12,10 @@
|
||||
- 上游直探分流证明：
|
||||
- DeepSeek 上游 `/chat/completions` = `HTTP 200`，host 侧 502 属于真实兼容性问题。
|
||||
- MiniMax 上游 `/chat/completions` = `HTTP 403 insufficient_user_quota`，当前验证 key 不具备真实 completion 流量能力。
|
||||
- 2026-05-21 进一步缩圈结果：
|
||||
- DeepSeek managed key 直打 fresh host 仍稳定 `502`；但 remote43 主机上对同一 upstream key + 同一 payload 的直接 `curl` 返回 `HTTP 200`，且响应是 `Content-Type: text/event-stream`。这把阻断进一步收敛为“宿主 chat 上游兼容层”而非 CRM 导入失败。
|
||||
- fresh-host app 日志显示 DeepSeek subscription group `5` 当前挂了 10 个 active duplicate accounts，host chat 会在这些 account 间持续 failover，全部报 `account_upstream_error 500/502` 后才返回 gateway `502`。
|
||||
- MiniMax subscription group `6` 当前挂了 6 个 active duplicate accounts，但它们的 `temp_unschedulable_reason` 都已明确写成 `insufficient_user_quota`，因此该分支的主阻断仍是 key/quota，而不是 CRM 路由链路。
|
||||
- 汇总证据：`artifacts/real-host-acceptance/20260521_064910_completion_smoke_calibration.md`
|
||||
- 调通细节与经验沉淀：`docs/REAL_HOST_ACCEPTANCE_LEARNINGS.md`
|
||||
- 代码/本地运行态门禁已于 2026-05-21 再次独立复跑：`gofmt -l .`、`go vet ./...`、`go test ./... -count=1`、`go test -race ./... -count=1`、`go test -cover ./internal/... -count=1`、`go test ./tests/integration/... -count=1` 全通过；并额外验证了本机 CRM(18100) `GET /healthz` / `GET /api/hosts` = `200`，以及 fresh smoke 实例 `127.0.0.1:18101` 可启动并返回 `GET /healthz = ok`、`GET /api/hosts = {"hosts":[]}`。
|
||||
|
||||
@@ -207,11 +207,46 @@
|
||||
- channel 是否同时具备 `model_mapping + model_pricing + restrict_models + billing_model_source=channel_mapped`
|
||||
- 是否误打到了旧 CRM 进程
|
||||
|
||||
### 现象 C：`/v1/models` 已 200，但 `/v1/chat/completions` 返回 502
|
||||
### 现象 C：`/v1/models` 已 200，但 `/v1/chat/completions` 失败
|
||||
优先判断：
|
||||
- host 侧 provider 兼容性问题
|
||||
- 上游 provider key/quota 问题
|
||||
- 不要再把问题回退归因为 CRM 导入或 access closure
|
||||
- host provider 兼容性
|
||||
- 上游 key/quota
|
||||
- 不要先回退归因为 CRM 导入失败
|
||||
|
||||
### 进一步缩圈：DeepSeek `chat/completions` 当前更像宿主兼容层问题，而不是 key 失效
|
||||
|
||||
2026-05-21 新增的直接证据链：
|
||||
|
||||
1. managed key 直打 fresh host 仍稳定失败
|
||||
- `http://127.0.0.1:18097/v1/models` = `HTTP 200`
|
||||
- `http://127.0.0.1:18097/v1/chat/completions` = `HTTP 502`
|
||||
- 说明普通用户 / subscription / key / group 绑定链路不是这一步的主阻断
|
||||
|
||||
2. 同一台 remote43 主机直打 upstream 反而成功
|
||||
- 对 `https://aitoken.quanfuli.cn/v1/chat/completions`
|
||||
- 使用同一 upstream key、同一 `deepseek-v4-flash` payload
|
||||
- 返回 `HTTP 200`
|
||||
- 但响应 `Content-Type` 是 `text/event-stream`
|
||||
|
||||
3. fresh-host app 日志显示 host chat 会在一组重复 DeepSeek accounts 间 failover，全部记成 `account_upstream_error 500/502`
|
||||
- 当前 group `5` 里有 10 个 active DeepSeek accounts：`14,15,16,17,19,20,23,25,26,28`
|
||||
- 它们 `credentials.api_key/base_url/model_mapping` 相同
|
||||
- 请求并不是命中一个固定坏 account，而是在重复 account 集合中轮流失败
|
||||
|
||||
当前最合理的解释：
|
||||
- DeepSeek 这条 completion 阻断已经缩到“宿主 chat 上游兼容/解析层”
|
||||
- 不是 CRM 没把模型、channel、subscription、managed key 准备好
|
||||
- 重复 account 不是唯一根因，但会把一次失败放大成整组 failover 噪音，增加生产不稳定性
|
||||
|
||||
### 进一步缩圈：MiniMax 当前是 quota 阻断，不是 CRM 路由阻断
|
||||
|
||||
1. managed key 视角 `/v1/models` 已 200
|
||||
2. upstream 直探 `/chat/completions` = `403 insufficient_user_quota`
|
||||
3. fresh-host group `6` 内 6 个 active MiniMax accounts 的 `temp_unschedulable_reason` 都明确记录了 `insufficient_user_quota`
|
||||
|
||||
因此：
|
||||
- MiniMax 当前要解的是“换可用 key / 补额度”
|
||||
- 不应继续把它归因为 CRM import/access 逻辑失败
|
||||
|
||||
## 当前建议固化到后续文档/脚本的规则
|
||||
|
||||
|
||||
Reference in New Issue
Block a user