同时不同模型执行不同任务会直接触发429错误

[losany]

版本[0.1.1-rc.2]

使用模型KIMI K3 / MINIMAX M3

使用任KIMI K3 执行任务 与 使用 MINIMAX M3 同时进行任务 两个任务同时报错429
任选一个执行在5次重试内会继续任务

[rootkiller6788]

先说你看到的"5 次重试"：dsh 默认的模型请求重试是 normal 模式、最多 5 次（退避 0.5s 起、封顶10s），RATE_LIMIT 属于可重试类。所以单个任务"5 次内能继续"=上游偶发限流、重试后恢复，属正常；会最终报 429 是 5 次都没挤进去。唯一会"秒失败"的情况：429 的 body 里带 quota / usage limit / balance / billing 这类字眼，会被判成额度耗尽、直接不重试。

然后是逻辑问题：K3 走 Kimi For Coding（api.kimi.com/coding），M3 走 MiniMax/MiniMax CN（api.minimaxi.com/io），这是两家不同厂商、配额完全独立，dsh 自己也不会生成 429 或给两个 provider 共享限流。所以"A 任务把 B 任务带崩"在代码上不成立——除非两条路由实际打到的是同一个上游，或者两边账号本来就各自在限流边缘（你单独跑也要重试才过，说明每条 key 余量已经很紧），一起跑只是让两边同时踩线。

两个信息能区分：

1. 这两条 provider 的 baseURL 和 key 是不是同一个。若 K3、M3 都是从某个网关/中转配的（指向同一域名、同一把聚合 key），那就是一个配额一起 429，完全吻合。
2. 429 响应原文。贴一下 body（有没有上面那些 quota/usage 字眼）和 Retry-After，以及是哪个域名返回的——判断是"限流太猛"还是"额度没了"。

想确认"并发 vs 跨厂商"，做个实验：同时开两个都用 Kimi K3 的任务。若也 429，就是这把 key 自己的并发/额度上限，跟 MiniMax 无关；那你的任务本就都在限流边缘，升 plan 或降单任务内并发才有余量。dsh 侧能调的只有每条路由的 retryPolicy（如把 maxRetries 调大多等几轮），减不了 429 的触发。

[losany]

感谢你的回答，之后我会做详细的对照试验