SGLang配合LiteLLM代理使用时的自定义供应商路由与请求超时设置

当SGLang作为推理服务、LiteLLM作为统一代理时，自定义供应商路由通常只需要修改LiteLLM的config.yaml，把对外模型名映射到SGLang的OpenAI兼容接口；请求超时则要同时考虑代理层、上游连接和推理时长三部分。下面按配置顺序、超时位置和验证步骤展开。

路由规则写在LiteLLM的model_list和router_settings中，指向SGLang的OpenAI兼容端点；超时值先给一个明显大于预期推理时长的数值，连通后根据日志调小。区分代理层读取超时、到上游的HTTP超时和SGLang推理时间。验证时用curl的`--max-time`作为客户端边界，同时看SGLang服务日志。若反复超时，优先排查模型排队和单次推理耗时，而不是无限增大超时值。

先分清两层路由与三层超时

LiteLLM在代理层根据模型名做路由，SGLang自身只暴露一个OpenAI兼容地址，不参与代理层的供应商选择。所以自定义路由的目标是让LiteLLM把特定请求转发到预先配置的SGLang服务端点上。超时则需要拆开看：第一层是LiteLLM处理请求的读取超时，第二层是LiteLLM到SGLang的HTTP往返超时，第三层是SGLang内部单次生成超时。三者的优先级是从用户侧向模型侧递减，哪一层先到点就会先断开。因此配置超时不能只改代理层，也要确认SGLang侧是否有自己的超时限制。

自定义供应商路由的配置骨架

在LiteLLM的config.yaml中，model_list定义对外可用的模型名和上游地址，router_settings定义路由策略。以下是一个能落地的通用骨架，具体字段名需要按你用的LiteLLM版本核对：

model_list:
  - model_name: sglang-a
    litellm_params:
      model: openai/sglang-server
      api_base: http://127.0.0.1:30000/v1
      api_key: dummy
      timeout: 300
  - model_name: sglang-b
    litellm_params:
      model: openai/sglang-server
      api_base: http://127.0.0.1:30001/v1
      api_key: dummy
      timeout: 300

router_settings:
  routing_strategy: simple-shuffle

这里的model_name是客户端调用时使用的名称；api_base指向SGLang的OpenAI兼容服务端口；timeout是LiteLLM等到上游响应的时间。routing_strategy可根据版本选择权重或随机策略。如果想做fallback，在router_settings里加fallbacks即可，但要以该版本的schema为准。保存后重启LiteLLM，用curl请求上述model_name，确认请求被转发到对应api_base。SGLang侧用python -m sglang.launch_server启动时不要忘了指定`--port`，和api_base保持一致。

超时设置的位置与优先级

超时配置可以出现在三个地方：

LiteLLM的litellm_params.timeout：代理等待上游返回的秒数。
客户端请求本身的超时：用户在调用LiteLLM时设置的读取超时，高于代理层。
SGLang启动参数：部分版本支持通过参数控制单请求超时或最大排队量，需结合具体版本确认。

如果代理层timeout小于客户端超时，客户端会先收到代理的504或408；如果代理层timeout大于SGLang内部超时，SGLang会先中断生成并返回错误，代理再把这个错误转发给用户。因此建议先给代理层timeout一个明显大于预期推理时长的值，比如60秒或300秒，再用真实请求测出耗时，逐步调小到合理范围。切忌在出现超时后只调大数值，要先看SGLang日志中的完成时间和错误码。

验证与排查清单

用curl可以快速验证代理层行为：

curl `--max-time` 30 \
  http://127.0.0.1:4000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"sglang-a","messages":[{"role":"user","content":"hello"}]}'

curl的`--max-time`参数是客户端硬超时，比代理层更早触发时看不出上游问题。建议把curl的`--max-time`设成代理层timeout的1.5倍，再配合SGLang日志判断。

先直接请求SGLang的/v1/chat/completions，确认推理服务本身能返回。
再通过LiteLLM请求同一模型名，比较两段耗时。
查看LiteLLM日志，确认请求被路由到哪个上游，以及是否出现connection timeout。
查看SGLang日志，确认请求是否到达，并记录实际生成耗时。
如果SGLang侧正常但代理超时，考虑增大litellm_params.timeout；如果SGLang侧本身就慢，应该从模型、batch配置或显存上解决，而不是一直调超时。