MoE on KnightLi的博客

2023-2026 大模型架构演进全复盘：分词器、位置编码、注意力机制、MoE、归一化与激活函数

Sun, 17 May 2026 08:53:29 +0800

2023 到 2026 年，大模型架构看起来变化很多：分词器变大，位置编码换成 RoPE，注意力机制从 MHA 走向 GQA、滑动窗口和 MLA，MoE 重新成为主流，归一化和激活函数也从传统写法变成 RMSNorm、SwiGLU 这类组合。

但如果用一句话概括，这几年的主线并不是“Transformer 被推翻了”，而是：在 Transformer 主体不变的前提下，围绕更长上下文、更低推理成本、更高训练效率和更强多语言能力做工程优化。

先理解一张大图

大模型可以先粗略拆成几层：

分词器：把文字切成模型能理解的 token。
位置编码：告诉模型每个 token 在句子里的位置。
注意力机制：决定每个 token 要看哪些上下文。
前馈网络：对每个位置做更复杂的非线性变换。
归一化：让训练过程更稳定。
激活函数：决定网络如何表达非线性关系。
MoE：把一部分前馈网络拆成多个专家，每次只调用少数几个。

2023-2026 年的演进，基本就是这些部件轮流被优化。

分词器：从“能切词”到“更省 token”

分词器的任务，是把自然语言变成 token 序列。模型看到的不是“你好世界”四个字，而是一串 token ID。

早期模型的分词器常常对英文更友好，对中文、代码、多语言文本不够省 token。同样一段中文或代码，如果被切得很碎，就会占用更多上下文窗口，也会增加训练和推理成本。

这几年一个明显趋势是词表变大、多语言支持变强。Llama 3 使用 128K token 词表，Meta 明确提到这样可以更高效地编码语言，提高模型表现。Qwen、DeepSeek 等模型也很重视中文、代码和多语言场景下的 token 效率。

零基础可以这样理解：分词器越合适，同样一句话越不容易被切得支离破碎，模型能在同样上下文长度里装下更多有效信息。

位置编码：RoPE 成为主流

语言是有顺序的。“狗咬人”和“人咬狗”词差不多，但位置不同，意思完全不一样。位置编码就是把顺序信息注入模型。

早期 Transformer 使用绝对位置编码，位置 1、位置 2、位置 3 各有自己的向量。后来大模型更常用 RoPE，也就是 Rotary Positional Embedding。RoPE 的特点是把位置信息融合进注意力计算中，对长上下文扩展更友好。

从 Llama 系列到很多开源模型，RoPE 已经成为事实标准之一。后来为了支持更长上下文，模型还会调整 RoPE 的 base frequency、做 RoPE scaling，或者配合滑动窗口、分块注意力等方案。

简单说，RoPE 不是让模型“突然变聪明”，而是让模型在更长文本里更好地理解相对位置关系。

注意力机制：从 MHA 到 GQA、滑动窗口和 MLA

注意力机制是 Transformer 的核心。它让每个 token 可以根据当前任务，去关注上下文里最相关的 token。

最经典的是 MHA，也就是 Multi-Head Attention。它会有多个注意力头，每个头学习不同的关注方式。问题是，模型越大、上下文越长，KV cache 占用越高，推理成本也越高。

所以 2023 之后，注意力机制的主要优化方向是降低推理成本。

GQA，也就是 Grouped-Query Attention，是非常重要的一步。它让多个 query head 共享较少的 key/value head，从而降低 KV cache 压力。Meta 在 Llama 3 中明确采用了 GQA，以提高推理效率。

Mistral 7B 代表了另一个方向：滑动窗口注意力。它不让每个 token 都看完整历史，而是主要看附近窗口里的上下文，从而降低长序列计算压力。对于很多任务来说，局部上下文已经足够有用。

DeepSeek-V2/V3 则把注意力优化推到更激进的方向：MLA，也就是 Multi-head Latent Attention。它的重点是压缩 KV cache，把推理时的显存压力降下来。DeepSeek-V3 技术报告把 MLA 和 DeepSeekMoE 列为架构核心。

可以把这几种方法放在一起理解：

MHA：经典做法，效果好但成本高。
GQA：牺牲很少表达能力，明显降低 KV cache 成本。
滑动窗口注意力：减少长上下文中全局注意力的计算压力。
MLA：进一步压缩注意力缓存，面向高效推理。

MoE：让模型“参数很多，但每次只用一部分”

MoE 是 Mixture of Experts，中文常叫混合专家模型。

