pureexe/dsh-vision-3090-fix

dsh-vision-3090-fix

一个 DeepSeek Harness（dsh）插件，用于修复：

400: {"message":"At most 1 image(s) may be provided in one prompt. (parameter=image)","type":"BadRequestError","param":"image","code":400}

该错误针对自托管的 OpenAI 兼容视觉后端（例如 syv-ai/qwen38-27b-rtx3090，一个单张 RTX-3090 的 vLLM 部署）。vLLM 以 --limit-mm-per-prompt image=1 提供这些模型，因此任何携带超过一个图像内容部分的请求都会被以 400 拒绝——即使是在同一对话中不相关的轮次之间，甚至在同一轮次中不同的工具调用之间（例如一个截图工具和一个文件拉取工具各自返回一张图像）也是如此。

为什么会发生这种情况

Harness 自带的 LLM 适配器（dsh-llm-pi-ai、dsh-llm-deepseek）仅按累计字节大小（maxRequestImageBytes / requestImageMaxBytes）来卸载图像。它们从不按数量设限。因此，在一个对话中，你附加一张小图像、得到回复，然后再附加第二张小图像，下一次请求就会发送两张图像——完全在字节预算之内，但却是两张图像，而此后端会直接拒绝。

此插件的作用

它是一个小型本地 HTTP 反向代理，作为普通的 Cordis 插件 effect 启动（参见 harness 文档中的 docs/user/develop/basic/index.md#automatic-cleanup——ctx.effect() 会随插件的生命周期启动和停止它）。你将它放在现有 provider 的 baseURL 前面；你与后端通信的其他一切方式——dsh-llm-pi-ai 的 pure provider、其模型列表、其凭据——都完全保持原样。

对于每个转发的请求，代理会：

1. 解析 JSON 请求体中的 messages 数组（标准 OpenAI 传输格式）。
2. 统计整个数组中每个 image_url 内容部分，包括嵌套在 tool 角色消息中的部分（返回的截图、拉取的文件）。
3. 将超出最新 maxImagesPerRequest（默认 1）的每一个就地替换为稳定的文本占位符。
4. 转发请求——请求头（包括 Authorization，原样保留——代理从不需要也看不到你的 API 密钥的含义，只是将其传递过去）和重写后的请求体——到真实后端。
5. 将响应逐字节直接流式返回，因此 SSE 流式传输的工作方式与直接与后端通信时完全一致（已验证：数据块是增量到达的，而非缓冲）。

已经处于或低于上限的请求会被完全原样转发。

安装

dsh plugin --profile web add /path/to/dsh-vision-3090-fix

（或者推送后使用 dsh plugin --profile web add github:pureexe/dsh-vision-3090-fix）。

在你的 profile 的 cordis.patch.yml（例如 ~/.dsh/profiles/web/cordis.patch.yml）中配置它：

- id: vision-3090-fix
name: dsh-vision-3090-fix
config:
upstreamOrigin: http://10.204.100.243:1234   # scheme+host+port only, no path
listenHost: 127.0.0.1
listenPort: 8931
maxImagesPerRequest: 1                        # 与你的服务器的 --limit-mm-per-prompt 保持一致
models: [qwen3.8-27b]                         # 可选；省略则对所有模型生效

dsh-llm-pi-ai 中的 baseURL 是按提供商设置的，而不是按模型——同一个提供商下列出的所有模型都共享它。因此，如果 pure 提供三个模型，而你把它的 baseURL 指向这个代理，那么这三个模型现在都会经过代理，即使其中只有一个需要这个上限。models（可选；为空表示“对所有模型生效”）限定的是上限本身，而不是路由：范围之外的请求仍然会额外经过本地代理这一跳，但会被完全原样转发——输入字节相同，输出字节相同，与直接和后端通信相比没有任何行为变化。

然后把你现有的提供商配置指向代理，而不是真实后端——这是唯一需要改的一行。对于 settings.yaml 中的 dsh-llm-pi-ai 路由：

llm-pi-ai:
providers:
pure:
displayName: pure
apiKeyEnv: PURE_API_KEY
api: openai-completions
baseURL: http://127.0.0.1:8931/v1   # 原来是：http://10.204.100.243:1234/v1
models:
- id: qwen3.8-27b
...保持不变

其他所有内容——凭据、模型列表、agent-default-model、Web UI 的 Models 设置页面——都完全照旧工作，因为 dsh-llm-pi-ai 仍然拥有 pure 路由，并且仍然是编辑/读取该部分的东西。除了 URL 之外，代理对它来说是不可见的。

配置参考

| 字段 | 默认值 | 含义 |
|---|---|---|
| upstreamOrigin | （必填） | 真实后端的协议+主机+端口，例如 http://10.204.100.243:1234——不含路径 |
| listenHost | 127.0.0.1 | 代理监听的主机 |
| listenPort | （必填） | 代理监听的端口；将你提供商的 baseURL 指向 http://:/v1 |
| maxImagesPerRequest | 1 | 每个转发请求保留的图片数量；超出的部分（从最旧的开始）会变成占位文本 |
| models | []（所有模型） | 上限适用的模型 id（与请求的 model 字段匹配）；其他所有模型都按字节原样转发 |
| verbose | false | 记录启动横幅以及每个被施加上限的请求。实际的代理错误（例如上游不可达）无论如何都会始终记录——它们不是日常噪音。 |
| requestTimeoutMs | 300000 | 上游响应的空闲超时（响应头和响应体；每收到一个字节就重置）。0 表示禁用——对于响应可能长时间暂停的推理模型很有用。超时只会结束那一个请求并记录日志；它绝不会使代理崩溃。 |

测试

npm install
npm test                # 单元测试 + 本地端到端测试（模拟上游，无网络）

若要针对真实后端运行端到端测试：

VISION_3090_FIX_LIVE_UPSTREAM=http://10.204.100.243:1234 \
VISION_3090_FIX_LIVE_API_KEY= \
VISION_3090_FIX_LIVE_MODEL=qwen3.8-27b \
VISION_3090_FIX_LIVE_IMAGE=/home/pakkapon/a.png \
node --test test/live.test.js

该测试会启动一个真实的代理实例，首先证明一个未设上限的双图像对话会从真实后端收到所报告的 400 错误，然后证明同一对话在通过 1 张图像上限的代理后能够成功。

已知限制

- 在转发前会完整缓冲请求体（解析和重写 JSON 所需）；适用于聊天/视觉负载，不适用于大型文件上传。响应以流式方式透传，不进行缓冲。
- 没有重试逻辑，也没有请求队列——它是一个轻量级透传，而不是负载均衡器。
- 假设后端是普通 HTTP/HTTPS 的 chat/completions 形式 JSON；如果提供商对图像使用不同的传输格式（不是 OpenAI 的 image_url 内容部分），则无法识别。

许可证

MIT