
Regression: Ollama-0.30.x hangs on “encoding image slice…”, Ollama-0.24.0 works as expected
快速结论:该报错通常出现在 Ollama 0.30.x 版本处理多模态图片输入(如 OCR 场景)时,进程卡在 encoding image slice... 阶段,CPU 占用飙升至 100%。优先排查是否可降级至 Ollama 0.24.0 作为临时规避方案。
问题场景
用户在运行 Ollama 0.30.x (0.30.0 ~ 0.30.8) 时,调用多模态模型(如 Qwen3.5:4b)进行图片 OCR 或图片加载时发生。模型正常加载,但卡在“processing image… encoding image slice…”步骤,CPU 满负载,进程无响应。Ollama 0.24.0 版本在相同环境下正常工作。
报错原文
2026-06-06T18:04:23.795536770Z time=2026-06-06T18:04:23.795Z level=INFO source=routes.go:1919 msg="server config" env="map[CUDA_VISIBLE_DEVICES: ...]"
...
time=2026-06-06T18:04:23.796Z level=INFO source=images.go:864 msg="total blobs: 11"
time=2026-06-06T18:04:23.796Z level=INFO source=images.go:871 msg="total unused blobs removed: 0"
...
# 模型加载成功后,进程在此处挂起,无进一步的错误日志输出。
# 用户观察到的挂起点: "processing image... encoding image slice..."
原因分析
这是一个已知的回归缺陷,发生在 Ollama 0.30.x 版本的多模态图片处理流程中。可能原因在于 vision adapter/projector 张量的处理或图像嵌入到后端 llama-server 的传输逻辑出现阻塞,导致 Go/C++ 桥接层的编码调用未能正常完成。由于 0.24.0 版本无此问题,且 llama.cpp 单独运行正常,推测是 Ollama 0.30.x 中引入的调度或同步变更导致了特定硬件(如老旧 CPU)下的死锁或无限循环。虽然 Issue 中标注为回归 bug,但截至 2026-06-23 关闭时,尚未提交根本修复方案,仅确认了可降级规避。
环境排查
- 确认 Ollama 版本:是否属于 0.30.x 范围(0.30.0 ~ 0.30.8),可执行
ollama --version。 - 确认模型名称及是否包含多模态能力(如 Qwen3.5:4b、GLM-OCR 等)。
- 确认运行环境:Docker 还是直接安装?GPU 是否为 NVIDIA?确认 CUDA 或 Vulkan 后端配置。
- 注意 CPU 型号:Issue 中提到 Intel Core i5 9400F 正常工作,Core2 Quad Q6600 则挂死。检查低端或老旧 CPU 是否更容易触发。
- 确认上下文长度设置(如
n_ctx=16384)是否会加剧问题。
解决步骤
- 临时降级:将 Ollama 降级到 0.24.0 版本。如果使用 Docker,运行
docker pull ollama/ollama:0.24.0并切换容器镜像。如果直接安装,重新安装 0.24.0 的对应二进制包。 - 可优先尝试(推测):降低图片分辨率或使用更小的图片尺寸,减少编码压力,观察是否可绕过挂起点。
- 可优先尝试(推测):修改
OLLAMA_NUM_PARALLEL环境变量为 1,减少并发调度导致的资源竞争风险。 - 调试协助(如需反馈给开发者):提供完整的服务器日志,在启动时设置
OLLAMA_DEBUG=DEBUG(已在使用),并记录挂死时刻的 goroutine 堆栈(通过发送 SIGQUIT 信号或kill -3至 ollama 主进程)。
验证方法
执行之前触发挂死的多模态图片请求(如 OCR 命令),如果进程成功返回结果,不再卡在 encoding image slice...,且 CPU 负载在图片编码完成后回落到正常水平,则表示问题已解决。使用降级方案时,请确认 0.24.0 版本下请求能正常完成。



