多模态大模型区别于纯文本模型的主要特点

很多人选型时把多模态模型当成「文本模型加个上传按钮」，接进去才发现图片要预缩放、token 计费口径不同、并发和延迟完全是另一套账，甚至有些任务纯文本模型反而更稳。这篇不提榜单也不比跑分，只把两类模型的能力边界、判断标准和落地前的核对动作讲清楚，帮你在动手接接口之前就知道该看哪些参数、哪些场景不该上多模态。

很多人选型时把多模态大模型当成「文本模型加个上传按钮」，接进去才发现图片要预缩放、token 计费口径不同、并发和延迟完全是另一套账，甚至有些任务纯文本模型反而更稳。这篇不提榜单也不比跑分，只把两类模型的能力边界、判断标准和落地前的核对动作讲清楚。

目标很简单：帮你在动手接接口之前就知道该看哪些参数、哪些场景不该上多模态。下面按输入形态、成本结构、能力边界、接入核对四块展开，每一块都给出可以直接照做的判断顺序。

输入输出形态不一样，接口契约就不一样

纯文本模型只有一条 token 序列，输入进来就是字符串，出去还是字符串。多模态要额外约定图片怎么编码、分辨率上限多少、采样方式是什么——同一张图用不同预处理送进去，模型看到的东西差别很大，结果也跟着变。所以第一步不是选模型，而是先把「你这边的图片长什么样」写清楚。

• 纯文本模型：一条 token 序列进出，接口契约最简单，出错也最容易定位
• 理解侧多模态：能读图但不能生成图，输出仍是文字，接入时只需多约定图片字段
• 生成侧多模态：能出图、出音、出视频，接口和计费另算一套，别和读图混为一谈
• 输出侧要分清「能看图」和「能生成」是两回事，很多所谓多模态只做了理解侧

判断方法也直接：翻接口文档，看图片字段是走 base64、URL 还是文件 ID，是否支持多图、是否支持多轮带图对话。这三条决定了你的调用封装怎么写，也决定了后面出问题好不好排查。

成本结构从「按字」变成「按图块」，预算算法要重写

纯文本的消耗基本随字数走，估起来直观。多模态不一样：图片通常先切块再编码成视觉 token，分辨率越高块越多，同一张图的消耗可能差好几倍。截图、长图、PDF 转图这类场景，尤其要先估算单次请求的视觉 token 量级，再乘以你的调用频次。

具体单价别套别人截图里的数字，模型和口径都会变。到 和 按当时的单价算一遍自己的真实用量，再决定预算。想做长期追踪的话，价格变动这类信息看 /price-watch 比看笔记靠谱。

能力边界：什么活多模态更合适，什么活纯文本反而稳

关键判据只有一句：信息在转换成文字时会不会丢失。丢了才需要多模态，没丢就别多一道环节。带版式的文档理解、图表读数、截图排错、现场照片判断，这些用文字无损转述很费劲，多模态合适；从结构化文本里做抽取、逻辑推理、长文改写，纯文本模型通常更便宜也更可控。

适合多模态

信息本身是图形或版式，转成文字会丢失结构或位置关系

适合纯文本

输入本来就能用文字无损表达，转换没有额外损失

边界模糊时

先用纯文本跑一遍，看错误率；错得离谱再补多模态通道

常见误区

以为能看图所以文字能力也强，多模态的文本表现不一定等于同档纯文本模型

还有一点容易被忽略：多模态模型的文字能力不一定等于同档纯文本模型。选型时别默认「能看图所以全都强」，把文字类任务单独拿纯文本模型比一遍，往往更划算。

接入前的核对清单与验收顺序

上面讲的是判断标准，这一节给的是动作顺序。按四步走，每一步都有验证方式，跑完再决定要不要全量切。

1. 第一步：定任务把要处理的输入按「纯文本能表达 / 必须看图」分两堆，只有第二堆才进多模态通道。验证方式：随便抽一批样本分堆，看看第二堆占比多少，占比很低就别专门搭一条链路。
2. 第二步：定规格明确图片最大边长、单次最多几张、能否接受压缩，写进你的调用封装里。验证方式：拿最大尺寸和最多张数各试一次，看接口会不会直接报错。
3. 第三步：定口径用几条真实样本跑一遍，记录成功率、耗时和单次消耗。验证方式：同一批样本跑两轮，看消耗波动是否在你能接受的范围内。
4. 第四步：定回退多模态调用失败或超时时，要有降级到纯文本或转人工的路径。验证方式：故意断掉图片字段，看主流程会不会被单点卡死。

多模态模型目录可以在 /multimodal 对照，具体型号与规格以站内当页为准。中转站这条链路是否稳定、限速怎么算，可以在 /tools/speed-test 测一下；想先看别人踩过的坑，/sites 和 /rankings 更省时间。

判断要不要上多模态，只问一句：这条信息转成文字会不会丢？会丢才值得多一道环节。