模型架构族谱、Decoder-only、Embedding 与 MoE 底层图谱

从 encoder、decoder、encoder-decoder、decoder-only、Embedding 模型、MoE 到多模态架构：理解不同模型形态为什么适合不同任务

阅读定位: 这一页放在 Transformer 之后、训练与部署之前。它不重复解释 Attention 的细节，也不展开权重文件、checkpoint 和格式转换；这些继续看参数 / 权重 / Checkpoint。本页把现代 AI 模型的主要架构分支放在同一张地图里，帮助你判断“为什么聊天模型、Embedding 模型、翻译模型、MoE 模型和多模态模型不是同一种东西”。

一、从 Transformer 到模型家族

Transformer
注意力 + MLP

→

Encoder
理解 / 表示

→

Decoder
逐 token 生成

→

Decoder-only LLM
Chat / Code

→

MoE / 多模态
规模与模态扩展

→

应用选型
RAG / Agent / Copilot

架构	核心直觉	典型任务	主要限制
Encoder-only	把输入整体读完，产出表示	分类、检索、语义匹配、Embedding	不擅长自由长文本生成
Decoder-only	从左到右逐 token 续写	聊天、写作、代码、Agent 指令生成	事实可靠性、工具执行和长链路控制要靠系统补
Encoder-decoder	先理解输入，再生成输出	翻译、摘要、结构化转换	通用开放对话生态不如 decoder-only 主流
Embedding / Bi-encoder	把文本或对象压成可比较向量	向量检索、聚类、推荐、RAG 召回	相似不等于正确，需要 rerank 和答案评测
MoE	每个 token 只激活部分专家	大规模语言模型、成本敏感的大模型服务	路由、负载均衡、部署和稳定性更复杂
多模态架构	把图像、音频、文档等接入统一表示或生成链路	视觉问答、文档理解、语音助手、视频理解	输入治理、模态对齐和审计更难

二、为什么 Decoder-only 成为 LLM 主流

训练目标简单统一

next token prediction 可以把网页、书籍、代码、对话和工具轨迹都统一成“给定前文预测后文”的训练问题，规模化更直接。

生成能力天然匹配产品

聊天、写作、代码、工具调用参数和计划文本，本质上都需要逐步生成输出。decoder-only 很容易统一承载这些形态。

上下文即接口

Prompt、历史、RAG 证据、工具结果都能放进同一个上下文窗口，应用工程可以用“组装上下文”驱动模型行为。

代价也很清楚

decoder-only 的优势是统一，代价也是统一：它把很多任务都变成续写问题。事实校验、动作执行、结构化约束、长程记忆、权限和审计，都需要外部系统来补。

三、Embedding 模型不是小号聊天模型

对比	Embedding 模型	聊天 / 生成模型
输出	向量	文本、JSON、工具调用参数
优化目标	相似语义靠近，不相关语义拉远	按上下文生成高概率且有用的下一个 token
适合	召回、去重、聚类、语义匹配	回答、推理、改写、规划、工具调用
评测	召回率、MRR、nDCG、相似度排序	任务成功率、事实正确、格式合法、用户满意
常见误用	把语义相似当事实正确	让生成模型直接承担大规模检索

RAG 的架构分工

Embedding 模型负责“从大量材料里找可能相关的东西”，生成模型负责“在上下文中组织答案”。两者都可能错，所以 RAG 要同时评测召回、重排、上下文拼装、引用和最终回答。

四、MoE：参数很多，但每次不全用

基本直觉

MoE 把部分前馈层 / FFN换成多个专家，每个 token 通过路由器选择少数专家。总参数量可以很大，但单次激活参数较少。

为什么有吸引力

在相同推理计算预算下，MoE 有机会获得更大的模型容量；对训练和服务成本都很有吸引力。

为什么工程更难

专家路由、负载均衡、跨卡通信、缓存、批处理和尾延迟都更复杂。参数多不等于部署简单。

问题	MoE 中为什么突出	工程观察
专家负载不均	热门 token 或任务可能挤向少数专家	需要辅助 loss、容量限制和路由监控
通信开销	专家分布在不同设备上，token 要被分发和聚合	吞吐、P95 和多机网络会成为瓶颈
缓存与调度	不同 token 激活不同专家	batch 编排和显存布局比 dense 模型复杂
能力解释	专家未必对应人类可理解领域	不要把“专家”误解成清晰知识模块

五、读模型卡：架构指标怎么翻译成工程判断

模型报告里的参数量、上下文长度、激活参数、模态能力和量化版本，不是排行榜装饰，而是会直接影响部署、延迟、成本、RAG、Agent 和产品边界；如果要继续理解这些字段怎样落到权重张量、adapter、safetensors、GGUF 和量化文件，继续看模型参数、权重与文件格式。

模型卡字段	真正要问什么	工程含义	常见误读
总参数量	模型容量有多大？是否 dense 或 MoE？	影响存储、加载、显存、微调和部署复杂度	只看总参数，以为一定等于每次推理成本
激活参数	每个 token 实际用多少参数？	MoE 里更接近单次计算成本，但不覆盖通信和调度开销	以为激活参数小就一定便宜
上下文长度	长上下文质量是否经过评测？	影响 RAG、长文档、代码库和 Agent 任务，但也增加 KV Cache 成本	把最大窗口当成全窗口可靠理解
训练 / 后训练数据	模型在哪些语言、代码、领域和安全口径上被塑形？	影响能力边界、偏见、版权风险、业务适配和微调必要性	只看 benchmark，不看数据和评测污染风险
模型类型	是生成、Embedding、Rerank、视觉语言还是语音模型？	决定它适合召回、排序、回答、工具调用还是多模态理解	拿聊天模型替代检索，或拿 Embedding 模型判断事实
量化 / 部署格式	量化后质量、延迟、显存和硬件兼容怎样？	影响端侧、本地部署、吞吐和成本	只看能不能跑，不看质量回归和长尾任务退化

