把一张带敏感数据的图表拖进对话框，云端 API 先走一遍公司代理，再排队等推理——这段过程本身就让人不安。

财务看板、用户画像、内部路演材料，一旦离开内网就失去掌控。上传到第三方云服务不仅可能触发合规审计，还会在日志里留下可追溯的痕迹。本地部署把推理留在机器上，文件和缓存都在自己手里，至少能把“数据出门”这层风险降到最低。

云端按量计费看着单价不高，但当团队每天几十张截图轮转、频繁调用分析时，月底账单会直接打回原形。一次投入的本地算力换来的是长期可用额度：哪怕是一块消费级显卡，配合 Ollama 的调度也能撑起反复迭代的截图解析与报告生成。先用 --model-dir 指定模型目录，便于把仓库挂载到宿主机做持久化，再配合 和 用于多卡环境下分配显存，装得下更大的多模态模型。先把模型拉下来，离线也能跑通整套流程，不必每次打开电脑都先看“余额不足”。

会议室里等着结论，网页却在转圈；跨境链路不稳定时，上传一张高清截图能等到怀疑人生。本地推理省掉网络往返，响应更快也更可控——尤其是当你要把图像理解嵌进自动化脚本时，这种稳定性比峰值性能更关键。

装 Ollama 和拉模型，比想象中简单但有几个坑

装 Ollama 其实没啥好说的，一条命令就完事。但我还是想多说一句：别在 root 下跑。

curl -fsSL https://ollama.com/install.sh | sh

三十秒，真的就三十秒。装完运行 启动服务，默认绑在 。这时候你就能拉模型了——但拉什么，得想清楚。

多模态模型不是每个都适合看图表。我试过一圈，llava 和 bakllava 对截图里的文字识别比较稳，moondream 轻量但容易漏细节。如果你机器显存紧，先用 llava:7b 试水；要分析带小字的财务报表，llava:13b 更靠谱。拉取命令都一样：ollama pull <model-name>。

拉完之后 ollama run <model-name> 就能直接对话，丢一张截图进去问“这张表里哪个品类销售额最高”，它真能给你指出来。不过单卡跑 13B 模型，显存占用直接飙到 12GB 以上，很多人就是栽在这步——一张 3090 勉强撑住，但你要是同时跑别的任务，OOM 没商量。

Ollama 支持多卡推理，但默认不会自动分摊。你得告诉它：哪些卡能用，怎么调度。环境变量两个就够：

CUDA_VISIBLE_DEVICES=0,1,2,3 OLLAMA_SCHED_SPREAD=1 ollama serve

指定哪些 GPU 可见， 设为 1 表示把模型尽量均匀摊到各卡。实测 4 张 3080 跑 llava:13b，每卡只占 4GB 左右，比挤在一张 3090 上舒服多了。注意：多卡对单次推理速度提升有限，主要解决的是“装不下”的问题。你要的是吞吐还是单次响应，得自己取舍。

还有个坑：如果你用 Docker 部署，记得把 --gpus all 加上，同时挂载模型目录：

docker run -d --gpus all -v /data/ollama:/root/.ollama -p 11434:11434 \
  -e OLLAMA_SCHED_SPREAD=1 \
  ollama/ollama

这样模型仓库就持久化到宿主机 /data/ollama，换容器也不重下。

装好了、拉完了、多卡也配好了——下一步才是真的头疼：怎么让模型看懂那张满是数字和折线的图表？这事儿光靠提示词不行，得调采样参数，甚至得考虑要不要把图像先切成小块再喂进去。下一章我们聊这个。

Ollama installation terminal command

从命令行到可视化聊天界面，Open-WebUI 让截图对话更顺手

命令行再爽，真要让 AI 读一张截图，还是得有个聊天界面才踏实。Open-WebUI 就是干这个的，它长得跟 ChatGPT 几乎一样，直接对接你本机跑着的 Ollama。本来以为又得装一堆 Node.js 依赖，结果 Docker 一行就拉起来了——上传图片、提问、出报告，整条链路直接可视化，不用再在黑框里敲命令了。

