`OLLAMA_NUM_PARALLEL` and multi-modal models lead to `failed processing images` error

快速结论：该报错出现在开启 OLLAMA_NUM_PARALLEL（大于 1）并用多模态模型（如 llava、moondream，以及后续讨论中涉及 qwen3.5 等视觉语言模型）处理多个并发请求时，服务端日志出现 `failed processing images`，生成过程卡住。核心问题是目标模型架构不支持真正的并行请求，应优先确认调度器实际生效的 runner.parallel 值。

适用环境：Issue 中已确认的信息：Ollama（评论中提及 0.16.3、0.17.7、0.18.0、0.19.0）、Apple Silicon（macOS）、H100 GPU（Docker 部署）；涉及模型 llava、moondream、qwen3.5 系列、qwen3-next 80b、Nemotron 3 super。Issue 正文未提供 OS/GPU/CPU/Ollama 版本字段，以上仅为评论中出现过的环境，不代表统一复现条件。

最快修复方案：暂无确认的一步修复方案。Issue 中的明确结论是“这些模型架构本身不支持在单个 Ollama 服务内并行查询”，已给出的可行做法是：多开 Ollama 服务实例，每个实例 OLLAMA_NUM_PARALLEL=1，在前端用反向代理（nginx、caddy 等）聚合为单一 API（可优先尝试，评论中提供的是 Docker Compose + nginx 示例思路）。

注意事项：多实例方案会让同一份模型权重被加载多份，占用原本可分配给上下文的内存；非 Docker 环境需避免端口冲突。官方对“何时实现这些模型的并行支持”未给出时间表。另需注意本 Issue 讨论中混入了关于 qwen35/qwen35moe 并行被限制为 Parallel=1 的独立问题，发帖人建议将其与多模态图片处理故障区分对待，两者结论不一定可直接互搬。

问题场景

用户在 Ollama 上把 OLLAMA_NUM_PARALLEL 配置为大于 1，同时向多模态模型（llava、moondream 等）发送多个并发请求，期望并行生成；实际表现为生成过程冻结，服务端日志打印 `failed processing images`。

评论中进一步暴露了相关表现：Qwen 3.5、qwen3-next 80b、Nemotron 3 super 等模型在 OLLAMA_NUM_PARALLEL=8 时日志仍显示 runner.parallel=1，请求全部排队；同一配置下 0.16.3 版本可看到 runner.parallel=8，0.18.0 则只显示 1。

报错原文

OLLAMA_NUM_PARALLEL and multi-modal models lead to `failed processing images` error

原因分析

根据评论中的维护者说法：所列出的这些模型“架构上不允许在 Ollama 服务内并行查询”，因此即使环境变量设置了并行数，调度器仍会把该模型限制为 Parallel=1，多余请求进入队列。多模态模型并发时出现的 `failed processing images` 报错，与此限制属于同一类行为。

为什么部分版本日志中会出现 runner.parallel=8、而另一些版本为 1，Issue 中并未给出明确解释，属于未确认部分，需以目标模型版本的日志为准。

环境排查

确认 Ollama 版本（评论中出现 0.16.3、0.17.7、0.18.0、0.19.0），不同版本对同一模型的实际并行数表现不同。
确认使用的模型及其架构族：llava、moondream、qwen3.5（vision language model）、qwen3-next 80b、Nemotron 3 super 均出现在讨论中。
确认 OLLAMA_NUM_PARALLEL 实际传入容器的值（可用 docker inspect 核对环境变量，评论中曾这样验证）。
查看服务端日志中该模型实际加载的 runner.parallel 值，而不是只看环境变量。
确认部署方式（单机/Docker/多用户共享）及是否在 Apple Silicon、H100 等平台上出现差异。

解决步骤

先查看服务端日志，确认目标模型的 runner.parallel 是否被限制为 1；若被限制，说明是该模型架构层面的并行限制，调大 OLLAMA_NUM_PARALLEL 不会生效。
若必须支持并发，按 Issue 建议改为运行多个 Ollama 服务实例，每个实例内设 OLLAMA_NUM_PARALLEL=1、OLLAMA_MAX_LOADED_MODELS=1，避免同一实例内争夺并行槽位。
在各实例前部署反向代理（nginx、caddy 等）作为统一入口，将客户端请求分发到多个实例；评论示例使用 nginx upstream + least_conn + max_conns 做负载均衡。
非 Docker 部署时，为每个实例指定不同端口，避免端口冲突。
若等待官方实现，则保持关注本 Issue；维护者声明实现后会更新该 ticket，目前无时间表。