普通 Dense 模型会在每个 token 上激活全部参数。MoE 的思路是：模型里放很多专家，但每个 token 只路由到少数几个专家。这样总参数量可以很大，但单次推理激活的参数量相对小。

2023 年底的 Mixtral 8x7B 是 MoE 重新进入大众视野的重要节点。Mistral 的论文说明，Mixtral 8x7B 基本沿用 Mistral 7B 架构，但把每层前馈网络换成 8 个专家，并通过稀疏路由选择部分专家参与计算。

后来的 DeepSeek-V3 进一步把 MoE 做成核心路线。它总参数量很大，但每个 token 只激活其中一部分参数，通过 DeepSeekMoE 降低训练和推理成本。Qwen3 等模型也同时提供 Dense 和 MoE 路线，说明 MoE 已经从“研究技巧”变成了主流工程选项。

零基础可以这样理解：Dense 模型像一个全员开会的公司，任何问题都让所有人参与；MoE 像把公司分成多个专家小组，每次只叫最相关的小组来处理。

MoE 的难点也很明显：

路由器要学会把 token 分给合适专家。
专家负载要均衡，不能所有 token 都挤到少数专家。
分布式训练和推理会更复杂。
总参数大，不等于每次推理都便宜，部署仍然有门槛。

归一化：RMSNorm 成为常见选择

归一化的作用，是让神经网络中间层的数值分布更稳定。训练大模型时，如果数值波动太大，训练会更难收敛，也更容易不稳定。

早期 Transformer 常用 LayerNorm。后来很多 Llama 系模型改用 RMSNorm。RMSNorm 相比 LayerNorm 更简化，不计算均值，只关注均方根尺度，计算更轻，也足够稳定。

对普通读者来说，不需要记公式，只要知道：RMSNorm 是一种更轻量的稳定器。它不能单独决定模型能力，但会影响训练稳定性、速度和工程实现。

激活函数：从 ReLU/GELU 到 SwiGLU

激活函数负责给神经网络加入非线性能力。没有激活函数，多层网络很容易退化成线性变换。

早期很多 Transformer 使用 GELU。Llama 系列、Mistral、Qwen、DeepSeek 等现代大模型中，更常见的是 SwiGLU 或类似 GLU 变体。SwiGLU 通常出现在前馈网络里，通过“门控”方式控制信息流。

可以粗略理解为：普通激活函数像一个固定开关，而 SwiGLU 更像一个可学习的阀门。它不只是决定信息过不过，还能学习哪些信息更应该被放大。

SwiGLU 的代价是前馈层结构稍复杂，参数和计算形式也不同，但在大模型实践中，它已经成为高性能架构的常见组件。

2023-2026 的整体趋势

如果按时间线看，可以这样总结：

2023：Llama、Mistral 7B、Mixtral 等开源模型让 RoPE、RMSNorm、SwiGLU、GQA、滑动窗口、MoE 等组合走向普及。
2024：Llama 3、Qwen2.5、DeepSeek-V2/V3 等模型继续扩大词表、改进长上下文、强化推理效率，MoE 和高效注意力成为重点。
2025：DeepSeek-V3/R1 引发更多人关注 MLA、DeepSeekMoE、FP8、MTP 等训练和推理效率设计，架构优化和系统工程深度绑定。
2026：趋势仍然是高效化和工程化：Dense 模型继续追求稳定通用，MoE 模型负责扩大容量，高效注意力负责降低长上下文成本。

这几年最重要的变化，不是某个单点组件取代了 Transformer，而是大家越来越清楚：只堆参数不够，架构、数据、训练系统、推理服务必须一起优化。

新手应该怎么学

如果你是零基础，不建议一开始就硬啃所有论文。更好的顺序是：

先理解 Transformer 的基本结构：token、embedding、attention、FFN。
再理解 RoPE、RMSNorm、SwiGLU 为什么会成为常见组合。
接着看 GQA 和 KV cache，理解推理为什么会吃显存。
再学 MoE，重点理解“总参数”和“激活参数”的区别。
最后看 DeepSeek-V3、Mixtral、Llama 3 这类模型报告，把组件放回真实模型里理解。

不要把这些名词当成孤立知识点。它们大多是在回答同一个问题：如何让模型更强，同时还能训练得起、部署得动、推理得快。

总结

2023-2026 年的大模型架构演进，可以看成 Transformer 的工程成熟期。分词器负责减少 token 浪费，RoPE 负责更好表达位置，GQA、滑动窗口和 MLA 负责降低注意力成本，MoE 负责扩大容量但控制激活计算，RMSNorm 和 SwiGLU 则让训练和表达更稳定高效。

