现在的大模型怎么分类：别把 MoE、推理模型和多模态混在一起

杨杨杨大侠
11 阅读11分钟

最近我在理解模型内部结构时，经常看到几个词：Dense、MoE、推理模型、编程模型、多模态模型、开放权重模型。

刚开始很容易把它们当成同一层的分类，例如认为一个模型要么是 MoE，要么是推理模型，要么是多模态模型。

其实不是。

这些词分别在回答不同的问题。一个模型通常同时属于很多类别：

image.png

1. 按内部架构分类

1.1 Dense：稠密模型

Dense 模型处理每个 Token 时，大部分模型层和参数都会参与计算。

image.png

它可以理解成一个整体大脑。Java、Python、产品知识和数学能力都分布在整个模型的参数中，没有清晰分开的“Java 小模型”和“Python 小模型”。

Dense 的特点大概是：

  • 结构相对直接。
  • 每个 Token 会使用较多参数参与计算。
  • 行为通常比较稳定。
  • 模型规模增大后，推理成本也会明显增加。

1.2 MoE：混合专家模型

MoE 全称 Mixture of Experts。它会在部分网络层中放置多个 Expert，再由内部 Router 为当前 Token 选择少数几个参与计算。

image.png

MoE 的核心价值是：模型可以拥有很大的总容量，但处理单个 Token 时只激活其中一部分参数。

例如 Qwen3 同时发布了 Dense 和 MoE 型号。其中 Qwen3-30B-A3B 有 30B 总参数、约 3B 激活参数；Qwen3-235B-A22B 有 235B 总参数、约 22B 激活参数。Qwen3 官方说明

DeepSeek-V3 也是 MoE，官方仓库给出的信息是 671B 主模型参数、每个 Token 激活约 37B 参数。DeepSeek-V3 官方仓库

这里要注意：

Expert 是模型内部的计算子网络，不是一个能够独立聊天、独立保存上下文的小模型。

MoE 也不等于多 Agent。MoE Router 选择的是模型内部参数，多 Agent 调度选择的是外部 Agent 实例和完整模型调用。

image.png

1.3 混合架构

还有一些模型会把 Transformer Attention 与状态空间、递归记忆、局部窗口、稀疏 Attention 等结构组合。

主要目标通常是：

  • 降低长上下文计算量。
  • 提高推理速度。
  • 减少显存和 KV Cache 压力。
  • 改善流式和超长序列处理。

因此，“是不是 Transformer”与“是不是 MoE”也不一定完全互斥。一个模型可以以 Transformer 为主体，同时使用 MoE 和其他长上下文优化。

2. 按基础模型结构分类

从输入输出方式看，Transformer 模型还常分成三种。

Encoder-only

主要擅长理解和表示输入，例如：

  • 文本分类。
  • 实体识别。
  • 语义检索。
  • Embedding。
输入文本 → 编码成语义表示

Decoder-only

根据已有 Token 持续预测后续 Token，目前多数聊天和生成式大模型属于这一类。

输入 + 已生成内容 → 下一个 Token → 继续生成

Encoder-Decoder

先编码输入，再由 Decoder 生成目标内容，常见于翻译、摘要和序列转换任务。

输入文本 → Encoder → 中间表示 → Decoder → 输出文本

这一分类描述的是基础网络组织方式；Dense／MoE 描述的是参数如何参与计算，两者仍然不是同一维度。

3. 按训练阶段分类

3.1 基础模型 Base Model

基础模型主要完成大规模预训练，核心任务通常是预测后续 Token。

它已经学到了语言、代码和知识模式，但不一定擅长：

  • 按用户指令做事。
  • 稳定输出固定格式。
  • 多轮对话。
  • 拒绝危险请求。
  • 正确使用工具。

基础模型更像一个拥有大量知识、但还没有接受岗位培训的人。

3.2 指令／聊天模型

