很多人在挑模型时会被「多模态」这个词卡住:看到某个模型支持图片输入就以为它更强,结果拿去做纯文本任务反而更贵更慢;也可能手上明明是票据、截图、表格这类活,却还在用只吃文字的模型硬凑。这篇不排榜也不报价,只把多模态和单模态的区别按「输入、输出、任务、成本」四条线拆开,给你一套照着就能判断的选型顺序。
多模态这个词容易被当成「更强」的同义词,其实它只描述一件事:模型能吃进或吐出不止一种信息形态。能读图不等于能画图,能生成图也不等于能理解图,这是两套独立能力。选型时真正该问的是——我手上的活里,非文字信息是不是关键、错了能不能改回来。答案是否定的,多模态能力就是白付的钱。
下面按输入、输出、任务、成本四条线拆开讲,最后给一套照着就能走的判断顺序。全程不排榜不报价,涉及具体数字的地方一律指到站内页面,你按当时的收录和行情自己核对。
先把「模态」这个词拆开:输入什么、输出什么
模态指的是信息形态:文字、图片、音频、视频、结构化数据。多模态模型就是能处理其中两种以上的模型。但这里有个最容易踩的坑——「能读图」和「能画图」是两套能力,前者叫输入多模态,后者叫输出多模态,市面上很多模型只占其中一头。
| 能力方向 | 典型输入 | 典型输出 | 常见误判 |
|---|---|---|---|
| 输入多模态 | 图片、音频、视频加文字 | 文字或结构化结果 | 以为它能顺便生成图 |
| 输出多模态 | 文字描述 | 图片、音频 | 以为它读图能力也强 |
| 双向多模态 | 图片加文字 | 图片加文字 | 以为两边质量一样好 |
| 单模态 | 纯文字 | 纯文字 | 以为它一定更差 |
顺带说一句:单模态模型不是低端货。纯文本任务里它往往更快更省,多模态能力在没用上的场景里就是纯开销。遇到拿不准的名词,先去 /ai-dict 和 /ai-dict/category/basics 把术语对上一遍,再谈选型。
多模态模型真正多出来的能力,只有这几类活
抛开营销话术,多模态模型比单模态多出来的能力其实就那么几类,认清边界比记住型号有用得多。
- 跨形态转换:图转文字(描述、OCR、图表读数)、语音转文字、视频抽帧理解,这类活单模态模型从原理上就做不了
- 跨形态联合判断:既要看截图又要读日志才能给结论,能力来自两类信息被放进同一个上下文里一起处理
- 输入质量敏感:多模态的实际表现高度依赖输入本身,清晰度和分辨率会影响结果乃至计费口径
- 理解型与生成型是两条线:需要像素级精确还原或强控图时,别拿理解型模型的排名去推生成能力
按你的任务形态对照一遍,而不是按模型名气
选型最容易犯的错是照着模型名气挑,而不是照着自己的任务形态挑。先坐下来把任务的三件事写清楚:输入是什么形态、输出要什么形态、允许人工兜底到什么程度。写不出来,说明任务本身还没想明白。
- 列输入形态把任务里的信息逐个标形态:纯文字、截图、扫描件、录音、表格。标完数一下非文字占几项,一项都没有就直接停在这里。
- 判断关键性非文字部分是不是关键信息?只是偶尔夹张配图,先把关键文字手抄出来更省;整份票据只有图没有文字版,那才是真需求。
- 估算纠错成本如果模型认错了,人工改回来要多久?几秒钟能改的,先用便宜方案加人工兜底;改一次要几十分钟,才值得为准确率上多模态。
- 核对规格确定要上多模态后,到 /multimodal 看当前有哪些模型可选,再到 /official-api 核对各家的输入规格和支持的模态。
成本账与风险:多模态的隐含开销在哪
多模态的贵不只体现在单价上,还有几笔容易被忘掉的隐性开销。这几笔不算清楚,选型阶段算出来的账是假的。
| 开销项 | 为什么会产生 | 怎么核 | 什么时候可以忽略 |
|---|---|---|---|
| 计费口径 | 图片、音频常按各自单位折算成 token | 到 /tools/token-price-calculator 和 /tools/model-cost-calculator 用真实样本现算 | 纯文本任务,压根不涉及 |
| 响应延迟 | 多模态输入体积大,首字和总耗时通常更高 | 赶时间的链路先小流量实测一次 | 离线批处理,不卡用户等待 |
| 验证人力 | 多模态输出更难自动校验,需要人工抽检 | 把抽检人力按工时折算进总成本 | 准确率要求低、错了无所谓 |
| 部署门槛 | 数据不能出内网时得考虑本地跑 | 到 /models/deploy 和 /compute/sizing 按模型估显存 | 可以走公有云接口的场景 |
延迟这块单独提一句:多模态输入体积大,首字延迟和总耗时通常高于同档位纯文本请求。对用户体验敏感、又赶时间的链路,切换前务必用真实样本测一遍,别只看单次花费。
一套能直接照做的选型顺序
上面四条线讲完,落到动作上就是下面这个顺序。按步骤走,每一步都有明确的停止条件,不用凭感觉纠结。
- 第一步定形态把任务输入输出的模态写清楚。只有文字就停在单模态,别为用不上的能力付费。
- 第二步定精度非文字信息出错能不能接受?能接受就先上便宜方案加人工兜底,不能接受再认真挑多模态。
- 第三步定成本用同一批真实样本,分别跑一遍纯文本方案和多模态方案,对比准确率、耗时和单次花费,具体换算用 /tools/model-cost-calculator。
- 第四步留退路先小流量试,把失败样本收集起来,确认多模态确实带来增量再放大。可选的模型清单以 /multimodal 和 /models 当时的收录为准。
多模态不是升级档,是另一条能力线:用得上才值,用不上就是纯成本。下一步把手上任务按上面的清单自检一遍,然后去站内模型库核对当前有哪些多模态模型、各自的输入规格和计费方式,用真实样本算一次账再决定。→
常见问题
支持图片输入的模型是不是就一定比纯文本模型强?
不是一回事。图片输入只是多了一种入口,纯文字任务上它不一定更准,还可能更贵更慢。判断方法很简单:把你的任务去掉图片后还能不能做,能做的就别为多模态能力付费,除非去掉图片后关键信息确实丢了。
多模态模型的价格为什么和纯文本模型不好直接比?
因为图片、音频这类输入通常有各自的折算规则,一张图算多少、按什么口径折算都会影响最终单价,各家写法也不统一。想横向比就统一按同一批样本跑一遍,再拿实际用量去站内算价页面折算,别只看标称单价。
本地部署多模态模型和调 API,该按什么分界?
看两点:数据能不能出内网,以及调用量够不够大。数据敏感就必须本地,但要先确认显存够不够跑多模态,按模型估一遍再动手;数据不敏感且调用量不大时,按量调 API 通常更省事,也免得为偶尔一用的能力常年养卡。