大语言模型 视觉大模型 多模态大模型 区别

很多人卡在同一件事上：手上有个活要干，不知道该调语言模型、视觉模型还是多模态模型，于是要么用文本模型硬啃图片，要么花高价上了多模态结果只用到它十分之一的能耐。这篇不堆概念，先把三者的能力边界切开，再给你一张按任务对照的表和一套验证顺序，最后说明哪些情况下这套判断不适用。

很多人卡在同一件事上：手上有个活要干，不知道该调语言模型、视觉模型还是多模态模型。于是要么用文本模型硬啃图片，要么花高价上了多模态，结果只用到它十分之一的能耐。这篇不堆概念，先把三者的能力边界切开，再给一张按任务对照的表和一套验证顺序，最后说明哪些情况下这套判断不适用。

先说结论方向：选型的默认起点不是「越全越好」，而是「越窄越稳」。能用窄模型解决的，就别上通用多模态；只有当任务真的同时需要看图和写字，再考虑多模态。下面逐节展开怎么判断。

先把三类模型的名字对齐：它们解决的不是同一件事

很多人混着叫，其实这三类的输入输出形态根本不一样。语言模型输入文本、输出文本；视觉模型输入图像、输出标签或坐标；多模态模型把图像等信号编码之后塞进语言模型的上下文，输出仍然是文本或结构化结果。名字对齐了，后面才谈得上选型。

语言模型

输入输出都是文本，擅长生成、推理、改写、抽取，看不到任何像素

视觉模型

只处理图像信号，输出通常是标签、框、掩码或向量，不负责写整段话

多模态模型

把图像、音频、视频等编码后拼进语言模型上下文，输出仍是文本或结构化结果

关键区分点

不是「能不能看图」，而是输出形态和是否具备语言生成与推理能力

注意最后一个区分点。一个视觉模型也能「看图」，但它不会给你写一段解释；一个多模态模型也能做分类，但它做分类时往往比专用视觉模型更贵、更慢。判断时先问自己要的是什么形态的输出，而不是先问模型能不能看图。

能力边界对照表：按「输入什么、要什么输出」定位

下面这张表是最实用的定位工具。你只要把手上任务的输入模态和期望输出填进去，基本就能圈定候选范围。填不进去的，说明任务还没拆清楚，先拆任务再选模型。

这里容易踩的一个坑：图表、票据、截图里的细小文字和数值，多模态模型经常读错，而且错得很自信。这类任务不要因为它「能看图」就无条件相信，必须配人工抽检环节。

为什么没有一个模型通吃：三条技术路线的取舍

经常有人问，既然多模态又能看图又能写字，为什么不直接全用它？因为三条路线的训练目标和成本结构不一样，通吃意味着在某些场景上必然要付出额外代价。

• 视觉模型的训练目标偏判别，参数量小、延迟低，但不具备语言表达能力，写不出一段话
• 多模态模型要额外承接视觉编码器和跨模态对齐，同一件事上通常比纯文本模型更贵更慢
• 融合方式（早期融合、后期融合、适配器式）决定了它更擅长细粒度识别还是整体语义描述
• 所以选型的默认起点应该是：能用窄模型就别上通用多模态

换句话说，通用性是有价格的。一个只做卡片识别的视觉模型，可能又快又稳；换成多模态，你为它写报告的能力付了钱，但你根本不需要。什么时候值得上多模态？当你的任务确实需要「看完图再说一段话」，或者图文的边界本身是模糊的。

按任务挑：一份能直接照着勾的选型清单

下面这套顺序不是让你背，而是让团队里的人按同样步骤走一遍，得到大致一致的结论。先写清三件事，再看候选模型，最后跑样本。

1. 写清输入模态这段活喂进去的是纯文字、图片，还是图文混排？把最常见的一种和最难的一种都列出来。
2. 写清输出形态你要的是一段自然语言、一个标签、一批坐标，还是一个结构化字段？输出形态直接决定候选范围。
3. 写清可接受的错误代价错一次是无关紧要还是会造成损失？代价高的任务要留人工抽检和回退方案。
4. 圈定候选并跑样本开放性理解、跨图比较、图文混排问答走多模态；批量的固定格式识别优先窄模型或规则加小模型组合。
5. 验证细节准确率涉及数值、坐标、细小文字的任务，务必人工抽检，多模态在这类细节上最容易翻车。

这份清单里第三步最容易被跳过，但它恰恰决定了后面要不要加人。错误代价低的任务，哪怕准确率不是顶尖也能上线；错误代价高的任务，哪怕准确率很高也得留兜底。

成本与延迟怎么估：别只看单价

很多人比较模型时只看单价，结果上线后发现总成本完全不是那么回事。原因是多模态请求的输入量计算方式和纯文本不一样，同一张图在不同分辨率下折算出来的量差别很大。具体折算口径和当天的数字，到 官方 API 资料页（/official-api） 和 Token 成本计算器（/tools/token-price-calculator） 核对。

延迟这块特别提醒一句：先把你的可接受延迟基线量出来，再去挑模型。否则很容易出现「模型能力很满意、速度完全不能忍」的情况，白折腾一轮。

上线前的三步验证：示例集、对照跑、回退位

选型定了不等于结束，上线前至少走完下面三步。这三步不复杂，但能挡掉大部分事后返工。

1. 抽真实样本从真实业务里抽样本，覆盖正常、模糊、极端三类，数量不用多但要真，别自己造。
2. 两路线对照跑至少拿两个不同路线的模型跑同一批样本，重点对比错误类型，而不只是对错比例。
3. 留回退方案模型服务不可用时，能不能降级到窄模型或人工兜底？把这条路径写清楚。

验证结论记得记下来：用了哪批样本、错在哪几类。将来模型换代，按同样样本重跑一遍，就能判断要不要跟。没有固定样本集，每次换模型都等于从零开始。

这些情况下上面的判断不适用

前面讲的判断标准有适用范围，下面这几种情况要另做打算，别硬套。

• 任务本身就是生成图片、音频或视频，那是生成模型的事，不在这三类讨论范围内
• 对延迟极其敏感的端侧场景，多模态经常直接出局，要考虑量化后的小模型，见 /models/deploy
• 合规要求数据不出内网时，选型顺序会被可用权重清单改写，先看授权再看能力
• 预算极紧且任务单一，专用小模型加人工抽检往往比通用多模态更划算

尤其是合规那条：如果数据不能出内网，你能选的清单会大幅缩短，这时候能力排序要让位给可用性排序。先去 部署与模型页（/models/deploy） 看清哪些权重可用，再谈能力。

最常见的四个误区

最后收一下，下面这四个坑出现频率最高，检查一下自己有没有中招。

• 把「支持图片输入」等同于「能读懂图表里的数值关系」，这两件事差得远
• 用文本模型描述图片内容再让它猜，结果全是编的，这类幻觉特别隐蔽
• 只在上线前测一次，没有固定回归样本集，模型换代后完全不知道好坏变化
• 忽略输出格式稳定性，跑起来才发现结果解析不了，返工成本很高

选型不是选最强的，而是选刚好够用、且你能验证得住的那一个。

把这三类模型的边界记成一句话：语言模型管文字，视觉模型管判别，多模态模型管「看图说话」。任务落在哪一档，就对号入座；拿不准的时候，按前面的清单跑一遍样本，比争论哪个模型更强有用得多。