ollama 部署qwen-vl

你想在 ollama 上跑个能看图的大模型，结果拉下来发现只会聊天，或者传图片进去报错、显存直接爆掉。这类问题多半不在 ollama 本身，而在模型是不是真的带视觉分支、你选的量化档和显存是否对得上、客户端有没有走视觉的请求格式。这篇按「确认能力—选档位—跑起来—验通路」的顺序给一套可执行动作，遇到不适用的情况也会标出来。

你想在 ollama 上跑一个能看图的大模型，结果拉下来发现它只会聊天，或者图片一传进去就报错、显存当场爆掉。这种坑多半不在 ollama 本身，而是三件事没对齐：你拉的那个模型到底带不带视觉分支、你选的量化档和手头显存是否匹配、客户端有没有按视觉请求的格式把图递进去。

下面按「确认能力—挑档位—拉模型—跑通—接进程序—看效果—长期维护」的顺序给一套能直接照着做的动作。每条都带判断标准和排查方向，也会标出什么情况下这套办法不适用。先说明一点：任何具体的参数规模、量化档位对应的资源占用、效果对比，都以站内页面当时的数据为准，这篇只讲怎么判断和怎么动手。

先确认你要的模型带不带视觉能力

ollama 上的模型名字相似度极高，纯文本版和视觉版经常只差一个后缀或一个词。很多人是照着一个名字拉下来，跑起来才发现根本没带图像输入。所以第一步不是装环境，是把「它到底支不支持图片」这件事先钉死，再谈后面的事。

• 看模型卡里有没有 image、vision 这类输入模态说明，以及有没有给图片理解的示例用法；只看参数量和名字一定会踩坑
• 到站内 /models 的模型条目页核对，再去 /multimodal 看多模态那批的整体范围，两个页面交叉确认，比单看一个地方稳
• 注意同名不同 tag 的情况，不同 tag 可能对应不同的量化或能力配置，拉之前先看清 tag 后缀
• 如果你已经有目标模型，先搜它的官方说明，确认它是原生视觉模型，还是靠外挂视觉编码器拼出来的

什么情况下可以不用视觉模型？如果你只是想让模型描述一张非常简单的图，比如一张纯色背景上的单个物体，纯文本模型配上外部的 OCR 或图像描述工具也能凑合。但一旦涉及版式理解、图表推理、多图对比、小字识别，就必须走真正的视觉模型，用拼凑方案只会得到似是而非的结果。

按显存和量化档位决定跑哪一版

视觉模型比同参数的纯文本模型更吃显存，因为图像编码器和图像 token 都要额外占地方，不能直接套纯文本的显存经验。先量出你机器实际可用的显存和内存，再去反推能上什么量级，而不是先挑模型再祈祷跑得动。

量化档位怎么选？档位越激进越省显存，但小字、表格线这类细粒度信息越容易糊。做票据、表格类任务时，宁可留一点余量换更保守的档位，也别为了塞进显存把图糊掉。选择之前，先去站内页面核对当时的档位分档和对应的资源区间，数字会变，判断逻辑不会变。

不适用的情况：走 CPU 或统一内存的机器没有「显存天花板」这个概念，但速度会慢到不适合交互式用图。如果你要的是实时看图的体验，与其硬跑，不如考虑调用托管接口，本地只做预处理或缓存。

装好 ollama、把模型拉下来

1. 先确认服务本身能用启动 ollama 服务，先拉一个小号纯文本模型跑通一次问答。这一步是为了排掉网络、代理、服务未启动这些基础问题，否则后面报错会混在一起，分不清是模型问题还是环境问题。
2. 核对磁盘与存储路径大模型文件动辄几个 G 到几十个 G，模型文件和运行时的临时空间是两笔账。拉之前先看磁盘余量，模型存储路径和空间换算可以去站内 /tools 里的换算工具对一遍。
3. 解决网络通路再拉视觉模型国内网络拉取慢或中断很常见。先把镜像源和网络通路解决好，再重试拉取，不要反复中断续传，容易把文件拉坏，最后表现为模型能加载但推理异常。
4. 拉完先确认条目状态到站内 /models 确认你要的模型条目当前是否仍可用、名字或 tag 有没有变，避免照着旧名字拉，拉下来的其实是另一个东西。

