最近在社群里被问得最多的问题之一就是“大模型到底怎么分类”。很多人会把 MoE、推理模型、多模态这三个词放在一起比较甚至有人问我“这个模型是不是既不是 MoE 也不是多模态”——这三个东西压根就不在同一个分类维度上。MoE 描述的是模型内部的网络结构怎么搭推理模型描述的是模型擅长不擅长做深度推理多模态描述的是模型能吃文本、图像还是音频视频。把它们混在一起聊就像把“汽油车、自动挡、SUV”放在一起比一样虽然都能描述一台车但回答的是完全不同的三个问题。这篇文章我打算把这三个维度彻底拆开来讲。先说明白它们各自回答的是“什么问题”再分别往深处挖一挖每种分类里的技术逻辑、实际表现和部署时要注意的坑最后再谈谈真实世界的模型是怎么把这些标签组合起来的。看完之后你至少能做到拿到一个模型不再被“是不是 MoE”“是不是推理模型”“是不是多模态”这些说法绕晕还能在选型、部署的时候心里有数。1. 三个词不在同一维度先分清三种分类逻辑1.1 为什么大家总把它们混在一起我复盘了一下大家会把这几个概念混在一起主要有两个原因。第一个原因是现在很多新模型的宣传文案喜欢把标签堆在一起比如“某某 MoE 大模型”“多模态推理大模型”时间长了大家就默认这些词是同一类东西。第二个原因是普通用户接触模型最直接的路径是聊天窗口看到的只是“回答得好不好”“能不能看图”很少去翻技术报告或模型卡的架构说明。标签到底是什么意思、背后属于哪个技术路线基本靠猜。猜来猜去就出现了“MoE 是不是比普通模型新”“多模态是不是一定比纯文本模型强”这类没有前提的提问。这些问题没法一句话回答因为一个描述的是“发动机结构”一个描述的是“能不能处理图片”拿不同维度硬比答案自然一团浆糊。1.2 一张表看清三种分类维度的本质我先把结论放在这张表里后面再逐个展开。分类维度回答的核心问题常见分支判断方法架构维度模型内部参数如何组织、推理时如何激活Dense、MoE看模型 config 里的专家数量、激活参数或看命名里的“A3B”等字段能力维度模型擅长什么类型任务是否有深度推理通用对话模型、推理模型看发布定位、是否带 thinking 模式、是否通过 RL 强化推理路径数据模态维度模型能接收和处理哪些输入类型纯文本、视觉语言、全模态看是否有视觉编码器、音频编码器是否接收 image/audio 输入看完这张表应该能明白一个模型完全可以同时属于“MoE 架构”“推理模型”“多模态”三个分类。它们不是并列选项而是三个独立坐标轴。1.3 日常沟通中怎么描述才不容易被误解我在跟团队和客户交流的时候一直习惯按固定的顺序描述一个大模型先说“数据模态”再补“能力定位”最后才提“底层架构”。举个例子有一个模型能吃图和文字而且带深度推理模式底层是 MoE那么我就会说“这是一个多模态推理模型架构上用了 MoE总共 32B 参数、一次激活 3B”。这样说完对方基本不会产生歧义。如果你反过来先说“这是 MoE 模型”别人大概率不知道你到底在说尺寸、能力还是速度。所以日常沟通里不是不能说而是要把“维度”带出来。2. 架构维度MoE 与 Dense 的本质区别2.1 Dense 模型每个 Token 走全量参数要理解 MoE得先知道它的对立面 Dense稠密模型。Transformer 里最占参数的部分是前馈网络FFN传统的 Dense 架构会在每一层放一个很大的 FFN输入的任何 Token 都会经过这个 FFN所有的权重都会被激活一遍。比如 Llama 3 8B、Qwen2.5 7B 这些模型虽然层数、头数不同但本质都是 Dense 结构。推理时无论问题是“今天天气怎么样”还是“解一道微分方程”每一个 Token 都会把整个模型的参数全部算一遍。Dense 的好处是结构简单、训练稳定、推理逻辑直接坏处也很明显参数规模涨到几百 B 之后推理成本呈线性上升普通设备根本跑不动。2.2 MoE 的核心专家路由是怎么回事MoEMixture of Experts的思路特别像外包公司公司里养着几十位专家来一个需求先由门控网络Router看一眼然后只把任务分给其中两三位专家处理而不是让全公司的人都上手。所以公司总人数很多但每个需求实际干活的人很少。具体到模型里MoE 会把每一层的 FFN 拆成多个独立的“专家”每个专家是一个小的 FFN 子网络。Token 进入这一层时Router 会计算它和每个专家的匹配度选择分数最高的 Top-1 或 Top-2 专家只让这些专家处理数据。其他专家在这个 Token 的计算中完全不生效。这就是“总参数 600B单次激活只占 30B”这种说法的来源。为了避免所有 Token 都挤到同一个专家里训练时还会加一项“负载均衡损失”Load Balancing Loss逼迫 Router 把 Token 均匀分配给不同专家。有些新模型还引入了“共享专家”的概念比如 DeepSeek-V3 就设置了一部分所有 Token 都要经过的共享专家用来保证基础的通用知识不会丢失。2.3 MoE 的优缺点与部署注意点MoE 能流行起来是因为它在“总参数量”和“推理开销”之间找到了一个不错的平衡总参数多了模型记住的知识更多激活参数少了单次推理的计算量没有线性增长。实测下来同等级推理速度下MoE 的模型能力通常明显强于 Dense。但这里有个特别容易踩的坑MoE 的总参数量依然决定了模型文件的体积和显存下限。Mixtral 8x7B 总参数量约 47B虽然一次只激活约 13B 参数但加载模型时还是得按 47B 的权重来装。Q4 量化后文件接近 28GB一张 24GB 显存的卡勉强放下推理速度确实快但显存占用并不会因为“只激活 13B”就变成 13B。部署时我习惯先确认两件事一是总参数量这决定你能不能装下二是激活参数量这决定推理速度。官方模型卡里一般都会写清楚比如 Qwen3 系列里带“A3B”这种命名意思是 Activated 3 Billion即单次激活 3B 参数。如果模型卡里没有写也可以在 config.json 里翻一翻找一下类似 num_experts、moe_intermediate_size 的字段。3. 能力维度推理模型到底“推理”了什么3.1 从快问快答到深度思考推理模型这个概念重点不在于用了什么底层架构而在于模型生成的流程发生了根本变化。普通对话模型的目标是“快速给出一个通顺的回复”它倾向于在第一个合适的回答处直接停下。而推理模型的目标是“在给出最终答案之前先把思考链条走完”哪怕这会多生成上千个 Token。类比来说普通模型像你问路对方脱口而出“往前走右转”推理模型像你问路对方先在手机上查地图、确认几条路线、比较路程时间然后告诉你“走 A 路线因为现在 B 路线堵车”。这个“在手机上查地图”的过程对应到模型里就是深度推理Reasoning阶段。3.2 推理模型的技术底座是什么推理模型的代表大家最熟的是 OpenAI 的 o1 系列和 DeepSeek-R1。它们的技术路线不完全一样但核心有两点思维链Chain-of-Thought和强化学习Reinforcement Learning。思维链很好理解模型被要求把“解题过程”拆成一步步的文字而不是直接从问题跳到答案。但光有思维链还不够模型得知道“哪些路径是对的、哪些路径是错的”。这就要靠强化学习。DeepSeek-R1 发布的时候训练里设计了一系列奖励规则比如数学题答案正确就给加分格式符合要求也给加分模型在大量尝试中逐渐学会了“先多想想再回答”的习惯。这个能力和底层是不是 MoE 没有任何绑定关系。R1 底层恰好是基于 DeepSeek-V3 的 MoE 架构但 Qwen3 系列的 14B、32B 是 Dense 结构同样能开启 thinking 模式做深度推理。3.3 实际使用中的误区推理模型不是万能选项很多人拿到推理模型之后什么任务都用它跑这是不对的。我实测下来的经验是简单的翻译、摘要、日常闲聊、知识检索类任务用普通模型就行速度快、省 token、成本低。数学、编程、逻辑分析、复杂规划这类需要多步推导的任务才真正适合开推理模式。推理模型的“思考过程”不是免费的。它可能在回答前先生成几百上千个思考 Token这些 Token 也是要计费、要耗时、要占显存的。本地部署时如果你的推理模型一口气写了两千个思考 Token显存里的 KV Cache 会迅速膨胀。所以选模型前先判断你的任务属不属于“需要深度推理”的类型而不是看到“推理模型”三个字就无脑选。4. 数据模态维度多模态不只是“能看图”4.1 多模态到底多在哪里多模态这个词现在被用得很泛滥好像模型能识别图片里的猫就叫多模态了。严格来说多模态指的是模型能够接收并融合多种类型的数据比如文本、图像、音频、视频并且在模态之间做对齐和理解。真正的多模态模型不只是“看图说话”。它需要把图像里的对象、文本中的语义、音频里的语气结合起来做判断。比如你给我一张电影海报加一段台词让我判断这部电影大概是什么情绪基调这就需要跨模态推理。这类能力背后是大量图文对数据训练出来的对齐效果不是加一个摄像头接口就能实现的。4.2 从实现路线上看清多模态模型的构成目前主流的多模态模型最通用的做法是在一个文本大模型前面加一个视觉编码器Vision Encoder图片先由视觉编码器切成 Patch 并编码成视觉 Token然后和文本 Token 拼在一起输入后面的大语言模型统一处理。这个“视觉编码器 LLM”的结构让多模态的选型变得比较好理解视觉编码器决定“模型能不能看懂图片”LLM 决定“看懂之后理不理解、会不会表达”。像 Qwen2.5-VL 这类模型还会特意去优化高分辨率图片的处理因为它把图片按动态分辨率切成多个 Patch而不是简单缩成固定大小。这也意味着输入图片的分辨率越高Token 数越多对显存的要求就越高。另外多模态不只有视觉语言这一种。现在还有能处理音频、视频的全模态模型只是在实际部署里视觉语言模型的应用最普及开源的生态也最成熟。4.3 部署多模态模型的显存与推理考量多模态模型部署时和纯文本模型最大的差别是显存开销不止看 LLM 的参数还要看视觉编码器的参数以及图片转成 Token 之后的上下文膨胀。我拿 16GB 显存的卡来举例。如果你跑一个 Qwen2.5-VL-7B 这类约 8.5B 总参数的模型量化到 Q4 之后权重约 5-6GB加上视觉编码器、KV Cache 和运行时开销16GB 完全够用而且比较流畅。但如果上到 34B 这个级别哪怕 Q4 量化后权重也要 20GB 上下16GB 卡就装不下了必须考虑把视觉塔单独放到 CPU 或者用更激进的重量化。还有一个很容易被忽略的点同一张图在 Qwen2.5-VL 里可能切成上百个视觉 Token如果对话里聊到多张图上下文会被迅速拉长KV Cache 成倍上涨。所以本地跑多模态模型时我一般会限制“最大图片数”和“图片分辨率”而不是一味往大里喂图。5. 组合才是常态一个模型可以同时是三者5.1 真实模型是复合标签前面把三个维度拆开讲是为了理清概念。但真实世界的模型几乎都是“混合体”。DeepSeek-R1 这个名字可能给人的印象是“推理模型”但它的底层其实是一个 MoE 架构的大模型Qwen3 系列里既有 Dense 版本也有 MoE 版本而且很多版本同时支持多模态输入和思考模式。所以你不能问“这是 MoE 还是推理模型”你应该问“这个 MoE 模型支持哪些能力、走什么数据模态”。这些标签是正交的底层架构决定运行效率能力决定它擅长什么任务模态决定它接收什么输入。三个条件交叉在一起才拼出一个模型的完整画像。5.2 怎么给一个模型“验明正身”接触一个新模型时我一般会按下面这个顺序快速验明正身。先看输入端口。如果模型支持 image 输入说明它至少是多模态模型或视觉语言模型如果只支持纯文本那它就属于单模态。这一步最关键因为多模态和纯文本的部署资源差很多。再看有没有 reasoning/thinking 开关。比如 Qwen3 系列模型有 thinking 模式的模型会要求你在 prompt 里加 think 标记或者在 API 参数里开启相应开关。能开、能跑就是推理能力不能开就是普通对话模型。最后看底层架构。打开 config.json搜索 moe、num_experts、expert 这些字段。有这些字段就是 MoE没有或者字段为 null大概率是 Dense。更直观的方法是看官方仓库里有没有“A3B”“A37B”这类激活参数标记有的话基本就是 MoE。5.3 选型时先问三个问题我在给实际业务选模型时不会一开始就陷入“哪个模型排名更高”这种问题。我会先问自己三个问题。第一输入是什么类型如果场景里只有文字就没必要选多模态模型选了只会白白增加显存和部署复杂度。第二任务需要多深的思考如果只是做客服问答、内容抽取普通模型足够如果是代码生成、复杂推理再考虑带思考模式或 R1 这类推理模型。第三部署资源有多少显存有限的情况下优先选激活参数小的 MoE 模型因为它能在总参数和速度之间找到平衡。三个问题问完大致方向就出来了纯文本、中等推理强度、16GB 显存我会选 7B-14B 级别的 Dense 或小型 MoE需要视觉理解、同样是 16GB 显存我会选 7B 级别的多模态模型而不是强行上 34B。6. 本地部署时最容易踩的分类误区这些账要分开算6.1 “MoE 一定省显存”是最大的误解我在本地部署社区里见过不少人抱怨说“我下了个 MoE 模型为什么 Ollama 还是给我拉了 30GB 的包”。原因很简单MoE 省的是推理时的计算量和开销不是存储和加载时的显存文件大小。模型文件只要包含了全部专家权重占用的硬盘和显存就是按总参数量来算的。所以部署前最好先分清两个数字总参数量决定容量激活参数量决定速度。如果你只有 16GB 显存选 MoE 的时候也要看总参数不能只看“激活参数 3B”就冲动下载一个 30B 总参数的模型。我遇到过不少这种情况模型下载完跑起来速度飞快但显存直接溢出白忙活一场。6.2 推理模型带来的隐藏显存消耗推理模型的部署成本比同样参数的普通模型要高一截这个账很多人没算清楚。推理模型在生成最终答案之前会先生成完整的思考链条有时甚至有几千个 Token。这些 Token 全部都要写入 KV Cache。KV Cache 的显存占用和上下文长度成正比序列越长占得越多。跑普通的 7B 对话模型16GB 显存很从容跑同尺寸的推理模型上下文一旦拉长显存就开始吃紧。给一个参考如果你用 Qwen3-32B 这类带思考模式的模型建议至少准备 24GB 以上显存最好能把上下文长度限制在 8K 以内。如果你强行开 32K 上下文又开思考模式显存会翻得很难看。我在实际使用时如果不能确定生产环境的上下文长度会优先选 14B 级别的推理模型留出 KV Cache 余量。6.3 多模态模型部署的实际建议多模态模型的部署坑主要集中在“图片吃显存”和“视觉塔选型”上。图片不是免费进的。一张 1024×1024 的图片经过 Vision Encoder 之后可能产生上千个视觉 Token这些 Token 会和文本 Token 一起进入 LLM 的注意力计算。聊三张图上下文长度可能直接顶上几千字文本。所以部署多模态模型时我会优先选择支持动态分辨率的模型它可以把小图按小 Token 处理大图才切细避免无谓的显存浪费。如果你手头是 16GB 显存想本地跑多模态我实测比较稳的配置是Qwen2.5-VL-7B 或同级别模型Q4 量化上下文 8K-16K单轮对话最多输入 1-2 张图。如果你需要更强的视觉理解那就不要硬扛本地考虑 API 或者更大显存的卡。真别指望 16GB 能流畅跑 72B 多模态模型哪怕是量化版也吃力。最后再分享一个我自己的判断习惯拿到任何一个新模型我第一件事是花两分钟看它的 config.json 和官方仓库说明。确认完是否有视觉塔、是否有思考开关、总参数量多少这个模型在什么设备上能跑、跑得快不快、适合什么任务基本上就有数了。这三个维度别混选型的时候省下的时间比你想象中多得多。
最近在社群里被问得最多的问题之一就是“大模型到底怎么分类”。很多人会把 MoE、推理模型、多模态这三个词放在一起比较甚至有人问我“这个模型是不是既不是 MoE 也不是多模态”——这三个东西压根就不在同一个分类维度上。MoE 描述的是模型内部的网络结构怎么搭推理模型描述的是模型擅长不擅长做深度推理多模态描述的是模型能吃文本、图像还是音频视频。把它们混在一起聊就像把“汽油车、自动挡、SUV”放在一起比一样虽然都能描述一台车但回答的是完全不同的三个问题。这篇文章我打算把这三个维度彻底拆开来讲。先说明白它们各自回答的是“什么问题”再分别往深处挖一挖每种分类里的技术逻辑、实际表现和部署时要注意的坑最后再谈谈真实世界的模型是怎么把这些标签组合起来的。看完之后你至少能做到拿到一个模型不再被“是不是 MoE”“是不是推理模型”“是不是多模态”这些说法绕晕还能在选型、部署的时候心里有数。1. 三个词不在同一维度先分清三种分类逻辑1.1 为什么大家总把它们混在一起我复盘了一下大家会把这几个概念混在一起主要有两个原因。第一个原因是现在很多新模型的宣传文案喜欢把标签堆在一起比如“某某 MoE 大模型”“多模态推理大模型”时间长了大家就默认这些词是同一类东西。第二个原因是普通用户接触模型最直接的路径是聊天窗口看到的只是“回答得好不好”“能不能看图”很少去翻技术报告或模型卡的架构说明。标签到底是什么意思、背后属于哪个技术路线基本靠猜。猜来猜去就出现了“MoE 是不是比普通模型新”“多模态是不是一定比纯文本模型强”这类没有前提的提问。这些问题没法一句话回答因为一个描述的是“发动机结构”一个描述的是“能不能处理图片”拿不同维度硬比答案自然一团浆糊。1.2 一张表看清三种分类维度的本质我先把结论放在这张表里后面再逐个展开。分类维度回答的核心问题常见分支判断方法架构维度模型内部参数如何组织、推理时如何激活Dense、MoE看模型 config 里的专家数量、激活参数或看命名里的“A3B”等字段能力维度模型擅长什么类型任务是否有深度推理通用对话模型、推理模型看发布定位、是否带 thinking 模式、是否通过 RL 强化推理路径数据模态维度模型能接收和处理哪些输入类型纯文本、视觉语言、全模态看是否有视觉编码器、音频编码器是否接收 image/audio 输入看完这张表应该能明白一个模型完全可以同时属于“MoE 架构”“推理模型”“多模态”三个分类。它们不是并列选项而是三个独立坐标轴。1.3 日常沟通中怎么描述才不容易被误解我在跟团队和客户交流的时候一直习惯按固定的顺序描述一个大模型先说“数据模态”再补“能力定位”最后才提“底层架构”。举个例子有一个模型能吃图和文字而且带深度推理模式底层是 MoE那么我就会说“这是一个多模态推理模型架构上用了 MoE总共 32B 参数、一次激活 3B”。这样说完对方基本不会产生歧义。如果你反过来先说“这是 MoE 模型”别人大概率不知道你到底在说尺寸、能力还是速度。所以日常沟通里不是不能说而是要把“维度”带出来。2. 架构维度MoE 与 Dense 的本质区别2.1 Dense 模型每个 Token 走全量参数要理解 MoE得先知道它的对立面 Dense稠密模型。Transformer 里最占参数的部分是前馈网络FFN传统的 Dense 架构会在每一层放一个很大的 FFN输入的任何 Token 都会经过这个 FFN所有的权重都会被激活一遍。比如 Llama 3 8B、Qwen2.5 7B 这些模型虽然层数、头数不同但本质都是 Dense 结构。推理时无论问题是“今天天气怎么样”还是“解一道微分方程”每一个 Token 都会把整个模型的参数全部算一遍。Dense 的好处是结构简单、训练稳定、推理逻辑直接坏处也很明显参数规模涨到几百 B 之后推理成本呈线性上升普通设备根本跑不动。2.2 MoE 的核心专家路由是怎么回事MoEMixture of Experts的思路特别像外包公司公司里养着几十位专家来一个需求先由门控网络Router看一眼然后只把任务分给其中两三位专家处理而不是让全公司的人都上手。所以公司总人数很多但每个需求实际干活的人很少。具体到模型里MoE 会把每一层的 FFN 拆成多个独立的“专家”每个专家是一个小的 FFN 子网络。Token 进入这一层时Router 会计算它和每个专家的匹配度选择分数最高的 Top-1 或 Top-2 专家只让这些专家处理数据。其他专家在这个 Token 的计算中完全不生效。这就是“总参数 600B单次激活只占 30B”这种说法的来源。为了避免所有 Token 都挤到同一个专家里训练时还会加一项“负载均衡损失”Load Balancing Loss逼迫 Router 把 Token 均匀分配给不同专家。有些新模型还引入了“共享专家”的概念比如 DeepSeek-V3 就设置了一部分所有 Token 都要经过的共享专家用来保证基础的通用知识不会丢失。2.3 MoE 的优缺点与部署注意点MoE 能流行起来是因为它在“总参数量”和“推理开销”之间找到了一个不错的平衡总参数多了模型记住的知识更多激活参数少了单次推理的计算量没有线性增长。实测下来同等级推理速度下MoE 的模型能力通常明显强于 Dense。但这里有个特别容易踩的坑MoE 的总参数量依然决定了模型文件的体积和显存下限。Mixtral 8x7B 总参数量约 47B虽然一次只激活约 13B 参数但加载模型时还是得按 47B 的权重来装。Q4 量化后文件接近 28GB一张 24GB 显存的卡勉强放下推理速度确实快但显存占用并不会因为“只激活 13B”就变成 13B。部署时我习惯先确认两件事一是总参数量这决定你能不能装下二是激活参数量这决定推理速度。官方模型卡里一般都会写清楚比如 Qwen3 系列里带“A3B”这种命名意思是 Activated 3 Billion即单次激活 3B 参数。如果模型卡里没有写也可以在 config.json 里翻一翻找一下类似 num_experts、moe_intermediate_size 的字段。3. 能力维度推理模型到底“推理”了什么3.1 从快问快答到深度思考推理模型这个概念重点不在于用了什么底层架构而在于模型生成的流程发生了根本变化。普通对话模型的目标是“快速给出一个通顺的回复”它倾向于在第一个合适的回答处直接停下。而推理模型的目标是“在给出最终答案之前先把思考链条走完”哪怕这会多生成上千个 Token。类比来说普通模型像你问路对方脱口而出“往前走右转”推理模型像你问路对方先在手机上查地图、确认几条路线、比较路程时间然后告诉你“走 A 路线因为现在 B 路线堵车”。这个“在手机上查地图”的过程对应到模型里就是深度推理Reasoning阶段。3.2 推理模型的技术底座是什么推理模型的代表大家最熟的是 OpenAI 的 o1 系列和 DeepSeek-R1。它们的技术路线不完全一样但核心有两点思维链Chain-of-Thought和强化学习Reinforcement Learning。思维链很好理解模型被要求把“解题过程”拆成一步步的文字而不是直接从问题跳到答案。但光有思维链还不够模型得知道“哪些路径是对的、哪些路径是错的”。这就要靠强化学习。DeepSeek-R1 发布的时候训练里设计了一系列奖励规则比如数学题答案正确就给加分格式符合要求也给加分模型在大量尝试中逐渐学会了“先多想想再回答”的习惯。这个能力和底层是不是 MoE 没有任何绑定关系。R1 底层恰好是基于 DeepSeek-V3 的 MoE 架构但 Qwen3 系列的 14B、32B 是 Dense 结构同样能开启 thinking 模式做深度推理。3.3 实际使用中的误区推理模型不是万能选项很多人拿到推理模型之后什么任务都用它跑这是不对的。我实测下来的经验是简单的翻译、摘要、日常闲聊、知识检索类任务用普通模型就行速度快、省 token、成本低。数学、编程、逻辑分析、复杂规划这类需要多步推导的任务才真正适合开推理模式。推理模型的“思考过程”不是免费的。它可能在回答前先生成几百上千个思考 Token这些 Token 也是要计费、要耗时、要占显存的。本地部署时如果你的推理模型一口气写了两千个思考 Token显存里的 KV Cache 会迅速膨胀。所以选模型前先判断你的任务属不属于“需要深度推理”的类型而不是看到“推理模型”三个字就无脑选。4. 数据模态维度多模态不只是“能看图”4.1 多模态到底多在哪里多模态这个词现在被用得很泛滥好像模型能识别图片里的猫就叫多模态了。严格来说多模态指的是模型能够接收并融合多种类型的数据比如文本、图像、音频、视频并且在模态之间做对齐和理解。真正的多模态模型不只是“看图说话”。它需要把图像里的对象、文本中的语义、音频里的语气结合起来做判断。比如你给我一张电影海报加一段台词让我判断这部电影大概是什么情绪基调这就需要跨模态推理。这类能力背后是大量图文对数据训练出来的对齐效果不是加一个摄像头接口就能实现的。4.2 从实现路线上看清多模态模型的构成目前主流的多模态模型最通用的做法是在一个文本大模型前面加一个视觉编码器Vision Encoder图片先由视觉编码器切成 Patch 并编码成视觉 Token然后和文本 Token 拼在一起输入后面的大语言模型统一处理。这个“视觉编码器 LLM”的结构让多模态的选型变得比较好理解视觉编码器决定“模型能不能看懂图片”LLM 决定“看懂之后理不理解、会不会表达”。像 Qwen2.5-VL 这类模型还会特意去优化高分辨率图片的处理因为它把图片按动态分辨率切成多个 Patch而不是简单缩成固定大小。这也意味着输入图片的分辨率越高Token 数越多对显存的要求就越高。另外多模态不只有视觉语言这一种。现在还有能处理音频、视频的全模态模型只是在实际部署里视觉语言模型的应用最普及开源的生态也最成熟。4.3 部署多模态模型的显存与推理考量多模态模型部署时和纯文本模型最大的差别是显存开销不止看 LLM 的参数还要看视觉编码器的参数以及图片转成 Token 之后的上下文膨胀。我拿 16GB 显存的卡来举例。如果你跑一个 Qwen2.5-VL-7B 这类约 8.5B 总参数的模型量化到 Q4 之后权重约 5-6GB加上视觉编码器、KV Cache 和运行时开销16GB 完全够用而且比较流畅。但如果上到 34B 这个级别哪怕 Q4 量化后权重也要 20GB 上下16GB 卡就装不下了必须考虑把视觉塔单独放到 CPU 或者用更激进的重量化。还有一个很容易被忽略的点同一张图在 Qwen2.5-VL 里可能切成上百个视觉 Token如果对话里聊到多张图上下文会被迅速拉长KV Cache 成倍上涨。所以本地跑多模态模型时我一般会限制“最大图片数”和“图片分辨率”而不是一味往大里喂图。5. 组合才是常态一个模型可以同时是三者5.1 真实模型是复合标签前面把三个维度拆开讲是为了理清概念。但真实世界的模型几乎都是“混合体”。DeepSeek-R1 这个名字可能给人的印象是“推理模型”但它的底层其实是一个 MoE 架构的大模型Qwen3 系列里既有 Dense 版本也有 MoE 版本而且很多版本同时支持多模态输入和思考模式。所以你不能问“这是 MoE 还是推理模型”你应该问“这个 MoE 模型支持哪些能力、走什么数据模态”。这些标签是正交的底层架构决定运行效率能力决定它擅长什么任务模态决定它接收什么输入。三个条件交叉在一起才拼出一个模型的完整画像。5.2 怎么给一个模型“验明正身”接触一个新模型时我一般会按下面这个顺序快速验明正身。先看输入端口。如果模型支持 image 输入说明它至少是多模态模型或视觉语言模型如果只支持纯文本那它就属于单模态。这一步最关键因为多模态和纯文本的部署资源差很多。再看有没有 reasoning/thinking 开关。比如 Qwen3 系列模型有 thinking 模式的模型会要求你在 prompt 里加 think 标记或者在 API 参数里开启相应开关。能开、能跑就是推理能力不能开就是普通对话模型。最后看底层架构。打开 config.json搜索 moe、num_experts、expert 这些字段。有这些字段就是 MoE没有或者字段为 null大概率是 Dense。更直观的方法是看官方仓库里有没有“A3B”“A37B”这类激活参数标记有的话基本就是 MoE。5.3 选型时先问三个问题我在给实际业务选模型时不会一开始就陷入“哪个模型排名更高”这种问题。我会先问自己三个问题。第一输入是什么类型如果场景里只有文字就没必要选多模态模型选了只会白白增加显存和部署复杂度。第二任务需要多深的思考如果只是做客服问答、内容抽取普通模型足够如果是代码生成、复杂推理再考虑带思考模式或 R1 这类推理模型。第三部署资源有多少显存有限的情况下优先选激活参数小的 MoE 模型因为它能在总参数和速度之间找到平衡。三个问题问完大致方向就出来了纯文本、中等推理强度、16GB 显存我会选 7B-14B 级别的 Dense 或小型 MoE需要视觉理解、同样是 16GB 显存我会选 7B 级别的多模态模型而不是强行上 34B。6. 本地部署时最容易踩的分类误区这些账要分开算6.1 “MoE 一定省显存”是最大的误解我在本地部署社区里见过不少人抱怨说“我下了个 MoE 模型为什么 Ollama 还是给我拉了 30GB 的包”。原因很简单MoE 省的是推理时的计算量和开销不是存储和加载时的显存文件大小。模型文件只要包含了全部专家权重占用的硬盘和显存就是按总参数量来算的。所以部署前最好先分清两个数字总参数量决定容量激活参数量决定速度。如果你只有 16GB 显存选 MoE 的时候也要看总参数不能只看“激活参数 3B”就冲动下载一个 30B 总参数的模型。我遇到过不少这种情况模型下载完跑起来速度飞快但显存直接溢出白忙活一场。6.2 推理模型带来的隐藏显存消耗推理模型的部署成本比同样参数的普通模型要高一截这个账很多人没算清楚。推理模型在生成最终答案之前会先生成完整的思考链条有时甚至有几千个 Token。这些 Token 全部都要写入 KV Cache。KV Cache 的显存占用和上下文长度成正比序列越长占得越多。跑普通的 7B 对话模型16GB 显存很从容跑同尺寸的推理模型上下文一旦拉长显存就开始吃紧。给一个参考如果你用 Qwen3-32B 这类带思考模式的模型建议至少准备 24GB 以上显存最好能把上下文长度限制在 8K 以内。如果你强行开 32K 上下文又开思考模式显存会翻得很难看。我在实际使用时如果不能确定生产环境的上下文长度会优先选 14B 级别的推理模型留出 KV Cache 余量。6.3 多模态模型部署的实际建议多模态模型的部署坑主要集中在“图片吃显存”和“视觉塔选型”上。图片不是免费进的。一张 1024×1024 的图片经过 Vision Encoder 之后可能产生上千个视觉 Token这些 Token 会和文本 Token 一起进入 LLM 的注意力计算。聊三张图上下文长度可能直接顶上几千字文本。所以部署多模态模型时我会优先选择支持动态分辨率的模型它可以把小图按小 Token 处理大图才切细避免无谓的显存浪费。如果你手头是 16GB 显存想本地跑多模态我实测比较稳的配置是Qwen2.5-VL-7B 或同级别模型Q4 量化上下文 8K-16K单轮对话最多输入 1-2 张图。如果你需要更强的视觉理解那就不要硬扛本地考虑 API 或者更大显存的卡。真别指望 16GB 能流畅跑 72B 多模态模型哪怕是量化版也吃力。最后再分享一个我自己的判断习惯拿到任何一个新模型我第一件事是花两分钟看它的 config.json 和官方仓库说明。确认完是否有视觉塔、是否有思考开关、总参数量多少这个模型在什么设备上能跑、跑得快不快、适合什么任务基本上就有数了。这三个维度别混选型的时候省下的时间比你想象中多得多。