先决条件：你已经在本机装好 Ollama 并且至少 pull 过一个多模态模型（例如 llava:7b）。接着只需要一条 docker run：

docker run -d \
  --name openwebui \
  --gpus all \
  -v /data/ollama:/root/.ollama \
  -p 8080:8080 \
  -e OLLAMA_BASE_URL=http://host.docker.internal:11434 \
  ghcr.io/open-webui/open-webui:main

注意两点：一是加了 --gpus all 才能让 llama 系列模型走显卡加速；二是 必须指向宿主机的服务，容器里的 11434 端口并不存在。浏览器打开 localhost:8080，注册账号后在 Settings → Connection 里确认能看到 Models 列表，就说明通了。

Open-WebUI 原生就能处理多模态，你直接把一张 PNG 或 JPG 拖进对话框，敲个问题就行。前阵子我拿公司上周那张销售趋势图试了一下，就问它：“从这张图里把 Q3 环比增长率提出来，再给个结论”。十几秒过去，它不光给了 18.7% 这个数字，还自动吐了一段 Markdown 表格，末了补了句“增速放缓，建议盯一下库存”。那个瞬间我确实愣了一下——本地部署终于能像模像样地完成“截图”到“洞察”的转化了。

图片分辨率太高？先缩一下再丢进去，不然 token 分分钟爆给你看。13B 的模型对付 2K 屏截图已经有点喘了。想要答案结构清楚点，可以在 Prompt 屁股后面加一句“请用 JSON 格式输出”——大概率会给你一个能直接解析的对象，省得自己再手撕文本。

光看单张图毕竟信息有限，真正干活时还得结合过往文档。Open-WebUI 自带 RAG 功能：把去年的 Excel 导出成 PDF，丢进 Data 文件夹，它就能用 Embedding 索引起来。下次提问时记得带上“参考去年年报”这句提示，模型会自动召回相关段落，输出的报告风格也更贴近业务习惯。实测在 32GB 内存的机器上，加载 50 页 PDF 也就 20 秒左右，完全能接受。

Open-WebUI chat interface with screenshot upload

用 Dify 搭自动化工作流，让截图自己变成报告

Open-WebUI 单聊图片挺爽，但真要批量干活——比如每天上午十点自动把昨晚的销售截图转成报表——手工拖图就太慢了。这时候需要一个能编排工作流的东西，Dify 刚好干这事。

Dify 社区版可以直接连你本地的 Ollama 实例，不需要申请任何云端密钥。在 Dify 的 Settings → Model Provider 里选 Ollama，填上 ，然后选一个你拉好的多模态模型，比如 llava:13b 或者 bakllava:7b。测试连接通过后，这个模型就能在 Dify 的所有应用里用了。

重点在「工作流」里。新建一个 Chatflow，拖进一个「LLM」节点，模型选刚才配好的 Ollama 多模态模型。然后在节点输入里挂一个「文件上传」变量，让用户传截图。Prompt 写明确：
“分析这张财务报表截图，提取营业收入、营业成本、净利润三项数据，输出 Markdown 表格，并标注同比变化百分比。如果图中没有同比数据，注明‘仅当期数据’。”

第一次跑的时候我用了一张真实财报截图。llava:13b 花了大概 25 秒，输出了一个三行两列的表格，数字基本对得上，就是“同比变化”那列它脑补了个 5.2%——截图里根本没去年数字。所以 Prompt 里那半句“注明‘仅当期数据’”不是废话，是保底。

你可以再加一个「参数提取」节点，让 Dify 把模型输出的表格解析成 JSON，然后接一个「代码执行」节点，用 Python 把 JSON 拼成更复杂的报告格式，比如直接生成一个 HTML 邮件正文。整个流程跑通后，配一个定时触发器（Dify 的 Schedule 功能），每天早上 9:30 自动读取指定文件夹里的新截图，输出报告扔到飞书群里。

这套组合最爽的地方不是 AI 多聪明，而是你不用再手动截图→贴 Excel→写邮件了。Dify 负责编排，Ollama 负责推理，你只负责验收。