在基础模型之上继续进行指令微调和偏好训练，使模型学会：

  • 识别系统、开发者和用户指令。
  • 根据要求回答问题。
  • 保持对话风格。
  • 输出代码、表格或 JSON。
  • 遵循安全和行为约束。

我们日常通过聊天客户端使用的模型，大部分已经经过这一阶段。

3.3 推理模型

推理模型针对数学、代码、规划、科学问题和复杂决策进行了进一步训练，使它能够在最终回答前使用更多中间计算。

用户问题
   ↓
理解目标和约束
   ↓
进行更多推理与检查
   ↓
生成最终回答

推理模型可能是 Dense，也可能是 MoE；可能只支持文本，也可能同时支持图片。推理描述的是训练和运行能力，不是唯一的底层架构。

3.4 领域模型

领域模型会针对某类数据和任务继续训练，例如：

  • 编程。
  • 数学。
  • 医疗。
  • 法律。
  • 金融。
  • 安全分析。

领域模型不一定从头训练，也可能由通用模型通过继续预训练、微调、蒸馏或强化学习得到。

4. 按主要能力分类

4.1 通用语言模型

面向写作、问答、知识解释、总结、翻译和一般推理。

它的覆盖面广，但不一定在每个垂直任务上都最好。

4.2 编程模型

针对代码进行更多训练、后训练或评测，常见能力包括：

  • 生成和修改代码。
  • 理解调用链。
  • 修复 Bug。
  • 执行终端和测试。
  • 完成仓库级任务。

“编程模型”不等于内部存在 Java、Python、Go 等多个完整小模型。不同语言通常表现为模型内部不同特征的激活组合。

4.3 Agent／工具调用模型

这类模型更擅长输出结构化工具调用，并根据工具结果决定下一步。

模型判断需要证据
      ↓
输出工具名和参数
      ↓
Harness 校验并执行
      ↓
结果返回模型
      ↓
模型继续判断或给出结论

但它仍然只是模型：

支持工具调用的模型不等于完整 Agent，完整闭环还需要 Harness 管理上下文、权限、工具执行、重试和停止条件。

4.4 多模态模型

多模态模型可以理解或生成多种数据：

文本
图片
音频
视频
代码
  ↓
模型内部的统一或关联表示

例如 Google 将 Gemini 3.5 Flash 描述为原生多模态推理模型，可接收文本、图片、音频和视频。Google DeepMind 模型卡

“多模态”回答的是模型能处理什么数据，不表示它一定是 Dense 或 MoE。

4.5 专用模型

有些模型不负责聊天，而是完成一项明确任务：

类型主要作用
Embedding把文本、图片等内容转换成向量
Reranker对检索结果重新排序
ASR把语音转换成文字
TTS把文字转换成语音
图片生成根据文本或图片生成图片
视频生成根据文本、图片或视频生成视频
Moderation对内容进行安全分类

当前模型平台通常会把通用模型、图片、实时语音、转录和专业模型分开提供。OpenAI 模型目录

5. 按模态分类

如果只看输入输出，可以画成下面这样：

文本模型
文本 → 文本

视觉理解模型
图片 + 文本 → 文本

语音模型
音频 ↔ 文本／音频

图片生成模型
文本／图片 → 图片

视频生成模型
文本／图片／视频 → 视频

全模态模型
多种输入 → 多种输出

同样是多模态，有的模型只能“看图并回答文字”，有的还能原生生成图片或音频，不能只看到“多模态”三个字就认为能力完全相同。

6. 按部署方式分类

6.1 闭源 API 模型

自己的应用 → 厂商 API → 模型服务

特点：

  • 不需要自己准备大规模推理资源。
  • 模型权重不可见。
  • 厂商可以更新模型和服务配置。
  • 具体内部架构不一定公开。

6.2 开放权重模型

模型权重可以下载，并部署到自己的设备或服务器：

自己的应用 → 推理框架 → 本地模型权重