这里有个常见的误判：模型拉取成功不等于模型可用。拉取只是把文件放到本地，能不能加载、能不能推理是下一步的事。所以拉完不要急着接客户端，先用最小命令行验证一次。

跑起来并验证图片真的被读到了

这是最容易自我欺骗的一步。很多人传了图，模型也回了话，就以为视觉通路通了，其实模型压根没看那张图，全靠你问法里的线索瞎编。验证的核心是设计一个「只有真看图才能答对」的问题。

• 命令行最小验证：挑一张内容明确的图，问一个答案只能从图里得到的问题，答不上来或答偏，说明走的是纯文本分支
• 再走接口验证：用同样的图片和问题请求一次，对比返回内容。接口和命令行结果不一致，问题多半在客户端请求格式，不在模型
• 建立性能基线：到站内 /tools/speed-test 量一次接口延迟和吞吐，后面出问题才有对照物
• 检查返回结构：接口返回里如果没有图像相关的字段或标记，基本可以判定请求没带上图，回头改请求结构

不适用的情况：图片过大或分辨率过高时，前端可能先压缩、也可能直接拒绝，你看到的现象会像「模型不认图」。正确做法是先把图片缩到合理尺寸再测，不要一上来就下结论说模型坏了或部署失败。

接到客户端或自己的程序里

本地跑通和接进程序之间还有一道坎。命令行能看图，不代表你的图形客户端或业务代码能看图，因为视觉请求的格式和纯文本请求不一样，图片要按特定结构塞进去。

本地部署的 ollama 一般只监听本机，想把图片请求从别的机器发过来，要先改绑定地址。改之前先去站内 /ollama-expose-all-ip-hardening 对应的安全思路里确认暴露范围，别为了图省事把服务裸奔到公网。另外，不同客户端对视觉请求的支持程度差别很大，稳妥的顺序是命令行、接口层各跑通一次，再上图形客户端，能少绕很多圈。

想验证服务是不是真的在按你的请求干活，可以去站内 /tools/verify 借一下探针思路：用固定输入比对固定输出，输入变了输出也跟着变，就说明服务在处理真实请求，而不是缓存或兜底回复。

效果预期与什么时候别用它

本地小参数视觉模型的能力边界很清楚：擅长整体描述、粗略定位，弱在小字 OCR、复杂表格和多图对比。别拿它和托管大模型比，也别拿它去做对准确率要求极高的活。先用你自己业务里的真实图片做一轮抽样测试，再决定够不够用。

• 抽 10 到 20 张真实业务图，固定问法，只换图片，看结果稳不稳
• 同一张图换不同问法结果差异可能很大，测的时候固定问法，才能判断是模型问题还是提问问题
• 要横向比不同方案，去站内 /multimodal 和 /benchmarks 看当时的横评结果，别凭印象拍板
• 对准确率要求高又没人复核的场景，本地部署不该作为唯一依据

不适用的情况要说清楚：如果任务错一次的代价很高，比如票据金额录入、合同条款提取，本地小模型只能当预筛，最终结果必须配人工校验，或者改用更强的托管接口。硬用本地模型省下的资源，往往会在返工里加倍还回去。

长期使用的维护动作

本地部署不是跑通就完事，后面还有版本更新、机器迁移、显存吃紧这些日常问题。把这些动作提前固化下来，比出事再救火省心得多。

• 记录你实际用的模型标识、量化档和硬件组合，换机器或换版本时才有回退依据
• 显存吃紧时优先降图片输入规模、限制并发，而不是急着换更大参数模型
• 模型目录和存储路径变动会影响升级，操作前先去站内 /models 确认条目状态，再动本地文件
• 迁移到另一台机器前，先核对目标机的显存与内存是否满足同一档位，再搬文件，避免搬完才发现跑不动
• 定期复测一次视觉通路，确认升级或环境变动后图片输入仍然生效

迁移这件事最容易翻车：两台机器参数看着一样，实际可用显存和内存可能差不少。先去站内页面核对目标机的资源是否满足同一档位，再开始搬。搬完不要只看模型能不能加载，一定要重跑一次「只有真看图才能答对」的验证问题。