LLM idle timeout (120s): no response from model 怎么解决

zhengzhijie2022

15:35:55 [agent/embedded] embedded run failover decision: runId=1faaaa-8a5a-4099-8e57-1e94118c8df0 stage=assistant decision=surface_error reason=timeout from=nvidia/qwen/qwen3.5-397b-a17b profile=sha256:354ea9687bc3 rawError=LLM idle timeout (120s): no response from model

怎么将timeout时间调大？

claw-newbie

我也遇到过类似的情况，当时排查下来是本地 ollama 的并发请求队列满了，后面的请求直接被挂起。可以试试调大 OLLAMA_MAX_LOADED_MODELS 或者把并发限制设低一点。另外如果是远程 API，看看是不是 provider 的 rate limit 触发了，有些服务商 120s 超时其实是变相拒绝。

script-yang

120s idle timeout 很多情况下不是模型本身的问题，而是中间网关或者反向代理的 keepalive 设置太短。我之前遇到过类似的情况，把 gateway 的 timeout 从 120 调到 300 之后基本没再复现。不过也得看模型服务商那边的限制，有的云函数层就有硬上限，改不了。

script-yang

这个 timeout 一般有两个地方可以调：

OpenClaw 配置里的 timeout 参数。如果你是在 openclaw 的 config 里配 Qwen，可以尝试在 provider 或模型配置块里加 timeout 字段，把默认 120s 往上调。具体路径通常是 models.<name>.timeout 或 llm.timeout（具体键名取决于你的配置文件版本）。
模型侧的负载问题。有时候 timeout 不是因为 120s 不够用，而是模型本身在高峰期排队或者推理卡住，这种情况下调大 timeout 并不会改善响应时间，只是让你等更久。

看你日志里用的是 nvidia/qwen/qwen3.5-397b-a17b，如果是通过 Ollama 起的，也可以去 Ollama 那边看看有没有并发数或超时限制。另外，如果能复现的话，建议查一下对应时间段 Ollama 的日志，确认是请求根本没发出去，还是模型推理 hang 住了。这两种情况的处理方式不一样。

model-tuner

补充一个排查角度：先确认到底是「模型真的没吐字」还是「中间层提前判定 idle」。你这条日志里 decision=surface_error reason=timeout，是 failover 逻辑主动 surface 出来的，不一定是模型卡死。可以先把 idle timeout 临时调到 300s 看会不会复现，如果调大之后正常出结果，那大概率是大模型首 token 延迟（397B 这种规模冷启动确实慢）；如果调大还是超时，再去查网关 keepalive 和 provider 侧限制。另外想问下你是本地起的还是走远程 endpoint？两种情况要查的地方不太一样。