DSH连接llama.cpp的模型时候，总是出现断流的情况

[pangafu]

我发现dsh当前版本，llama.cpp的服务器运行的模型，会出现think->tool调用->(stream流断，重试)->think->tool调用->(stream流断，重试)的循环。

经过检查，确定是dsh的bug，因为我用trae和其他工具，使用这个模型都没有问题。

sseye-turn-1.json
sseye-T1-S1-c22.json
是两次出问题，我用sseye dump的dsh工作日志。检查完本地目录后，工具返回结果后，就卡住了，服务器端也没收到后面继续的请求。然后等待重试一次请求，又能接着跑一次 think->tool调用->断流重试。。

[pangafu]

花了5块钱，终于分析出问题了，似乎全网都没找到回答，.dsh\settings.yaml要做以下修改

localhost-2080ti:
  displayName: localhost-2080ti
  api: openai-completions
  baseURL: http://127.0.0.1:6080/v1
  models:
    - id: qwen27b
      contextWindow: 128000
      maxTokens: 32000
  apiKeyEnv: LOCALHOST_2080TI_API_KEY
  # llm-pi-ai reads these exact keys (Ms suffix). The old keys
  # (timeout / streamIdleTimeout / stream / defaultRequestOptions) were inert
  # and silently ignored, so the idle watchdog stayed at the 300000ms default.
  timeoutMs: 1200000
  streamIdleTimeoutMs: 1200000
  headers:
    # llama.cpp closes the TCP connection after every streamed response while
    # still advertising Keep-Alive. Reusing that pooled socket makes the next
    # request hang until the idle watchdog (then llm-retry re-issues). Forcing
    # Connection: close per request opens a fresh socket and stops the
    # think->tool->stall->retry loop.
    connection: close

重点

timeoutMs: 1200000              # 原 timeout 无效，改为 schema 认的键名
streamIdleTimeoutMs: 1200000    # 原 streamIdleTimeout 无效
headers:
  connection: close             # 关键：每次请求独立 TCP 连接，杜绝复用死 socket

结论摘要
问题不在模型也不在请求内容，而是 DSH 的 HTTP 连接管理与 llama.cpp 服务器的连接行为不匹配，叠加一个配置键名写错导致超时设置从未生效的问题。

根因

1. llama.cpp 服务器在每条流式响应结束后直接关闭 TCP 连接（实测：响应头写着 Keep-Alive: timeout=5, max=100，但下一个请求发到同一连接时服务器直接 socket closed）。

2. DSH（pi-ai → openai SDK v6 → Node undici 全局连接池）会复用 keep-alive 连接。于是：上一次流结束 → socket 被放回池 → 下次模型请求派发到已死的 socket → 服务器端根本没收到请求（与你的观察一致）→ 客户端空等 → pi-ai 空闲看门狗（默认 300000ms）触发 TIMEOUT → llm-retry 重试（此时旧 socket 被销毁、开新连接）→ 成功 → 下一步又复用新死连接 → 无限循环：think → 工具调用 → 卡 300s → 重试 → 成功 → 再卡。

3. 你原来设的 timeout / streamIdleTimeout（无 Ms 后缀）被静默忽略 —— dsh-llm-pi-ai 的 schema 认的是 timeoutMs / streamIdleTimeoutMs（见日志 idle timeout after 300000ms，正是默认值而非你设的 1200000）。Trae 等工具要么不复用连接、要么 Connection: close，所以没事。

[pangafu]

这个方案不是太优，最好还是直接改llama.cpp，参考下面的回答。

[wszhoho]

可以可以，我同事也碰到过，我自己这边正常，但是不敢迭代了，等正式版。

[pangafu]

看起来应该是llama.cpp的问题，整体过了一遍两边的代码：

我把结论和证据整理给你。先看我们这次实测的关键对照：

场景（同一连接连发 2 个请求）	结果
非流式 → 非流式	✅ req2 正常返回（连接真的能复用）
流式 → 非流式	❌ req2 挂死（90s 无响应）
流式 → 流式	❌ req2 挂死

并且两种响应都带 Keep-Alive: timeout=5, max=100、都没有 Connection: close（HTTP/1.1 下这等于承诺 keep-alive）。

