前面几篇聊的基本都是「打字」的模型——提示词、参数、检索，输入输出都是文字。但真实的活儿往往不是文字：商品图要写卖点、发票要录数据、报错截图要翻译成人话。这些都得让模型先看见。多模态模型就是干这个的，可它们的名字五花八门——VL、Vision、OCR、Omni，价格能差出几十倍。这篇把选型的思路理一遍。
模型「看懂图片」，其实是把图切成了 token
文字模型把句子切成 token 再计算，视觉模型多了一步：先把图片按一个个小方块切开，每一块也转成一串数字，再和文字 token 拼进同一个序列送进网络。所以图片在模型眼里不是「一张画」，而是一大把 token。这也解释了两件常被忽略的事：图片越大，消耗的 token 越多；一张 4K 截图，可能顶掉几千字文本的额度。选型时要把「图片成本」当成流量成本来算，而不是当成一次免费的上传。
先分清三类任务，选型方向就定了
很多人一上来就问「哪个视觉模型最强」，这个问题其实没法回答，因为「看图」是三类完全不同的事——
- 分类与判断：图里有没有瑕疵、是不是同一件东西、属于哪个品类。只要模型给出标签或结论，对细节要求最低，便宜的小模型就够
- 描述与理解：给商品图写文案、看图表总结趋势、读界面截图说明功能。要求模型能把看到的东西组织成语言，主流的视觉对话模型都能胜任
- 精确读取：发票、票据、表格、扫描件里逐字抽取。这是 OCR 的战场，通用模型那种「看个大概」在这里要命——一个数字差一位，后面全错
分不清任务，就容易花旗舰的钱办入门的事；反过来，拿通用模型去做结构化抽取，然后在准确率上无限返工，也是常见的坑。
选型的四个硬指标
方向定了，再用四个指标卡一遍：
- 场景与语言匹配：中文票据、中文排版、小程序截图，国产模型通常更稳；纯英文文档、复杂图表推理，则可以往 gpt-5.6-sol、gemini-3 这类旗舰上看
- 单图还是多图：只发一张图，和一次发十张图做对比，对上下文长度的要求完全不同，价格也差一档；多图任务别拿小上下文的模型硬扛
- 能不能稳定吐结构化结果：能直接返回 JSON 的模型，接进流程才省事；否则每次都要写正则去捞字段，返工成本比省下的模型费高得多
- 成本与延迟：图片按 token 计费，一张图可能等于几百到几千 token。批量任务先拿少量样本跑一遍，看清每张图实际花了多少，再决定用哪个档位
一个常被忽视的坑：不少视觉模型只在特定尺寸下表现好。把几千万像素的原图直接丢过去，往往不如先缩到长边 2000 像素以内再传——既省 token，识别率还常常更高。
常见问题
图片该传链接还是 base64？
两种都行。传 https 链接最省事，前提是这张图公网可访问；本地文件或涉及隐私的图，就转成 base64 直接塞进请求体。接口地址统一走 https://api.aigcbreeze.cn/v1/chat/completions，调用方式和文字模型一样，只是消息内容从纯文本换成了图文混合数组。
OCR 场景直接用通用大模型行不行？
少量、清晰的截图可以。但票据、表格这种「一个字段都不能错」的场景，建议用专门的 OCR 模型（站内的 qwen-vl-ocr 系列），或者走「OCR 先抽文本、再让语言模型做结构化」的两段式——比让一个模型从头包到尾稳得多，出错时也好定位是哪一段的问题。
多图任务里图片顺序重要吗？
重要。模型是按顺序理解图片的，对比类任务里最好在文字里明确写清「第一张是 A，第二张是 B」。顺序说不清，模型很容易张冠李戴，而且它会用很自信的语气把这个错误一路说下去。