模型请求并发门控 d3vmeh/dsh-llm-gate

dsh-llm-gate

用于 DeepSeek Harness 模型请求的按提供商并发门控。

如果某个提供商一次只能处理固定数量的请求（例如带有 --parallel 1 的本地 llama-server），每个多余的请求都会被服务器推迟处理，且不会返回任何内容。客户端无法区分“正在等待槽位”和“已死”，Node HTTP 层会在 300 秒后以 terminated 超时。实际上，当子代理与主代理之间存在重叠，或压缩与代理之间存在重叠时，就会发生这种情况。

此插件将多余的请求保留在 dsh 内部。请求在发出任何 HTTP 请求之前会在 FIFO 队列中等待，因此等待期间不会有超时在运行。当槽位释放时，下一个请求会被派发。

安装

dsh plugin --profile web add dsh-llm-gate

然后在 ~/.dsh/profiles/web/cordis.patch.yml 中配置要门控的提供商：

- id: llm-gate
config:
providers:
llamacpp:
maxConcurrent: 1
maxQueued: 16
queueTimeoutMs: 3600000

提供商键是你的 llm-pi-ai.providers（或其他适配器）设置中的路由名称。未列出的提供商不会被门控。重启 dsh web 并打开一个新会话。

使用 dsh --profile web --dump-config 检查组合后的配置。

设置

| 设置 | 必需 | 含义 |
| maxConcurrent | 是 | 允许发往此提供商的在途请求数。对于 llama.cpp，应与 --parallel 匹配。 |
| maxQueued | 否 | 允许等待的请求数。超过此数量时，请求会立即以 QUEUE_FULL 失败。默认：无限制。 |
| queueTimeoutMs | 否 | 请求在因 QUEUE_TIMEOUT 失败之前等待槽位的最长时间。默认：无限期等待。 |

队列失败会以所示的代码结束本轮。它们不会被 dsh-llm-retry 重试。

你将看到的内容

只有当请求必须等待时，插件才会向 dsh 终端打印一行：

llm-gate: llamacpp session=a61e6e40 queued (depth 1)
llm-gate: llamacpp session=a61e6e40 dispatched after 5730ms

对于辅助请求，会添加 purpose=compaction 或 purpose=session-title。立即获得槽位的请求不会打印任何内容。

注意事项

- 此门控会串行化请求，因此它不会让单槽位服务器变得更快。若要并行化，请为 llama.cpp 提供更多槽位（--parallel 2 --kv-unified），并相应提高 maxConcurrent。
- 等待时间不会被适配器的 streamIdleTimeoutMs 计入，因为在获取槽位之前不会调用适配器。你仍然需要让 streamIdleTimeoutMs 足够大，以覆盖你的提示处理时间（参见 llm-pi-ai 提供商设置）。
- 排队中的请求通过其中止信号取消。在不中止的情况下丢弃流会使请求保持排队，直到槽位释放，此时它会派发并立即关闭。
- 需要 llm 服务；挂接 llm/stream 瀑布流，因此它覆盖主机中的每个模型请求：代理、子代理、压缩和标题生成。
许可证

MIT