本地 Ollama 视觉搭建全记录：从云端到免费 GPU

之前一直在用豆包 VLM 做图片理解——截图、照片、图表，统统丢给云端好用是好用，但每个请求都烧 API token，一张图 ¥0.2-0.3 不算贵，架不住量多一个月下来账单叠得挺扎眼

于是动了个心思：能不能全丢本地跑？免费、离线、不限量正好手头有块 RTX 显卡，目标就是 Ollama + qwen3-vl 本地视觉，彻底告别按张计费的苦日子

这篇文章讲的是一路踩过去的坑——CUDA 库不全、模型选错变体、大图塞爆上下文，以及最后跑通时的爽快

硬件准备：RTX 50 系的坑

先从装 Ollama 说起去官网下了 OllamaSetup.exe，大概 1.5GB，装到 %LOCALAPPDATA%\Programs\Ollama安装过程很安静，装完服务自动跑在 11434 端口我还写了个 vbs 脚本放开机启动里，每次开机自动启动 Ollama 服务

然而一拉模型跑推理，傻了——CPU 跑的，GPU 纹丝不动一张 4K 图推理了快半分钟，完全不是预期的体验

坑 1RTX 50 系（Blackwell）缺 cuda_v13 库

RTX 50 系列用的是 Blackwell 架构，sm_120，需要 cuda_v13 版本的 CUDA 库才能跑 GPU 推理但 Ollama 安装器在某些环境下会静默跳过 CUDA 库的解压——特别是安装超时被杀掉重来的时候，解压不全，lib\ollama\cuda_v13\ggml-cuda.dll 根本不存在

Ollama 发现没有合适的 CUDA 库，就悄悄回退到 CPU 模式，不报错、不提示，只有跑起来才知道慢

✅ 修复：卸载 Ollama，重新安装，装完后确认 %LOCALAPPDATA%\Programs\Ollama\lib\ollama\cuda_v13\ggml-cuda.dll 存在重装一次就好了，之前是安装器被系统策略中途 kill 了

GPU 和 CPU 的差距有多大？我拿同一张图测了一下：

配置	qwen3-vl:4b	qwen3-vl:8b-instruct
GPU（RTX 4060，~6GB 显存）	0.3-0.5s	0.5-2s
CPU 纯算（笔记本 i7）	8-12s	25-40s

GPU 跑 8b 模型比 CPU 跑 4b 还快一个数量级所以装完后第一步就是确认 CUDA 库在不在，不要想当然以为「装了就有 GPU」

模型选型：思考版还是 instruct 版

Ollama 装好了，GPU 也跑起来了，接下来该拉模型了qwen3-vl 系列有多个变体，我第一个拉的是 qwen3-vl:4b——理智上觉得 4b 小模型够用，快一点

结果呢？输出全是「推理过程」，真正的回答是空的调了各种参数都不行，差点以为本地模型就是不行

坑 2qwen3-vl 思考版在 Ollama 有 bug

Qwen3 系列分两个版本：思考版（默认标签，如 qwen3-vl:4b）和 instruct 版（加 -instruct 后缀，如 qwen3-vl:4b-instruct）思考版设计上可以通过 think:false 参数关闭推理过程，只输出最终答案

但 Ollama 上的 qwen3-vl 思考版有一个已知 bug（issue #14798）：模板里缺少 thinking 开关，think:false 被静默忽略结果就是模型输出全耗在 reasoning 内容上，content 字段为空，finish_reason 是 length（被截断）

✅ 修复：换用 qwen3-vl:4b-instruct 或 qwen3-vl:8b-instructinstruct 版本没有 reasoning 机制，直接输出答案，实测完全正常我现在用的是 qwen3-vl:8b-instruct，8b 参数，日常读图完全够用

几个模型变体的对比：

模型	参数量	类型	GPU 推理速度	实际可用？
qwen3-vl:4b	4B	思考版	~0.3s	❌ think:false 无效，输出空
qwen3-vl:4b-instruct	4B	非思考	~0.3s	✅ 可用，但精度偏低
qwen3-vl:8b-instruct	8B	非思考	~0.5-2s	✅ 推荐，日常首选
qwen2.5vl:7b	7B	v1 端点	~2-3s	⚠️ v1 端点读图报 Failed to load image

选模型的第一原则是「哪个能正常跑」思考版模型再强，输出为空也白搭

配置与集成