直接回答你的三个问题

1. 是设计如此吗？——不是「设计成每次都关」，更像一个实现缺陷（连接状态机没被正确回收）。

依据：

• 非流式路径在同一连接上连续两次都成功，说明 llama.cpp 服务器本身是支持 HTTP/1.1 keep-alive 的；
• 只有流式（SSE/text/event-stream）响应结束后，该连接才不可复用——表现还不稳定：有时服务器立刻关 socket（我第一版探测见过 server closed socket），有时连接既不关也不响应，处于“半死”状态（这次严谨版探测是 90s 超时、无数据也无 close）。
• llama.cpp 官方 issue 里也有同类记录：#17388 llama-server keepalive header corruption（keepalive 处理不当、连接在错误/结束场景没被正确关闭/回收）和 #19758 Reverse port not properly closed after SSE stream（SSE 流结束后连接资源没有正确收尾）。这属于社区承认的 bug 类问题，而不是“有意每次断开”。
• 你跑的版本很新：build_info: b10816-427291b5b，对应 llama.cpp commit 427291b5b（2026-09-04 的 master 附近），所以这不是老版本遗留问题，现版仍存在。

2. 有开关吗？——服务器侧没有。

我翻了当前 master 的 tools/server（README.md 全部参数表、server-http.cpp 的连接处理）：只有 --timeout（读写超时，默认 3600s）、sse_ping_interval（流期间防客户端超时的 ping）等参数，没有任何选项能控制“SSE 流结束后该连接是否可复用/是否关闭”。SSE 通道的连接生命周期由服务器内部管理，没暴露开关。流式响应由 httplib 的 chunked content provider 驱动（server-http.cpp 里 res.set_chunked_content_provider(...)），结束后连接不归还给可复用池——正是缺陷所在。

3. 为什么看起来“每次都关”？

因为 SSE（text/event-stream）响应在 HTTP/1.1 下没有 Content-Length、只能走 chunked，这类“推完即走”的通道在许多实现里就是一次性连接；llama.cpp 在流结束后没有把底层 socket 正确置回 keep-alive 状态，等于对遵守 HTTP/1.1 语义的客户端（会按 Keep-Alive 头去复用连接的 DSH/undici、httpx 连接池等）埋雷——第三方也踩到过同样的坑：hermes-agent #82805：pooled httpx client reuses connection the server closed after SSE → 偶发 400/空响应。你的 DSH 里 undici 复用死连接 → 服务器端收不到请求 → 客户端空等到 300s 空闲看门狗 → 重试 → 循环，就是这个机制。

结论与建议

• 这不是你能在 llama.cpp 侧“拨个开关”解决的；它是服务器端缺陷，正确规避点是客户端不要复用流式响应后的连接——即我们已做的 headers: { connection: close }（每次请求独立连接），或者像 Trae 那样连接策略不同。
• 若服务器是你自建可改的：可给 llama.cpp 前加一层反向代理（nginx/caddy 管理上游连接），或在 llama.cpp 仓库跟进 #17388 类修复并升级。
• 服务器端可确认的启动参数 --timeout 只影响读写超时，不影响该行为。

顺带说明：这次补充的实测与源码抓取已归档到 D:\AI工具\dsh-llamacpp-issue\_llama-server-src\（master 源码片段）与 llm-keepalive-true.mjs、hdrs.mjs（新探测脚本）。

[pangafu]

llama.cpp的修复方案：

修复
文件：tools/server/server-http.cpp（第 569 行 return has_next; 改为 return true;，附注释）

             if (!has_next) {
                 sink.done();
                 SRV_DBG("%s", "http: stream ended\n");
             }
-            return has_next;
+            // The chunked provider contract (upstream cpp-httplib, see
+            // write_content_chunked) requires the provider to return true after
+            // calling sink.done(): done() clears data_available so the write
+            // loop exits normally with Error::Success. Returning false here is
+            // interpreted as Error::Canceled, which fails the response write
+            // and closes the TCP connection right after every streamed
+            // response -- breaking HTTP keep-alive reuse for the next request.
+            return true;

server-http.cpp.txt

[pangafu]

改llama.cpp的效果要好于设置dsh的模型connection: close