可以进行量化、微调和私有部署，但需要自己解决：

  • 显存和内存。
  • 推理框架适配。
  • 并发和性能。
  • 模型许可证。
  • 安全和版本管理。

“开放权重”也不必然等于训练数据、训练代码和全部实现细节都完全开源。

6.3 端侧小模型

运行在手机、笔记本、浏览器或嵌入式设备上。

优势是：

  • 延迟低。
  • 可以离线使用。
  • 数据可以不离开设备。
  • 单次推理成本更容易控制。

限制通常是模型容量、上下文和复杂推理能力不如大型云端模型。

7. 按产品档位分类

厂商还经常把同一模型家族分成不同档位：

旗舰模型 → 复杂推理、编程和高价值任务
平衡模型 → 质量、速度和成本折中
轻量模型 → 分类、提取和高并发任务
端侧模型 → 本地和低延迟场景

这属于产品和成本定位，不一定意味着底层采用完全不同的架构。

同一个任务也不应该默认选择最大的模型。简单分类、字段提取和固定格式转换，可以先使用小模型；跨系统排查、架构设计和高风险判断，再使用更强的推理模型。

8. 一个模型应该怎么描述

不要只说“这是一个 MoE 模型”，可以完整描述成：

内部架构：MoE
训练形态：指令 + 推理
主要能力：代码 + 工具调用
模态：文本 + 图片输入，文本输出
部署方式：开放权重
产品档位：中大型模型

这样才能知道它到底适合什么场景。

举几个组合示意：

模型架构训练／能力模态部署
Qwen3-32BDense指令、推理、通用与代码文本开放权重
Qwen3-235B-A22BMoE指令、推理、通用与代码文本开放权重
DeepSeek-V3MoE通用、代码、推理增强文本开放权重／API
Gemini 3.5 Flash厂商未在当前模型卡中完整披露推理、Agent、编程文本、图片、音频、视频输入API

这张表也说明了一个问题：厂商没有公开的架构信息，不应该根据模型表现自行猜测。

9. Harness 真正应该按什么选择模型

Harness 进行模型路由时，不应该只判断 Dense 还是 MoE，而应该维护一份模型能力目录：

model_id: example-model
architecture: moe
context_window: 200000
max_output_tokens: 32000
modalities:
  - text
  - image
capabilities:
  reasoning: true
  coding: true
  tool_calling: true
deployment: api
cost_tier: balanced
latency_tier: medium

然后根据任务选择：

image.png

例如 Java 开发常见任务可以这样路由：

任务更需要哪种模型
判断问题属于代码还是产品小型指令模型
生成普通 Java DTO轻量编程模型
排查跨模块调用链强编程／推理模型
根据截图排查前端问题多模态编程模型
在仓库中修改并测试支持工具调用的编程模型 + Harness
代码向量检索Embedding 模型，不是聊天模型

10. 几个容易混淆的概念

MoE 不等于多 Agent

MoE：模型内部参数路由
多 Agent：Harness 外部任务编排

推理模型不等于另一种固定架构

Dense 和 MoE 都可以经过推理训练。

多模态不等于一定能生成多种内容

能看图片，不一定能生成图片；能听音频，也不一定能直接输出音频。

激活参数不等于部署只需要加载这些参数

MoE 每次只激活部分参数，但部署时通常仍要考虑完整权重、KV Cache、运行框架和并发需求，不能直接用“激活参数量”估算机器内存。

编程模型不等于内部包含多个语言小模型

Java、Python、Go 等能力通常分布在共享参数和内部特征中。

11. 最后总结

我现在对模型分类的理解是：不要只给模型贴一个标签，而要先确定自己在问哪个维度。

image.png

一句话总结：

MoE 描述内部计算，推理和编程描述能力，多模态描述输入输出，开放权重描述部署方式；这些标签可以同时出现在同一个模型上。

avatar
文章
阅读
粉丝