开源大模型推理服务接入 OneAPI 网关时，自定义渠道重试机制与超时设置的关键在于区分网关全局参数和渠道独立参数。OneAPI 通常会把超时、重试等行为暴露成两类配置：一类作用于所有渠道，另一类只作用于某个渠道。实际操作时，建议先确认当前版本支持哪些渠道级字段，再决定用环境变量还是渠道表单。不要只改全局超时，否则自建推理服务的长耗时请求会被过早掐断。

自定义重试与超时设置应先按渠道单独配置，再以网关全局参数作为兜底。超时设置应避免比模型实际最长推理时间短；重试次数要克制，只对可重试的错误（连接失败、5xx）生效，不能对超时无限重试。验证时用真实请求日志和上游日志核对触发条件，不要只看网关管理页面。

先分清全局参数和渠道参数

OneAPI 网关的请求生命周期里，超时和重试可能出现在两个位置：一是网关本身向上游发起请求时的超时；二是渠道调度层在某个渠道失败后切换到下一个渠道的重试。很多版本把“渠道失败重试次数”放在环境变量里，比如 RETRY_TIMES，把请求超时放在环境变量 REQUEST_TIMEOUT 或渠道自定义字段里。建议先查当前部署版本的环境变量列表，再决定配置方式。渠道级配置通常优先级更高，如果没有渠道级字段，才使用全局值。

超时设置：预留推理时间余量

自建开源模型推理服务的响应时间不稳定，尤其是长上下文或批量生成场景。设置超时时，先估算模型返回首 token 的最长时间和完整响应最长耗时。OneAPI 中的超时字段如果是秒，建议设为比该估算值多 1.5 到 2 倍，避免正常请求被误杀。比如一个 ChatGLM 类模型在长上下文下需要 60 秒，超时建议先设 120 秒。同时要看反向代理或负载均衡器是否还有一层超时，否则网关超时设置会失效。

配置示例：环境变量方式

# docker-compose 环境变量片段
RETRY_TIMES=2
REQUEST_TIMEOUT=120

这种设置对所有渠道生效。若只针对某个推理渠道，需要查看渠道表单里是否支持“超时时间”这类字段，支持就直接在渠道配置里填写，不写则沿用全局值。注意环境变量改动通常需要重启容器。

重试设置：只重试可恢复的错误

重试不是越多越好。开源推理服务一旦进入生成阶段，出现中断后重新调用会浪费算力，还可能导致重复计费或重复生成。建议把重试次数设为 1 到 2，并且只对连接超时、连接被拒、5xx 这类错误生效。如果网关本身在超时后没有区分错误类型，重试就可能把“请求太慢”当成普通失败再压一次上游，反而加剧拥塞。

可复制判断表

如果网关支持“状态码”或“错误类型”过滤，优先配置白名单。没有的话，就把重试次数调低，并在网关日志里核对重试原因。

验证清单：配置后这样确认

配置完成后，先跑一条正常请求确认可用，再模拟异常验证超时和重试逻辑。可以临时把上游地址写错，观察网关是否按预期重试；再把超时调成 1 秒，观察请求是否提前返回超时错误。每次修改配置后，检查网关 access log 和上游推理服务 access log 的时间戳，两者对齐才能确定超时值真的生效。

• 在渠道 A 配置较短超时，渠道 B 不配置，确认 A 的请求在预期时间返回超时
• 把上游服务关停，确认网关返回 502 前是否产生了重试
• 观察流式响应场景下超时是否按首 token 时间计算
• 检查 OneAPI 所在容器和上游服务所在容器的时间是否同步，避免日志错位

最后需要提醒：重试和超时是保护措施，不是性能优化手段。如果频繁触发重试，应当排查上游推理服务的稳定性或并发瓶颈，而不是继续加大重试次数。