最后提醒一句：Dify 的工作流里如果传高分辨率图片，token 消耗会猛涨。我踩过坑——一张 4K 的柱状图让 llava:13b 跑了 2 分钟才出结果，改成 1080p 压缩后秒回。

真实案例：每周五的销量截图，两分钟变成周报

每周五上午，销售群都会准时丢来一张折线图截图：横轴是日期，纵轴是销量。过去我得手动把点位读出来，再贴进 Excel 做对比。上周我用 Open-WebUI 试了一手：直接把那张 1080p 截图拖进去，让它按 Prompt 输出 JSON。

我的 Prompt 写得挺啰嗦：“读取折线图，提取周一到周日的销量数值，单位件；如果图中只有累计值，换算成日均；输出 { "week": "2026-W04", "items": [{ "day": "Mon", "sales": 1234 }] }。”第一次跑用的是 llava:13b，结果它把纵轴刻度当成千位读了，整串数字全偏大。后来加了半句“纵轴单位为百件，请以刻度最小间隔 100 为准”，第二次就稳了。

Open-WebUI 支持把对话固定成“任务”，我把同样的 Prompt 存成了模板，并把输出格式限定为严格 JSON。为了防翻车，我在前端加了个简单校验：如果解析失败，自动重试一次并提示“请降低图片分辨率或更换截图区域”。实测三周，准确率大概 92%，偶尔遇到双 Y 轴会乱，我会顺手把另一轴遮住再传一次。

拿到 JSON 后，我用一段 Python 脚本把它拼成 Markdown 表格，再把结论段喂给本地 llama3.2 生成两句话的“本周要点”。最后用 smtplib 发给团队邮箱。整套流程从截图上传到发出邮件，平均两分钟。周五下午不再被这张图卡住，这种感觉比省了多少分钟更爽。

踩过的几个坑，说出来让你少走弯路

一路折腾下来，你会发现真正卡住你的往往不是模型有多聪明，而是那些看起来不值一提的小细节。说几个我踩过的坑，能避一个是一个。

llava:34b 听起来很香，但除非你手上有 24GB 显存以上的卡，否则别碰。我拿一张 RTX 3090 试了试，量化后的 34b 加载进去直接占满 24GB，推理一张 720p 截图要 40 秒。换成 llava:13b 或 bakllava:7b，8GB 显存就能跑，1080p 的图表 5 秒内出结果。实际干活 7B~13B 完全够用，再往上就是给自己找不痛快。多卡部署倒是能把 34b 塞进去，但推理速度几乎没提升——CUDA_VISIBLE_DEVICES 配合 只是让模型装得下，单次推理还是只占一张卡。别指望双卡能跑出翻倍速度。

你把一张 4K 的柱状图喂给 Ollama，它不会感激你。我试过一张 3840×2160 的折线图，llava:13b 花了 2 分 10 秒才吐出 JSON，中间还把日期刻度读错了。后来在 Open-WebUI 的上游加了一步压缩，用 Python 的 PIL 缩到 1024px 宽，再传过去 8 秒就搞定。分辨率太高纯属浪费 token，模型看图表根本不需要那么细的像素，1024 以内最稳。

第一次跑的时候我只写了“提取销量数据”，结果 llava 把输出写成了“周一到周日分别是 1200、1350、…”，每次表述还不一样。后来直接把格式塞进 Prompt：“请严格按照 JSON 格式输出，键为 date 和 sales，值均为数字，日期格式 YYYY-MM-DD。”一劳永逸。如果你用 Dify 编排工作流，可以再加一个 Code 节点做 JSON 校验，解析失败就触发重试，避免下游拿到乱码。

遇到过两次柱状图叠了双 Y 轴——左边是销售额，右边是增长率，两条线颜色还接近。llava 死活分不清哪个值对应哪条轴，输出的 JSON 全乱了。我现在的做法：用截图工具把另一轴遮住，只留需要的那条线，再传一次。笨但有效，准确率从 60% 直接拉到 95%。

这些坑踩完，剩下的就是享受本地模型不花钱、不联网、随时可调的快感了。说到底，AI 替你读图写报告这件事，关键不在模型多大，而在于你愿不愿意多花五分钟把流程打磨到顺手。