对新手来说，最重要的不是背名词，而是抓住主线：现代大模型架构的每一次改动，几乎都在围绕成本、效率、上下文长度和可扩展性做权衡。

参考链接：

本地部署 DeepSeek V4：Pro、Flash 与 Base 版本显存占用估算表

Fri, 01 May 2026 11:55:25 +0800

DeepSeek V4 和 Gemma 4 的本地部署不是一个量级。 Gemma 4 的 26B、31B 还能讨论 24GB、32GB 显卡怎么选量化版；DeepSeek V4 则是超大 MoE 模型，真正完整本地部署时，显存需求会直接进入多卡工作站或服务器级别。

官方发布的 DeepSeek V4 Preview 主要包含两个推理版本：

DeepSeek-V4-Pro：1.6T total / 49B active params
DeepSeek-V4-Flash：284B total / 13B active params

Hugging Face 官方 collection 里还包含两个 Base 版本：

DeepSeek-V4-Pro-Base
DeepSeek-V4-Flash-Base

这篇只讨论完整加载模型权重时的大致显存门槛。 MoE 的 active params 主要影响每个 token 的计算量，不等于只需要加载这部分参数。如果没有专家按需加载、CPU/NVMe offload、分布式推理或专门运行时优化，显存仍然要按完整权重来估。

先看结论

显存规模	能比较现实地尝试什么	不建议期待什么
24GB	不能完整跑 DeepSeek V4；只能跑小型蒸馏模型或 API	V4-Flash / V4-Pro 完整本地加载
48GB	仍不适合完整加载；可做小模型或远程 API 客户端	V4-Flash Q4 稳定运行
80GB	理论上可尝试 V4-Flash Q2/Q3 或强 offload	V4-Pro
128GB	V4-Flash Q4 比较现实；Q5/Q6 仍紧	V4-Pro Q4
192GB	V4-Flash FP8/Q6 更从容；Pro Q2 勉强进入讨论	V4-Pro Q4
256GB	V4-Flash FP8 比较稳；Pro Q2/Q3 可实验	V4-Pro Q5 以上
512GB	V4-Pro Q4 开始进入可讨论范围	V4-Pro FP8
1TB+	V4-Pro FP8、Pro-Base 低位宽更现实	单机低成本部署
2TB+	Pro-Base FP8 级别	普通工作站部署

如果你的目标是个人电脑本地运行，DeepSeek V4 并不是合适对象。更现实的路线是：

用 DeepSeek 官方 API 或兼容服务；
等社区稳定的 GGUF/EXL2/MLX 量化和推理支持；
使用更小的 DeepSeek 蒸馏模型；
或者把本地模型换成 Qwen、Gemma、Llama 等 7B 到 70B 级别模型。

官方权重体积

以下是 Hugging Face 官方仓库的 model.safetensors.index.json 中统计到的权重总量。它反映的是当前公开权重文件大小，不等于长上下文运行时的完整显存占用。

模型	参数规模	官方权重体积	说明
`DeepSeek-V4-Flash`	284B total / 13B active	159.61GB	推理版，体积相对最小
`DeepSeek-V4-Pro`	1.6T total / 49B active	864.70GB	推理版，能力更强，体积巨大
`DeepSeek-V4-Flash-Base`	284B total	294.67GB	Base 版，更接近全量 FP8 权重体积
`DeepSeek-V4-Pro-Base`	1.6T total	1606.03GB	Base 版，约 1.6TB 级别

可以看到，即使是最小的 V4-Flash，官方权重也已经接近 160GB。这就是为什么它不能按“13B active params”理解成 13B 小模型。

DeepSeek V4 Flash 显存估算

V4-Flash 是 DeepSeek V4 里最适合本地尝试的一档。但“最适合”只是相对 Pro 而言，它仍然不是消费级单卡模型。

下面按官方 159.61GB 权重体积做折算。其中 Q4/Q3/Q2 是按位宽估算，不代表当前已经有稳定可用的官方 GGUF 版本。

版本/量化	估算权重体积	最低显存	更稳妥显存	适合场景
`FP8 / 官方权重`	159.61GB	192GB	256GB	多卡服务器、推理服务
`Q6`	120GB	160GB	192GB	质量优先的量化尝试
`Q5`	100GB	128GB	160GB	质量和体积折中
`Q4`	80GB	96GB	128GB	Flash 本地化较现实的起点
`Q3`	60GB	80GB	96GB	大显存单卡或多卡实验
`Q2`	40GB	48GB	64GB	极限低位宽实验，质量风险明显

