用本地模型报错: Body Timeout Error

[yuubo]

模型思考完开始工作后5分钟就会报错，用的标准模式

TypeError: terminated
    at Fetch.onAborted (node:internal/deps/undici/undici:13842:53)
    at Fetch.emit (node:events:509:28)
    at Fetch.terminate (node:internal/deps/undici/undici:12972:14)
    at Object.onError (node:internal/deps/undici/undici:13976:38)
    at Request.onError (node:internal/deps/undici/undici:3121:31)
    at Object.errorRequest (node:internal/deps/undici/undici:1942:17)
    at Socket.onHttpSocketClose (node:internal/deps/undici/undici:7860:14)
    at Socket.emit (node:events:521:24)
    at TCP.<anonymous> (node:net:355:12)
    at TCP.callbackTrampoline (node:internal/async_hooks:130:17)`
	
  name: "BodyTimeoutError",
  code: "UND_ERR_BODY_TIMEOUT",
  message: "Body Timeout Error",

配置中也加了超时相关的配置

ui-onboarding:
  welcomeNoticeVersion: 2026-08-13.1
agent-presets:
  default: minimal
llm-pi-ai:
  providers:
    ollama:
      displayName: ollama
      apiKeyEnv: OLLAMA_API_KEY
      api: openai-completions
      baseURL: http://127.0.0.1:11434/v1
      defaultInput: [ text, image ]
      timeoutMs: 3600000
      streamIdleTimeoutMs: 3600000
      websocketConnectTimeoutMs: 3600000
      retryPolicy:
        mode: normal
        maxRetries: 0
        backoff:
          initialDelayMs: 500
          maxDelayMs: 10000
          jitterRatio: 0.1
      models:
        - id: qwen3.8:27b-mtp-q4_K_M
        - id: qwen3.8:27b-q4_K_M
agent-default-model:
  provider: ollama
  model: qwen3.8:27b-mtp-q4_K_M
ui-conversation:
  busyEnter: steer

[PensiveFei]

结论先行：这不是模型的问题，也不是你配的 1 小时超时没生效的问题——这是 Node.js 底层 fetch 客户端（undici）的 bodyTimeout，默认就是 300 秒（5 分钟），到点就把连接掐了。你配置里的 timeoutMs: 3600000 大概率没有作用到真正发起 HTTP 请求的那条路径上，所以被默认值卡死在 5 分钟整。

为什么是 5 分钟：undici 的 bodyTimeout 默认 300000ms，和你的报错时间点精确对应。标准模式（非流式）下，模型思考期间响应体一个字节都不会返回，连接上长时间没有 body 数据流动 → 触发 body timeout。

分步排查：

1. 先确认超时配置到底有没有生效
   检查你本地 dsh 版本对应的 llm-pi-ai provider 配置文档，确认超时项的实际配置键名和生效路径（有的版本里超时是放在请求/HTTP 层，不是 provider 层；改配置后需要重启 dsh 进程/会话才会重新读取）。

2. 用 curl 直连 ollama 做基准测试，区分是客户端超时还是模型本身就慢

   curl -N --max-time 3600 http://127.0.0.1:11434/v1/chat/completions ^
     -H "Content-Type: application/json" ^
     -d "{\"model\":\"qwen3.8:27b-q4_K_M\",\"messages\":[{\"role\":\"user\",\"content\":\"你的测试问题\"}],\"stream\":true}"
   

   • 如果 curl 能等到首个 token 且整体在 5 分钟内完成 → 问题在 dsh 客户端这侧的 body timeout，去调大 undici/fetch 层的 bodyTimeout。
   • 如果 curl 也要等很久甚至断流 → 先解决 ollama 侧（减小上下文、换更小量化、调 keep_alive），再看 dsh。

3. 尽量走流式
   流式下超时按 streamIdleTimeoutMs（你已设 1 小时）判断，比非流式的整体 body 超时更能扛长思考。确认你的"标准模式"是否真的禁用了流式。

4. 快速验证根因
   临时把模型换成小量化/关闭思考（first token 早点返回），如果不再报错，就坐实了"响应整体耗时超过 bodyTimeout"这个根因。

请补充：dsh 版本（dsh --version）、llm-pi-ai 配置所在文件（全局还是工作区 cordis.yml）、以及第 2 步 curl 的实测耗时。

[yuubo]

谢谢，

1. dsh版本是0.1.1-rc.2。
2. cordis.yml是全局的，也没改过，工作区是空的没有文件。
3. curl大概10秒左右就开始有内容输出，非流的情况下20分钟左右。

[yuubo]

补充：

1. timeoutMs和streamIdleTimeoutMs配置确实是生效的，没有改这两个配置之前也会超时，但是报的是timeout之类的错误，我在deepseek-harness的官网文档里看到了这两个配置，就加在了settings文件里，改完后是重启过的，后面就开始报terminated.
2. 除了settings没有改过其他文件，"标准模式"感觉在模型开始写代码的时候就没有用流模式了，在思考的时候和回复消息的时候都是流模式。

[d3vmeh]

补充一个相关情况：如果是本地 llama.cpp --parallel 1，只要主 agent 和子 agent（或压缩）的请求重叠，第二个请求会被服务器静默挂起、不返回任何字节，Node 的 300 秒超时就会把它杀掉，streamIdleTimeoutMs 设多大都没用。我写了一个小插件，让请求在 DSH 内部排队、等槽位空闲再发出：#4995

(English: on --parallel 1, overlapping requests are deferred by the server with zero bytes back, so Node's 300 s timeout fires regardless of streamIdleTimeoutMs. dsh-llm-gate queues requests inside DSH until a slot is free.)

[yuubo]

插件很棒！
问题是写文件的时候才会有，是write.ts的问题，这个工具是要完整内容覆盖原文件的，所以AI一直在默默生成内容，没有给客户端消息，所以就超时了，dhs也没有bodyTimeout相关配置

[173787247]

[yuubo]

v0.1.2-alpha.1 依然有这个问题，我是在windows上部署的，用的ollama。主要是这个工具的问题：write.ts，文件写入必须一次性得到全部内容，然后覆盖文件，大模型一直在默默写代码，准备写完后调用write，奈何电脑配置低要写20分钟才能写完，但是dsh空闲5分钟后就中断了。
只要是写文件的任务不超过5分钟就没问题，超过就会中断。

[argszero]

Source-verified at cd5ef81481 (0.1.2-alpha.1) — two corrections/additions to the thread, one of which changes the fix recipe:

1. timeoutMs DOES reach the HTTP layer's doorway — the "doesn't apply" claim is wrong at the harness level.

The pi-ai adapter forwards it verbatim into the SDK stream options:

• packages/llm/llm-pi-ai/src/adapter.ts:127 — profileOptions() spreads ...profile.timeoutMs === undefined ? {} : { timeoutMs: profile.timeoutMs } into SimpleStreamOptions, and adapter.ts:349-350 reads the stream through the same profile.

So your timeoutMs: 3600000 is handed to @earendil-works/pi-ai@^0.84.2; the harness layer is not dropping it. Whether the SDK maps timeoutMs onto undici's bodyTimeout (or onto its own overall timer, or a connect timeout) is inside the third-party SDK — this repo contains zero bodyTimeout overrides (grep across the tree: no hits), so dsh relies entirely on the SDK's fetch mapping. If you're still hitting exactly 300 s, the SDK either doesn't map timeoutMs to bodyTimeout or maps it to a different knob — that's worth confirming against pi-ai's own docs, not against dsh config.

2. There's a SECOND, independent 5-minute killer the thread missed: the harness's own idle watchdog defaults to the same 300 000 ms.

• DEFAULT_STREAM_IDLE_TIMEOUT_MS = 300_000 in both adapters: packages/llm/llm-pi-ai/src/config.ts:43 and packages/llm/llm-deepseek/src/adapter.ts:138.
• It's a watchdog armed on every stream read (packages/util/timeout/src/index.ts:126-180 idleWatchdog): each iterator.next() arms a timer; zero bytes for streamIdleTimeoutMs → abort with LLM_STREAM_IDLE_TIMEOUT (adapter.ts:410 pi-ai / :477/:500 deepseek).
• Your config raised only timeoutMs — streamIdleTimeoutMs stays at its 5-minute default, so even after the undici layer is fixed, the harness itself kills a 5-minute silent thinking phase at the same 300 s.

Your stack shows undici's UND_ERR_BODY_TIMEOUT won the race this time, but the harness watchdog is the identical-duration next killer standing behind it. Both must be raised together:

llm-pi-ai:
  providers:
    ollama:
      ...
      timeoutMs: 3600000          # reaches the pi-ai SDK (adapter.ts:127)
      streamIdleTimeoutMs: 3600000  # harness idle watchdog (default 300_000; max 2_147_483_647 ms)

Note the watchdog also covers the --parallel 1 llama.cpp case d3vmeh raised: the deferred request returns zero bytes, so both the 300 s bodyTimeout and the 300 s harness watchdog fire — raising streamIdleTimeoutMs alone doesn't help there if the SDK still maps nothing to bodyTimeout; raising timeoutMs is the other half. (Their queueing-plugin route — #4995 — sidesteps both by not issuing the request until a slot is free.)

[yuubo]

你说的非常对，streamIdleTimeoutMs不配置不行，配置了也不行，要有bodyTimeout相关的配置才行，但是dsh忽略了。并不是所有大模型都能在5分钟内搞定任务。

[d3vmeh]

感谢反馈。你的情况和我的不同，原因也确认了：Ollama 在生成工具调用参数（write 的整个文件内容）期间不向客户端发送任何字节，也没有 keepalive，所以 Node 底层 undici 的 bodyTimeout（300 秒，dsh 没有对应配置）会先把连接掐掉；streamIdleTimeoutMs 调多大都没用。llama.cpp 之所以没有这个问题，是因为它每 30 秒发一次 SSE ping。

目前 dsh 侧没有配置能改 undici 的超时，只能通过 #3157 里的 node_modules 补丁。我可以做一个很小的插件，在进程启动时把 undici 的 headersTimeout/bodyTimeout 调大（影响整个 dsh 进程的 fetch，但对本地单用户部署基本无害）。如果你愿意试，我发布后在这里贴链接。

(English: Ollama sends nothing back, not even a keepalive, while it generates tool-call arguments, so Node's 300 s body timeout kills the connection before anything dsh controls. There's no dsh setting for that timeout; llama.cpp avoids the whole issue by sending a ping every 30 s. If it helps, I can put together a small plugin that raises those timeouts for the whole dsh process.)

[yuubo]

好的，感谢，我先看看补丁，当然有插件肯定更好了，肯定也会帮助其他遇到这个问题的人，向你致敬，向你学习！

[PerryLink]

注：本条评论原文因编码问题曾显示为乱码，已重建为可读版（2026-09-07）。

我遇到过同样的超时（在 bodyTimeout 场景，来自 dsh-local-ai 的排障）特别是长输出（如 write 场景）。Ollama 服务端默认 keepalive，undici 300 秒后断连，超时错误就是这么来的：

1. 调大 keep_alive 与 OLLAMA_NUM_PARALLEL（这点与 d3vmeh 的判断一致）；
2. 降低请求体积（输出分段或增量流式）；
3. 用 dsh-local-ai 的本地超时配置项，把「长输出不断连」做进默认值。

如果问题依旧，欢迎贴出 Ollama 日志与请求参数，我再帮你看。

[d3vmeh]

插件发布了：https://github.com/d3vmeh/dsh-fetch-timeouts

安装：

dsh plugin --profile web add dsh-fetch-timeouts

默认把 headersTimeout 和 bodyTimeout 都调到 30 分钟，可以在 profile 的 cordis.patch.yml 里改。记得同时把 ollama 路由上的 streamIdleTimeoutMs 和 timeoutMs 也调大，否则 dsh 自己的看门狗会先触发。它是全进程生效的（dsh 里所有 fetch 都会用更长的超时），在本地单人使用的机器上没问题；如果设置了 NODE_USE_ENV_PROXY，代理仍然有效。Windows 上我没有测过，试了之后欢迎反馈。

(English: published. Install with the line above; defaults to 30 minutes for both timeouts, configurable in your profile patch. Also raise streamIdleTimeoutMs and timeoutMs on the ollama route or dsh's own watchdog fires first. Process-wide, proxy env vars still honoured. Not tested on Windows yet, feedback welcome.)

[yuubo]

好的，感谢

[yuubo]

测试一个写文件任务，耗时20分钟，没有再出现超时的情况，非常棒！！！

[d3vmeh]

太好了，感谢测试！这也是这个插件第一次在 Windows + Ollama 上得到验证，我会在 README 里注明。后续有任何问题欢迎到仓库提 issue：https://github.com/d3vmeh/dsh-fetch-timeouts

[yuubo]

好的，非常感谢你的帮助，后面遇到相关问题给你提issue。

[d3vmeh]

@PerryLink 你的评论显示为乱码（中文都变成了问号），能重新发一下吗？从能看到的部分猜测你提到了 keep_alive、OLLAMA_NUM_PARALLEL 和在 dsh-local-ai 里处理长时间静默；很想看完整内容。另外 undici 超时的插件已经发了：https://github.com/d3vmeh/dsh-fetch-timeouts