八个字就能说明白MoE是骨架推理是脑子多模态是五官。这不是什么严谨的教科书定义而是我做了这么多年模型应用之后觉得最不容易把人绕晕的类比。但问题恰恰出在——大多数人对这三个词的认知是割裂的甚至把它们当成互斥的选项来讨论。这个是MoE架构所以它不是多模态那个模型会推理所以它一定不是稀疏架构这种话我在不少技术群里见过每次看到都想叹气。今天这篇就把这事彻底捋清楚大模型的分类不是一个维度而是至少三个互相独立的坐标系。搞懂这个你再去选型、读论文、看各种模型榜单思路会清晰非常多。1. 三个概念各自回答一个不同的问题1.1 乱象的根源分类维度不同却放在同一个天平上先做一个最简单的思想实验。你去问一个路人苹果和橘子哪个更好吃他可能会犹豫。但你去问苹果和水果刀哪个更好用他一定觉得你疯了——因为一个能吃、一个能用根本不在同一个类比维度上。现在很多人讨论大模型干的就是这种苹果对比水果刀的事情。MoE、推理模型、多模态这三个词经常出现在同一个投票帖、同一个选型表格、同一个评测榜单里好像它们是并列选项。但稍微想一下就知道MoE回答的是模型的内部结构长什么样、参数怎么组织、算力怎么分配推理模型回答的是模型在回答问题之前要不要多想一会儿、能不能处理复杂逻辑任务多模态回答的是模型能吃进去什么类型的输入、能吐出什么类型的输出。一个是结构问题一个是能力问题一个是接口问题。你说它们怎么并列之所以会有这种混乱是因为过去几年模型的演进节奏太快。两年前市面上绝大多数模型都是稠密结构的通用文本模型一个词就能概括全部特征到了现在DeepSeek V3是MoE但通用、DeepSeek R1是MoE且会推理、Qwen2.5-VL可能是稠密结构但是多模态、Kimi k1.5又可能是多模态加推理的混合体。每个模型身上同时背着多个标签如果底层分类逻辑不清楚看什么都像一锅粥。1.2 一个简单的分析框架从三个正交轴去看模型我在实际做技术选型和方案设计的时候习惯用三个独立的轴去拆解任何一个大模型。这个方法没有任何学术门槛就是一个工程判断工具分类轴核心问题典型取值关注对象结构轴模型内部是全员激活还是部分专家激活稠密Dense、稀疏MoE显存占用、推理吞吐、部署成本能力轴模型是否具备深度推理能力通用模型、推理模型复杂任务的准确率、思维链长度、错误修正能力模态轴模型支持哪些输入输出类型纯文本、视觉语言、全模态业务场景的数据形态、接口设计这三个轴是正交的。意思是说你在任何一个轴上取了一个值都不影响你在其他轴上取值。一个模型可以同时是MoE结构 推理能力 纯文本输入也可以同时是稠密结构 普通能力 多模态输入。这些组合都是真实存在的不是理论上硬凑的。这样一拆你会发现以前很多纠结的问题变得特别简单。比如我想部署一个本地多模态模型但显存只有16G该选哪个本质上是在「模态轴」上选多模态在「结构轴」上尽量选参数量小的稠密模型或者小MoE模型两个轴各查各的答案自然就出来了。接下来我按照结构轴 → 能力轴 → 模态轴的顺序把每个维度单独讲透最后再放到一起看真实世界里的组合案例。2. MoE模型内部结构的稀疏化改造2.1 稠密模型与稀疏模型的分界线先回到最基础的概念。传统的Transformer模型无论是GPT-3、Llama 2还是早期的ChatGLM它们的核心特点是前馈网络FFN这一层里的所有参数在处理每个token时都会被激活。这种结构叫稠密模型Dense Model。打个比方就像一家公司无论来的是什么需求所有员工都得参与处理一遍。稠密模型的优点是想都不用想的——训练稳定、推理逻辑简单、生态工具成熟。但缺点也明摆着参数量一上去推理成本跟着爆炸。70B的稠密模型光权重就占140GB左右的显存FP16精度每次前向传播都要把全部参数过一遍。这就是为什么很长一段时间里开源社区能做7B、13B但能做70B以上的个人或小团队屈指可数。MoEMixture of Experts混合专家把这个问题换了个解法。它的思路是我不需要所有参数同时参与计算我只需要让一部分专家去处理特定的token。还是那家公司的类比MoE相当于把公司拆成了多个专业小组来了一个需求门控路由器Router先看一眼然后只把需求派给两三个对口的专家组其他专家照常休息。什么是专家在MoE模型里一般就是把Transformer的FFN层复制若干份每一份就是一个专家前馈网络。原来的一个FFN层变成了一组FFN层每个token只激活其中少数几个。这样做的直接效果是总参数量可以做得非常大但每次推理的实际计算量FLOPs只和激活的专家数量相关。2.2 路由机制、专家分工与负载均衡MoE听起来简单但让它在工程上真正work有无数细节。最关键的是路由Routing机制。路由器的本质是一个轻量级的线性层输入是token的隐层表示输出是每个专家的得分。在训练和推理的时候我们需要从这个得分分布里选出Top-K个专家通常K取1到4之间。但这个选择是离散的没法直接做梯度回传所以主流做法是在训练时用软路由所有专家都参与梯度计算来指导硬路由推理时只激活Top-K个的逐步逼近。然后是负载均衡。这绝对是MoE训练里最头疼的问题之一。因为路由器完全自主学的话很快会发现某些专家特别强、用途广于是大量token都往那几个专家身上堆其他专家变成摆设。这就好比公司里两三个骨干累到死其他人天天闲着——整体效率反而下降。业界应对手段主要有几个负载均衡损失在训练目标函数里加入一项惩罚让路由器给每个专家的分配概率尽量均匀专家容量限制给每个专家设定一个最大token处理上限超出部分走残差连接跳过路由噪声训练时给路由得分加一点高斯噪声增加探索性让模型不至于过早陷入少数专家垄断的局面。还有一个在工程里容易被忽略的点共享专家Shared Expert的设计。像DeepSeek V3的MoE结构里除了被路由的细粒度专家之外还加了一个始终被激活的共享专家负责吸收通用知识。这个设计明显缓解了一个问题——如果没有共享专家通用知识和专用知识都要靠路由去分配路由压力大且容易导致专家职责重叠。你实际部署的时候不需要关心这些但理解它有助于你判断一个MoE模型的参数量、激活量这些指标到底意味着什么。2.3 主流MoE模型与几点选型心得现在开源生态里的MoE模型已经不少了我列几个有代表性的模型总参数量激活参数量专家数量说明Mixtral 8x7B46.7B12.9B8Top-2开源MoE的先行者DeepSeek V3671B37B256细粒度1共享Top-8当前开源MoE的性价比标杆Qwen3 MoE系列多档位约1/4总参量各版本不同中文生态友好Grok系列数百B级约1/5总参量多专家闭源但公开了部分信息从使用者的角度MoE带来的实际影响非常直接显存占用看总参数因为所有专家权重都要加载到内存里即使推理时只激活一部分。用FP16精度的DeepSeek V3权重也要1.3TB左右不是单卡能玩的必须上多机多卡或量化。推理速度看激活参数因为实际计算的FLOPs由激活参数决定。这就是为什么MoE模型总参数量很大但推理吞吐不一定比同级别稠密模型差的原因。量化MoE要小心专家之间有负载不均衡问题量化误差在某些专家上可能被放大最好用针对MoE设计的量化方案而不是直接套稠密模型的量化脚本。3. 推理模型从快答到慢想的范式转变3.1 推理模型到底改变了什么如果说MoE是在模型骨架上做文章那么推理模型就是在使用范式上做文章。这两者完全不冲突但经常被放在一起比较——这是我看到的最常见的误区之一。普通的大模型不管它是稠密还是MoE是怎么回答问题的你输入一个问题模型看一眼然后立刻按照已经学到的概率分布一个token一个token地把答案生成出来。这个过程中模型在第一直觉上做反应生成的内容是相当快的。对于给我写一封请假邮件总结这段文字这类任务这种快很合理答案质量也确实够用。但碰到复杂问题呢比如数学竞赛题、逻辑推理题、多步规划的编程题第一直觉往往不够用。人怎么解决复杂问题会先打个草稿列几个思路发现路径不对再折返最后正式作答。推理模型要做的就是把打草稿这件事也交给模型做。最核心的机制是推理时扩展Inference-Time Scaling。传统的模型训练完成后你在推理时的计算量是固定的——生成多少token就是多少计算。而推理模型会在正式回答前内部先生成一段很长的思维链Chain of Thought模型在这条思维链里尝试多种解法、发现错误、自我修正最后才给出最终答案。代价是什么肉眼可见的是变慢。你问一个普通模型问题几秒钟出结果问推理模型可能十几秒甚至几分钟。用户感知的慢其实是模型在内部悄悄做了大量额外推理。所以我也经常跟团队说不要把推理模型当默认选择——只有任务复杂度配得上那段思维链的时候才值得为之付出延迟。3.2 推理能力是怎么训练出来的推理模型不是改一下推理阶段的参数就能得到的它的关键在于训练方法的变革。目前业界主流路线可以分三个阶段看第一个阶段是冷启动的SFT。为了让模型产生高质量的思维链先用人工标注或者用强模型蒸馏出的长思维链数据做监督微调。这个阶段解决的是模型会不会输出思维链的问题。第二个阶段是大规模强化学习。这是推理模型和普通模型最根本的分水岭。普通模型微调终点通常是交叉熵损失尽可能低推理模型则在SFT之后继续做强化学习奖励信号不是一句接得好不好而是规则可验证的结果——比如数学题答案是否数值正确、代码能否通过测试用例。模型在强化学习中不断试错逐渐学会在复杂问题上花更多时间思考学会了自我纠错。第三个阶段是推理时策略的优化。一些更新的模型开始引入以思考长度换取精度的动态机制模型可以根据问题难度自己决定要多长思维链。这就是慢思考的由来。了解这些之后你再看这个模型是不是推理模型就有了判断依据推理模型一般都有专门的长思维链训练阶段而且往往在数学、代码等规则可验证的任务上特别强。这不是随便在普通模型上加个Lets think step by step提示词能模拟的——提示词只能唤起模型在预训练阶段见过的一些推理样例质量和稳定性都不如专门训练出来的推理模型。3.3 市面上常见的推理模型与辨别指南现在你能接触到的推理模型已经挺多了。OpenAI的o1、o3系列是最早带火这个概念的产品开源社区里DeepSeek R1绝对是一个里程碑它证明了用强化学习让开源模型获得强推理能力是可行的之后QwQ、Kimi k1.5、GLM-Z1、以及各种基于R1蒸馏出来的小参数推理模型也层出不穷。如何辨别一个模型属不属于推理模型我的经验是看三个信号官方文档或模型卡的训练说明。明确提到长思维链、强化学习、推理时扩展这些字眼的基本就是API的支持参数。推理模型一般都有控制思考长度的字段或者response中会额外返回reasoning_content这样的字段普通模型没有任务表现特征。在数学竞赛、复杂代码题上表现明显好于同规模普通模型但简单任务上速度反而偏慢。这里要特别提醒一下因DeepSeek R1走红之后市面上出现了一堆蒸馏出来的推理模型。正规蒸馏当然是有效的——比如用R1生成大量思维链数据去微调一个小模型小模型确实能继承一部分推理能力。但有些所谓的推理模型就是在普通模型之上套了个提示词模板让它假装慢思考实际并没有专门训练过。怎么区分看它生成的思维链是不是真的在自我纠错还是只是在重复已知信息。前者会有这里可能有问题我重新检查一下这样的内部对话后者一眼就能看出来是流水账。4. 多模态输入与输出接口的扩展4.1 多模态的模态到底指什么第三个维度离普通用户最近也最容易造成概念混乱。很多非技术背景的人一听到多模态就以为是一个更高级的大模型——很多厂商也确实这么宣传好像多模态是模型的某种超能力标签。但从工程角度看多模态就是一件非常朴素的事情模型能处理的信号类型更多了。纯文本模型能读能写的只有token。你给它一张图片它看到的只是一串二进制字节无法理解图片里的内容。多模态模型做的事情本质上是在输入端加感官、在输出端加表达方式。具体拆开看视觉-语言模型VLM能读文字加图片比如GPT-4V、Qwen-VL系列、Llama 3.2 Vision、InternVL音频输入模型能听录音、识别语音意图比如Qwen-Audio、Gemini系列视频理解模型能读懂视频帧序列的内容这在当前多模态领域是推进最快的方向之一生成类多模态不仅读多种模态还能输出图像、音频、视频比如Sora、可灵、Veo系列。注意多模态是一个接口范围的描述不是模型能力的评价。一个支持图片输入的模型在纯文本推理能力上未必比同规模的纯文本模型强甚至因为视觉编码器占用了参数空间文本能力可能被削弱。这也是为什么很多实际项目里宁可分别用一个纯文本模型做复杂逻辑处理 一个视觉模型做OCR提取也不硬上一个多模态模型因为分工更明确、效果更可控。4.2 多模态模型的两种主流技术路线理解多模态最重要的是理解它跟文本模型的关系。目前主流技术路线可以分成两大类。拼接式Modular / Adapter-based。这种做法以LLaVA为代表保留一个完整的文本大模型作为大脑在前端接一个视觉编码器比如CLIP的ViT把图片编码成视觉token再通过一个投影层Projector把视觉token映射到文本模型的语义空间里。图片进来之后视觉token和文本token被拼接到一起文本模型照常做自回归生成。这种路线的核心是让模型学会看图——训练时冻结文本模型的大部分参数只训练投影层和视觉编码器通过大量图文对数据把两者的语义空间对齐。优点是工程上简单视觉部分和语言部分可以独立迭代优化实验成本低。缺点是视觉信息经过投影层的压缩之后可能有损失模型对图片细节的感知能力不如对文字的敏感度高。原生式Native / Unified。这种路线更激进它从一开始就不分文本engine和视觉engine而是把所有模态统一成一种token表示放进同一个Transformer里训练。Gemini系列的底层思路、以及各种以统一分词器为核心的模型走的就是这条路线。优点是模态间融合得更自然模型可以在视觉和文本交叉的任务上做更灵活的推理缺点是训练数据要求极高、工程复杂度大不是一般团队能做到的。如果你只是调用API或者部署开源模型不需要关心内部到底走哪条路。但如果你要做微调或者二次开发就必须搞清楚你的模型属于哪一种因为微调策略完全不同拼接式模型微调时通常还是要冻结视觉编码器只动投影层和语言层的LoRA原生式模型则可以尝试在多模态数据上统一做LoRA。4.3 多模态与MoE、推理模型的关系我见过的最大误区就是有人把多模态和MoE当成对立选项其实它们根本不是一个维度。多模态描述的是输入输出的接口范围MoE描述的是模型的内部结构。一个多模态模型完全可以是MoE架构——事实上目前很多主流产品就是比如Gemini 1.5 Pro采用了MoE架构同时支持图片、音频、视频输入Qwen2.5-Omni也把多模态编码器和MoE结构结合在了一起。同样多模态和推理模型也不冲突。新一代的推理模型已经在往多模态方向扩展——比如能看图解题的推理模型输入一张几何题图片输出一步一步的推导过程。这种模型同时占据了能力轴的推理位置和模态轴的多模态位置。别被市场上的标签宣传带偏多模态不是模型等级的象征它只是一个能力维度的标记。5. 正交坐标系下的真实产品拆解5.1 用三维框架看几个实际模型理论讲了这么多现在放到真实世界的模型身上验证一下。我用三个维度给几个代表性模型打标签你感受一下这种拆解方式有多清晰模型结构轴能力轴模态轴Llama 3.1 8B稠密通用纯文本Mixtral 8x7BMoE通用纯文本Qwen2.5-VL 7B稠密通用视觉语言DeepSeek V3MoE通用纯文本DeepSeek R1MoE推理纯文本GPT-4o官方未公开推测含MoE通用全模态o1 / o3系列官方未公开推理纯文本视觉输入Gemini 2.0系列混合含MoE通用推理混合全模态Kimi k1.5官方未公开推理视觉语言推理这张表一下子就能说明问题每个模型其实是三维空间里的一个点标签跟标签之间是组合关系不是互斥关系。比如你在用DeepSeek R1你说它是MoE模型没错说它是个推理模型也对说它是个文本模型还是对——只是这三个判断分别回答的是三个不同的问题。5.2 为什么同一款产品在不同榜单里定位完全不同理解了三维拆解你就能看穿很多宣传话术和榜单排名的障眼法了。有些榜单测的是通用对话能力上榜的自然是结构轴能力轴综合评分高的通用模型有些榜单测的是数学推理那推理模型肯定名列前茅有些榜单测的是视觉理解那纯文本模型再强也上不了榜。不是模型变强或变弱了是榜单在拿不同的尺子量。这就好比拿奔跑速度和游泳速度两个指标去给运动员排名博尔特可能两者都出色但你不能因为一个游泳健将没进百米决赛就否定他。做选型的时候先搞清楚自己业务的核心瓶颈到底在哪个维度再去找对应的尺子。5.3 三维拆解法在项目选型里的实际用法我在技术方案里经常用一套非常朴素的选型流程分享出来供你参考。假设我要给一个实际业务选模型我会按下面顺序走先确定模态轴。我的业务数据是什么形态是纯文本、图文混合、还是涉及音视频这一步直接筛掉一大批不合适的模型缩小候选范围。再确定能力轴。我的任务需要快答还是慢想如果90%的请求是简单问答、信息抽取、格式整理通用模型就够了硬上推理模型只会白白增加延迟和成本。如果任务涉及复杂数学运算、多步代码生成、严谨逻辑推导再考虑推理模型。最后看结构轴。这一步更多是部署层面的考量——我的GPU资源够不够需要的吞吐量多大如果是个人开发者、单卡16G显存就别惦记数百B参数的大MoE了老老实实选个7B左右的稠密模型或者小规模的MoE量化版如果是企业级多卡集群则可以考虑大MoE用总参数换效果、用稀疏激活保吞吐。在剩余候选中做效果实测。这一步不能省榜单数据只能帮你初筛真实业务里的数据分布跟公开评测集往往差距很大。6. 常见误区自查清单6.1 六个高频误区你现在中了几个误区一MoE不如稠密模型。有些人觉得MoE是偷懒的做法用一堆小专家凑数。实际训练得当的MoE效果是能超过同激活参数量的稠密模型的因为总参数量大了知识容量上限更高。误区二推理模型就是更聪明的模型。推理模型在复杂任务上确实表现更强但在简单任务上它可能因为想太多而答错且延迟高、成本高。我实际测试过让推理模型做11等于几它有时候会因为过度怀疑自己而给出一个莫名其妙的答案。误区三多模态模型的文本能力一定更强。完全相反很多多模态模型因为要在视觉数据上分配训练预算纯文本能力反而不如同参数量的纯文本模型。想用多模态模型做大段文本的深度分析很可能失望。误区四本地部署大模型一定要选MoE。MoE省的是推理计算量不省显存。你本地一台16G显存的机器跑7B稠密模型很舒服跑一个总参数量46B的Mixtral 8x7B就算量化到4bit也够呛。误区五只要API支持传图片就是多模态模型。严格说很多文本模型是通过外部OCR工具把图片转成文字再处理的你传图片它也能看懂一些内容但这不叫多模态。真正的多模态是图片以视觉token形式进模型而不是图片先被外部工具转成文本。误区六推理模型会逐渐取代通用模型。至少在成本和延迟大幅下降之前不会。实际业务里绝大多数请求都是低难度任务通用模型的性价比远高于推理模型。未来的方向大概率是系统层面做路由——简单问题走通用模型复杂问题走推理模型而不是单一模型通吃。6.2 拿一个新模型时我建议你先问自己五个问题你新拿到一个模型或者看到一篇新的模型发布公告不要急着跑benchmark。以下五个问题问完你对它的认知就已经超过80%的围观群众了它的总参数量和激活参数量分别是多少判断结构轴稠密还是MoE、规模多大它是否有专门的思维链/强化学习训练阶段判断能力轴通用还是推理它原生支持哪些输入和输出类型判断模态轴纯文本、视觉、音频、视频官方文档里部署时的显存推荐是多少倒推模型的真实部署成本它是从头训练的还是从某个基座微调/蒸馏来的判断创新含量蒸馏模型和基座模型差距很大6.3 一个我自己的踩坑经历最后讲一个真实踩过的坑。之前接了一个项目客户要求模型能读合同截图并给出风险提示。我当时图省事直接选了一个很火的全模态模型因为它宣传图片视频音频全能我心想既然图片能读那合同扫描件肯定没问题。结果一到现场就翻车了。合同图片里大量密集的小字号条款文字普通多模态模型的视觉编码器根本认不全经常漏字、错字给出的风险提示自然也不可靠。后来我换了个思路先用专门的OCR模型把合同图片转成结构化文本再用一个纯文本的通用模型做条款分析。效果立竿见影错误率直接降了一个数量级。这个案例完美说明了三维拆解法的重要性。我当时只盯着模态轴看觉得支持图片输入就够了却忽略了一个事实多模态支持的是看图不等于识文。复杂场景里单模态的专业工具往往比多模态的通才更可靠。这也是我现在给所有团队的建议选型的时候不要被全能两个字冲昏头脑先搞清楚三个轴各自的需求再把每个轴用最合适的方案填上最后组合起来。模型选型不是选一个最贵的而是选一个最匹配的。