过去我们说大模型，很多时候默认它会“读文字、写文字、写代码”。但现在，越来越多模型开始能看图、听音频、理解视频、读截图、看 PDF。于是一个问题变得非常关键：文本大模型和多模态模型，到底差在哪里？

答案不是一句“多模态会看图”这么简单。真正的差别是：输入变了，内部表示变了，推理链路变了，成本结构变了，落地架构也必须跟着变。

一、先给结论：文本模型是“语言大脑”，多模态模型是“带感官的大脑”

文本大模型主要处理文字、代码、JSON、日志、SQL、Markdown 等文本序列。它把文字切成 Token，再通过 Transformer 计算上下文关系，最后生成答案。它擅长写作、总结、推理、代码、知识问答和结构化输出。

多模态模型则多了一个关键能力：它可以把图片、音频、视频、PDF、屏幕截图等非文本信号接入模型。比如你上传一张报错截图，它不仅能读上面的字，还能理解按钮位置、页面状态、图表趋势、截图中的对象关系。

所以最通俗的说法是：文本模型像一个只读文字的高手；多模态模型像一个能读文字、看图片、听声音、看视频的助手。前者在高频文本任务上便宜稳定，后者在真实世界信息理解上更有想象力。

二、底层原理：差别从“输入怎么变成模型能理解的东西”开始

文本模型的世界里，最重要的是 Token。无论你输入一段中文、一段 Java 代码，还是一份 JSON 配置，模型第一步都是把它切分成 Token，再把 Token 转成向量。后面的推理，本质上是在计算这些向量之间的关系。

多模态模型则复杂得多。图片通常要切成视觉块或提取视觉特征；音频要转成声学特征；视频要按帧或片段处理；PDF 可能还要结合文字层、版面和图片。随后，这些非文本特征要通过投影层对齐到语言模型能理解的语义空间。

这就是为什么多模态模型看起来只是“多上传一张图”，实际工程上却多出了一整套感知、对齐、融合和校验链路。

三、能力边界：文本模型不是落后，多模态也不是万能

如果你的任务是写文章、生成 SQL、解释代码、总结会议纪要、做知识库问答，文本大模型依然是非常高性价比的选择。因为这些任务输入就是文字，没必要把它交给更贵、更慢的多模态模型。

但如果你的任务里出现截图、票据、页面、合同扫描件、商品图、短视频、监控画面，那多模态模型的价值就出来了。它能把“过去人眼才能看的东西”转成模型可推理的上下文，再接入自动化流程。

四、成本差异：多模态为什么更容易烧钱

文本模型的输入成本通常和文字 Token 数量直接相关。你输入一段问题、几段上下文、几份知识片段，成本相对容易估算。

多模态输入的成本更隐蔽。一张图片可能被切成很多视觉块；一段视频可能要抽帧；一段音频可能要转写、分段、对齐。复杂截图、高清图片、长视频、PDF 扫描件都会把输入量推高。

所以工程上一定要做模型路由：纯文本走文本模型；只有当图片、音频、视频本身承载关键信息时，才上多模态模型。否则看起来模型更强，最后成本会先失控。

五、真正有价值的多模态场景

多模态的价值，不是让模型“描述一张猫图”，而是让模型进入业务流程。比如客服系统里，用户发来报错截图，模型可以先识别页面状态，再给出排查步骤；财务系统里，用户上传发票和回单，模型可以抽取字段并标记置信度；短视频系统里，模型可以拆镜头、总结剧情、提取封面候选。

这些场景有一个共同点：核心信息不在文字里，而在图片、视频、音频、版面和屏幕状态里。

六、别神化多模态：它最容易在这些地方翻车

多模态模型虽然能看图，但它不是人眼，也不是测量仪。它可能看错小字，可能把相似按钮认错，可能对图表数值做近似判断，可能漏掉视频中某个关键动作。越是涉及金额、合同、医疗、法律、生产安全，越不能让模型单独闭环。

企业落地时，一定要让多模态输出带上证据：它是根据图片里的哪块区域判断的？哪些字段不确定？置信度是多少？原始文件是否可以回看？这些信息比一句“模型认为”更重要。

七、企业架构：文本模型和多模态模型应该搭配用

成熟系统不会让所有任务都走同一个模型。正确做法是先识别输入类型和任务风险，再决定调用哪类模型。高频、低风险、纯文本任务用便宜模型；图片、截图、PDF、视频任务用多模态模型；关键字段和高风险任务再加校验模型或人工复核。

这套思路的核心不是“省钱”两个字，而是让系统的质量、成本、延迟和风险都可控。

八、多模态 Prompt 要怎么写

很多人第一次用多模态模型，会直接写：“帮我看看这张图”。这种提示词太宽泛，模型会自由发挥，输出不可控。真正适合业务落地的提示词，应该明确观察区域、抽取字段、输出格式、证据要求和不确定性规则。

比如分析报错截图时，不要只让模型“看看”，而是要求它重点观察错误提示、按钮状态、页面字段、网络提示，并把结果输出成 JSON，同时要求它把看不清的地方标记为无法确认。

九、怎么选择：别问哪个更强，要问哪个更适合

如果你的项目主要是问答、写作、代码、摘要、SQL、RAG，优先选择文本大模型。它速度快、成本低、稳定性更好。

如果你的项目核心输入是截图、扫描件、商品图、视频、音频、仪表盘、页面 UI，就应该引入多模态模型。尤其是那些过去依赖人工看图、看表、看视频的流程，多模态可能带来质变。

如果你的任务既有图片又有业务规则，就不要只依赖一个多模态模型。更稳的方案是：多模态负责理解原始材料，文本模型负责规则推理和结构化输出，校验模块负责拦截高风险结果。

十、30 天落地路线：从一个小场景开始

多模态项目最怕一上来就做“大而全”。正确路线是选一个高价值小场景，例如报错截图诊断、票据信息抽取、商品图审核、短视频拆镜头，然后准备一小批真实样本，先把准确率、成本、延迟和不可接受错误跑出来。

跑通之后，再做模型路由、Prompt 版本管理、结构化输出、证据回链、灰度发布和监控告警。只有这些工程能力补齐，多模态能力才不是一次演示，而是能进生产的系统。

最后总结：一句话讲透区别

文本大模型解决的是“语言世界”的问题：读文字、写文字、写代码、做推理。多模态模型解决的是“现实世界进入模型”的问题：让图片、音频、视频、PDF、屏幕截图也能参与推理。

真正成熟的 AI 系统，不是盲目上最强模型，而是把文本模型、多模态模型、工具调用、检索、校验、人审组合起来。简单任务用便宜稳定的模型，复杂感知任务用多模态，高风险任务加审校。这样才是从玩模型走向做系统。