如果未来社区出现成熟的 V4-Flash Q4，它大概率也不是 24GB 显卡的模型。更现实的硬件起点是 96GB 到 128GB 级别的总显存，或者依赖 CPU 内存/offload 换速度。

DeepSeek V4 Pro 显存估算

V4-Pro 是旗舰推理版，官方权重体积约 864.70GB。即使做 4-bit 量化，完整权重也仍然是数百 GB 级别。

版本/量化	估算权重体积	最低显存	更稳妥显存	适合场景
`FP8 / 官方权重`	864.70GB	1TB	1.2TB+	多机多卡推理服务
`Q6`	648GB	768GB	1TB	高质量量化服务
`Q5`	540GB	640GB	768GB	高质量与成本折中
`Q4`	432GB	512GB	640GB	Pro 本地化较现实的最低质量线
`Q3`	324GB	384GB	512GB	低位宽实验
`Q2`	216GB	256GB	320GB	极限实验，质量和稳定性风险高

对个人用户来说，V4-Pro 更适合通过 API 使用。如果目标是完整本地部署，至少要把它当成多卡服务器模型，而不是 4090、5090、RTX PRO 单卡模型。

DeepSeek V4 Flash-Base 显存估算

Base 版通常用于研究、微调或继续训练，不是普通聊天部署的首选。 V4-Flash-Base 官方权重体积约 294.67GB。

版本/量化	估算权重体积	最低显存	更稳妥显存	适合场景
`FP8 / 官方权重`	294.67GB	384GB	512GB	研究、训练前处理、评测
`Q6`	221GB	256GB	320GB	高质量量化研究
`Q5`	184GB	224GB	256GB	质量和体积折中
`Q4`	147GB	192GB	224GB	Base 版低成本实验
`Q3`	111GB	128GB	160GB	低位宽实验
`Q2`	74GB	96GB	128GB	极限实验

如果只是要使用 DeepSeek V4 能力，不建议从 Base 版开始。 Base 版的部署和调优成本更高，普通应用更适合推理版或 API。

DeepSeek V4 Pro-Base 显存估算

V4-Pro-Base 是最重的一档，官方权重体积约 1606.03GB。这已经是 1.6TB 级别的模型文件。

版本/量化	估算权重体积	最低显存	更稳妥显存	适合场景
`FP8 / 官方权重`	1606.03GB	2TB	2.4TB+	大规模研究集群
`Q6`	1205GB	1.5TB	2TB	高质量量化研究
`Q5`	1004GB	1.2TB	1.5TB	研究与评测
`Q4`	803GB	1TB	1.2TB	低位宽研究
`Q3`	602GB	768GB	1TB	极限低位宽研究
`Q2`	402GB	512GB	640GB	极限实验

这类模型不适合被放进“家用显卡能不能跑”的框架里讨论。哪怕是 Q4，也已经超过绝大多数单机工作站的舒适范围。

为什么不能只看 active params

DeepSeek V4 是 MoE 模型。 MoE 的特点是每个 token 只激活一部分专家，因此计算量会明显低于总参数量。但这不等于显存只需要放 active params。

完整本地推理通常还要考虑：

所有专家权重是否需要常驻 GPU；
是否支持按需专家加载；
CPU 内存与 GPU 显存之间的数据搬运成本；
NVMe offload 的延迟；
KV cache 在长上下文下的增长；
1M context 场景下的额外运行时开销；
多机多卡通信成本。

所以，49B active 的 V4-Pro 不能当成 49B 模型来部署。 13B active 的 V4-Flash 也不能当成 13B 小模型来部署。

怎么选

如果你只是普通个人用户：

不建议完整本地部署 DeepSeek V4。
需要 DeepSeek V4 能力时，优先用官方 API。
需要本地私有化时，优先看是否有成熟推理服务商或内部多卡服务器。
只有 24GB 到 48GB 显存时，转向 7B、14B、32B、70B 级别量化模型更实际。

如果你有 128GB 到 256GB 总显存：

可以关注 V4-Flash Q4/Q5 是否有稳定社区实现。
不建议把 V4-Pro 当成主力本地模型。

如果你有 512GB 以上总显存：

V4-Pro Q4 才开始进入工程验证范围。
仍然要关注推理框架、专家调度、KV cache、吞吐和并发。

DeepSeek V4 的本地部署重点不是“下载哪个量化文件”，而是“有没有足够的系统级推理能力”。它更接近一个服务器模型，而不是普通桌面模型。