模型选对了，接下来就是把它集成到 DSH 的视觉系统中DSH 通过 modlens 插件管理视觉读图，配置文件在 ~/.modlens/config.json

配置很简单——把 provider 改成 openai 兼容格式，指向本地 Ollama 服务：

// ~/.modlens/config.json 中的 openai 段
{
  "provider": "openai",
  "baseUrl": "http://localhost:11434/v1",
  "model": "qwen3-vl:8b-instruct",
  "apiKey": "ollama",          // Ollama 不校验 key，但协议要求填
  "structuredOutput": false    // 本地小模型不支持 JSON schema 输出
}

几个要点：

baseUrl 指向 http://localhost:11434/v1——Ollama 兼容 OpenAI 的 API 格式，这个路径就是 OpenAI 兼容的端点
structuredOutput: false 很重要本地小模型不支持 response_format json_schema，开了会返回空内容这个开关在云端大模型上能用，但本地模型老老实实关掉
failover 链：我保留了一个降级策略——本地 Ollama 优先，如果失败（比如大图超上下文），自动降级到豆包 VLM，再不行到 SiliconFlow这样日常 90% 的请求走本地免费，关键任务自动切云端保底

视觉 failover 链：
  本地 Ollama（免费）→ 豆包 VLM（¥0.2-0.3/张）→ SiliconFlow（备用）

大图处理的坑

本地跑通了，日常截图都挺满意直到有一天丢了一张 4K 截图进去——直接报错 exceed_context_size

坑 3大图 base64 撑爆上下文

图片通过 base64 编码传给模型，一张 1800px 以上的图片编码后经常超过 4096 token而 qwen3-vl 的默认上下文窗口对图片 token 有限制，超了就报错

我试了几种方法：

设置 num_ctx 参数——Ollama v1 API 端点根本不认这个参数，静默忽略
设置 OLLAMA_CONTEXT_LENGTH 环境变量——对官方已经打包好的模型无效，只对 Modelfile 自定义模型起效
自定义 Modelfile——qwen2.5vl 可以用 Modelfile 重定义 num_ctx，但 v1 端点读图又报 Failed to load image，这条路走不通

✅ 最终方案：传图前先 resize 到 1024px 以内，base64 编码后控制在 2000 token 左右，完全不会触发上下文超限如果一定要看原图细节（比如密密麻麻的表格），就切到云端豆包 VLM 处理——它上下文窗口大，扛得住大图

虽然本地处理大图有局限，但日常 90% 的场景（截图、照片、简单图表、UI 界面）完全够用只有遇到复杂表格、超长文档 OCR 时才需要切云端

成本与性能对比

最后来算算账——从云端迁到本地，到底省了多少？

维度	云端（豆包 VLM）	本地（qwen3-vl:8b-instruct）
成本	¥0.2-0.3/张	免费
速度	1-3s（含网络延迟）	0.5-2s（GPU，无网络）
隐私	数据上传云端	完全本地，数据不出门
离线	❌ 必须联网	✅ 完全离线
质量（复杂图表）	✅ 优秀	⚠️ 够用，细节弱于云端
质量（日常截图/照片）	✅ 优秀	✅ 完全可以接受
大图处理（>1800px）	✅ 支持	⚠️ 需 resize 或切云端
日调用 100 次	¥20-30/天	¥0

按每天 100 次图片理解算，一个月省下 ¥600-900一年就是一台中端显卡的钱而且速度还更快了——少了网络往返，GPU 直出隐私方面更是质的飞跃：敏感截图、内部文档，再也不需要交给第三方 API

结语

这次搭建让我更坚定了「能本地就本地」的理念本地模型是另一个维度的选择——牺牲了极端场景下的精度，换来了免费、隐私、离线、不限量的自由

几个核心收获：

RTX 50 系装 Ollama 要确认 CUDA 库——cuda_v13/ggml-cuda.dll 在不在，装完看一眼，别被 CPU 摸鱼模式骗了
Ollama 拉模型看清后缀——-instruct 才是非思考版，思考版有 bug 输出为空，别踩了
大图先 resize——1024px 以内，base64 不超 2000 token，省心省力
保留云端兜底——复杂图表、超长文档还是切云端，不跟自己过不去

最后，这条路径不是终点随着本地模型越来越强（Llama 4、Qwen4 已经在路上），本地和云端的差距会越来越小到那时候，「云端」可能真的只用来做那些本地确实做不了的事了

而现在，我已经先把最日常的图片理解搬到了本地免费，离线，无限——这种感觉，真好