mirror of
https://gitcode.com/JianFeeeee/ModelRouter.git
synced 2026-11-07 09:47:23 +00:00
b57b442c0a
用户连续报「codeart 还是不可用 / empty stream」。把上游原始响应打出来逐条对齐，
三个症状同源，且都不是"模型坏了"：
| 场景 | 上游实际返回 |
|---|---|
| 流式、短时间连续请求 | HTTP **200** + 只带 error 的帧 ⇒ 内核判 `empty stream` |
| 非流式、同一条件 | HTTP 400 `TM.00001041: 并发会话数已达上限(3个)` |
| 突发请求 | HTTP 429 `TPM limit … 500000 tokens per minute` |
实测：最后一个请求结束后约 **44~60 秒**释放；同一账号连续请求 3~4 次即占满。
参考实现（示例插件 llm-adapter.ts）的做法是**每 10s 轮询后重试 chat**（最多 30
分钟），所以用户那边"看起来没事"。
## 我们的改法（内核只做通用机制，厂商知识留在插件）
1. **内核新增声明式重试策略** `source.retry`（纯数据：状态码列表 + 响应体子串 +
间隔 + 次数）。内核不认识任何厂商；命中即在同一网关请求内每 10s 重试一次。
流式只在**握手阶段**重试（首帧尚未下发，不会重复输出），非流式整体重试。
2. **插件为 codearts 声明**：400/429 + 命中 `TM.00001041` / `TPM limit` /
`并发会话数已达上限` → 10s × 最多 18 次（≈3 分钟）。
3. **适配器补两个会话细节**：`Connection: close`（keep-alive 空闲连接会被上游
计入并发会话）与稳定 `Session-Id`（同一账号恒定，避免每次请求新建会话）。
4. 错误文案补可行动提示（并发会话上限 / TPM 限流，约 1 分钟释放）。
## 验证（生产）
- 连续 6 次**流式**：6/6 成功（撞上限时自动等 10s 再试，客户端只感觉慢）：
`+0s / +12s / +34s / +86s / +100s / +144s`
- 连续 5 次**非流式**：5/5 成功（`+0 / +11 / +20 / +28 / +38s`）
- 修复前：第 4 个请求起必然 TM.00001041 / empty stream。
> 注：`TM.00001005 无正常可用套餐` 属于账号权益问题（不重试、如实报出），
> 与限流要分开处理。
(cherry picked from commit 6454b094bc)