六、Dense、MoE、小模型和专用模型怎么取舍

选型对象	优势	代价	适合场景
大 Dense LLM	行为稳定、部署路径成熟、批处理和缓存相对简单	每次推理激活全部参数，成本和显存压力大	高质量通用生成、复杂推理、企业级稳定服务
MoE LLM	在较低激活计算下获得更大容量，可能有更好性价比	专家路由、负载均衡、通信、尾延迟和推理引擎要求更高	大规模服务、成本敏感但有平台能力的团队
小 / 中模型	便宜、低延迟、可私有化、可控性强	复杂任务、长上下文、跨领域泛化可能弱	分类、抽取、批处理、低风险生成、边缘部署
Embedding / Rerank 模型	专门优化检索和排序，成本可控	不能直接生成最终答案	RAG、搜索、推荐、相似案例、知识库召回
多模态专用模型	在 OCR、ASR、图像理解、文档布局等任务上更可控	需要工作流编排和中间结果治理	票据、合同、会议、图像审核、视频理解

选型不是模型强弱题，而是系统匹配题

同一个产品里常常同时存在生成模型、Embedding 模型、Rerank 模型、小模型分类器和规则系统。架构选型的目标不是“找一个万能模型”，而是把不同模型放在最适合的位置，并用路由、评测和观测证明这个组合值得。

七、多模态模型的几种接法

接法	做法	适合	风险
视觉 / 音频编码器 + LLM	先把图像或音频编码成向量，再接入语言模型	图像问答、语音理解、文档辅助问答	模态对齐和细节保真不足
统一 token 化	把不同模态都转成 token 序列	统一生成、跨模态推理	序列很长，成本和训练难度高
工具式多模态	OCR、ASR、视觉检测先处理，再交给 LLM	企业文档、票据、会议、审计	流程复杂，但可追踪性更强
端到端多模态大模型	直接输入图像、语音、文档或视频	原型、交互、开放视觉语言任务	结构化控制、引用和回放较难

选型关键

高风险业务里，多模态架构不一定越端到端越好。OCR / ASR / layout / 检索这些中间资产虽然麻烦，却能带来可回放、可校验和可审计。

八、架构选型表

你要做的事	优先考虑	不要误用	继续下钻
企业知识库问答	Embedding + RAG + 生成模型	只换更大聊天模型，不治理检索	Embedding / 向量检索、RAG
通用聊天助手	decoder-only LLM + Prompt + 安全策略	把聊天助手当万能业务系统	Prompt / 上下文、AI 产品 UX
代码助手 / Agent	强生成模型 + 工具协议 + 测试验证	只看模型榜单，不接仓库和测试	AI 编程 Agent、Tool Calling
私有化大模型服务	Dense 或 MoE 结合硬件、延迟和成本评估	只看参数量，不看激活参数和推理引擎	开源部署、模型服务 / 网关
文档 / 图像 / 语音系统	多模态模型 + 解析工具 + 工作流审计	直接把所有文件扔给模型	多模态工程

架构选型证据包

架构不是“喜欢哪个模型”的口味题，而是要留下可复盘的选择依据，证明为什么这个任务该用 dense、MoE、Embedding、Rerank、小模型或多模态链路。

证据节点	必须记录字段	用来判断什么
model_family_decision	model_family、dense_or_moe、active_parameters、context_length、modality_support	模型形态是否匹配任务、成本和上下文需求
capability_fit	task_type、eval_slice、baseline_model、win_loss_result、failure_mode	架构收益是否来自真实任务，而不是榜单平均分
serving_fit	engine_version、gpu_type、batch_policy、p95_latency、cost_per_request	架构能否在生产延迟和成本下稳定服务
rollback_plan	release_gate_id、fallback_model、routing_rule_version、rollback_trigger	上线后质量或成本异常时能否回退

九、常见误区

误区：参数越多越强

参数量要和训练数据、架构、后训练、上下文、推理计算、评测任务一起看。MoE 的总参数和激活参数更要分开理解。

误区：Embedding 模型只是便宜版 LLM

Embedding 模型优化的是表示和相似度，不是生成答案。它在 RAG 里很关键，但不能替代生成和校验。

误区：MoE 一定更省钱

MoE 可能降低每 token 计算，但会增加路由、通信、部署和调度复杂度。生产成本要看端到端系统。

误区：多模态就是模型多支持几个输入

多模态系统的难点通常在输入保真、结构恢复、跨模态引用、回放审计和工作流，而不只是模型接口。

十、回到 AI 主干

AI 全景 → 神经网络 / 深度学习 → Token / Attention / Transformer → 参数 / 权重 → 训练 / 推理 / Scaling → 模型服务 / 网关 → 开源部署 → 成本 / 性能 → 多模态工程

这张图在主干里的位置

Transformer 页解释结构细节，这一页解释结构分叉和架构选型；后面再进入训练 / 推理 / Scaling、开源部署和多模态工程，就能更清楚每类模型为什么有不同成本和边界。